An image stream and its associated tags provide an abstraction for referencing container images from within Red Hat OpenShift Service on AWS. The image stream 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.
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:
-
Red Hat OpenShift Service on AWS’s integrated registry.
-
An external registry, for example registry.redhat.io or quay.io.
-
Other image streams in the Red Hat OpenShift Service on AWS cluster.
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, Red Hat OpenShift Service on AWS 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 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, Red Hat OpenShift Service on AWS 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 image stream, which triggers the build 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 image stream tag still points to a known-good version of the image, ensuring that your application does not break unexpectedly.
-
You can configure security around who can view and use the images through permissions on the image stream objects.
-
Users that lack permission to read or list images on the cluster level can still retrieve the images tagged in a project using image streams.