Containers, images, and imagestreams 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 imagestream 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.
Containers in OpenShift Dedicated are based on OCI- or 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 Dedicated 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 Dedicated 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
fd44297e2ddb050ec4f…) which is usually shortened to 12
The basic units of OpenShift Dedicated 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 Dedicated 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 Dedicated, understanding their capabilities and terminology is important for understanding their role in OpenShift Dedicated and how your applications function inside of containers.
Tools such as
can be used to replace
docker command-line tools for running and managing
containers directly. Using
podman, you can experiment with containers
separately from OpenShift Dedicated.
An image registry is a content server that can store and serve container images. For example:
A registry contains 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 Dedicated can also supply its own
internal registry for managing custom container images.
An image repository is a collection of related container images and tags identifying them. For example, the OpenShift Jenkins images are in the repository:
An image tag is a label applied to a container image in a repository that distinguishes a specific image from other images in an imagestream. Typically, the tag represents a version number of some sort. For example, here v3.11.59-2 is the tag:
You can add additional tags to an image. For example, an image might be assigned the tags :v3.11.59-2 and :latest.
An image ID is a SHA (Secure Hash Algorithm) code that can be used to pull an image. A SHA image ID cannot change. A specific SHA identifier always references the exact same container image content. For example:
An imagestream and its associated tags provide an abstraction for referencing container images from within OpenShift Dedicated. The imagestream and its tags allow you to see what images are available and ensure that you are using the specific image you need even if the image in the repository changes.
Imagestreams 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 imagestream 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 imagestreamtag 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 will continue using the previous, presumably known good image.
The source images can be stored in any of the following:
OpenShift Dedicated’s integrated registry.
An external registry, for example
Other imagestreams in the OpenShift Dedicated cluster.
When you define an object that references an imagestreamtag (such as a Build or Deployment configuration), you point to an imagestreamtag, not the Docker repository. When you Build or Deploy your application, OpenShift Dedicated queries the Docker repository using the imagestreamtag to locate the associated ID of the image and uses that exact image.
The imagestream metadata is stored in the etcd instance along with other cluster information.
Using imagestreams has several significant benefits:
You can tag, rollback a tag, and quickly deal with images, without having to re-push using the command line.
You can trigger Builds and Deployments when a new image is pushed to the registry. Also, OpenShift Dedicated has generic triggers for other resources, such as Kubernetes objects.
You can mark a tag for periodic re-import. If the source image has changed, that change is picked up and reflected in the imagestream, which triggers the Build and/or Deployment flow, depending upon the Build or Deployment configuration.
You can share images using fine-grained access control and quickly distribute images across your teams.
If the source image changes, the imagestreamtag will still point to a known-good version of the image, ensuring that your application will not break unexpectedly.
You can configure security around who can view and use the images through permissions on the imagestream objects.
Users that lack permission to read or list images on the cluster level can still retrieve the images tagged in a project using imagestreams.
An imagestream image allows you to retrieve a specific container image from a particular imagestream where it is tagged. An image stream image is an API resource object that pulls together some metadata about a particular image SHA identifier.
An imagestream trigger causes a specific action when an imagestreamtag changes. For example, importing 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.
For more information on using imagestreams, see Managing image streams.