I need to reset a moodle docker to its initial state every 24 hours. This docker will be a running a demo site where users can login and carry out various setting changes and the site needs to reset itself every day. Does docker provide any such feature?
I searched for a docker reset command but it doesn't seem to be there yet.
Will such a process of removing and reinitiating docker container work?
docker rm -f $(docker ps -a -q)
docker volume rm $(docker volume ls -q)
docker-compose up -d
I should be able to do this programatically ofcourse, preferably using a shell script.
Yes you do not need to reset just recreate the container is enough but if you bind volumes with the host it will not work if there is anything that pick from persistent storage of the host in docker-compose up.
Write a bash script that will run every 1:00 AM or whatever time you want to create fresh container.
0 0 * * * create_container.sh
create_container.sh
#!/bin/bash
docker-compose rm -f
docker-compose up -d
or you can use your own script as well but if there is bind volumes the clear that files before creating the container.
rm -rf /path/to_host_shared_volume
docker rm -f $(docker ps -a -q)
.
.
.
As the behavour of -v is different it will create directory if not exist.
Or if you want to remove everything then you can use system-prune
#!/bin/bash
docker system prune -f -a --volumes
docker-compose up -d
Remove all unused containers, networks, images (both dangling and unreferenced), and volumes.
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all volumes not used by at least one container
- all images without at least one container associated to them
- all build cache
Related
I'm working on 2 projects that both use Docker, in separate directories.
In the 2nd project, for a new local build, the first command given (of a series of commands) is the following:
docker container stop $(docker container ls -a -q) && docker system prune -a -f --volumes
However, as a side effect, this kills the containers in the 1st project, also destroying the databases associated with it as well.
This is annoying because I have to constantly rebuild and re-seed the database in the 1st project.
How can I edit the first command such that it only effects the project in the current directory?
Note that this project is also using docker-compose, which I know is good at noting the current directory, so maybe we could make use of docker-compose instead.
The full list of commands given for a new local build are:
docker container stop $(docker container ls -a -q) && docker system prune -a -f --volumes
docker stack rm up
docker-compose -f docker-compose.local.yml build
docker stack deploy up --compose-file docker-compose.local.yml
Thank you very much in advance for any help.
-Michael
In my continuous delivery process I deploy every night a container with the last build of my application. But with each iteration the docker build cache is growing...
Here are the commands applied every night :
docker rm $(docker stop $(docker ps -a -q --filter ancestor=myApplication --format="{{.ID}}"))
docker rmi $(docker images -f "dangling=true" -q)
docker build -t myApplication . --rm
docker run -d -p 9090:8080 -v C:\localFolder:/usr/local/mountedFolder myApplication
when I check with docker system df, I see that the build cache is growing with every build. Is there a way to make sure the unused cache is deleted ?
The build cache is part of buildkit, and isn't visible as images or containers in docker. Buildkit itself talks directly to containerd, and only outputs the result to docker. You can prune the cache with:
docker builder prune
And there are flags to keep storage based on size and age. You can see more in the docker documentation: https://docs.docker.com/engine/reference/commandline/builder_prune/
I'm reading through the Docker documentation and I don't understand the difference between:
docker container prune
and
docker rm $(docker container ls -aq)
Note that in the link, the second command I've listed is docker rm $(docker ps -a -q), but there is no difference between that and what I've written. container ls is just the newer version of the ps command.
It seems that both of these commands remove all stopped containers. Is there more to it than that, or are these just synonyms?
I don't think there is substantial difference. This -a though means list all containers and as a result docker rm ... will also try to remove running containers. This gives the error that you see below:
Error response from daemon: You cannot remove a running container [...] Stop the container before attempting removal or force remove
example:
$ docker container run --rm -itd alpine:latest
0ec4d7459d35749ecc24cc5c6fd748f4254b0782f73f1ede76cf49b1fc53b2d4
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0ec4d7459d35 alpine:latest "/bin/sh" 4 seconds ago Up 1 second jovial_ritchie
$ docker rm $(docker container ls -aq)
Error response from daemon: You cannot remove a running container 0ec4d7459d35749ecc24cc5c6fd748f4254b0782f73f1ede76cf49b1fc53b2d4. Stop the container before attempting removal or force remove
$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
But... difference when --force, -f is used:
In this case, the commands do 2 different things:
docker rm -f ... Forces the removal of a running container (uses SIGKILL) which means that it will remove running containers.
$ docker rm -f $(docker container ls -aq)
0ec4d7459d35
docker container prune -f will remove all stopped containers without asking for confirmation (no [y/N] prompt will be printed).
$ docker container prune -f
Total reclaimed space: 0B
The effects of the two commands are indeed similar, but there are some nuances to consider:
docker container prune can be used with the --filter option.
docker container prune has a synchronous protection that blocks concurrent prune executions on the daemon.
docker container prune attempts to remove only the containers that are not running, instead of trying to delete all containers and relying on the daemon to throw an exception for those that are not stopped, therefore is quicker and does not generate unnecessary error logs in case someone is tracking the daemon logs.
docker container prune builds a report at the end of its execution, providing the reclaimed space. The report is added in daemon.EventsService and implicitly displayed on the screen.
docker container prune is shorter
In the end of this answer I have a question: Why would someone type 15 additional characters to get the same result or worse?
docker system prune -f : to remove all the stopped containers (docker do not touch the running containers)
docker system prune -a : to remove all the stopped containers (docker do not touch the running containers) + unused images
docker rm <container_id> : remove a specific container, it should be stopped before (docker stop <container_id>)
I use docker-compose and find following problem:
When I change my code and want to rebuild dockers I use
docker-compose stop
docker-compose build
And then I want to run system by:
docker-compose up
But no new version of code/containers are run but old ones. What to do?
You could use, docker-compose up --build or docker-compose up --build --force-recreate
I have a helper function to nuke everything so that our Continuous blah, cycle can be tested, erm... continuously. Basically it boils down to the following:
To clear containers:
docker rm -f $(docker ps -a -q)
To clear images:
docker rmi -f $(docker images -a -q)
To clear volumes:
docker volume rm $(docker volume ls -q)
To clear networks:
docker network rm $(docker network ls | tail -n+2 | awk '{if($2 !~ /bridge|none|host/){ print $1 }}')
I generally don't require old containers, volumes and networks, so to clear them all I made a bash script which runs to clean up docker environment before each build. And to rebuild the docker using updated code, I use docker-compose up --build
Credits to marcelmfs and borrowed from Source
In this case first we should remove old containers (by rm -f). So we can deploy new code by:
docker-compose build
docker-compose stop
docker-compose rm -f
docker-compose up
Above sequence is not coincidence - when first instruction build image, the old images running - but when building is finish then old container is stopped, deleted and exchange by new builded one.
I put above commands in handy copy-paste oneliner:
docker-compose build && docker-compose stop && docker-compose rm -f && docker-compose up
I want to rebuild everything from my docker VM named default, I used docker-compose down but it only removed the containers, all the requirements are still installed and I would like it to be as it was from the beginning so I can 're'-setup everything. Is it possible ?
This will remove all containers, images and volumes
docker rm -f $(docker ps -aq)
docker image rm $(docker image ls -q)
docker volume rm $(docker volume ls -q)
There are other things like networks and secrets that will not be removed, but they should not cause any problems.
If you are using a newer version of docker try the docker system prune -a command instead.
But maybe the --no-cache argumant ist the real solution for your problem. With it, docker will not use the cache and will do a full rebuild of the image.
The simple solution that will ignore previous builds:
docker-compose build --no-cache
But if you want something more destructive:
docker-machine rm default
docker-machine create default
eval $(docker-machine env default)