10

As the title goes, safe means... the proper way?

Safe = consistent, no data loss, professional, legit way.

Hope to share some experiences with pro docker users.

Q. Commit is safe for running docker containers (with the exception of rapidly changing realtime stuff and database stuff, your own commentary is appreciated.)

Yes or No answer is accepted with comment. Thanks.

stashfree
  • 655
  • 6
  • 22
  • 1
    Maybe this answer I made to a previous similar question can help... : http://stackoverflow.com/questions/24071148/is-it-safe-to-export-tarball-of-running-docker-container – mbarthelemy Dec 04 '14 at 07:19

1 Answers1

9

All memory and harddisk storage is saved inside the container instance. You should, as long as you don't use any external mounts/docker volumes and servers (externally connected DBs?) never get in trouble for stopping/restarting and comitting dockers. Please read on to go more in depth on this topic.

A question that you might want to ask yourself initially, is how does docker store changes that it makes to its disk on runtime? What is really sweet to check out, is how docker actually manages to get this working. The original state of the container's hard disk is what is given to it from the image. It can NOT write to this image. Instead of writing to the image, a diff is made of what is changed in the containers internal state in comparison to what is in the docker image. Docker uses a technology called "Union Filesystem", which creates a diff layer on top of the initial state of the docker image.

This "diff" (referenced as the writable container in the image below) is stored in memory and disappears when you delete your container. When you use docker commit, the writable container that is retained in the temporary "state" of the container is stored inside a new image, however: I don't recommend this. The state of your new docker image is not represented in a dockerfile and can not easily be regenerated from a rebuild. Making a new dockerfile should not be hard. So that is alway the way-to-go for me personally.

When your docker is working with mounted volumes, external servers/DBs, you might want to make sure you don't get out of sync and temporary stop your services inside the docker container. When you would use a dockerfile you can start up a bootstrap shell script inside your container to start up connections, perform checks and initialize the running process to get your application durably set up. Again, running a committed container makes it harder to do something like this.

Union Filesystem

RoyB
  • 3,104
  • 1
  • 16
  • 37
  • Are you sure that Docker saves memory inside of container? – anatoly techtonik Feb 20 '15 at 12:38
  • At runtime, memory is assigned to the processes within the container, as with stopped containers, memory is no longer reserved to the processes running inside the container as they're stopped, and I assume it must be saved to disk in order for the container to be re-startable. – RoyB Feb 23 '15 at 20:57
  • I'd appreciate some proof links for that behavior, because in my setup `nginx` process failed to persist in saved container. – anatoly techtonik Feb 24 '15 at 10:12
  • Thats curious, I never have these problems. Can you post a new question and send a link here? To get back to my point: Proof is simple, a computer only has RAM and ROM (Disk). When a process is able to restore its RAM state, the only resource to get the data from is disk. You should be able to find the swapfile somewhere in /var/lib/docker – RoyB Feb 24 '15 at 14:02
  • when I `RUN sudo nginx`, it won't persist, so I need to use `CMD sudo nginx -g 'daemon off;'` at the end. You can test it yourself. – anatoly techtonik Feb 25 '15 at 11:45
  • RUN is for adding changes to an IMAGE and not to a CONTAINER, you should never run your executable other than to supplement changes to your image just once, you should always use CMD, and run an executable on the foreground. If you don't understand why I say this, than you don't understand the concept of "containers" – RoyB Feb 26 '15 at 11:16