Parameters as Environment Variables

In real life, a container’s inputs and outputs are likely to vary according to the container’s environment. For instance, if you run a web application, it is likely to connect to a database and listen for incoming requests on a given DNS. The database connection details and DNS will have different values on a development machine, on the test server, and the production server.

Reading a value#

Whatever the technology you use inside your container, you can access environment variables. For instance, if you set a name environment variable, you may access it with:

Providing a value#

On a real machine, environment variables are set on your system. Inside a container, they can be set from several sources, which make them appropriate for parameterizing your containers.

In order to provide an environment variable’s value at runtime, you simply use the -e name=value parameter on the docker run command.

A special use case is when the system that runs the container has the name environment variable defined, and you want to reuse it, then you can simply use the -e name parameter without specifying a value.

Default value#

You may also want to define a default value for an environment variable, in case it isn’t provided when a container is created; this may be done in the Dockerfile file, using the ENV instruction. For instance, the following makes sure that if the name variable isn’t provided to the docker run command, it has a default value of Dockie:

It’s good practice to add an ENV instruction for every environment variable your image expects since it documents your image.

Sample usage#

I want to create an image that can ping any given site. I’ll do this using a Linux shell script. I define it in a $ping.sh$ file:

ping.sh

Note that I make use of a host environment variable. I’m going to define an image that includes and runs that script:

Dockerfile

Note that my Dockerfile file includes an ENV instruction that specifies that the host variable will be $www.google.com$ in case it isn’t provided. I create my image from that Dockerfile file by running a docker build command:

Next, I run two containers based on that image:

We don’t provide the first container with any value for the host environment variable in order for it to default to the $www.google.com$ value specified in the Dockerfile file. The second container is provided the $www.bing.com$ value.

Run the following to observe the output of docker run --rm pinger command.

Run the following to observe the output of docker run --rm -e host=www.bing.com pinger command.

We don’t provide the first container with any value for the host environment variable, for it to default to the $www.google.com$ value, specified in the Dockerfile file. The second container is provided the $www.bing.com$ value.

You can see in the output that each container pinged a different host, according to the values provided to them.

This was a simple demo, but you can provide advanced values. You would typically provide full connection strings or URLs to other services, usernames, and passwords, to name a few. This is a flexible and powerful feature since those values may come from many sources once you begin to use orchestrators.

Before we move on to storage, try the exercise in the next lesson.