Container – Part 2: Working with Docker-Containers

Categories: Allgemein, Linux, Netzwerk

After showing the creation of an exemplary Docker container in the first part, this part of the article series now focuses on working with containers.

Build

Creating a Docker container is done using the build command. For this, we must be in the Dockerfile folder, otherwise the location of the Dockerfile must also be specified.

docker build -t opensuse-tomcat .

Docker now creates a corresponding Docker image named opensuse-tomcat. This now serves as a template for the containers we want to use (runtime environment(s)).

If errors occur, e.g. the files to be added via ADD cannot be found, this is displayed in the form of corresponding messages on the console. The following is an example of a missing file:

Step 13/22 : ADD ./webapp.war /opt/tomcat/webapp/
ADD failed: no source files were specified

Images

If we now want to know which usable images already exist on the host system, enter the following:

docker images

As feedback we get

REPOSITORY      TAG    IMAGE ID     CREATED     SIZE
opensuse-tomcat latest 662c7e16ad72 2 days ago  378MB
debian-tomcat   latest deeb279b66c2 3 days ago  319MB
opensuse/leap   15.2   9c0b2c564878 10 days ago 105MB
opensuse/leap   15.1   b1ee6ac1cd81 11 days ago 106MB

Run

The start of a new container based on an image is done with run. Additionally, a port mapping can be specified with -p. If there are several ports, the p parameter is simply repeated

docker run -p 8080:8080 -p 8443:8443 opensuse-tomcat

Name

Docker assigns randomly generated names to the running instances by default. If the container is to be specifically addressed by a name, it is possible to assign a name to it at startup using -name <name>

docker run -p 8080:8080 -p 8009:8009 -name tomcat01 opensuse-tomcat 

Entrypoint

In the first part of this article series, we defined a so-called entrypoint in the Dockerfile. This is executed when the container is started. However, if you do not want to have this hardwired or overwrite it, the entrypoint parameter is available for this purpose. The associated argument defines what is to be executed at the end of the startup process. In this case we execute the shutdown.sh script of the Tomcat. The additional parameter rm specifies that the container is also removed after it has been shut down.

docker run --rm --entrypoint=/opt/tomcat/bin/shutdown.sh -p 8080:8080 -p 8009:8009 opensuse-tomcat

Exec

If you want to run the above shell script in a running container (named tomcat01) exec is used, which I would prefer for terminating a running Tomcat.

docker exec tomcat01 /opt/tomcat/bin/shutdown.sh

Mount (v)

For the operation of a Tomcat, the log files are a helpful source, e.g. for troubleshooting. Here it makes sense that Tomcat writes to a directory specific to its instance. This can be specified externally with the v parameter. For this the external path and its mountpoint within the container is specified.

docker run -it --rm -p 8080:8080 -p 8009:8009 -v D:\docker\tomcat01\log:/opt/tomcat/logs --name tomcat01 opensuse-tomcat

Each instance can thus be given its own log directory at startup.

Environment variables (env-file) and hostname (h)

If I now want to set additional environment variables from outside within the container, which e.g. the web application can access in order to adapt specifically depending on e.g. a stage information, then this and further environment variables and values can be specified by means of env-file and so-called properties files when starting the container. By means of the given entrypoint the defined environment variables are output in this example.

docker run --entrypoint=/usr/bin/env --env-file env-vars.properties -h testhost123 opensuse-tomcat

The following is an example of a Propierties file. The name of this file can be assigned arbitrarily and does not have to follow any defaults.

var1=1111
var2=2222

By calling /usr/bin/env the defined environment variables are now output:

HOSTNAME=testhost123
var1=1111
var2=2222
HOME=/root

The output hostname was not part of the properties file, it was passed by means of the h parameter when the container was started.

«
»

    Leave a Reply

    Your email address will not be published. Required fields are marked *