Questo contenuto non è disponibile nella lingua selezionata.
Chapter 5. Managing images
5.1. Managing images overview Copia collegamentoCollegamento copiato negli appunti!
With OpenShift Container Platform you can interact with images and set up image streams, depending on where the registries of the images are located, any authentication requirements around those registries, and how you want your builds and deployments to behave.
5.1.1. Images overview Copia collegamentoCollegamento copiato negli appunti!
An image stream comprises any number of container images identified by tags. It presents a single virtual view of related images, similar to a container image repository.
By watching an image stream, builds and deployments can receive notifications when new images are added or modified and react by performing a build or deployment, respectively.
5.2. Tagging images Copia collegamentoCollegamento copiato negli appunti!
The following sections provide an overview and instructions for using image tags in the context of container images for working with OpenShift Container Platform image streams and their tags.
5.2.1. Image tags Copia collegamentoCollegamento copiato negli appunti!
An image tag is a label applied to a container image in a repository that distinguishes a specific image from other images in an image stream. Typically, the tag represents a version number of some sort. For example, here
: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
:latest
OpenShift Container Platform provides the
oc tag
docker tag
5.2.2. Image tag conventions Copia collegamentoCollegamento copiato negli appunti!
Images evolve over time and their tags reflect this. Generally, an image tag always points to the latest image built.
If there is too much information embedded in a tag name, like
v2.0.1-may-2019
If the tag is named
v2.0
Although tag naming convention is up to you, here are a few examples in the format
<image_name>:<image_tag>
| Description | Example |
|---|---|
| Revision |
|
| Architecture |
|
| Base image |
|
| Latest (potentially unstable) |
|
| Latest stable |
|
If you require dates in tag names, periodically inspect old and unsupported images and
istags
5.2.3. Adding tags to image streams Copia collegamentoCollegamento copiato negli appunti!
An image stream in OpenShift Container Platform comprises zero or more container images identified by tags.
There are different types of tags available. The default behavior uses a
permanent
permanent
A
tracking
Procedure
You can add tags to an image stream using the
command:oc tag$ oc tag <source> <destination>For example, to configure the
image streamrubytag to always refer to the current image for thestatic-2.0image streamrubytag:2.0$ oc tag ruby:2.0 ruby:static-2.0This creates a new image stream tag named
in thestatic-2.0image stream. The new tag directly references the image id that therubyimage stream tag pointed to at the timeruby:2.0was run, and the image it points to never changes.oc tagTo ensure the destination tag is updated when the source tag changes, use the
flag:--alias=true$ oc tag --alias=true <source> <destination>
Use a tracking tag for creating permanent aliases, for example,
latest
stable
-
You can also add the flag to have the destination tag be refreshed, or re-imported, periodically. The period is configured globally at the system level.
--scheduled=true The
flag creates an image stream tag that is not imported. The tag points to the source location, permanently.--referenceIf you want to instruct OpenShift Container Platform to always fetch the tagged image from the integrated registry, use
. The registry uses the pull-through feature to serve the image to the client. By default, the image blobs are mirrored locally by the registry. As a result, they can be pulled more quickly the next time they are needed. The flag also allows for pulling from insecure registries without a need to supply--reference-policy=localto the container runtime as long as the image stream has an insecure annotation or the tag has an insecure import policy.--insecure-registry
5.2.4. Removing tags from image streams Copia collegamentoCollegamento copiato negli appunti!
You can remove tags from an image stream.
Procedure
To remove a tag completely from an image stream run:
$ oc delete istag/ruby:latestor:
$ oc tag -d ruby:latest
5.2.5. Referencing images in imagestreams Copia collegamentoCollegamento copiato negli appunti!
You can use tags to reference images in image streams using the following reference types.
| Reference type | Description |
|---|---|
|
| An
|
|
| An
|
|
| A
|
When viewing example image stream definitions you may notice they contain definitions of
ImageStreamTag
DockerImage
ImageStreamImage
This is because the
ImageStreamImage
ImageStreamImage
Procedure
To reference an image for a given image stream and tag, use
:ImageStreamTag<image_stream_name>:<tag>To reference an image for a given image stream and image
ID, usesha:ImageStreamImage<image_stream_name>@<id>The
is an immutable identifier for a specific image, also called a digest.<id>To reference or retrieve an image for a given external registry, use
:DockerImageopenshift/ruby-20-centos7:2.0NoteWhen no tag is specified, it is assumed the
tag is used.latestYou can also reference a third-party registry:
registry.redhat.io/rhel7:latestOr an image with a digest:
centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
5.3. Image pull policy Copia collegamentoCollegamento copiato negli appunti!
Each container in a pod has a container image. After you have created an image and pushed it to a registry, you can then refer to it in the pod.
5.3.1. Image pull policy overview Copia collegamentoCollegamento copiato negli appunti!
When OpenShift Container Platform creates containers, it uses the container
imagePullPolicy
imagePullPolicy
| Value | Description |
|---|---|
|
| Always pull the image. |
|
| Only pull the image if it does not already exist on the node. |
|
| Never pull the image. |
If a container
imagePullPolicy
-
If the tag is , OpenShift Container Platform defaults
latesttoimagePullPolicy.Always -
Otherwise, OpenShift Container Platform defaults to
imagePullPolicy.IfNotPresent
5.4. Using image pull secrets Copia collegamentoCollegamento copiato negli appunti!
If you are using the OpenShift image registry and are pulling from image streams located in the same project, then your pod service account should already have the correct permissions and no additional action should be required.
However, for other scenarios, such as referencing images across OpenShift Container Platform projects or from secured registries, additional configuration steps are required.
You can obtain the image pull secret from the Red Hat OpenShift Cluster Manager. This pull secret is called
pullSecret
You use this pull secret to authenticate with the services that are provided by the included authorities, Quay.io and registry.redhat.io, which serve the container images for OpenShift Container Platform components.
5.4.1. Allowing pods to reference images across projects Copia collegamentoCollegamento copiato negli appunti!
When using the OpenShift image registry, to allow pods in
project-a
project-b
project-a
system:image-puller
project-b
When you create a pod service account or a namespace, wait until the service account is provisioned with a docker pull secret; if you create a pod before its service account is fully provisioned, the pod fails to access the OpenShift image registry.
Procedure
To allow pods in
to reference images inproject-a, bind a service account inproject-bto theproject-arole insystem:image-puller:project-b$ oc policy add-role-to-user \ system:image-puller system:serviceaccount:project-a:default \ --namespace=project-bAfter adding that role, the pods in
that reference the default service account are able to pull images fromproject-a.project-bTo allow access for any service account in
, use the group:project-a$ oc policy add-role-to-group \ system:image-puller system:serviceaccounts:project-a \ --namespace=project-b
5.4.2. Allowing pods to reference images from other secured registries Copia collegamentoCollegamento copiato negli appunti!
The
.dockercfg
$HOME/.docker/config.json
To pull a secured container image that is not from OpenShift image registry, you must create a pull secret from your Docker credentials and add it to your service account.
The Docker credentials file and the associated pull secret can contain multiple references to the same registry, each with its own set of credentials.
Example config.json file
{
"auths":{
"cloud.openshift.com":{
"auth":"b3Blb=",
"email":"you@example.com"
},
"quay.io":{
"auth":"b3Blb=",
"email":"you@example.com"
},
"quay.io/repository-main":{
"auth":"b3Blb=",
"email":"you@example.com"
}
}
}
Example pull secret
apiVersion: v1
data:
.dockerconfigjson: ewogICAiYXV0aHMiOnsKICAgICAgIm0iOnsKICAgICAgIsKICAgICAgICAgImF1dGgiOiJiM0JsYj0iLAogICAgICAgICAiZW1haWwiOiJ5b3VAZXhhbXBsZS5jb20iCiAgICAgIH0KICAgfQp9Cg==
kind: Secret
metadata:
creationTimestamp: "2021-09-09T19:10:11Z"
name: pull-secret
namespace: default
resourceVersion: "37676"
uid: e2851531-01bc-48ba-878c-de96cfe31020
type: Opaque
Procedure
If you already have a
file for the secured registry, you can create a secret from that file by running:.dockercfg$ oc create secret generic <pull_secret_name> \ --from-file=.dockercfg=<path/to/.dockercfg> \ --type=kubernetes.io/dockercfgOr if you have a
file:$HOME/.docker/config.json$ oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjsonIf you do not already have a Docker credentials file for the secured registry, you can create a secret by running:
$ oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>To use a secret for pulling images for pods, you must add the secret to your service account. The name of the service account in this example should match the name of the service account the pod uses. The default service account is
:default$ oc secrets link default <pull_secret_name> --for=pull
5.4.2.1. Pulling from private registries with delegated authentication Copia collegamentoCollegamento copiato negli appunti!
A private registry can delegate authentication to a separate service. In these cases, image pull secrets must be defined for both the authentication and registry endpoints.
Procedure
Create a secret for the delegated authentication server:
$ oc create secret docker-registry \ --docker-server=sso.redhat.com \ --docker-username=developer@example.com \ --docker-password=******** \ --docker-email=unused \ redhat-connect-sso secret/redhat-connect-ssoCreate a secret for the private registry:
$ oc create secret docker-registry \ --docker-server=privateregistry.example.com \ --docker-username=developer@example.com \ --docker-password=******** \ --docker-email=unused \ private-registry secret/private-registry
5.4.3. Updating the global cluster pull secret Copia collegamentoCollegamento copiato negli appunti!
You can update the global pull secret for your cluster by either replacing the current pull secret or appending a new pull secret.
To transfer your cluster to another owner, you must first initiate the transfer in OpenShift Cluster Manager Hybrid Cloud Console, and then update the pull secret on the cluster. Updating a cluster’s pull secret without initiating the transfer in OpenShift Cluster Manager causes the cluster to stop reporting Telemetry metrics in OpenShift Cluster Manager.
For more information about transferring cluster ownership, see "Transferring cluster ownership" in the Red Hat OpenShift Cluster Manager documentation.
Prerequisites
-
You have access to the cluster as a user with the role.
cluster-admin
Procedure
Optional: To append a new pull secret to the existing pull secret, complete the following steps:
Enter the following command to download the pull secret:
$ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location>1 - 1
- Provide the path to the pull secret file.
Enter the following command to add the new pull secret:
$ oc registry login --registry="<registry>" \1 --auth-basic="<username>:<password>" \2 --to=<pull_secret_location>3 Alternatively, you can perform a manual update to the pull secret file.
Enter the following command to update the global pull secret for your cluster:
$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location>1 - 1
- Provide the path to the new pull secret file.
This update is rolled out to all nodes, which can take some time depending on the size of your cluster.
NoteAs of OpenShift Container Platform 4.7.4, changes to the global pull secret no longer trigger a node drain or reboot.