As part of my work at Standard Treasury implementing our continuous integration infrastructure, I ran into a bunch of issues creating ephemeral service instances for test executions. Fortunately for me, the Docker project added links to enable services to expose connection information to each other.
Effectively utilizing these variables in a way that doesn’t tightly couple your application to these ephemeral environment variables is tricky, though. I’ll talk about my strategy for adapting Docker environment variables to application-specific variables in this post.
Linking is a recent feature added to Docker in the 0.6.5 release on October 31. Passing the
docker run commands will enable a new container to access an existing container’s
exposed ports via environment variables.
To link containers, start a container with the
-name argument and use the name when starting the
second container like this:
docker run -name first -p 5432 -d <container hash> docker run -name second -link first:db <hash>
When used correctly, the “second” container will have additional environment variables exposed that describe the IP address and port of the mapped container, e.g.:
DB_NAME=first DB_PORT_5432_TCP_PORT=5432 DB_PORT=tcp://172.17.0.33:5432 DB_PORT_5432_TCP=tcp://172.17.0.33:5432 DB_PORT_5432_TCP_ADDR=172.17.0.33 DB_PORT_5432_TCP_PROTO=tcp
The string after the
: value is used as the prefix for the set of environment variables added to
the second container.
Using these environment variables is non-trivial; the additional variables may not match up to the
values your application is anticipating, so some transformation may be necessary. For example, if
your application is expecting
SQLALCHEMY_DATABASE_URI to contain the database URI, you’ll need to
use the now-exposed DB_PORT_XXX_TCP_ADDR to set SQLALCHEMY_DATABASE_URI.
You might be tempted to try the
ENV parameter available for Dockerfile, but this won’t work; the
environment variables exposed by
-link arguments are only available inside a running docker
container, not via the Dockerfile.
To solve this, I’ve opted to use a wrapper script called
env.sh in each repo to take variables
exposed by linked containers and create new ones that the application expects,
remaining arguments. The Dockerfile for each application sets the ENTRYPOINT as
Here is the
env.sh wrapper script that is used at the ENTRYPOINT for each repo’s container.
DB_NAME="/$JOB_NAME-$BUILD_NUMBER-db" DB_CONTAINER=$(sudo docker run -d -name $DB_NAME <private repository URL>/database) sudo docker run -link $DB_NAME:db -t $JOB_NAME/$BUILD_NUMBER nosetests
In my next post, I’ll describe how this wrapper script is used to expose services in a continuous integration flow.