5 ms·

There's no need to manually take snapshots, docker does this automatically every time you run a process inside a container. In your example of running /bin/bash

There's no need to manually take snapshots, docker does this automatically every time you run a process inside a container. In your example of running /bin/bash, after you exit bash and return to the host machine docker will give you the id for the container which has your changes. You can restart the container or run a new command inside it and your changes will still be there. If you want to access it more easily later, you can run 'docker commit' which will create an image from the container with a name you can reference. You can also use that new image as a base for other containers. This is great for development or playing around with something new, but the best practice for creating a reusable image with your custom changes would be to write a Dockerfile which describes the steps necessary to build the image: http://docs.docker.io/en/latest/use/builder/ http://docs.docker.io/en/latest/use/builder/

dmunoz 13y ago
Yes, my goal here is ease of playing around with something new. I would setup a dockerfile after I knew exactly what setup I wanted. You're right, I misunderstood what docker was doing when shutting down the container. Seems like I can start and reattach just fine. Here is an example workflow for anyone curious: root@chris-VM:~# docker run -i -t ubuntu /bin/bash root@0a8f96822140:/# cd /root root@0a8f96822140:/root# ls root@0a8f96822140:/root# vim shouldStayHere bash: vim: command not found root@0a8f96822140:/root# apt-get install -qq vim ...<snipped>... Setting up vim (2:7.3.429-2ubuntu2) ... root@0a8f96822140:/root# vim shouldStayHere ...Not exactly necessary, but I added a line to the file so I could identify it... root@0a8f96822140:/root# exit root@chris-VM:~# docker ps ID IMAGE COMMAND CREATED STATUS PORTS root@chris-VM:~# docker ps -a ID IMAGE COMMAND CREATED STATUS PORTS 0a8f96822140 ubuntu:12.04 /bin/bash About a minute ago Exit 0 root@chris-VM:~# docker attach 0a8f96822140 2013/11/26 10:29:41 Impossible to attach to a stopped container, start it first root@chris-VM:~# docker start 0a8f96822140 0a8f96822140 root@chris-VM:~# docker attach 0a8f96822140 ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var root@0a8f96822140:/# cd /root root@0a8f96822140:/root# ls shouldStayHere root@0a8f96822140:/root# cat shouldStayHere Hello World! root@0a8f96822140:/root# So, if I did some heavylifting to set something up and wanted to keep this as a base for later work, now I would do e.g. docker commit a8f96822140 <some identifier>
- yebyen 13y ago
  Yes, I wrote a long wordy response and neglected to mention "docker start" which is a perfectly good way to come back to a stopped container after the first "docker run". I prefer to never keep anything important in a stopped container (for very long) without committing it back to an image, and I don't like dealing with numeric ids. Recently (it looks like you don't have this change yet) docker added the automatic naming scheme giving every container a random name of some "color_animal" pair which I think reinforces the point, stopped containers are not a place to store meaningful/persistent state information for very long. This mishmash gets run almost every day on my docker hosts to clean up after terminated experiments: docker ps -a|egrep -v 'ID|Up'|awk '{print $1}'|xargs docker rm Beware, it will delete all of the stray containers you've ever created before that are now stopped!
  - shykes 13y ago
    You can assign permanent names to containers. We're designing the naming syatem to make it completely OK to keep persistent containers. They're just named directories, docker will never remove them on its own. For example a common pattern is to create a placeholder database container with reference dara as a volume, but no actual process running and no network ports. Then successive versions of the database container are started on the side, with shared access to the placeholder's volume. Later you might run a backup container on the same volume. In other words you can point to a particular dataset as a container of its own, separate of the various applications which might access it. All of these interactions are visible to docker so it can authenticate, restrict, log, or hook them in all the standard ways. In fact internally images and containers are stored side-by-side. In future versions we are going to accentuate that similarity.
  - dmunoz 13y ago
    Indeed, if I had done anything important I would certainly commit the changes to the container. It's great to have some version control for my playful discovery. The changes you mention sound nice. It's no surprise I don't have them: root@chris-VM:~# docker version Client version: 0.5.3 Server version: 0.5.3 Go version: go1.1 It was the easiest VM I had access to at the moment of posting. I should update the docker in there. I have used docker ps -a | awk '{print $1}' | xargs docker rm a couple times to clean up after playing around. I was slightly annoyed that it tried to docker rm a (nonexistent) container with the id ID. Thanks for reminding me to throw a egrep -v 'ID|Up' in front of awk.

dmunoz 13y ago

Yes, my goal here is ease of playing around with something new. I would setup a dockerfile after I knew exactly what setup I wanted. You're right, I misunderstood what docker was doing when shutting down the container. Seems like I can start and reattach just fine. Here is an example workflow for anyone curious: root@chris-VM:~# docker run -i -t ubuntu /bin/bash root@0a8f96822140:/# cd /root root@0a8f96822140:/root# ls root@0a8f96822140:/root# vim shouldStayHere bash: vim: command not found root@0a8f96822140:/root# apt-get install -qq vim ...<snipped>... Setting up vim (2:7.3.429-2ubuntu2) ... root@0a8f96822140:/root# vim shouldStayHere ...Not exactly necessary, but I added a line to the file so I could identify it... root@0a8f96822140:/root# exit root@chris-VM:~# docker ps ID IMAGE COMMAND CREATED STATUS PORTS root@chris-VM:~# docker ps -a ID IMAGE COMMAND CREATED STATUS PORTS 0a8f96822140 ubuntu:12.04 /bin/bash About a minute ago Exit 0 root@chris-VM:~# docker attach 0a8f96822140 2013/11/26 10:29:41 Impossible to attach to a stopped container, start it first root@chris-VM:~# docker start 0a8f96822140 0a8f96822140 root@chris-VM:~# docker attach 0a8f96822140 ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var root@0a8f96822140:/# cd /root root@0a8f96822140:/root# ls shouldStayHere root@0a8f96822140:/root# cat shouldStayHere Hello World! root@0a8f96822140:/root# So, if I did some heavylifting to set something up and wanted to keep this as a base for later work, now I would do e.g. docker commit a8f96822140 <some identifier>

yebyen 13y ago
Yes, I wrote a long wordy response and neglected to mention "docker start" which is a perfectly good way to come back to a stopped container after the first "docker run". I prefer to never keep anything important in a stopped container (for very long) without committing it back to an image, and I don't like dealing with numeric ids. Recently (it looks like you don't have this change yet) docker added the automatic naming scheme giving every container a random name of some "color_animal" pair which I think reinforces the point, stopped containers are not a place to store meaningful/persistent state information for very long. This mishmash gets run almost every day on my docker hosts to clean up after terminated experiments: docker ps -a|egrep -v 'ID|Up'|awk '{print $1}'|xargs docker rm Beware, it will delete all of the stray containers you've ever created before that are now stopped!
- shykes 13y ago
  You can assign permanent names to containers. We're designing the naming syatem to make it completely OK to keep persistent containers. They're just named directories, docker will never remove them on its own. For example a common pattern is to create a placeholder database container with reference dara as a volume, but no actual process running and no network ports. Then successive versions of the database container are started on the side, with shared access to the placeholder's volume. Later you might run a backup container on the same volume. In other words you can point to a particular dataset as a container of its own, separate of the various applications which might access it. All of these interactions are visible to docker so it can authenticate, restrict, log, or hook them in all the standard ways. In fact internally images and containers are stored side-by-side. In future versions we are going to accentuate that similarity.
- dmunoz 13y ago
  Indeed, if I had done anything important I would certainly commit the changes to the container. It's great to have some version control for my playful discovery. The changes you mention sound nice. It's no surprise I don't have them: root@chris-VM:~# docker version Client version: 0.5.3 Server version: 0.5.3 Go version: go1.1 It was the easiest VM I had access to at the moment of posting. I should update the docker in there. I have used docker ps -a | awk '{print $1}' | xargs docker rm a couple times to clean up after playing around. I was slightly annoyed that it tried to docker rm a (nonexistent) container with the id ID. Thanks for reminding me to throw a egrep -v 'ID|Up' in front of awk.