All storage of memory and hard disk is stored inside the container instance. You should, as long as you do not use external volumes and servers (for example, external connected DBs), never get into a difficult position to stop / restart and send dockers. Please read on to delve deeper into this topic.
The question that you might want to ask yourself at the initial stage is how docker changes are saved to disk at runtime? What is really nice to check out is how docker really does it. The initial state of the container’s hard drive is what is given to it from the image. He may NOT write to this image. Instead of writing on the image, there is a difference in what has changed in the internal state of the containers compared to what is in the docker image. Docker uses the Union Filesystem technology, which creates a diff layer on top of the original state of the docker image.
This "diff" (designated as the recordable container in the image below) is stored in memory and disappears when you delete your container. However, when you use docker commit, a rewritable container that is stored in the temporary "state" of the container is saved inside the new image: I do not recommend this. The state of your new docker image is not represented in the docker file and cannot be easily restored from rebuilds. Creating a new docker file should not be difficult. So this is always the way for me personally.
When your docker works with mounted volumes, external servers / databases, you may want to make sure that you do not get synchronization and temporarily stop your services inside the docker container. When you use the dockerfile, you can run a script shell in your container to start connections, perform checks, and initialize the process to ensure reliable application creation. Again, launching the target container makes it difficult to do something like this.
RoyB Dec 04 '14 at 8:35 2014-12-04 08:35
source share