Containers and Images

Containers

The basic units of OpenShift Container Platform applications are called containers.
Linux container technologies
are lightweight mechanisms for isolating running processes so that they are
limited to interacting with only their designated resources.

Many application instances can be running in containers on a single host without
visibility into each others' processes, files, network, and so on. Typically,
each container provides a single service (often called a "micro-service"), such
as a web server or a database, though containers can be used for arbitrary
workloads.

The Linux kernel has been incorporating capabilities for container technologies
for years. More recently the Docker project has developed a convenient
management interface for Linux containers on a host. OpenShift Container Platform and
Kubernetes add the ability to orchestrate Docker-formatted containers across
multi-host installations.

Though you do not directly interact with the Docker CLI or service when using
OpenShift Container Platform, understanding their capabilities and terminology is
important for understanding their role in OpenShift Container Platform and how your
applications function inside of containers. The docker RPM is available
as part of RHEL 7, as well as CentOS and Fedora, so you can
experiment with it separately from OpenShift Container Platform. Refer to the article
Get Started with Docker Formatted Container Images on Red Hat Systems for a guided introduction.

Init Containers

A pod can have init containers in addition to application containers. Init
containers allow you to reorganize setup scripts and binding code. An init
container differs from a regular container in that it always runs to completion.
Each init container must complete successfully before the next one is started.

Images

Containers in OpenShift Container Platform are based on Docker-formatted container images. An
image is a binary that includes all of the requirements for running a single
container, as well as metadata describing its needs and capabilities.

You can think of it as a packaging technology. Containers only have access to
resources defined in the image unless you give the container additional access
when creating it. By deploying the same image in multiple containers across
multiple hosts and load balancing between them, OpenShift Container Platform can provide
redundancy and horizontal scaling for a service packaged into an image.

You can use the Docker CLI directly to build images, but OpenShift Container Platform also
supplies builder images that assist with creating new images by adding your code
or configuration to existing images.

Because applications develop over time, a single image name can actually
refer to many different versions of the "same" image. Each different
image is referred to uniquely by its hash (a long hexadecimal number
e.g. fd44297e2ddb050ec4f…​) which is usually shortened to 12
characters (e.g. fd44297e2ddb).

Image Version Tag Policy

Rather than version numbers, the Docker service allows applying tags (such as
v1, v2.1, GA, or the default latest) in addition to the image name to
further specify the image desired, so you may see the same image referred to as
centos (implying the latest tag), centos:centos7, or fd44297e2ddb.

Do not use the latest tag for any official OpenShift Container Platform images. These are
images that start with openshift3/. latest can refer to a number of
versions, such as 3.4, or 3.5.

How you tag the images dictates the updating policy. The more specific you are, the less frequently the image will be updated. Use the following to determine your chosen OpenShift Container Platform images policy:

vX.Y

The vX.Y tag points to X.Y.Z-<number>. For example, if the registry-console
image is updated to v3.4, it points to the newest 3.4.Z-<number> tag, such
as 3.4.1-8.

X.Y.Z

Similar to the vX.Y example above, the X.Y.Z tag points to the latest
X.Y.Z-<number>. For example, 3.4.1 would point to 3.4.1-8

X.Y.Z-<number>

The tag is unique and does not change. When using this tag, the image does not update if an image is updated. For example, the 3.4.1-8 will always point to 3.4.1-8, even if an image is updated.

Container Registries

A container registry is a service for storing and retrieving Docker-formatted
container images. A registry contains a collection of one or more image
repositories. Each image repository contains one or more tagged images. Docker
provides its own registry, the Docker Hub, and you can also use private or third-party registries. Red Hat provides a
registry at registry.access.redhat.com for subscribers. OpenShift Container Platform can
also supply its own internal registry for managing custom container images.

The relationship between containers, images, and registries is depicted in the
following diagram: