イメージ

コンテナーイメージは、1 つのコンテナーを実行するために必要なものをすべて含んでいるバイナリーです。OpenShift Container Platform では、イメージを使用してアプリケーションをパッケージ化し、複数のコンテナーとホストに一貫してデプロイできます。

コンテナーは、作成時にコンテナーに追加のアクセスを付与しない限り、イメージで定義されるリソースにのみアクセスできます。同じイメージを複数のホストにまたがって複数のコンテナーにデプロイし、それらの間で負荷を分散することにより、OpenShift Container Platform はイメージにパッケージ化されたサービスの冗長性および水平的なスケーリングを提供できます。

イメージをビルドするために podman または docker CLI を直接使用することはできますが、OpenShift Container Platform は、コードまたは設定を既存イメージに追加して新規イメージの作成を支援するビルダーイメージも提供します。

アプリケーションは一定期間をかけて開発されるため、単一のイメージ名が同じイメージの数多くの異なるバージョンを参照する場合があります。それぞれの異なるイメージは、通常は 12 文字 (例: fd44297e2ddb) に省略されるそのハッシュ (fd44297e2ddb050ec4f…​ などの長い 16 進数) で一意に参照されます。

イメージレジストリーとは、OpenShift Container Platform においてコンテナーイメージを保存および提供するコンテンツサーバーのことです。レジストリーを使用すると、外部ソースまたは OpenShift Container Platform に統合されたレジストリーからコンテナーイメージにアクセスできます。

レジストリーには、1 つ以上のイメージリポジトリー群が含まれています。各リポジトリーには、1 つ以上のタグ付けされたイメージが含まれています。Red Hat は、サブスクリプションをお持ちのお客様に対して registry.redhat.io でレジストリーを提供しています。OpenShift Container Platform は、カスタムコンテナーイメージを管理するための独自の OpenShift イメージレジストリーを提供することもできます。

イメージリポジトリーとは、関連するコンテナーイメージと、それらを識別するタグの集合体です。イメージリポジトリーを使用すると、OpenShift Container Platform 内の関連するコンテナーイメージを整理および管理できます。

たとえば、OpenShift Container Platform Jenkins イメージは次のリポジトリーにあります。

docker.io/openshift/jenkins-2-centos7

OpenShift Container Platform のイメージタグを使用すると、イメージストリーム内のコンテナーイメージの特定のバージョンを整理、識別、参照できます。タグとは、特定のイメージレイヤーやダイジェストへのポインターとして機能する、人間が読みやすいラベルのことです。

タグは、イメージストリーム内で可変ポインターとして機能します。新しいイメージがストリームにインポートまたはタグ付けされると、タグは新しいイメージの不変の SHA ダイジェストを指すように更新されます。1 つのイメージダイジェストには、複数のタグを同時に割り当てることができます。たとえば、:v3.11.59-2 と :latest という タグは、同じイメージダイジェストに割り当てられます。

タグには主に 2 つの利点があります。

イメージタグは主に設定ファイル内のイメージを参照するために使用されますが、OpenShift Container Platform では、イメージストリーム内でタグを直接管理するための oc tag コマンドが提供されています。このコマンドは、podman の tag コマンド や docker の tag コマンドに似ていますが、ローカルイメージを直接操作するのではなく、イメージストリームに対して操作を行います。これは、イメージストリーム内で新しいタグポインターを作成したり、既存のタグポインターを更新して新しいイメージを指すようにするために使用されます。

イメージタグは、コロン (:) を区切り文字として使用して、イメージ名またはイメージストリーム名に追加されます。

イメージ ID は、OpenShift Container Platform においてコンテナーイメージを一意に識別するセキュアハッシュアルゴリズム (SHA) コードです。イメージ ID を使用すると、決して変更されない特定のバージョンのイメージをプルできます。

たとえば、次のイメージ ID は docker.io/openshift/jenkins-2-centos7 イメージのものです。

docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324

コンテナーとは、OpenShift Container Platform アプリケーションの基本単位として機能する、コンテナーイメージの独立した実行インスタンスのことです。コンテナーを理解することで、コンテナー化されたアプリケーションを操作し、クラスター内での実行方法を管理できるようになります。

数多くのアプリケーションインスタンスは、相互のプロセス、ファイル、ネットワークなどを可視化せずに単一ホストのコンテナーで実行される可能性があります。通常、コンテナーは任意のワークロードに使用されますが、各コンテナーは Web サーバーまたはデータベースなどの (通常はマイクロサービスと呼ばれることの多い) 単一サービスを提供します。

Linux カーネルは数年にわたりコンテナーテクノロジーの各種機能を統合してきました。Docker プロジェクトはホスト上の Linux コンテナーの便利な管理インターフェイスを開発しました。さらに最近では、Open Container Initiative により、コンテナー形式およびコンテナーランタイムのオープン標準が策定されています。OpenShift Container Platform および Kubernetes は複数ホストのインストール間で OCI および Docker 形式のコンテナーのオーケストレーションを実行する機能を追加しています。

OpenShift Container Platform を使用する際にコンテナーランタイムと直接対話することはありませんが、それらの OpenShift Container Platform におけるロールやコンテナー内でのアプリケーションの機能を理解する上で、それらの機能および用語を理解しておくことは重要です。

Podman などのツールは、コンテナーを直接実行および管理するための Docker コマンドラインツールの代わりとして使用できます。podman CLI を使用すると、OpenShift Container Platform と切り離してコンテナーを試すことができます。

イメージストリームは、OpenShift Container Platform 内でコンテナーイメージを参照するための抽象化を提供します。イメージストリームを使用すると、イメージバージョンの管理、クラスター内でのビルドおよびデプロイメントの自動化を行うことができます。

イメージストリームには実際のイメージデータは含まれませんが、イメージリポジトリーと同様に、関連するイメージの単一の仮想ビューが提示されます。

ビルドおよびデプロイメントをそれぞれ実行し、ビルドおよびデプロイメントを、新規イメージが追加される際やこれに対応する際の通知をイメージストリームで確認できるように設定できます。

たとえば、デプロイメントで特定のイメージを使用していて、そのイメージの新規バージョンが作成される場合、デプロイメントを、そのイメージの新規バージョンを選択できるように自動的に実行きます。

デプロイメントまたはビルドで使用するイメージストリームタグが更新されない場合には、コンテナーイメージレジストリーのコンテナーイメージが更新されても、ビルドまたはデプロイメントは以前の、既知でおそらく適切であると予想されるイメージをそのまま使用します。

ソースイメージは以下のいずれかに保存できます。

ビルドまたはデプロイメント設定などのイメージストリームタグを参照するオブジェクトを定義する場合には、リポジトリーではなく、イメージストリームタグを参照します。アプリケーションのビルドまたはデプロイ時に、OpenShift Container Platform がこのイメージストリームタグを使用してリポジトリーに対してクエリーし、対象のイメージに関連付けられた ID を特定して、そのイメージを使用します。

イメージストリームメタデータは他のクラスター情報と共に etcd インスタンスに保存されます。

イメージストリームの使用には、いくつかの大きな利点があります。

イメージストリームタグは、OpenShift Container Platform のイメージストリーム内のイメージへの名前付きポインターです。ユーザーは、特定のバージョンのコンテナーイメージを参照するようにイメージストリームタグを設定できます。

イメージストリームイメージは、OpenShift Container Platform における API リソースオブジェクトであり、イメージストリームから特定のコンテナーイメージを取得します。イメージストリームイメージを使用すると、特定のイメージ SHA 識別子に関するメタデータにアクセスできます。

OpenShift Container Platform のイメージストリームトリガーは、イメージストリームタグが変更されたときに特定のアクションを実行します。ユーザーは、新しいイメージのインポート時にビルドまたはデプロイを自動的に開始するようにトリガーを設定できます。

たとえば、新しいイメージをインポートすると、タグの値が変更されることがあります。このとき、値の変更を待ち受けているデプロイメントやビルドなどのリソースがあると、トリガーが起動します。

OpenShift Container Platform でサンプルイメージストリームとテンプレートを管理するには、Cluster Samples Operator を使用できます。Cluster Samples Operator は、初期起動時にデフォルトのサンプルを作成し、openshift ネームスペース内のイメージストリームとテンプレートを初期化します。

Operator はインストール時に独自にデフォルト設定オブジェクトを作成し、その後にクイックスタートテンプレートを含む、サンプルのイメージストリームおよびテンプレートを作成します。

Cluster Samples Operator の設定は、クラスター全体のリソースです。この Operator は、openshift-cluster-samples-operator namespace にデプロイされます。

Cluster Samples Operator のイメージには、関連付けられている OpenShift Container Platform リリースのイメージストリームとテンプレート定義が含まれています。各サンプルが作成または更新されると、Cluster Samples Operator には OpenShift Container Platform のバージョンを示すアノテーションが含まれます。Operator はこのアノテーションを使用して、各サンプルをリリースバージョンに一致させるようにします。このインベントリーの外にあるサンプルは省略されるサンプルであるために無視されます。バージョンのアノテーションが変更または削除されると、Operator が管理するサンプルに変更が加えてもそれらの変更は自動的に元に戻されます。

Cluster Samples Operator 設定リソースには、削除時に以下を消去するファイナライザーが含まれます。

サンプルリソースが削除されると、Cluster Samples Operator はデフォルト設定を使用してリソースを再作成します。

インストール中に Cluster Samples Operator が削除された場合は、別のレジストリーで Cluster Samples Operator を使用することで、コンテンツをインポートできるようになります。その後、Cluster Samples Operator を Managed に設定してサンプルを取得できます。以下の手順を使用してください。

認証情報の設定の詳細は、次のリンクを参照してください。

Cluster Samples Operator はデフォルトで Managed としてブートストラップされるか、グローバルプロキシーが設定されている場合にブートストラップされます。

Managed 状態では、レジストリーからサンプルイメージストリームとイメージをプルし、必要なサンプルテンプレートがインストールされた状態になるように、Cluster Samples Operator がリソースを積極的に管理し、コンポーネントをアクティブな状態に維持します。

次のような特定の状況では、Cluster Samples Operator が Removed 状態でブートストラップされます。

ただし、Cluster Samples Operator が IPv6 ネットワーク上にあることが検出され、かつ OpenShift Container Platform グローバルプロキシーが設定されている場合は、IPv6 チェックがすべてのチェックよりも優先されます。その結果、Cluster Samples Operator はそれ自体を Removed としてブートストラップします。

apiVersion: samples.operator.openshift.io/v1
kind: Config
metadata:
  name: cluster
spec:
  architectures:
  - x86_64
  managementState: Removed

サンプルイメージストリームの作成または更新後に、Cluster Samples Operator はそれぞれのイメージストリームタグのイメージインポートの進捗をモニターします。

インポートが失敗した場合、Cluster Samples Operator は、次のいずれかが発生するまで、約 15 分ごとにイメージストリームイメージインポート API を介してインポートを再試行します。

サンプルリソースは以下の設定フィールドを提供します。

シークレット、イメージストリーム、およびテンプレート監視イベントは、初期サンプルリソースオブジェクトの作成前に追加することができ、Cluster Samples Operator はイベントを検出し、再度キューに入れます。

Cluster Samples Operator は、提供されるパラメーターでファイルを編集して設定できます。

Cluster Samples Operator は、ユーザーが非推奨のイメージストリームタグを使用するデプロイメントを持っている可能性があるため、非推奨のイメージストリームタグをイメージストリームに残します。

oc tag コマンドでイメージストリームを編集して、非推奨のイメージストリームタグを削除できます。

必要なコンテナーイメージを取得するには、インターネットへのアクセスが必要です。代替レジストリーを使用するということは、使用しているネットワークとインターネットの両方にアクセスできるミラーホストにミラーレジストリーを配置することを意味します。

OpenShift Container Platform のインストールとその後の製品更新に必要なイメージは、Red Hat Quay、JFrog Artifactory、Sonatype Nexus Repository、Harbor などのコンテナーミラーレジストリーにミラーリングできます。大規模なコンテナーレジストリーにアクセスできない場合は、OpenShift Container Platform サブスクリプションに含まれる小規模なコンテナーレジストリーである mirror registry for Red Hat OpenShift を使用できます。

Red Hat Quay、mirror registry for Red Hat OpenShift、Artifactory、Sonatype Nexus リポジトリー、Harbor など、Dockerv2-2 をサポートする任意のコンテナーレジストリーを使用できます。選択したレジストリーに関係なく、インターネット上の Red Hat がホストするサイトから分離されたイメージレジストリーにコンテンツをミラーリングする手順は同じです。コンテンツをミラーリングした後に、各クラスターをミラーレジストリーからこのコンテンツを取得するように設定します。

mirror registry for Red Hat OpenShift 以外のコンテナーレジストリーを選択する場合は、プロビジョニングするクラスター内のすべてのマシンからそのレジストリーにアクセスできる必要があります。レジストリーに到達できない場合、インストール、更新、またはワークロードの再配置などの通常の操作が失敗する可能性があります。そのため、ミラーレジストリーは可用性の高い方法で実行し、ミラーレジストリーは少なくとも OpenShift Container Platform クラスターの実稼働環境の可用性の条件に一致している必要があります。

ミラーレジストリーを OpenShift Container Platform イメージで設定する場合、2 つのシナリオを実行することができます。インターネットとミラーレジストリーの両方にアクセスできるホストがあり、クラスターノードにアクセスできない場合は、そのマシンからコンテンツを直接ミラーリングできます。このプロセスは、connected mirroring (接続ミラーリング) と呼ばれます。このようなホストがない場合は、イメージをファイルシステムにミラーリングしてから、そのホストまたはリムーバブルメディアを制限された環境に配置する必要があります。このプロセスは、disconnected mirroring (非接続ミラーリング) と呼ばれます。

ミラーリングされたレジストリーの場合は、プルされたイメージのソースを表示するには、CRI-O ログで Trying to access のログエントリーを確認する必要があります。ノードで crictl images コマンドを使用するなど、イメージのプルソースを表示する他の方法では、イメージがミラーリングされた場所からプルされている場合でも、ミラーリングされていないイメージ名を表示します。

Red Hat からミラーにイメージをミラーリングできるように、コンテナーイメージレジストリー認証情報ファイルを作成します。インストールホストで以下の手順を実行します。

クラスターのインストールまたはアップグレード時に使用するために、OpenShift Container Platform イメージリポジトリーをお使いのレジストリーにミラーリングします。ミラーホストで以下の手順を実行します。

Red Hat レジストリーを使用する代わりに、代替レジストリーまたはミラーレジストリーを使用してイメージストリームをホストできます。

Cluster Samples Operator によって管理される openshift namespace のほとんどのイメージストリームは、Red Hat レジストリーの registry.redhat.io にあるイメージを参照します。

OpenShift Container Platform で実行するコンテナーイメージを作成する場合には、イメージの作成者は、イメージの使いやすさの点で数多くのベストプラクティスを考慮する必要があります。イメージは変更不可で、そのままの状態で使用されることが意図されているため、以下のガイドラインは、イメージを使用しやすく、OpenShift Container Platform で簡単に使用できるようにするのに役立ちます。

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y

FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile

FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory

作成中に包括的なイメージメタデータを定義して、OpenShift Container Platform がイメージのランタイム設定を正しく設定し、イメージの系統とコンプライアンスを追跡できるようにします。これにより、イメージを使用する開発者に優れたエクスペリエンスを提供できます。

たとえば、メタデータを追加して、イメージに関する役立つ情報を提供したり、必要とされる可能性のある他のイメージを提案したりできます。

このトピックでは、現在の一連のユースケースに必要なメタデータのみを定義します。他のメタデータまたはユースケースは、今後追加される可能性があります。

LABEL io.openshift.tags   mongodb,mongodb24,nosql

LABEL io.openshift.wants   mongodb,redis

LABEL io.k8s.description The MySQL 5.5 Server with master-slave replication support

LABEL io.openshift.non-scalable     true

LABEL io.openshift.min-memory 16Gi
LABEL io.openshift.min-cpu     4

Source-to-Image (S2I) は、アプリケーションのソースコードを入力として取り、アセンブルされたアプリケーションを出力として実行する新規イメージを生成するイメージを簡単に作成できるようにするフレームワークです。

再生成可能なコンテナーイメージのビルドに S2I を使用する主な利点として、開発者の使い勝手の良さが挙げられます。ビルダーイメージの作成者は、イメージが最適な S2I パフォーマンスを実現できるように、ビルドプロセスと S2I スクリプトの基本的なコンセプト 2 点を理解する必要があります。

#!/bin/bash

# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
    mv /tmp/s2i/artifacts/* $HOME/.
fi

# move the application source
mv /tmp/s2i/src $HOME/src

# build application artifacts
pushd ${HOME}
make all

# install the artifacts
make install
popd

#!/bin/bash

# run the application
/opt/application/run.sh

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

#!/bin/bash

# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF

Source-to-image (S2I) 環境と、結果として得られるアプリケーションイメージを検証し、OpenShift Container Platform 内でコンテナーのデプロイメントが成功し、再現可能であることを確認します。

S2I ビルダーイメージの作成者は、S2I イメージをローカルでテストして、自動テストや継続的な統合に OpenShift Container Platform ビルドシステムを使用できます。

S2I ビルドを正常に実行するには、S2I に assemble と run スクリプトが必要です。S2I 外のコンテナーイメージを実行した場合に、save-artifacts スクリプトがあると、ビルドのアーティファクトが再利用され、usage スクリプトがあると、使用に関する情報がコンソールに出力されるようになります。

S2I イメージのテストは、ベースのコンテナーイメージを変更したり、コマンドが使用するツールが更新されたりした場合でも、上記のコマンドが正しく機能することを確認するのが目的です。

$ s2i create <image_name> <destination_directory>

IMAGE_NAME = openshift/ruby-20-centos7
CONTAINER_ENGINE := $(shell command -v podman 2> /dev/null | echo docker)

build:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME) .

.PHONY: test
test:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME)-candidate .
	IMAGE_NAME=$(IMAGE_NAME)-candidate test/run

OpenShift Container Platform のイメージストリームは、コンテナーイメージの上に抽象化レイヤーを提供し、CI/CD パイプラインの自動化を可能にします。ビルドとデプロイメントを設定することで、イメージストリームを監視し、イメージが更新されたときに新しいビルドまたはデプロイメントを自動的にトリガーすることができます。

イメージストリームを使用する主な利点は、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインの自動化を可能にすることです。以下に例を示します。

イメージタグは、イメージストリーム内のコンテナーイメージの特定のバージョンを識別します。イメージタグを使用すると、イメージを整理したり、ビルドやデプロイメントで使用するバージョンを制御したりできます。

OpenShift Container Platform でイメージの更新を管理し、Pod の起動パフォーマンスを最適化するには、コンテナー仕様で imagePullPolicy パラメーターを設定できます。この設定は、コンテナーイメージがレジストリーからプルされるタイミングを制御します。

apiVersion: apps/v1
kind: Deployment
# ...
spec:
  # ...
  template:
    spec:
      containers:
      - name: my-app-container
        image: registry.example.com/myapp:v1.2.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080

コンテナーレジストリーで認証を行い、OpenShift Container Platform プロジェクト全体またはセキュリティー保護されたレジストリーからイメージをプルするには、イメージプルシークレットを設定して使用できます。

まず、レジストリー認証情報を取得します。これは通常、Docker の場合は ~/.docker/config.json ファイル、Podman の場合は ~/.config/containers/auth.json ファイルにあり、Red Hat OpenShift Cluster Manager プロセスからシークレットをプルすること で作成されます。このコンテンツは、クラスター内のグローバルな pullSecret オブジェクトを作成または更新するために使用され、quay.io および registry.redhat.io からのイメージへのアクセスを可能にします。

{
   "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"
      }
   }
}

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

イメージストリームは、OpenShift Container Platform 内でコンテナーイメージを参照するための抽象化を提供します。イメージストリームを使用すると、イメージバージョンの管理、クラスター内でのビルドおよびデプロイメントの自動化を行うことができます。

イメージストリームには実際のイメージデータは含まれませんが、イメージリポジトリーと同様に、関連するイメージの単一の仮想ビューが提示されます。

ビルドおよびデプロイメントをそれぞれ実行し、ビルドおよびデプロイメントを、新規イメージが追加される際やこれに対応する際の通知をイメージストリームで確認できるように設定できます。

たとえば、デプロイメントで特定のイメージを使用していて、そのイメージの新規バージョンが作成される場合、デプロイメントを、そのイメージの新規バージョンを選択できるように自動的に実行きます。

デプロイメントまたはビルドで使用するイメージストリームタグが更新されない場合には、コンテナーイメージレジストリーのコンテナーイメージが更新されても、ビルドまたはデプロイメントは以前の、既知でおそらく適切であると予想されるイメージをそのまま使用します。

ソースイメージは以下のいずれかに保存できます。

ビルドまたはデプロイメント設定などのイメージストリームタグを参照するオブジェクトを定義する場合には、リポジトリーではなく、イメージストリームタグを参照します。アプリケーションのビルドまたはデプロイ時に、OpenShift Container Platform がこのイメージストリームタグを使用してリポジトリーに対してクエリーし、対象のイメージに関連付けられた ID を特定して、そのイメージを使用します。

イメージストリームメタデータは他のクラスター情報と共に etcd インスタンスに保存されます。

イメージストリームの使用には、いくつかの大きな利点があります。

アプリケーションのイメージ取得とセキュリティーポリシーをカスタマイズするには、OpenShift Container Platform 内でイメージストリームを設定します。このプロセスにより、イメージプル仕様の定義、タグの管理、信頼性の高いアプリケーションデプロイメントに必要なアクセス権限の制御が可能になります。

ImageStream オブジェクトには以下の要素が含まれます。

apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftNewApp
  labels:
    app: ruby-sample-build
    template: application-template-stibuild
  name: origin-ruby-sample
  namespace: test
spec: {}
status:
  dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
  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-01T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest

以下は、

特定のタグに関連付けられた実際のイメージコンテンツを正確に識別して管理するために、OpenShift Container Platform でイメージストリームイメージを参照して使用します。これにより、アプリケーションデプロイメントが確実にイミュータブルなイメージ定義をターゲットにします。

イメージストリームイメージは、イメージストリームから特定のイメージ ID をポイントします。

イメージストリームイメージにより、タグ付けされている特定のイメージストリームからイメージに関するメタデータを取得できます。

イメージストリームイメージオブジェクトは、イメージをイメージストリームにインポートしたり、タグ付けしたりする場合には OpenShift Container Platform に常に自動的に作成されます。イメージストリームを作成するために使用するイメージストリームイメージオブジェクトをイメージストリーム定義に明示的に定義する必要はありません。

イメージストリームのイメージは、リポジトリーからのイメージストリーム名とイメージ ID で構成されており、@ 記号で区切られています。

<image-stream-name>@<image-id>

ImageStream オブジェクトのサンプルでイメージを参照する際、イメージストリームのイメージは以下のようになります。

origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d

イミュータブルなイメージへの人間が判読できる参照を維持するには、OpenShift Container Platform 内でイメージストリームタグを活用します。これらのタグは、ビルドとデプロイメントで特定の安定したイメージコンテンツを正確にターゲットにするために不可欠です。

イメージストリームタグは、イメージストリームのイメージに対する名前付きポインターです。これは istag として省略されます。イメージストリームタグは、指定のイメージストリームおよびタグのイメージを参照するか、取得するために使用されます。

イメージストリームタグは、ローカル、または外部で管理されるイメージを参照できます。これには、タグが参照したすべてのイメージのスタックとして表されるイメージの履歴が含まれます。新規または既存のイメージが特定のイメージストリームタグでタグ付けされる場合はいつでも、これは履歴スタックの最初の位置に置かれます。これまで先頭の位置を占めていたイメージは 2 番目の位置に置かれます。これにより、タグを過去のイメージに再び参照させるよう簡単にロールバックできます。

以下のイメージストリームタグは、ImageStream オブジェクトからのものです。

kind: ImageStream
apiVersion: image.openshift.io/v1
metadata:
  name: my-image-stream
# ...
  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-01T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest
# ...

イメージストリームタグには permanent タグまたは tracking タグを使用できます。

各自のニーズに合わせて独自のイメージストリームタグを作成できます。

イメージストリームタグは、コロンで区切られた、イメージストリームの名前とタグで構成されています。

<imagestream name>:<tag>

たとえば、上記の ImageStream オブジェクトのサンプルで sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d イメージを参照するには、イメージストリームタグは以下のようになります。

origin-ruby-sample:latest

アプリケーションのライフサイクルを自動化して最新のコードを使用するために、OpenShift Container Platform でイメージストリームトリガーを設定します。イメージストリームトリガーにより、ビルドおよびデプロイメントは、アップストリームの新規バージョンが利用可能になると自動的に起動します。

たとえば、ビルドおよびデプロイメントは、イメージストリームタグの変更時に自動的に起動します。これは、特定のイメージストリームタグをモニターし、変更の検出時にビルドまたはデプロイメントに通知することで実行されます。

イメージストリームマッピングを理解し、OpenShift Container Platform が新しくアップロードされたイメージを追跡する方法を管理します。統合レジストリーは、新しいイメージを受信すると、イメージの重要なプロジェクト、名前、タグ、メタデータを提供するイメージストリームマッピングを自動的に作成して送信します。

この情報は、新規イメージを作成するする際 (すでに存在しない場合) やイメージをイメージストリームにタグ付けする際に使用されます。OpenShift Container Platform は、コマンド、エントリーポイント、および環境変数などの各イメージに関する完全なメタデータを保存します。OpenShift Container Platform のイメージはイミュータブル (変更不可能) であり、名前の最大長さは 63 文字です。

以下のイメージストリームマッピングのサンプルにより、イメージが test/origin-ruby-sample:latest としてタグ付けされます。

apiVersion: image.openshift.io/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

OpenShift Container Platform でコンテナーイメージを整理および管理するには、イメージストリームとイメージストリームタグを使用できます。イメージストリームを使用することで、イメージのバージョンを追跡し、デプロイメントを簡素化できます。

コンテナーイメージを OpenShift Container Platform クラスターに取り込み、その参照を管理するには、外部レジストリーからイメージをインポートし、イメージストリームを使用して整理することができます。このプロセスを利用することで、アプリケーション用のコンテナーイメージを一元管理されたレジストリーとして維持できます。

次のセクションでは、イメージストリームをインポートして操作する方法を説明します。

Kubernetes リソースを使用する場合は、イメージストリーム名とそのタグを識別する ruby:2.5 などのセグメント値を 1 つ指定して、同じプロジェクト内にあるイメージストリームを参照する必要があります。これにより、リソースがそのスコープ内のローカルイメージストリームを正しくターゲットにします。

Kubernetes リソースでイメージストリームを有効にする方法は 2 つあります。

oc set image-lookup を使用して、特定のリソース上のイメージストリームの解決またはイメージストリーム上のイメージストリームの解決を有効にすることができます。

OpenShift Container Platform デプロイメントの設定およびビルド設定は、イメージストリームタグの変更によって自動的にトリガーされます。トリガーされたアクションは更新されたイメージストリームタグで参照されるイメージの新規の値を使用して実行できます。

デプロイメント や ステートフルセット などの Kubernetes リソースが新しいイメージバージョンをシームレスに利用できるようにするには、OpenShift Container Platform でイメージストリームの変更トリガーを設定します。これにより、関連付けられたイメージストリームが変更を検出すると、アプリケーションのデプロイメントが自動的に更新されます。

API 定義の一部としてトリガーを制御するためのフィールドセットを含むデプロイメントおよびビルド設定とは異なり、Kubernetes リソースにはトリガー用のフィールドがありません。その代わりに、OpenShift Container Platform でアノテーションを使用してトリガーを要求できるようにします。

アノテーションは以下のように定義されます。

apiVersion: v1
kind: Pod
metadata:
  annotations:
    image.openshift.io/triggers:
      [
       {
         "from": {
           "kind": "ImageStreamTag",
           "name": "example:latest",
           "namespace": "myapp"
         },
         "fieldPath": "spec.template.spec.containers[?(@.name==\"web\")].image",
         "paused": false
       },
      # ...
      ]
# ...

ここでは、以下のようになります。

コア Kubernetes リソースの 1 つに Pod テンプレートとこのアノテーションの両方が含まれる場合、OpenShift Container Platform は現時点でトリガーで参照されるイメージストリームタグに関連付けられているイメージを使用してオブジェクトの更新を試行します。この更新は、指定の fieldPath に対して実行されます。

Pod テンプレートおよびアノテーションの両方が含まれるコア Kubernetes リソースの例には、以下が含まれます。

Kubernetes によって管理されるデプロイ済みのアプリケーションの自動更新を有効にするには、コマンドラインインターフェイス (CLI) を使用して、Kubernetes リソースにイメージストリーム変更トリガーを設定します。これにより、アップストリームイメージの新しいバージョンが利用可能になったときに、Deployments や StatefulSets などのリソースが自動的に呼び出されます。

イメージトリガーをデプロイメントに追加する際に、oc set triggers コマンドを使用できます。たとえば、この手順のコマンド例は、イメージ変更トリガーを example という名前のデプロイメントに追加し、example:latest イメージストリームタグの更新時に、デプロイメント内の web コンテナーが新規の値で更新されるようにします。このコマンドは、デプロイメントリソースに正しい image.openshift.io/triggers アノテーションを設定します。

image.config.openshift.io/cluster リソースの spec で、クラスター全体でイメージを処理する特定のパラメーターを設定できます。

image.config.openshift.io/cluster リソースの status フィールドは、クラスターから観察される値を保持します。

Machine Config Operator (MCO) は、image.config.openshift.io/cluster カスタムリソース (CR) を監視してレジストリーへの変更を検出し、レジストリーが変更された場合には特定の手順を実行します。

レジストリーへの変更が image.config.openshift.io/cluster CR に適用されると、MCO は以下の一連のアクションを実行します。

image.config.openshift.io/cluster カスタムリソース (CR) を編集してイメージレジストリーの設定を行うことができます。

イメージの短縮名を使用すると、プル spec パラメーターに完全修飾ドメイン名を追加せずにイメージを検索できます。

たとえば、registry.access.redhat.com/rhe7/etcd の代わりに rhel7/etcd を使用できます。image.config.openshift.io/cluster カスタムリソース (CR) を編集して、イメージの短縮名を検索するためにレジストリーを追加できます。

完全パスを使用することが実際的ではない場合に、短縮名を使用できる場合があります。たとえば、クラスターが DNS が頻繁に変更される複数の内部レジストリーを参照する場合、毎回の変更ごとにプル仕様の完全修飾ドメイン名を更新する必要が生じる可能性があります。この場合は、イメージの短縮名を使用した方が良いでしょう。

イメージをプルまたはプッシュする場合、コンテナーランタイムは image.config.openshift.io/cluster CR の registrySources パラメーターの下にリスト表示されるレジストリーを検索します。短縮名を使用してイメージをプル際に、containerRuntimeSearchRegistries パラメーターでレジストリーのリストを作成している場合、コンテナーランタイムはそれらのレジストリーを検索します。

コンテナーレジストリーリポジトリーのミラーリングを設定すると、次のタスクを実行できます。

OpenShift Container Platform のリポジトリーミラーリングには、以下の属性が含まれます。

リポジトリーのミラーリングは次の方法で設定できます。

これらのカスタムリソースオブジェクトはそれぞれ、次の情報を識別します。

次のアクションと、それがノードの drain 動作にどのように影響するかに注意してください。

新しいクラスターの場合は、必要に応じて IDMS、ITMS、および ICSP CR オブジェクトを使用できます。ただし、IDMS と ITMS の使用を推奨します。

クラスターをアップグレードした場合、既存の ICSP オブジェクトは安定を維持し、IDMS オブジェクトと ICSP オブジェクトの両方がサポートされるようになります。ICSP オブジェクトを使用するワークロードは、引き続き期待どおりに機能し続けます。一方、IDMS CR で導入されたフォールバックポリシーを利用する場合は、oc adm migrate icsp コマンドを使用して、現在のワークロードを IDMS オブジェクトに移行できます。これは、後述の イメージレジストリーリポジトリーミラーリング用の ImageContentSourcePolicy (ICSP) ファイルの変換 セクションで説明しています。IDMS オブジェクトへの移行に、クラスターの再起動は必要ありません。