Chapter 1. Overview of images

Containers, images, and image streams are important concepts to understand when you set out to create and manage containerized software. An image holds a set of software that is ready to run, while a container is a running instance of a container image. An image stream provides a way of storing different versions of the same basic image. Those different versions are represented by different tags on the same image name.

Container images are binaries that include all requirements for running a single container. You can use images to package applications and deploy them across multiple containers and hosts in OpenShift Container Platform.

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 podman or 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 such as fd44297e2ddb050ec4f…​, which is usually shortened to 12 characters, such as fd44297e2ddb.

You can create, manage, and use container images.

An image registry is a content server that stores and serves container images. You can use registries to access container images from external sources or OpenShift Container Platform’s integrated registry.

Registries contain a collection of one or more image repositories, which contain one or more tagged images. Red Hat provides a registry at registry.redhat.io for subscribers. OpenShift Container Platform can also supply its own OpenShift image registry for managing custom container images.

An image repository is a collection of related container images and tags identifying them. You can use image repositories to organize and manage related container images in OpenShift Container Platform.

For example, the OpenShift Container Platform Jenkins images are in the following repository:

docker.io/openshift/jenkins-2-centos7

docker.io/openshift/jenkins-2-centos7

Image tags are labels applied to container images in image streams to distinguish specific versions of images. They help you organize and reference specific versions of images in OpenShift Container Platform.

Typically, an image tag represents a version number of some sort. The following example shows the registry.access.redhat.com/openshift3/jenkins-2-rhel7 image with the tag :v3.11.59-2:

registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2

registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2

You can add additional tags to an image. For example, an image might be assigned the tags :v3.11.59-2 and :latest.

OpenShift Container Platform provides the oc tag command, which is similar to the docker tag command, but operates on image streams instead of directly on images.

Image IDs are Secure Hash Algorithm (SHA) codes that uniquely identify container images. You can use image IDs to pull specific versions of images that never change.

For example, the following image ID is for the docker.io/openshift/jenkins-2-centos7 image:

docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324

docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324

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. The word container is defined as a specific running or paused instance of a container image.

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. The Docker project developed a convenient management interface for Linux containers on a host. More recently, the Open Container Initiative has developed open standards for container formats and container runtimes. OpenShift Container Platform and Kubernetes add the ability to orchestrate OCI- and Docker-formatted containers across multi-host installations.

Though you do not directly interact with container runtimes 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.

Tools such as Podman can be used to replace Docker command-line tools for running and managing containers directly. By using the podman CLI, you can experiment with containers separately from OpenShift Container Platform.

Image streams provide an abstraction for referencing container images from within OpenShift Container Platform. You can use image streams to manage image versions and automate builds and deployments.

Image streams do not contain actual image data, but present a single virtual view of related images, similar to an image repository.

You can configure builds and deployments to watch an image stream for notifications when new images are added and react by performing a build or deployment, respectively.

For example, if a deployment is using a certain image and a new version of that image is created, a deployment could be automatically performed to pick up the new version of the image.

However, if the image stream tag used by the deployment or build is not updated, then even if the container image in the container image registry is updated, the build or deployment continues using the previous, presumably known good image.

The source images can be stored in any of the following:

When you define an object that references an image stream tag, such as a build or deployment configuration, you point to an image stream tag and not the repository. When you build or deploy your application, OpenShift Container Platform queries the repository using the image stream tag to locate the associated ID of the image and uses that exact image.

The image stream metadata is stored in the etcd instance along with other cluster information.

Using image streams has several significant benefits:

You can manage image streams, use image streams with Kubernetes resources, and trigger updates on image stream updates.

Image stream tags are named pointers to images in image streams. You can configure image stream tags to reference specific versions of container images.

Image stream images are API resource objects that retrieve specific container images from image streams. You can use image stream images to access metadata about particular image SHA identifiers in OpenShift Container Platform.

Image stream triggers cause specific actions when image stream tags change. You can configure triggers to automatically start builds or deployments when new images are imported.

For example, importing a new image can cause the value of the tag to change, which causes a trigger to fire when there are deployments, builds, or other resources listening for those.

During the initial startup, the Operator creates the default samples resource to initiate the creation of the image streams and templates. You can use the Cluster Samples Operator to manage the sample image streams and templates stored in the openshift namespace.

As a cluster administrator, you can use the Cluster Samples Operator to:

A template is a definition of an object to be replicated. You can use templates to build and deploy configurations.

As a developer, you can use Ruby on Rails to: