DOCKER HOME LAB | Affect container with Dockerfile

In the last post we learned how to use Dockerfiles to automate the build process of making contain images.

Now were going to see how we can use Dockerfiles to affect containers beyond the file system.


DOCKER HOME LAB | Where to Start ?

DOCKER HOME LAB | Managing Docker Containers

DOCKER HOME LAB | Commit changes to a container

DOCKER HOME LAB | Using / Finding / Sharing in Docker Public index

DOCKER HOME LAB | Building Containers with Dockerfile

DOCKER HOME LAB | Affect container with Dockerfile

Affect container defaults with Dockerfile

Docker containers are about running processes, but there are many properties of the environment that affect the processes including what the user is running as, environment variables and its access to the network.

We can use Dockerfiles to specify this extra information about how a container processes should be run.

First there are two instructions that affect what is run. When you run a container you can specify the command to run, but you don’t have too if there is a default command on the container.

The CMD instruction lets specify this.

Back in our sshd server container project directory, we can open our Dockerfile

vi Dockerfile

And here we will add the CMD instruction to run the sshd daemon by default


Now after we have built this Dockerfile we will be able to run an sshd container with no command

First, we build the image

docker build

And now we run the container based on the new image

docker run

I will stop the container for now to continue adding more options

docker rm

The other instruction affecting what processes is run in a container, is ENTRYPOINT.


ENTRYPOINT can be used to achieve the same effect as CMD, but using ENTRYPOINT you can’t specify different commands without using a special flag in the execution of docker run, instead the command passed in docker run will be appended to the entry points command, making the container a little more locked into a particular command. But normally you should CMD instead of ENTRYPOINT.

Now while we are at the Dockerfile lets add some instructions that would affect the environment of the processes

First, I’m going to set a user CMD to set the run as. This is significant because by default they run as root

Here we will run as the nobody user

set user nobody

Next will set the working directory /tmp

set working directory

Lastly we are going to set an environment variable, just to see how we can do it

set environment variables

Now let’s run a few commands in this container to see the effect of our new instructions

Let’s rebuild the image and review the details.

docker build

And let’s run a container with this command:

docker run –rm -it galvezjavier/sshd id

First the user ID we can see is not root, it’s the nobody user

show user id

Run this command: docker run –rm -it galvezjavier/sshd pwd to show the current working directory

When running a command we can see is /tmp

show working directory


Lastly if we show the environment variables inside the container. We can see our foobar Hello value

environment variables

There is one more instruction to cover here, which is the EXPOSE instruction.

EXPOSE tells docker that this container is going to be running a demon and will be listening on a particular port. Since container run an isolated network in order for container process to accept connections Docker must forward a port. We have been doing this with the -p argument on the docker run command. We always have to do this but is useful to know that the container will be listening on port, so we can provide that Meta data using EXPOSE

We will EXPOSE 2222 since that will be set at the sshd config file that we were using previously


And re build the image one more time

docker build

The internal port is not that important since only ever access it via port specified when using docker run.

We will run the continer now even if we don’t use –p to open a port, we can see with docker ps that this container is exposing a TCP port 2222

docker ps

To summarize we can use Dockerfile instructions to affect how users ultimately use the container, including the command they run and how it runs.

In the next post we take a look ways in which we can build upon and reuse existing Docker containers.

Docker Home Lab

Docker Home Lab


  1. […] DOCKER HOME LAB | Affect container with Dockerfile […]

  2. […] DOCKER HOME LAB | Affect container with Dockerfile […]

Speak Your Mind


%d bloggers like this: