Explain container concepts and the core technologies for building, storing, and running containers.

Software applications typically depend on system libraries, configuration files, or services that their runtime environment provides. Traditionally, the runtime environment for a software application is installed in an operating system that runs on a physical host or a virtual machine. Administrators then install application dependencies on top of the operating system.

In Red Hat Enterprise Linux, packaging systems such as RPM help administrators to manage application dependencies. When you install the httpd package, the RPM system ensures that the correct libraries and other dependencies for that package are also installed.

The major drawback to traditionally deployed software applications is that these dependencies are entangled with the runtime environment. An application might require earlier or later versions of supporting software than the software that is provided with the operating system. Similarly, two applications on the same system might require different and incompatible versions of the same software.

One way to resolve these conflicts is to package and deploy the application as a container. A container is a set of one or more processes that are isolated from the rest of the system. Software containers provide a way to package applications and to simplify their deployment and management.

Think of a physical shipping container. A shipping container is a standard way to package and ship goods. It is labeled, loaded, unloaded, and transported from one location to another as a single box. The container's contents are isolated from the contents of other containers so that they do not affect each other. These underlying principles also apply to software containers.

Red Hat Enterprise Linux supports containers by using the following core technologies:

Differences Between Containers and Virtual Machines

Containers provide many of the same benefits as virtual machines, such as security, storage, and network isolation.

Both technologies isolate their application libraries and runtime resources from the host operating system or hypervisor, and vice versa.

Figure 16.1: Comparison between virtualization and containerization

Containers and virtual machines interact differently with hardware and the underlying operating system.

A virtual machine has the following characteristics:

• Enables multiple operating systems to run simultaneously on a single hardware platform.

• Uses a hypervisor to divide hardware into multiple virtual hardware systems.

• Requires a complete operating system environment to support the application.

A container has the following characteristics:

• Runs directly on the host operating system, and it shares resources with all containers on the system.

• Shares the host's kernel, but it isolates the application processes from the rest of the system.

• Requires far fewer hardware resources than virtual machines, so containers are also quicker to start.

• Includes all dependencies, such as system and programming dependencies, and configuration settings.

Note

Some applications might not be suitable to run as a container. For example, applications that access low-level hardware information might need more direct hardware access than containers generally provide.

To run containers, you must use a container image. A container image is a static file that contains codified steps, and it serves as a blueprint to create containers. The container images package an application with all its dependencies, such as its system libraries, programming language runtimes and libraries, and other configuration settings.

Container images are built according to specifications, such as the Open Container Initiative (OCI) image format specification. These specifications define the format for container images, as well as the metadata about the container host operating systems and hardware architectures that the image supports.

A container registry is a repository for storing and retrieving container images. A developer pushes or uploads container images to a container registry. You can pull or download container images from a registry to a local system to run containers.

You might use a public registry that contains third-party images, or you might use a private registry that your organization controls. The source of your container images matters. As with any other software package, you must know whether you can trust the code in the container image. Policies vary between registries about whether and how they provide, evaluate, and test container images that are submitted to them.

Red Hat distributes certified container images through two main container registries that you can access with your Red Hat login credentials:

The Red Hat Container Catalog (https://access.redhat.com/containers) provides a web-based interface to search these registries for certified content.

You need a Red Hat Developer account to download an image from the Red Hat registries. You can use the podman login command to authenticate to the registries. If you do not provide a registry URL to the podman login command, then it authenticates to the default configured registry.

[user@host ~]$ podman login registry.lab.example.com
Username: RH134
Password: EXAMPLEPASSWORD
Login Succeeded!

You can also use the podman login command --username and --password-stdin options, to specify the user and password to log in to the registry. The --password-stdin option reads the password from stdin. Red Hat does not recommend using the --password option to provide the password directly, because this option stores the password in the log files.

[user@host ~]# echo $PASSWORDVAR | podman login --username RH134 \
--password-stdin registry.access.redhat.com

To verify that you are logged in to a registry, use the podman login command --get-login option.

[user01@rhel-vm ~]$ podman login registry.access.redhat.com --get-login
RH134
[user01@rhel-vm ~]$ podman login quay.io --get-login
Error: not logged into quay.io

In the preceding output, the podman utility is authenticated to the registry.access.redhat.com registry with the RH134 user credentials, but the podman utility is not authenticated to the quay.io registry.

[user@host ~]$ cat /etc/containers/registries.conf
# For more information on this configuration file, see containers-registries.conf(5).
#
...output omitted...

unqualified-search-registries = ["registry.fedoraproject.org", "registry.access.redhat.com", "registry.centos.org", "quay.io", "docker.io"]

# [[registry]]
# # The "prefix" field is used to choose the relevant [[registry]] TOML table;
# # (only) the TOML table with the longest match for the input image name
# # (taking into account namespace/repo/tag/digest separators) is used.
# #
# # The prefix can also be of the form: *.example.com for wildcard subdomain
# # matching.
# #
# # If the prefix field is missing, it defaults to be the same as the "location" field.
# prefix = "example.com/foo"
#
# # If true, unencrypted HTTP as well as TLS connections with untrusted
# # certificates are allowed.
# insecure = false
#
# # If true, pulling images with matching names is forbidden.
# blocked = false
#
...output omitted...

[user@host ~]$ podman pull ubi

[user@host ~]$ podman pull registry.access.redhat.com/ubi8/ubi:latest

[[registry]]
location = "registry.lab.example.com"
insecure = true
blocked = false

[user@host ~]$ cat Containerfile
FROM registry.access.redhat.com/ubi8/ubi:latest
RUN dnf install -y python3
CMD ["/bin/bash", "-c", "echo hello"]

New applications increasingly use containers to implement functional components. Those containers provide services that other parts of the application consume. In an organization, managing a growing number of containers might become an overwhelming task.

Deploying containers at scale in production requires an environment that can adapt to the following challenges:

Kubernetes is an orchestration service that deploys, manages, and scales container-based applications across a cluster of container hosts. Kubernetes redirects traffic to your containers with a load balancer, so that you can scale the number of containers that provide a service. Kubernetes also supports user-defined health checks to monitor your containers and to restart them if they fail.

Red Hat provides a distribution of Kubernetes called Red Hat OpenShift. Red Hat OpenShift is a set of modular components and services that are built on top of the Kubernetes infrastructure. It provides additional features, such as remote web-based management, multitenancy, monitoring and auditing, advanced security features, application lifecycle management, and self-service instances for developers.

Red Hat OpenShift is beyond the scope of this course, and you can learn more about it at https://www.openshift.com.