cancel
Showing results for 
Search instead for 
Did you mean: 
Skrh2023
Cadet
Cadet
  • 189 Views

OpenShift- ImageStream Obj

I'm having hard time to wrap my understanding on OpenShift ImageStream object and it's feature set.

What I know reading various available documents on this is, Image stream obj is that it is an virtual object created by OpenShift

and stored in etdc db with a ref to source image digest and source image tag plus with its own image-stream -object tag.

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

 Source              Image ID                   Tage

 quay.io             /repo/image-ID           Image Tag

 

Image Digest              Image tag                       Image-stream-tag

Imageid (sha-digest)   Source image tag          Image-stream tag created by OpenShift

 

So, having a ref to the source image-digest rather than source image-tags, image-stream avoids image updates based on tags. This is understood to a level.

But how is then automatic trigger and subsequent image update rollout works ?

Once we set / configure the trigger(s) to watch a particular image source, (my understanding is watching a image source digest + source image tag combo for a change) if this is true,

When a new image is uploaded we have new image-id but how does the watcher knowns that there is a new image with ref to the watched image-digest ? Will their be a back-link of some kind reference to image-id ?

Or does it poll all images under the repo and monitors the change ? that would be very tedious and overloading registry service.

** 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.**

May be I totally mis-understood this image-stream obj, kindly help me clear my mental clog on this topic.

 

2 Replies
VishalBadgujar
Mission Specialist
Mission Specialist
  • 38 Views

OpenShift leads to no need for continuous polling for changes because it's using an event-driven architecture. Instead, it waits for the triggers from the container registry. Most of the modern container registries have supported the webhook features for Eg: Docker Hub. Accordingly, when a new image is uploaded to the registry, it contacts OpenShift and sends an HTTP POST request that carries information about the image to a specified address.

An Push or tag event is generated by the registry when a image is uploaded to the registry. It employs webhooks to send this event to OpenShift and other pieces of information like Image ID, digest: a SHA-256 hash of the new image, Tags. As these webhook messages are directed to OpenShift, they allow it to respond quickly, instead of having to poll for notifications. 

In case a webhook notification is received, OpenShift examines the received data for consistency. adds the modified image details to the respective ImageStream
It may create a new entry within the ImageStream, linking the new image ID with the corresponding digest and any associated tags.
This update could mean adding or updating the image reference in the ImageStream, thus incorporating a new image to the ImageStream.

If all the specified triggers that are watching this ImageStream are altered in accordance with the changed ImageStream data, this applies similarly for the ImageStream changes.
For example, if you trigger a deployment on a new image, OpenShift will trigger off a new deployment based on the image ID and the relevant tags.

Skrh2023
Cadet
Cadet
  • 33 Views

Thanks Vishal for responding to the query, I really appreicate it,

Will go thru your inputs and try to digest the content.

 

Join the discussion
You must log in to join this conversation.