Docker 0.6.5: name your containers, link them together, selectively publish ports, and more

Michael Crosby

Oct 31 2013

Today we’re happy to announce Docker 0.6.5. Don’t be fooled by the version number: this is a significant release! Think of it as a preparation for 0.7, which will be even more significant.

In addition to numerous bug fixes, this release introduces container naming, links between containers, better host integration, and advanced port redirects.

A big thank you to (in no particular order) to Paul Nasrat, Tianon Gravi, Edmund Wagner, Travis Cline, Gurjeet Singh, Justin Force, Johan Euphrosine, Ole Reifschneider, Will Rouesnel, Alex Larsson, Greg Thornton, Sven Dowideit, Scott Bessler, Todd Lunter, Vladimir Rutsky, Nicolas Dudebout, Nicolas Dudebout, Roger Peppe, Jerome Petazzoni for your contributions. Not bad for a minor release! (sorry if we forgot anyone).


Read this before you upgrade

Two warnings before you upgrade:

First, if you are running the brand new Ubuntu 13.10, your version of the lxc scripts is unstable and not supported by Docker. Please make sure to install lxc 0.8 or 0.7 before you make the upgrade.

Second, in order to improve port redirection we had to introduce two small breaking changes. We did our best to keep the disruption to a minimum, and we hope you’ll agree that the new features are worth it. Please see Advanced port redirects below for details.


Container naming

We are happy to announce that we can finally close issue #1! You can now give memorable names to your containers using the new -name flag for docker run. If no name is specified Docker will automatically generate a name. When you link one container to another you will have to provide the name and alias of the child that you want to link to via -link child_name:alias.


Enough talk, let’s see some examples! You can run two databases with corresponding names like so:

  • docker run -d -name mariadb user/mariadb
  • docker run -d -name mysql user/mysql

Every command that worked with a container_id can now be used with a name that you specified:

  • docker restart mariadb
  • docker kill mysql


Links: service discovery for docker

Links allow containers to discover and securely communicate with each other. In 0.6.5 inter-container communication can be disabled with the daemon flag -icc=false. With this flag set to false, Container A cannot access Container B unless explicitly allowed via a link. This is a huge win for securing your containers. When two containers are linked together Docker creates a parent child relationship between the containers. The parent container will be able to access information via environment variables of the child such as name, exposed ports, ip, and environment variables.

When linking two containers Docker will use the exposed ports of the container to create a secure tunnel for the parent to access. If a database container only exposes port 8080 then the linked container will only be allowed to access port 8080 and nothing else if inter-container communication is set to false.


When running a WordPress container we need to be able to connect to a database such as MySQL or MariaDB. Using links we can easily swap out the backend database and not have to change our configuration files for the wordpress site.

In order to build a wordpress container that works with both databases the container should look for the alias, in our example `db`, when linking to the database. This will allow you to access the database information via consistent environment variables no matter what the name of the container is. Using the two database containers from the naming example we will create a link between them to our wordpress container.

To link just add the -link flag to docker run:

docker run -d -link mariadb:db user/wordpress or

docker run -d -link mysql:db user/wordpress

After creating the new container linked into the database container with the alias db you can inspect the environment of the wordpress container and view the ip and port of the database.





The environment variables will be prefixed with the alias you specified on the -link flag.

For another example we encourage you to read the Building a redis container to link as a child of our web application example in the Docker documentation.

Host integration

Host integration allows Docker to better integrate with process supervisors like init, upstart, systemd, etc. docker start -a now automatically attaches to the container’s process and forwards all signals to the container so that process supervisors can detect when the container crashes and correctly restart it.

See the documentation for details and usage examples.

Advanced port redirects

Note: this feature introduces 2 small breaking changes to improve security. See the end of this section for details.

Docker 0.6.5 extends the run -p flag to give you more control over port redirection. Instead of automatically redirecting on all host interfaces, you can specify which interfaces to redirect on. Note that this extends the existing syntax without breaking it.

For example:

  • -p 8080 will publish port 8080 of the container to all interfaces of the host with a dynamically allocated port
  • -p 8080:8080 will publish port 8080 of the container to all interfaces of the host with a static port of 8080
  • -p # Publish port 80 of the container to localhost of the host with a static port to 80

You can also choose to not redirect on any host interface, effectively making that port unreachable from the outside. This is very useful in combination with links (see “Links” below), for example to expose an unprotected database port to an application container without publishing it on the public internet. You can do this without a Dockerfile thanks to the new -expose flag.

This release introduces two breaking changes to improve security:

First, we are changing the default behavior of docker run to not redirect ports on the host. This is better for security: ports are private by default, and you can explicitely publish them with the -p flag. If you currently rely on exposed ports being published on all host interfaces by default, that will no longer be true in 0.6.5. You can revert to the old behavior by simply adding the appropriate -p flags.

Second, we are deprecating the advanced “<public>:<private>” syntax of the EXPOSE build instruction. This special syntax allowed the Dockerfile to specify in advance that the exposed port should be published on a certain port on all host interfaces. We have found that this hurts separation of concerns between dev and ops, by restricting in advance the system administrator’s ability to configure redirects on the host. The regular “EXPOSE <private>” syntax is not affected.

For example:

  • Not deprecated: EXPOSE 80 will continue to expose tcp port 80 as usual.
  • Deprecated: EXPOSE 80:80 will trigger a warning, and be treated as identical to EXPOSE 80. The public port will simply be ignored.

We apologize for these breaking changes. We did our best to minimize the inconvenience, and we hope you’ll agree that the improvements are worth it!


Happy hacking!

The Docker team


13 thoughts on “Docker 0.6.5: name your containers, link them together, selectively publish ports, and more

  1. I may have upgraded to quickly 🙂

    I’m using docker-py and I can’t seem a way to expose and redirect a port. Before I was taking care of it in the Dockerfile using a random port:

    EXPOSE 8787

    Now, I understand I must run the container using -p 8787. However, when I create the container using docker-py and set PortSpecs to [‘8787’] I end up with the same result where docker ps shows:


    (no port redirection)

    Has the API not been updated yet?


  2. Totally great update, thanks!

    One question left, though: How can I delete/reuse a name once given?

  3. martin, I was wondering the same thing after I ran a “docker kill my-container-name”. Ended up looking at “docker ps -a” and seeing it in there as a stopped container, which is why I couldn’t run another “docker run -name my-container-name …” command.

    So, you need to run “docker rm my-container-name” to remove the container that the name is attached to. And of course use “docker stop my-container-name” or “docker kill my-container-name” first if it’s still running.

  4. is it possible to start my docker image completely from scratch without any parent images? (If so, I’m planning to create my own base image via a net-install).

    I ask because all getting-started guides for Docker are basing their docker images on someone else’s. However, even the base image has 180MB of virtual storage there. I want to start completely from scratch. Is it possible?


  5. Great work! I was a little worried when I read about the backwards incompatible changes, but these are very sensible changes and fit exactly with how I use Docker with my custom orchestration layer. I create dynamic run scripts which explicitly expose ports. In my docker image I indeed just indicate which ports I want to use internally. The orchestration layer knows, by parsing meta-data about the application, that certain ports must be mapped to fixed port numbers, and other are allowed to be created dynamically.

  6. Nice! After playing with names for several minutes, my zookeeper container are having many *dead* links to some random named (but not active) containers. I couldn’t find any “name-link” manipulator commands. How can I clean up not-used-any-more links?

  7. Will docker ever switch from aufs to btrfs? Almost all my server machines are running debian, and I’d love to use docker on them. Moreover aufs isn’t going to be in ubuntu kernels forever while btrfs is becoming more popular

    • Hey Vincenzo,

      BTRFS support should arrive “soon”. But meanwhile, you can already use Docker 0.7 with Device Mapper on Debian (and almost every distro out there). Also, Debian kernels support AUFS (I run Debian on my laptop and it has AUFS!)


  8. In Docker for Mac, the way to assign a name to a container requires two hyphens, e.g.:
    docker run -d –name mariadb user/mariadb

  9. -name should be –name

Leave a Reply