Yesterday I created a docker container with
docker-compose up -d
(and docker-compose.yaml file). It created a wordpress site, a database, phpmyadmin, etc.)
I made some changes to the wordpress installation, content, etc. I then shut it down with:
docker-compose down -volumes
This morning I wanted to run this container again and run the docker-compose up -d command again and when I visited the url it showed a wordpress configuration wizard instead of the existing installation from yesterday. In hindsight, it makes sense. Not sure why I expected not to create a new container. I then deleted the install* file from wp-admin but it didn't help.
Are the changes from my yesterday's wp installation lost? Have I overwritten everything?
Generally, how can I re-start an existing container with docker/docker-compose
by using docker-compose down -volumes you deleting :
Stops containers and removes containers, networks, volumes, and images created by up
see this
you may use docker-compsoe start/stop instead to stop or start your running containers
The command
docker-compose down
will stop all your containers, delete all your containers and remove any networks defined in your docker compose file.
It does not remove your volumes, by the way (unless you additonally pass the -v flag to the command).
So your command
docker-compose down --volumes
will also remove any volumes.
If you want to persist your wordpress installation for development purpose but want to be able to remove and create containers during development you can mount volumes on your host machine. E.g. for your database data or also for your wordpress source code (if needed).
See also here: https://docs.docker.com/compose/wordpress/
Take a look at the docker compose file provided there and specifically take a look at the volume directives.
In the example the database files are mounted on your host machine so that they don't vanish if you remove the database container.
If you are already using volumes in your docker compose file than you can simply remove the --volumes flag from the docker-compose down command
You can recreate a service inside compose file with following command.
for example you have wordpress,mysql,nginx services inside compose file.
docker-compose -f docker-compose.yml up -f --build wordpress
this command recreate your container
Related
I'm hoping someone has some expertise with AWX running as a Docker container. We've switched on the Azure AD authentication and I'd like to hide the local login modal via CSS. It seems that the CSS files are generated on startup and any changes to app.xxxxxxxx.css in /var/lib/awx/public/static/css don't seem to have any effect, and are newly generated upon restart anyway. I was wondering if there was a source CSS file I could edit so I can make changes and keep them through a reboot. Any help would be appreciated.
Docker image: ansible/awx_web
AWX Version: 7.0.0.0
Here was my solution to this.
I copied the static folder from the awx_web container:
docker cp id:/var/lib/awx/public/static/ /somefolder/static/
This will copy all of the HTML/CSS/JS elements of the web application to a local folder so that you can edit the files and keep your changes through a reboot.
This particular issue required me edit the app.xxxxxxx.css file in /static/css/ and find the styling for "btn LoginModal-signInButton" and change the visibility to hidden.
The next step was to mount the locally copied static folder from earlier to the static folder inside the container. I navigated to the 'awxcompose' directory (in my case it was /var/awxcompose) and added the following line to the docker-compose.yml file under awx_web > volumes:
- "somefolder/static/:/var/lib/awx/public/static/:ro"
Then once I was ready to push my changes, I re-made the container using docker-compose:
docker-compose down && docker-compose up -d
And to make sure the containers remained in this state after a reboot, I added the following line to my crontab:
#reboot docker-compose -f /var/awxcompose/docker-compose.yml up -d
I am deploying a Docker image (Wordpress) on Elastic Beanstalk using a single container deployment.
My deployment zip file includes:
public folder containing a complete wordpress build
Dockerfile
.ebextensions/permissions.config
The standard Wordpress image creates a volume VOLUME /var/www/html and in my Dockerfile I do
COPY ./public /var/www/html
Now the problem is that I cannot upload media using Wordpress admin dashboard.
Unable to create directory wp-content/uploads/2019/02. Is its parent directory writable by the server?
I've tried to change the permissions on the uploads folder using the EB config in .ebextensions/permissions.config
container_commands:
91writable_dirs:
command: |
chmod -R 777 /var/app/current/public/wp-content/uploads
cwd: "/var/app/current"
I see from the logs that the docker image gets built before running chmod. I've seen on other SO posts that some run the script on /var/app/ondeck/, but that fails with the directory doesn't exist
Despite all the above, my question is actually how do I get to upload media to Wordpress with my current setup.
EDIT: When I attach a shell to the docker container and change the file permissions of wp-content/uploads in the VOLUME /var/www/html I am able to upload media. So how can this be made permanent on the VOLUME?
Whenever wordpress docker image is built and run, the docker ENTRYPOINT of the wordpress image is executed first. Hence your command to change the directory permissions is not getting executed.
This ENTRYPOINT is a bash script located in /usr/local/bin/docker-entrypoint.sh
If you want your command to be executed, you could add your command to this script and it will be called every time your container starts.
You could do it the following way -
Start your container and copy the contents of the existing
docker-entrypoint.sh
Create a new docker-entrypoint.sh outside the container and edit
that script to add your chmod command at appropriate location.
In your Dockerfile add a line to copy this new entrypoint to the
location /usr/local/bin/docker-entrypoint.sh
docker-compose.yml file:
web:
build: ./code
ports:
- "80:80"
volumes:
- ./mount:/var/www/html
dockerfile in ./code:
FROM wordpress
WORKDIR /var/www/html
RUN touch test.txt
This is a production environment I'm using to set up a simple WordPress blog (omitted other services in docker-compose.yml & Dockerfile for simplicity).
Here's what I'm doing:
Bind mounting host directory at container destination /var/www/html
Create test.txt file during build time
What's NOT working:
When I inspect /www/var/html on the container, I don't find my test.txt file
What I DO understand:
Bind mounting happens at run-time
In this particular case file gets created, but the when you mount the host directory, commands in Dockerfile get overridden
When you use volume mount, It works
What I DON'T understand:
What are the ways in which you can get your latest code into the container which is using a bind mount to persist data?
How can one create a script that can let me achieve this in runtime?
How else can I achieve this considering I HAVE to use a bind mount (AWS ECS persists data only when you use a host directory path for a volume)
Your data will be persisted at runtime. Everything stored in /var/www/html at runtime will be persisted in the host ./mount directory.
At build time, everything happens at docker layer inside the container image.
If you want to do things before anything you could create a script, ADDit to your image and use CMD or ENTRYPOINT to run the script when the container starts.
In summary
What are the ways in which you can get your latest code into the container which is using a bind mount to persist data?
You add your latest code to the image (i.e. git clone, COPY, ADD, or what suits you). A container shouldn't be mutable, so you keep your code versioned and you define persist folder (e.g. for uploads)
How can one create a script that can let me achieve this in runtime?
If you want to do it at runtime, you add your shell script to the image and then you run it. Although, this is not the best approach for this use case.
How else can I achieve this considering I HAVE to use a bind mount (AWS ECS persists data only when you use a host directory path for a volume)
IMHO, you should use your images as your build of your code. Your image should not be mutable and must reflect an instance in your code lifecycle. Define paths with data and those paths would be your mounts at host level.
I have a docker container with installed WP and I want to create a new custom theme for it, but I don't want to install wp on own machine. Can I develop a new theme only via Docker container?
UDP:
I solved my problem in this way:
1) in docker-composer.yml in a wordpress field need create a field
volumes:
- ./wordpress:/var/www/html
2) Create in your file system the directory wordpress and run docker-compose build and then docker-compose up. Files will be moved in your directory and you can work with them and see a result in localhost.
you can try to login into container (make sure it is running) using following command
#>docker exec -it <container-name-or-id> sh
After that you can edit and create themes inside this container.
I'm using docker to run a simple static web project, using the nginx official image. As a bower dependence I have a ui lib that is mine and is shared among two of my projects. To facilitate the development process I created a volume to my local machine to serve local files through the /html folder inside the nginx container. It works fine this way.
But, if I try to use bower link to create a link between a local copy of my ui lib and the bower dependence the nginx web server is not able to find the folder, since the link points to my local machine.
I'm running the docker vm in a Mac.
Did someone experienced something similar and have an idea about how to solve it?
Thanks,
I just run into this issue and found a way to solve it nicely.
The problem is that when you mount as a volume the whole /html folder the symlinks created by bower link are copied into your container but not the actual folders they are pointing at. When nginx tries to serve the file, it follows the symlink but now INSIDE the container, where the route is invalid.
To fix this, create another volume that maps the symlink directly. This way, docker-compose will follow the symlink BEFORE mounting into the container, therefore copying the actual folder contents. The nice thing about this is that in your local file system you still have the folder and the symlink working, so you can work as usually :)
Practical example:
My folder structure
/app
|--/bower_components
|--/packageA
|--/packageB -> symlink to /foo/bar/packageB
My compose file:
version: '2'
services:
nginx:
volumes:
- .:/foo
- ./bower_components/packageB:/foo/bower_components/packageB
...
Let me know if it worked, cheers!