I would like to deploy my instance of wordpress using docker compose.
I have docker-compose code:
version: '3.3'
services:
wordpress:
image: wordpress:latest
ports:
- "8000:80"
restart: always
volumes:
- ./data-docker/wordpress:/data
environment:
WORDPRESS_DB_HOST: host.docker.internal:3306
WORDPRESS_DB_USER: root
WORDPRESS_DB_PASSWORD:
WORDPRESS_DB_NAME: wordpress
I would like to have some "wordpress" folder contains data (images, etc) on my local machine to be able make a backup of current data. I tried to use ./data-docker/wordpress:/data but this folder is still empty.
Where are for example uploaded images stored? And how can I backup it?
I know that there is also mysql - it is backuped separately.
According to wordpress docker documentation the following should work:
...
volumes:
- ./data-docker/wordpress:/var/www/html
...
Related
There is a question that asks about volumes, mine is a bit different.
What I'm interested in is that when I use a simple docker-compose.yml file
version: '3'
services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: wordpress
MYSQL_USER: user
MYSQL_PASSWORD: password
app:
depends_on:
- db
image: wordpress:latest
ports:
- "8000:80"
restart: always
volumes:
- .:/var/www/html/
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: user
WORDPRESS_DB_PASSWORD: password
volumes:
db_data:
The default image somehow downloads the entire WordPress installation to my host. How does it do that?
I'm asking, because I have a custom Dockerfile in which I ADD the wp zip file, unzip it and put the contents to /var/www/html which is mapped in my docker-compose.yml file in the ../:/var/www/html (my docker-compose.yml file is in the project-root/.docker/ folder so I map the project root to the WP root).
When I tried with the official image the contents were copied to my host, so I'm clearly missing some crucial part that is in the official images. But which one?
So it turns out that you have to copy/download/install using wpcli the WP inside the entrypoint script, and native WP docker images are doing that. Either that or inside the CMD command.
It's the same with this question.
Once done there, all the files in the container will appear in the host as well.
I'm trying to build a docker based WordPress development environment and I want to be able to have a folder structure like this:
.
|
--wp-data
|
--wp-content
|
--plugins
|
--themes
where plugins and themes are also inside wp-content
this is my docker-compose file:
version: '3.3'
services:
db:
image: mysql:5.7
volumes:
- ./wp-data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: wordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- '8000:80'
restart: always
volumes:
- ./wp-content:/var/www/html/wp-content/
- ./themes:/var/www/html/wp-content/themes/
- ./plugins:/var/www/html/wp-content/plugins/
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
wp-data:
wp-content:
themes:
plugins:
the wp-data and w-content are created ok
but the nested themes and plugins arent
what im missing?
Regards
You are misusing volumes. In your docker-compose.yml you create bind mounts for each service - that means you mount a particular directory of the host into containers.
At the same time you are declaring a section volumes where explicitly declare volumes with the same names, but they are never used and created as empty directories.
Of you want to create and use volumes, you need to rewrite your docker-compose.yml in the following manner:
services:
...
db:
...
volumes:
- wp-data:/var/lib/mysql
...
wordpress:
volumes:
- wp-content:/var/www/html/wp-content/
- themes:/var/www/html/wp-content/themes/
- plugins:/var/www/html/wp-content/plugins/
volumes:
wp-data:
wp-content:
themes:
plugins:
This will enable volumes, but you still need a way to put data from host into them (like docker cp for example).
From the other hand, of you intended to use bind mounts, you need to completely remove ending volumes: section not to get confused.
I have a website which i want to containerised i tried following the steps mentioned on this link
i have my files copied to /var/www/html/example.com/src/ and also my docker-compose file looks like this :
version: '2'
services:
example_db:
image: mysql:5.7
environment:
MYSQL_ROOT_PASSWORD: ${WP_DB_USER_PASSWORD}
MYSQL_DATABASE: ${WP_DB_NAME}
volumes:
- /var/lib/mysql:/docker-entrypoint-initdb.d/example.sql
container_name: example_db
restart: always
example:
depends_on:
- example_db
image: wordpress:5.0.0-php5.6-apache # we're using the image with php7.1
environment:
WORDPRESS_DB_PASSWORD: ${WP_DB_USER_PASSWORD}
WORDPRESS_DB_NAME: ${WP_DB_NAME}
container_name: example
ports:
- "1512:80"
restart: always
links:
- example_db:mysql
volumes:
- ./src:/var/www/html/docker/example.com/src/
i have my wordpress file in /www/html/docker/example.com/src/ and the db backup inside /src/docker/example.com/data/docker-entrypoint-initdb.d/lbdocker.sql
every time i acces the website it goes to the WordPress setup guide.
this is old but the issue is related to the $table_prefix
Your backup table prefix is different than the destination.
Update your config and it will work.
Fix
I have all set in my local machine for virtual machine shared folders. I have following code in my Docker compose file for Wordpress service. but not sure how the volumes work here. Can you please explain?
version: '2'
services:
database:
image: mysql:5.6
volumes:
- ./mysql-data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: password
restart: unless-stopped
wordpress:
image: wordpress:4.9.6
ports:
- 49160:80
links:
- database:mysql
volumes:
- ./wordpress:/var/www/html/wp-content
environment:
WORDPRESS_DB_PASSWORD: password
restart: unless-stopped
phpmyadmin:
image: phpmyadmin/phpmyadmin
links:
- database:db
ports:
- 8080:80
Does the above volumes line of code mean, does it need to create a WordPress folder in my docker-compsose.yml file that I am currently running?
Or is it anyhow related to my shared folders in virtual machine?
Basically volumes are instruments for Docker so it can retain data. Docker containers are generally designed to be stateless, but if you need to retain state/information between runs, that's where volumes come in.
You can create an unnamed volume in the following way:
volumes:
- /var/www/html/wp-content
This will retain your wp-content folder in the internal volumes storage without a particular name.
A second way would be to give it a name, making it a named volume:
volumes:
- mywp:/var/www/html/wp-content
And the final type, which is also what you are doing, is called a Volume Bind. This basically binds/mounts the content of a folder on your host machine in the container. So if you change a file in either place, it will be saved on the other.
volumes:
- ./wordpress:/var/www/html/wp-content
In order to use your Volume Bind, you will need to create the folder "wordpress" in the folder where you're running the docker-compose.yaml (usually your root folder). Afterwards, when your installation changes within the container, it will also change on the bind and vice-versa.
EDIT: In your particular case the following should work:
version: '3.2'
services:
database:
image: mysql:5.6
volumes:
- ./mysql-data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: password
restart: unless-stopped
wordpress:
image: wordpress:4.9.6
ports:
- 49160:80
links:
- database:mysql
volumes:
- type: bind
source: ./wordpress
target: /var/www/html/wp-content
environment:
WORDPRESS_DB_PASSWORD: password
restart: unless-stopped
phpmyadmin:
image: phpmyadmin/phpmyadmin
links:
- database:db
ports:
- 8080:80
Adding a volume to your docker-compose.yml file will enable you to 'mount' content from your local file system into the running container.
So, about the following line here:
volumes:
- ./wordpress:/var/www/html/wp-content
This means that whatever's in your local wordpress directory will be placed in the /var/www/html/wp-content directory inside your container. This is useful because it allows you to develop themes and plugins locally and automatically inject them into the running container.
To avoid confusion, I'd recommend renaming wordpress to something else, so it's clear that you're mounting only your WordPress content, and not core files themselves.
I have a similar setup here, in case you need another reference:
https://github.com/alexmacarthur/wp-skateboard
I have a docker-compose.yml file like this
version: '2'
services:
wordpress:
image: wordpress
ports:
- 8080:80
environment:
WORDPRESS_DB_NAME: my_wp
WORDPRESS_DB_USER: my_user
WORDPRESS_DB_PASSWORD: my_pass
volumes:
- ./src:/var/www/html
mysql:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: my_pass
volumes:
- ./db:/etc/mysql
I can run my containsers using the command docker-compose up and it works fine, but shows the default wordpress site with empty db to setup. What I want is, I have a db dump file my_db.sql which I want to load into mariadb when its initializing. How can I do that? and where do I need to put my my_db.sql file to be picked by mariadb container?
You have 3 options:
Mount your .sql file to /docker-entrypoint-initdb.d/
version: '2'
services:
wordpress:
image: wordpress
ports:
- 8080:80
environment:
WORDPRESS_DB_NAME: my_wp
WORDPRESS_DB_USER: my_user
WORDPRESS_DB_PASSWORD: my_pass
volumes:
- ./src:/var/www/html
mysql:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: my_pass
volumes:
- ./db:/etc/mysql
- ./my_db.sql:/docker-entrypoint-initdb.d/my_db.sql
Use build directive in your docker-compose file and point to a dockerfile with following content:
FROM mysql
COPY my_db.sql /docker-entrypoint-initdb.d
Create a dummy container, Mount /my/own/datadir:/var/lib/mysql, then restore the database manually using the docker exec, then you can use the host directory when ever you want that db in a container.
Mount the folder with your sql files to /docker-entrypoint-initdb.d on the container in the volumes section of the db definitions. Any .sql (and .sql.gz) files will be automatically run in.
See the Initializing a fresh instance section of the docs for more info.