Red Hat OpenShift Development I: Introduction to Containers with Podman

You can package your application in a container with the application runtime dependencies. However, developers commonly create containers that have a number of downsides, for example:

This section focuses on advanced container patterns that help you limit previously mentioned issues, such as:

The ENV instruction lets you specify environment dependent configuration, for example, hostnames, ports or usernames. The containerized application can use the environment variables at runtime.

To include an environment variable, use the key=value format. The following example declares a DB_HOST variable with the database hostname.

ENV DB_HOST="database.example.com"

Then you can retrieve the environment variable in your application. The following example is a Python script that retrieves the DB_HOST environment variable.

from os import environ

DB_HOST = environ.get('DB_HOST')

# Connect to the database at DB_HOST...

Use the ARG instruction to define build-time variables, typically to make a customizable container build.

You can optionally configure a default build-time variable value if the developer does not provide it at build time. Use the following syntax to define a build-time variable:

ARG key[=default value]

When you build the container image, use the --build-arg flag to set the value, such as podman build --build-arg key=example-value for the preceding example.

Consider the following Containerfile example:

ARG VERSION="1.16.8" \
    BIN_DIR=/usr/local/bin/

RUN curl "https://dl.example.io/${VERSION}/example-linux-amd64" \
        -o ${BIN_DIR}/example

If you do not provide the --build-arg flag, then Podman uses the default values during the build process. However, you can change the values during the build process without changing the Containerfile by using the ARG instruction.

Developers commonly configure the ENV instructions by using the ARG instruction. This is useful for preserving the build-time variables for runtime.

Consider the following Containerfile example:

ARG VERSION="1.16.8" \
    BIN_DIR=/usr/local/bin/

ENV VERSION=${VERSION} \
    BIN_DIR=${BIN_DIR}

RUN curl "https://dl.example.io/${VERSION}/example-linux-amd64" \
        -o ${BIN_DIR}/example

In the preceding example, the ENV instruction uses the value of the ARG instruction to configure the run-time environment variables.

If you do not configure the ARG default values but you must configure the ENV default values, then use the ${VARIABLE:-DEFAULT_VALUE} syntax, such as:

ARG VERSION \
    BIN_DIR

ENV VERSION=${VERSION:-1.16.8} \
    BIN_DIR=${BIN_DIR:-/usr/local/bin/}

RUN curl "https://dl.example.io/${VERSION}/example-linux-amd64" \
        -o ${BIN_DIR}/example

Use the VOLUME instruction to persistently store data. The value is the path where Podman mounts a persistent volume inside of the container. The VOLUME instruction accepts more than one path to create multiple volumes.

For example, the following Containerfile creates a volume to store PostgreSQL data.

FROM registry.redhat.io/rhel9/postgresql-13:1

VOLUME /var/lib/pgsql/data

In the previous Containerfile, if you add instructions that update /var/lib/pgsql/data after the VOLUME instruction, then those instructions are ignored.

To retrieve the local directory used by a volume, you can use the podman inspect VOLUME_ID command.

[user@host ~]$ podman inspect VOLUME_ID
[
    {
        "Name": "VOLUME_ID",
        "Driver": "local",
        "Mountpoint": "/home/your-name/.local/share/containers/storage/volumes/VOLUME_ID/_data",
        ...output omitted...
        "Anonymous": true
    }
]

The Mountpoint field gives you the absolute path to the directory where the volume exists on your host file system. Volumes created from the VOLUME instruction have a random ID in the Name field and are considered Anonymous volumes.

To remove unused volumes, use the podman volume prune command.

[user@host ~]$ podman volume prune
WARNING! This will remove all volumes not used by at least one container. The following volumes will be removed:
8c0c...bcb8c
Are you sure you want to continue? [y/N] y
8c0c...bcb8c

You can create a named volume by using the podman volume create command.

[user@host ~]$ podman volume create VOLUME_NAME
VOLUME_NAME

You can also format the podman volume ls command to include the Mountpoint field of every volume. Persistent data storage with volumes is covered in depth later in the course.

[user@host ~]$ podman volume ls \
 --format="{{.Name}}\t{{.Mountpoint}}"
0a8c...82c2  /home/your-name/.local/share/containers/storage/volumes/0a8c...82c2/_data
252d...b2ed  /home/your-name/.local/share/containers/storage/volumes/252d...b2ed/_data

The ENTRYPOINT and CMD instructions specify the command to execute when the container starts. A valid Containerfile must have at least one of these instructions.

The ENTRYPOINT instruction defines an executable, or command, that is always part of the container execution. This means that additional arguments are passed to the provided command.

Consider the following example:

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
ENTRYPOINT ["echo", "Hello"]

Running a container from the previous Containerfile with no arguments prints "Hello".

[user@host ~]$ podman run my-image
Hello

If you provide the container with the "Red" and "Hat" arguments, then it prints "Hello Red Hat".

[user@host ~]$ podman run my-image Red Hat
Hello Red Hat

If you only use the CMD instruction, then passing arguments to the container overrides the command provided in the CMD instruction.

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
CMD ["echo", "Hello", "Red Hat"]

Running a container from the previous Containerfile with no arguments prints Hello Red Hat.

[user@host ~]$ podman run my-image
Hello Red Hat

Running a container with the argument whoami overrides the echo command.

[user@host ~]$ podman run my-image whoami
root

When a Containerfile specifies both ENTRYPOINT and CMD then CMD changes its behavior. In this case the values provided to CMD are passed as default arguments to the ENTRYPOINT.

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
ENTRYPOINT ["echo", "Hello"]
CMD ["Red", "Hat"]

The previous example prints Hello Red Hat when you run the container.

[user@host ~]$ podman run my-image
Hello Red Hat

If you provide the argument Podman to the container, then it prints Hello Podman.

[user@host ~]$ podman run my-image Podman
Hello Podman

The ENTRYPOINT and CMD instructions have two formats for executing commands:

You might need to change the container entrypoint at runtime, for example for troubleshooting. Consider the following Containerfile:

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5

LABEL GREETING="World"

ENTRYPOINT echo Hello "${GREETING}"

When you run the container, you notice unexpected output:

[user@host ~]$ podman run my-image
Hello

You can execute the env command to print the environment variables in the container. However, the preceding container uses the ENTRYPOINT instruction, which means that you cannot change the echo command by adding an argument to the container execution:

[user@host ~]$ podman run my-image env
Hello

In that case, you can overwrite the entrypoint by using the podman run --entrypoint command.

[user@host ~]$ podman run --entrypoint env my-image
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
container=oci
HOME=/root
HOSTNAME=ba00a7663a93

Consequently, you verify that the GREETING environment variable is not set. This is because the developer that created the Containerfile used the LABEL instruction instead of the ENV instruction.

A secret is a blob of sensitive information required by containers at runtime. This can be usernames, passwords, or keys. For example, if your containerized application requires credentials for connecting to a database, then you must store those credentials as a secret. After creating the secret, you must instruct the application container to make the credentials available to the application when it starts. To manage this process, use the podman secret subcommands.

[user@host ~]$ echo "R3d4ht123" > dbsecretfile
[user@host ~]$ podman secret create dbsecret dbsecretfile
9c2400836ee16ed07d86a3122

[user@host ~]$ printf "R3d4ht123" | podman secret create dbsecret2 -
875a1e46fa64639756968c644

[user@host ~]$ podman secret ls
ID                         NAME         DRIVER      CREATED             UPDATED
875a1e46fa64639756968c644  dbsecret2    file        About a minute ago  About a minute ago
9c2400836ee16ed07d86a3122  dbsecret     file        14 minutes ago      14 minutes

[user@host ~]$ podman secret rm dbsecret2
875a1e46fa64639756968c644

[user@host ~]$ podman run -it --secret dbsecret \
--name myapp registry.access.redhat.com/ubi8/ubi /bin/bash
[root@f9fedddbc81a /]# cat /run/secrets/dbsecret
R3d4ht123

A multistage build uses multiple FROM instructions to create multiple independent container build processes, also called stages. Every stage can use a different base image and you can copy files between stages. The resulting container image consists of the last stage.

Multistage builds can reduce the image size by only keeping the necessary runtime dependencies. For example, consider the following example, where a Node application is containerized.

FROM registry.redhat.io/ubi8/nodejs-14:1

WORKDIR /app
COPY . .

RUN npm install
RUN npm run build

RUN serve build

The npm install command installs the required NPM packages, which includes packages that are only needed at build-time. The npm run build command uses the packages to create an optimized production-ready application build. Then, the container uses an HTTP server to expose the application by using the serve command.

If you build an image from the previous Containerfile, then the image contains both the build-time and runtime dependencies, which increases the image size. The resulting image also contains the Node.js runtime, which is not used at container runtime but might increase the attack surface of the container.

To avoid this issue, you can define two stages:

The following example implements the two-stage build process.

# First stage
FROM registry.access.redhat.com/ubi8/nodejs-14:1 as builder 
COPY ./ /opt/app-root/src/
RUN npm install
RUN npm run build 

# Second stage
FROM registry.access.redhat.com/ubi8/nginx-120 
COPY --from=builder /opt/app-root/src/ /usr/share/nginx/html 

Container images use a copy-on-write (COW), layered file system. When you create a Containerfile, the RUN, COPY, and ADD instructions create layers (sometimes referred to as blobs).

The layered COW file system ensures that a container remains immutable. When you start a container, Podman creates and mounts a thin, ephemeral, writable layer on top of the container image layers. When you delete the container, Podman deletes the writable thin layer. This means that all container layers stay identical, except for the thin writable layer.

...content omitted...
COPY . /app/
...content omitted...

...content omitted...
COPY package.json /app/
RUN npm ci --production
COPY src ./src
...content omitted...

RUN mkdir /etc/gitea
RUN chown root:gitea /etc/gitea
RUN chmod 770 /etc/gitea

RUN mkdir /etc/gitea && \
    chown root:gitea /etc/gitea && \
    chmod 770 /etc/gitea

[user@host ~]$ podman build -t localhost/not-squashed .
...output omitted...
[user@host ~]$ podman build --squash -t localhost/squashed .
...output omitted...
[user@host ~]$ podman build --squash-all -t localhost/squashed-all .
...output omitted...
[user@host ~]$ podman images --format="{{.Names}}\t{{.Size}}"
[localhost/not-squashed:latest]  419 MB 
[localhost/squashed:latest]      419 MB 
[localhost/squashed-all:latest]  394 MB