Hacker News Reader

Comment by dmunoz | Hacker News Reader

Nice to see Docker 0.7 hit with some very useful changes.

I see lots of people are getting some generic Docker questions answered in here, and want to ask one I have been wondering about.

What is the easiest way to use dockers like I would virtual machines? I want to boot an instance, make some changes e.g. apt-get install or edit config files, shutdown the instance, and have the changes available next time I boot that instance. Unless I misunderstand something, Docker requires me to take snapshots of the running instance before I shut it down, which takes an additional terminal window if I started into the instance with something like docker run -i -t ubuntu /bin/bash. I know there are volumes that I can attach/detach to instances, but this doesn't help for editing something like /etc/ssh/sshd_config.

View on HN

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/

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>

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!

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.

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.

If you hadn't heard, the new release of docker no longer uses "color_animal" but "mood_inventor"... "the most important new feature of docker 0.7"

https://github.com/dotcloud/docker/pull/2837

tl;dr They are going to pick a new pair of things for every major release of Docker. This is meant to let you keep track of more containers over a long time. Apparently you are in fact meant to keep them around if they're still in working order, and remember them "by ID" or by name.

I have not updated my own docker in a long time, I use CoreOS now, which comes with automatic updating via chaos monkeys. It's always a pleasant surprise when I see my system is about to go down for a reboot, and trying to find what's changed when it comes back up!

You don't have to take the snapshot before you shut it down. The container persists after its main process is terminated. It's safe to take the snapshot any time after.

Your question is very near to me, I published a teeny-tiny script called 'urbinit'[1] for doing exactly what you are asking. It's meant to use with urbit, where you start by creating a 'pier' and use it to begin 'ships'. The ships must not be discarded (unless you don't mind having no real identity, and many parts of urbit require you to maintain a persistent identity). If you re-do the key exchange dance again from a fresh pier to identify yourself as the same 'destroyer' (having discarded the previous incarnation), you wind up as a perfectly viable ship with packet sequence numbers that are out of order and can't really receive any messages or acknowledge any packets that are waiting to be delivered in the correct order from your neighbor ships.

Anyway, urbinit is a manifestation of the fact that Docker doesn't really have anything to help you deal with this (very common and not at all unique to Urbit) problem. Docker offers that you can use a volume... make the state you need to be persistent part of a volume. Unfortunately this means it won't be present in your images; or you can do roughly what urbinit does, which is a very simple and classic problem all Computer Scientists past year 1 should already know.

Launch the container in detached mode (-d) and save the ID. Create a lock file. Urbinit won't do step 1 if there is already a lock file created that was never cleared. This is to prevent you from launching the same ship twice at one time with two addresses, which is very confusing to the network.

Attach if you need to interact through terminal, or however you want, affect the container by sending packets to it (eg. login via ssh and do stuff). Terminate your process or let it end when it's ready to end naturally, or the power goes out. If you're using urbinit (and the power did not go out), this is the point where the commit process comes along and commits your container ID back to the named image that it was created from, simultaneously clearing the lock created in step 2.

If you're doing this with several different images on one host that are meant to run simultaneously, a nice trick is to name your lock file after the actual docker image that's used in the commit step.

[1]: http://nerdland.info/urbit-docker

Reply on news.ycombinator.com