Abstract
| Goal |
Build custom container images to containerize applications. |
| Objectives |
|
| Sections |
|
| Lab |
|
A Containerfile lists a set of instructions that a container runtime uses to build a container image. You can use the image to create any number of containers.
Each instruction causes a change that is captured in a resulting image layer. These layers are stacked together to form the resulting container image.
You might have seen or used Dockerfiles instead of Containerfiles. These files are largely the same and mainly differ in historical context.
This course uses Containerfiles because they are not associated with any specific container runtime engine. Podman supports both Dockerfiles and Containerfiles.
When you build an image, podman executes the instructions in the Containerfile and applies the changes on top of a container base image. A base image is the image from which your Containerfile and its resulting image is built.
The base image you choose determines the Linux distribution and its components, such as:
Package manager
Init system
Filesystem layout
Preinstalled dependencies and runtimes
The base image can also influence other factors, such as image size, vendor support, and processor compatibility.
Red Hat provides container images intended as a common starting point for containers known as universal base images (UBI).
These UBIs come in four variants: standard, init, minimal, and micro. Additionally, Red Hat also provides UBI-based images that include popular runtimes, such as Python and Node.js.
These UBIs use Red Hat Enterprise Linux (RHEL) at their core and are available from the Red Hat Container Catalog. The main differences are as follows:
This is the primary UBI, which includes DNF, systemd, and utilities such as gzip and tar.
Simplifies running multiple applications within a single container by managing them with systemd.
This image is smaller than the init image and still provides nice-to-have features. This image uses the microdnf minimal package manager instead of the full-sized version of DNF.
This is the smallest available UBI because it only includes the bare minimum number of packages. For example, this image does not include a package manager.
Containerfiles use a small domain-specific language (DSL) consisting of basic instructions for crafting container images. The following are the most common instructions.
FROM
Sets the base image for the resulting container image. Takes the name of the base image as an argument.
WORKDIR
Sets the current working directory within the container.
Instructions that follow the WORKDIR instruction run within this directory.
COPY and ADD
Copy files from the build host into the file system of the resulting container image. Relative paths use the host current working directory, known as the build context.
Both instructions use the working directory within the container as defined by the WORKDIR instruction.
The ADD instruction adds the following functionality:
Copying files from URLs.
Unpacking tar archives in the destination image.
Because the ADD instruction adds functionality that might not be obvious, developers tend to prefer the COPY instruction for copying local files into the container image.
RUN
Runs a command in the container and commits the resulting state of the container to a new layer within the image.
ENTRYPOINT
Sets the executable to run when the container is started.
CMD
Runs a command when the container is started. This command is passed to the executable defined by ENTRYPOINT. Base images define a default ENTRYPOINT, which is usually a shell executable, such as Bash.
Neither ENTRYPOINT nor CMD run when building a container image.
Podman executes them when you start a container from the image.
USER
Changes the active user within the container.
Instructions that follow the USER instruction run as this user, including the CMD instruction. It is a good practice to define a different user other than root for security reasons.
LABEL
Adds a key-value pair to the metadata of the image for organization and image selection.
EXPOSE
Adds a port to the image metadata indicating that an application within the container binds to this port. This instruction does not bind the port on the host and is for documentation purposes.
ENV
Defines environment variables that are available in the container. You can declare multiple ENV instructions within the Containerfile. You can use the env command inside the container to view each of the environment variables.
ARG
Defines build-time variables, typically to make a customizable container build. Developers commonly configure the ENV instructions by using the ARG instruction. This is useful for preserving the build-time variables for runtime.
VOLUME
Defines where to store data outside of the container. The value configures the path where Podman mounts persistent volume inside of the container. You can define more than one path to create multiple volumes.
Each Containerfile instruction runs in an independent container by using an intermediate image built from every previous command. This means each instruction is independent from other instructions in the Containerfile. The following is an example Containerfile for building a simple Apache web server container:
# This is a comment lineFROM registry.redhat.io/ubi8/ubi:8.6
LABEL description="This is a custom httpd container image"
RUN yum install -y httpd
EXPOSE 80
ENV LogLevel "info"
ADD http://someserver.com/filename.pdf /var/www/html
COPY ./src/ /var/www/html/
USER apache
ENTRYPOINT ["/usr/sbin/httpd"]
CMD ["-D", "FOREGROUND"]
Lines that begin with a hash, or pound, sign ( | |
The | |
The | |
| |
| |
| |
The | |
| |
| |
| |
|
When building a container image, you can specify an image name to later identify the image. The image name is a string composed of letters, numbers, and some special characters.
An image tag comes after the image name and is delimited by a colon (:).
When you omit an image tag, podman uses the default latest tag.
It is a best practice to specify tags in addition to latest tag. Because latest is the default tag applied to new images, references that use the latest tag can change unintentionally.
The full name of the image includes both a name and an optional image tag.
For example, in the full image name my-app:1.0, the name is my-app and the tag is 1.0.
Best practices for building images that pass Red Hat Container Certification
For more information on the differences between UBI variants, refer to the Characteristics of UBI Images chapter in the Building, running, and managing containers guide for RHEL 9 at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/building_running_and_managing_containers/index#con_characteristics-of-ubi-images_assembly_types-of-container-images
The difference between an image name and an image tag is explained in the Podman documentation at https://docs.podman.io/en/latest/markdown/podman-tag.1.html