I’ve been spending some time this weekend looking more at docker and where I think it could be useful for my workflows, and along the way I’ve learned a couple of things which I didn’t know, so I thought it would be worth recording them, in case they’re useful to others. None of this is particularly earth shattering but hey could save someone some time :)

Images and Containers

First was the distinction between images and containers. Images are what you build from (e.g. a template) containers are running instances of those images.

Container Persistence

If you do one of the canonical examples that’s provided in many tutorials

docker run -t -i ubuntu:latest /bin/bash

You get an interactive shell prompt in a docker container. If you exit that process you go back to the host and if you repeat the command you get another instance of the container, with none of the files you created in the first one.

From that you might get the impression that docker container filesystems are not persistent (i.e. when the exit all the data is lost), but that’s not the case from what I can see.

To get back into a container instance you’ve used previously you need to get the name or ID first. To do that use

docker ps -a

which will list all the container instances you’ve ever run on that system and it’ll look something like

CONTAINER ID        IMAGE                        COMMAND                CREATED             STATUS                      PORTS                    NAMES
39c1e5cf8319        raesene/auto-docker-dradis   "bundle exec rails s   47 minutes ago      Up 47 minutes     >3000/tcp   cranky_kilby
e529903a3183        raesene/auto-docker-dradis   "bundle exec rails s   55 minutes ago                                                           compassionate_yonath
f084aaca32ee        raesene/dradisframework      "bundle exec rails s   24 hours ago        Exited (0) 47 minutes ago                            agitated_ptolemy
8a8f7b95082a        2bfb337a0aa8                 "bundle exec rails s   24 hours ago        Exited (0) 24 hours ago                              fervent_hopper
8a2a0046b769        ruby:latest                  "/bin/bash"            24 hours ago        Exited (0) 24 hours ago                         	 compassionate_goodall

from that you can see each container has an ID (the first column) and a name (the last column). You can restart the container using either of those. For example to restart the container with the name compassionate_goodall to get some files off it, you’d use

docker start compassionate_goodall
docker attach compassionate_goodall

docker hub build options

There’s two options for getting your builds onto docker hub. The first is to get a container, make modifications to it on your own docker engine and then commit the changes back to your own repository on docker hub. This works fine but is rather lacking in transparancy as to what went into the build and also doesn’t really lend to others participating.

The other option is using Docker Hub automated builds, where a github/bitbucket repository is created with the Dockerfile present and then Docker Hub handles the build in an automated fashion from that Dockerfile. docker automated build docs

Exposing docker ports

By default containers have no ports exposed the the host network and many containers do not have things like SSHD installed, so remote access isn’t there by default. The best way to map a port from the host to the guest is when the docker run command is used with the -p option.


Security Geek, Penetration Testing, Docker, Ruby, Hillwalking