I found this information on the Docker Website
Docker containers can be run, started, stopped, moved, and deleted.
As far as I know, Docker-Images can be moved and Docker-Containers can't. But the information above stands clearly below the headline "Docker containers".
So I would like to know, whether containers could be moved or not (and if not: What is meant with "Docker containers can be moved").
Thanks!
You can save a container with
docker save
see
https://docs.docker.com/reference/commandline/cli/#save
and restore them otherwhere with
docker load
see
https://docs.docker.com/reference/commandline/cli/#load
(it is just a tar file)
but keep in mind this will not save the volumes of the container
https://docs.docker.com/userguide/dockervolumes/#data-volumes
nor the associated volumes from
https://docs.docker.com/userguide/dockervolumes/#creating-and-mounting-a-data-volume-container
For that there is a project
docker-backup
https://github.com/discordianfish/docker-backup
Related
I know that when we stop docker our changes are lost. There are many answers how to prevent this - commit each time. Idea is that when docker runs it will spin up a fresh container based on the image. On the other hand container persists some data after it exists unless you start using --rm.
Just to simplify:
If you run apt-get install vim, you must commit to save the change
BUT If you change nginx.conf or upload new file to HDFS, you do not lose the data.
So, just curious:
How docker knows what to save and what not? Ex: At the end of apt-get-install we have new files in the system. The same is when I upload new file. for the container/image there is NO difference , Right? Just I/O modification. So how docker know which modification should be saved when we stop the image?
The basic rules here:
Anything you explicitly store outside the container — a database, S3 — will outlive the container.
If you attach a volume to the container when you create the container using a docker run -v option or a Docker Compose volumes: option, any data written to that directory outlives the container. (If it’s a named volume, it lasts until you docker volume rm it.)
Anything else in the container filesystem is lost as soon as you docker rm the container.
If you need things like your application source code or a helper tool installed in an image, write a Dockerfile to describe how to build the image and run docker build. Check the Dockerfile into source control alongside your application.
The general theory of working with Docker is that you always start from a clean slate. When you docker build an image, you start from a base image and install your application into it; you never try to upgrade an installed application. Similarly, when you docker run a container, you start from a fresh copy of its image.
So the clearest answer to the question you ask is really, if you consistently docker rm a container when you stop it, when you docker run a new container, it will have the base image plus the content from the mounted volumes. Docker will never automatically persist anything outside of this.
You should never run docker commit: this leads to magic images that can’t be recreated later (in six months when you discover a critical security issue that risks taking your site down). Similarly, you should never install software in a running container, because it will be lost as soon as the container exits; add it to your Dockerfile and rebuild.
For any Container working with the Docker platform by default all the data generated is temporary and all the file generation or data generation is temporary and no data will persist if you have not mounted the filesystem part of if you have not attached volumes to the container.
IF you are finding that the nginx.conf is getting reused even after changes i would suggest try to find what directories are you trying to mount or mapped to the docker volumes.
The configurations for nginx which reside at /etc/nginx/conf.d/* and you might be mapping the volume with this directory. So if you make any changes in a working container and then remove the container the data will still persist as the data gets written to the writable layer. If the new container which you deploy later with the same volume mapping you will find all the changes you had initially done in the previous case are reflected in the newer container as well.
How can I remove a container without removing all the changes that have been made in this container?
I already used:
Stop all running containers: docker stop $(docker ps -a -q)
Delete all stopped containers: docker rm $(docker ps -a -q)
You can create a docker image from your container with docker commit.
This image can be used to start up new containers or can be pushed to a docker repository for later use.
https://docs.docker.com/engine/reference/commandline/commit/
You don’t. Anything you change in a Docker container will be lost as soon as the container is deleted. Also, you need to routinely delete containers to change options like the base image (if there’s some security patch you need), networking options, or environment variables.
The standard pattern for this involves two things:
Don’t install software or make other configuration changes inside a running container. Instead, write a Dockerfile that does that work for you, check it into source control, and use docker build to build an image from it. (If you get something wrong, you can easily fix it and re-run it; if you need to update something in six months you have a written record of what you did.)
If your container does need some persistent state, start it with docker run -v or a similar option to mount a host directory or named volume into the container. Data stored there will outlive the container.
In theory docker commit can turn a container into an image, but using it really isn’t a best practice. Images you build this way can’t be recreated or updated (again, imagine a critical security fix in the underlying base image). In some cases a committed container won’t even have the data you want to save (for example you can’t usefully commit a MySQL or PostgreSQL container).
I have installed some software in a docker image. When I run the software, it creates some setting files (dot files) under the root home folder. The problem is docker container wipes those files when I quit the container.
Is there a way to keep those dot files after I quite containers? I know I can manually save the container into a image. But that is not an elegant solution. That means every time I used the container, I need to save it to a image.
Any better solutions?
Thanks!
A simple solution would be to use a volume.
docker volume create configuration
And then you just run each container with it.
docker run -d -v configuration:container_configuration_dir your_image_name
Left side of : is name of volume created with first command and right side is dir inside container where your dot files are created.
Keep in mind how mounts work and for more details check docker docs on volumes.
In some places when I read about Docker containers, I found some people talking that they lose their data (saved inside the container and not a part of volume data) when they restart the container.
I tried to create a simple Ubuntu container like this: docker run -it ubuntu /bin/bash, and created some files inside the container and then restarted it, but my data still there. Why does that actually happen? why do my data still there? Is this something new in the newer versions of Docker or do I have misunderstanding for something?
The data is lost when the container is removed, not when it's stopped or restarted.
Basically, if you do docker ps, if the containers keeps the same id (the big ugly hexadecimal id), the data is not lost.
It gets complicated when somehow your docker containers are not managed by you, but by some kind of automated-managing method. Tools like these usually start new containers if there is failure. In that case you should mount a volume to store your data on the host.
You might want to look at the Container Lifecycle: https://github.com/wsargent/docker-cheat-sheet#lifecycle
docker create creates a container but does not start it.
docker rename allows the container to be renamed.
docker run creates and starts a container in one operation.
docker rm deletes a container.
docker update updates a container's resource limits.
If you do docker rm and docker run again your state will not be there anymore.
If you want a transient container, docker run --rm will remove the container after it stops.
I recently created a mongodb docker instance running on boot2docker on windows.
Unfortunately during my experimenting with kitematic I managed to accidentally remove the volume from the mongo container and can no longer access my data.
The mongo instance seems to have created a new volume with the old volume now remaining dangling (orphaned) and not mounted in any containers.
Is there any way to recover this?
Thanks for your reply it got me on the right track, I managed to start a new mongo container using the following command
docker run -d -v 571284fbe08a3f2b675af299ec14e55550bad623f6316914d465843fa12d6f18:/data/db mongo
where 571284fbe08a3f2b675af299ec14e55550bad623f6316914d465843fa12d6f18 is the dangling volume identified by using
docker volume ls
I usually register the path (in a file) of any data volume container I create, precisely in that case. See "Docker volumes for persistent data - is it enough to pass container path only?" and my script updateDataContainerPath.
What I have seen is that:
any new data volume container comes with its own Mounts.Source path,
you can delete that new folder (which is empty)
you can replace it with the folder of your old data volume container (giving it the same name as the new one, but with the content of the old data volume container)
That will be enough for the new data volume container to give you access to your old data.
In your case, since you didn't register the path of your previous data volume container, you will have to do a search in /mnt/sda1/var/lib/docker/volumes/ for a known file.
This answer is probably just a rewrite of #VonC's, but I feel the need to sum things up a bit. Here are the steps I followed in order to put back a volume that got 'detached' after the container had been removed and recreated.
docker volume ls -f 'dangling=true' to see all detached volumes
docker volume inspect <volume_hash> on each to see where they sit (/var/lib/docker/volumes/ in my case)
Look into each volume's /_data folder to guess who's who.
Then as explained by VonC, just copy the content of the dangling volume into the new one.
(optional) when you are sure you've got back everything you need, docker volume prune will remove all dangling volumes (and therefore make a potential future search for the right dangling volume easier ^^)