此内容没有您所选择的语言版本。
Chapter 5. Managing imagestreams
Imagestreams provide a means of creating and updating container images in an on-going way. As improvements are made to an image, tags can be used to assign new version numbers and keep track of changes. This document describes how image streams are managed.
5.1. Using imagestreams
An imagestream and its associated tags provide an abstraction for referencing container images from within OpenShift Container Platform. 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 Container Platform’s integrated registry.
-
An external registry, for example
registry.redhat.ioorhub.docker.com. - Other imagestreams in the OpenShift Container Platform 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 Container Platform 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 Container Platform 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.
5.2. Configuring imagestreams
An imagestream object file contains the following elements.
Imagestream object definition
apiVersion: v1
kind: ImageStream
metadata:
annotations:
openshift.io/generated-by: OpenShiftNewApp
creationTimestamp: 2017-09-29T13:33:49Z
generation: 1
labels:
app: ruby-sample-build
template: application-template-stibuild
name: origin-ruby-sample 1
namespace: test
resourceVersion: "633"
selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample 2
tags:
- items:
- created: 2017-09-02T10:15:09Z
dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d 3
generation: 2
image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5 4
- created: 2017-09-29T13:40:11Z
dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
generation: 1
image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
tag: latest 5
- 1
- The name of the imagestream.
- 2
- Docker repository path where new images can be pushed to add/update them in this imagestream.
- 3
- The SHA identifier that this imagestreamtag currently references. Resources that reference this imagestreamtag use this identifier.
- 4
- The SHA identifier that this imagestreamtag previously referenced. Can be used to rollback to an older image.
- 5
- The imagestreamtag name.
5.3. Imagestream images
An imagestream image points from within an imagestream to a particular image ID.
Imagestream images allow you to retrieve metadata about an image from a particular imagestream where it is tagged.
Imagestream image objects are automatically created in OpenShift Container Platform whenever you import or tag an image into the imagestream. You should never have to explicitly define an imagestream image object in any imagestream definition that you use to create imagestreams.
The imagestream image consists of the imagestream name and image ID from the repository, delimited by an @ sign:
<image-stream-name>@<image-id>
To refer to the image in the imagestream object example, the imagestream image looks like:
origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
5.4. Imagestreamtags
An imagestreamtag is a named pointer to an image in an imagestream. It is often abbreviated as istag. An imagestreamtag is used to reference or retrieve an image for a given imagestream and tag.
Imagestreamtags can reference any local or externally managed image. It contains a history of images represented as a stack of all images the tag ever pointed to. Whenever a new or existing image is tagged under particular image stream tag, it is placed at the first position in the history stack. The image previously occupying the top position will be available at the second position, and so forth. This allows for easy rollbacks to make tags point to historical images again.
The following imagestreamtag is from an imagestream object:
Imagestreamtag with two images in its history
tags:
- items:
- created: 2017-09-02T10:15:09Z
dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
generation: 2
image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
- created: 2017-09-29T13:40:11Z
dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
generation: 1
image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
tag: latest
Imagestreamtags can be permanent tags or tracking tags.
- Permanent tags are version-specific tags that point to a particular version of an image, such as Python 3.5.
Tracking tags are reference tags that follow another imagestreamtag and could be updated in the future to change which image they follow, much like a symlink. Note that these new levels are not guaranteed to be backwards-compatible.
For example, the
latestimagestreamtags that ship with OpenShift Container Platform are tracking tags. This means consumers of thelatestimagestreamtag will be updated to the newest level of the framework provided by the image when a new level becomes available. Alatestimagestreamtag tov3.10could be changed tov3.11at any time. It is important to be aware that theselatestimage stream tags behave differently than the Dockerlatesttag. Thelatestimage stream tag, in this case, does not point to the latest image in the Docker repository. It points to another imagestreamtag, which might not be the latest version of an image. For example, if thelatestimagestreamtag points tov3.10of an image, when the3.11version is released, thelatesttag is not automatically updated tov3.11, and remains atv3.10until it is manually updated to point to av3.11imagestreamtag.NoteTracking tags are limited to a single imagestream and cannot reference other imagestreams.
You can create your own imagestreamtags for your own needs.
The imagestreamtag is composed of the name of the imagestream and a tag, separated by a colon:
<imagestream name>:<tag>
For example, to refer to the sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d image in the imagestream object example earlier, the imagestreamtag would be:
origin-ruby-sample:latest
5.5. Imagestream change triggers
Imagestream triggers allow your Builds and Deployments to be automatically invoked when a new version of an upstream image is available.
For example, Builds and Deployments can be automatically started when an image stream tag is modified. This is achieved by monitoring that particular image stream tag and notifying the Build or Deployment when a change is detected.
5.6. Imagestream mapping
When the integrated registry receives a new image, it creates and sends an image stream mapping to OpenShift Container Platform, providing the image’s project, name, tag, and image metadata.
Configuring imagestream mappings is an advanced feature.
This information is used to create a new image (if it does not already exist) and to tag the image into the imagestream. OpenShift Container Platform stores complete metadata about each image, such as commands, entry point, and environment variables. Images in OpenShift Container Platform are immutable and the maximum name length is 63 characters.
The following imagestream mapping example results in an image being tagged as test/origin-ruby-sample:latest:
Imagestream mapping object definition
apiVersion: v1
kind: ImageStreamMapping
metadata:
creationTimestamp: null
name: origin-ruby-sample
namespace: test
tag: latest
image:
dockerImageLayers:
- name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
size: 0
- name: sha256:ee1dd2cb6df21971f4af6de0f1d7782b81fb63156801cfde2bb47b4247c23c29
size: 196634330
- name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
size: 0
- name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
size: 0
- name: sha256:ca062656bff07f18bff46be00f40cfbb069687ec124ac0aa038fd676cfaea092
size: 177723024
- name: sha256:63d529c59c92843c395befd065de516ee9ed4995549f8218eac6ff088bfa6b6e
size: 55679776
- name: sha256:92114219a04977b5563d7dff71ec4caa3a37a15b266ce42ee8f43dba9798c966
size: 11939149
dockerImageMetadata:
Architecture: amd64
Config:
Cmd:
- /usr/libexec/s2i/run
Entrypoint:
- container-entrypoint
Env:
- RACK_ENV=production
- OPENSHIFT_BUILD_NAMESPACE=test
- OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
- EXAMPLE=sample-app
- OPENSHIFT_BUILD_NAME=ruby-sample-build-1
- PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- STI_SCRIPTS_URL=image:///usr/libexec/s2i
- STI_SCRIPTS_PATH=/usr/libexec/s2i
- HOME=/opt/app-root/src
- BASH_ENV=/opt/app-root/etc/scl_enable
- ENV=/opt/app-root/etc/scl_enable
- PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
- RUBY_VERSION=2.2
ExposedPorts:
8080/tcp: {}
Labels:
build-date: 2015-12-23
io.k8s.description: Platform for building and running Ruby 2.2 applications
io.k8s.display-name: 172.30.56.218:5000/test/origin-ruby-sample:latest
io.openshift.build.commit.author: Ben Parees <bparees@users.noreply.github.com>
io.openshift.build.commit.date: Wed Jan 20 10:14:27 2016 -0500
io.openshift.build.commit.id: 00cadc392d39d5ef9117cbc8a31db0889eedd442
io.openshift.build.commit.message: 'Merge pull request #51 from php-coder/fix_url_and_sti'
io.openshift.build.commit.ref: master
io.openshift.build.image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
io.openshift.build.source-location: https://github.com/openshift/ruby-hello-world.git
io.openshift.builder-base-version: 8d95148
io.openshift.builder-version: 8847438ba06307f86ac877465eadc835201241df
io.openshift.s2i.scripts-url: image:///usr/libexec/s2i
io.openshift.tags: builder,ruby,ruby22
io.s2i.scripts-url: image:///usr/libexec/s2i
license: GPLv2
name: CentOS Base Image
vendor: CentOS
User: "1001"
WorkingDir: /opt/app-root/src
Container: 86e9a4a3c760271671ab913616c51c9f3cea846ca524bf07c04a6f6c9e103a76
ContainerConfig:
AttachStdout: true
Cmd:
- /bin/sh
- -c
- tar -C /tmp -xf - && /usr/libexec/s2i/assemble
Entrypoint:
- container-entrypoint
Env:
- RACK_ENV=production
- OPENSHIFT_BUILD_NAME=ruby-sample-build-1
- OPENSHIFT_BUILD_NAMESPACE=test
- OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
- EXAMPLE=sample-app
- PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- STI_SCRIPTS_URL=image:///usr/libexec/s2i
- STI_SCRIPTS_PATH=/usr/libexec/s2i
- HOME=/opt/app-root/src
- BASH_ENV=/opt/app-root/etc/scl_enable
- ENV=/opt/app-root/etc/scl_enable
- PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
- RUBY_VERSION=2.2
ExposedPorts:
8080/tcp: {}
Hostname: ruby-sample-build-1-build
Image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
OpenStdin: true
StdinOnce: true
User: "1001"
WorkingDir: /opt/app-root/src
Created: 2016-01-29T13:40:00Z
DockerVersion: 1.8.2.fc21
Id: 9d7fd5e2d15495802028c569d544329f4286dcd1c9c085ff5699218dbaa69b43
Parent: 57b08d979c86f4500dc8cad639c9518744c8dd39447c055a3517dc9c18d6fccd
Size: 441976279
apiVersion: "1.0"
kind: DockerImage
dockerImageMetadataVersion: "1.0"
dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
5.7. Working with imagestreams
The following sections describe how to use imagestreams and imagestreamtags.
5.7.1. Getting information about imagestreams
You can get general information about the imagestream and detailed information about all the tags it is pointing to.
Procedure
Get general information about the imagestream and detailed information about all the tags it is pointing to:
$ oc describe is/<image-name>
For example:
$ oc describe is/python Name: python Namespace: default Created: About a minute ago Labels: <none> Annotations: openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z Docker Pull Spec: docker-registry.default.svc:5000/default/python Image Lookup: local=false Unique Images: 1 Tags: 1 3.5 tagged from centos/python-35-centos7 * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25 About a minute agoGet all the information available about particular imagestreamtag:
$ oc describe istag/<image-stream>:<tag-name>
For example:
$ oc describe istag/python:latest Image Name: sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25 Docker Image: centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25 Name: sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25 Created: 2 minutes ago Image Size: 251.2 MB (first layer 2.898 MB, last binary layer 72.26 MB) Image Created: 2 weeks ago Author: <none> Arch: amd64 Entrypoint: container-entrypoint Command: /bin/sh -c $STI_SCRIPTS_PATH/usage Working Dir: /opt/app-root/src User: 1001 Exposes Ports: 8080/tcp Docker Labels: build-date=20170801
More information is output than shown.
5.7.2. Adding tags to an imagestream
You can add additional tags to imagestreams.
Procedure
Add a tag that points to one of the existing tags by using the
oc tagcommand:$ oc tag <image-name:tag1> <image-name:tag2>
For example:
$ oc tag python:3.5 python:latest Tag python:latest set to python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25.
Confirm the imagestream has two tags, one (
3.5) pointing at the external container image and another tag (latest) pointing to the same image because it was created based on the first tag.$ oc describe is/python Name: python Namespace: default Created: 5 minutes ago Labels: <none> Annotations: openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z Docker Pull Spec: docker-registry.default.svc:5000/default/python Image Lookup: local=false Unique Images: 1 Tags: 2 latest tagged from python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25 * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25 About a minute ago 3.5 tagged from centos/python-35-centos7 * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25 5 minutes ago
5.7.3. Adding tags for an external image
You can add tags for external images.
Procedure
Add tags pointing to internal or external images, by using the
oc tagcommand for all tag-related operations:$ oc tag <repository/image> <image-name:tag>
For example, this command maps the
docker.io/python:3.6.0image to the3.6tag in thepythonimagestream.$ oc tag docker.io/python:3.6.0 python:3.6 Tag python:3.6 set to docker.io/python:3.6.0.
If the external image is secured, you must create a secret with credentials for accessing that registry.
5.7.4. Updating imagestreamtags
You can update a tag to reflect another tag in an imagestream.
Procedure
Update a tag:
$ oc tag <image-name:tag> <image-name:latest>
For example, the following updates the
latesttag to reflect the3.6tag in an imagestream:$ oc tag python:3.6 python:latest Tag python:latest set to python@sha256:438208801c4806548460b27bd1fbcb7bb188273d13871ab43f.
5.7.5. Removing imagestreamtags
You can remove old tags from an imagestream.
Procedure
Remove old tags from an imagestream:
$ oc tag -d <image-name:tag>
For example:
$ oc tag -d python:3.5 Deleted tag default/python:3.5.
5.7.6. Configuring periodic importing of imagestreamtags
When working with an external container image registry, to periodically re-import an image, for example to get latest security updates, you can use the --scheduled flag.
Procedure
Schedule importing images:
$ oc tag <repositiory/image> <image-name:tag> --scheduled
For example:
$ oc tag docker.io/python:3.6.0 python:3.6 --scheduled Tag python:3.6 set to import docker.io/python:3.6.0 periodically.
This command causes OpenShift Container Platform to periodically update this particular image stream tag. This period is a cluster-wide setting set to 15 minutes by default.
Remove the periodic check, re-run above command but omit the
--scheduledflag. This will reset its behavior to default.$ oc tag <repositiory/image> <image-name:tag>
