イメージ
Red Hat OpenShift Service on AWS のイメージ
概要
第1章 イメージの概要 リンクのコピーリンクがクリップボードにコピーされました!
1.1. コンテナー、イメージおよびイメージストリームについて リンクのコピーリンクがクリップボードにコピーされました!
コンテナー、イメージ、およびイメージストリームは、コンテナー化されたソフトウェアを作成し、管理する際に理解しておくべき重要な概念です。イメージは、コンテナーがコンテナーイメージの実行中のインスタンスである場合に、実行の準備ができている一連のソフトウェアを保持します。イメージストリームは、同一の基本的なイメージの異なるバージョンを保存する 1 つの方法です。それらの異なるバージョンは、同じイメージ名の異なるタグによって表されます。
1.2. イメージ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS のコンテナーは OCI または Docker 形式のコンテナーの イメージ をベースにしています。イメージは、単一コンテナーを実行するためのすべての要件、およびそのニーズおよび機能を記述するメタデータを含むバイナリーです。
これはパッケージ化テクノロジーとして考えることができます。コンテナーは、作成時にコンテナーに追加のアクセスを付与しない限り、イメージで定義されるリソースにのみアクセスできます。同じイメージを複数のホストにまたがって複数のコンテナーにデプロイし、それらの間で負荷を分散することにより、Red Hat OpenShift Service on AWS はイメージにパッケージ化されたサービスの冗長性および水平的なスケーリングを提供できます。
イメージをビルドするために podman または docker
CLI を直接使用することはできますが、Red Hat OpenShift Service on AWS は、コードまたは設定を既存イメージに追加して新規イメージの作成を支援するビルダーイメージも提供します。
アプリケーションは一定期間をかけて開発されるため、単一のイメージ名が同じイメージの数多くの異なるバージョンを参照する場合があります。それぞれの異なるイメージは、通常は 12 文字 (例: fd44297e2ddb
) に省略されるそのハッシュ (fd44297e2ddb050ec4f…
などの長い 16 進数) で一意に参照されます。
1.3. イメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
イメージレジストリーは、コンテナーイメージを保管し、提供するコンテナーサーバーです。以下に例を示します。
registry.redhat.io
registry.redhat.io
レジストリーには、1 つ以上のタグ付けされたイメージを持つ 1 つ以上のイメージリポジトリーのコレクションが含まれます。Red Hat は、サブスクリプションをお持ちのお客様に対して registry.redhat.io
でレジストリーを提供しています。Red Hat OpenShift Service on AWS では、カスタムコンテナーイメージを管理するための独自の OpenShift イメージレジストリーを使用することもできます。
1.4. イメージリポジトリー リンクのコピーリンクがクリップボードにコピーされました!
イメージリポジトリーは、関連するコンテナーイメージとそれらを識別するタグのコレクションです。たとえば、Red Hat OpenShift Service on AWS の Jenkins イメージがリポジトリーにあります。
docker.io/openshift/jenkins-2-centos7
docker.io/openshift/jenkins-2-centos7
1.5. イメージタグ リンクのコピーリンクがクリップボードにコピーされました!
イメージタグは、イメージストリーム内の他のイメージから特定のイメージを識別するリポジトリーのコンテナーイメージに適用されるラベルです。通常、タグはある種のバージョン番号を表します。たとえば、ここでは :v3.11.59-2
がタグになります。
registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2
registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2
イメージにタグを追加することができます。たとえば、イメージには :v3.11.59-2
および :latest
というタグが割り当てられる可能性があります。
Red Hat OpenShift Service on AWS には oc tag
コマンドがあります。これは docker tag
コマンドに似ていますが、イメージを直接操作するのではなく、イメージストリームを操作するものです。
1.6. イメージ ID リンクのコピーリンクがクリップボードにコピーされました!
イメージ ID は、イメージをプルするために使用できる SHA (Secure Hash Algorithm) コードです。SHA イメージ ID は変更できません。特定の SHA ID は同一のコンテナーイメージコンテンツを常に参照します。以下に例を示します。
docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324
docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324
1.7. コンテナー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS アプリケーションの基本単位はコンテナーと呼ばれます。Linux コンテナーテクノロジー は、指定されたリソースのみと対話するために実行中のプロセスを分離する軽量なメカニズムです。このコンテナーという用語は、コンテナーイメージの実行中または一時停止している特定のインスタンスとして定義されています。
数多くのアプリケーションインスタンスは、相互のプロセス、ファイル、ネットワークなどを可視化せずに単一ホストのコンテナーで実行される可能性があります。通常、コンテナーは任意のワークロードに使用されますが、各コンテナーは Web サーバーまたはデータベースなどの (通常はマイクロサービスと呼ばれることの多い) 単一サービスを提供します。
Linux カーネルは数年にわたりコンテナーテクノロジーの各種機能を統合してきました。Docker プロジェクトはホスト上の Linux コンテナーの便利な管理インターフェイスを開発しました。さらに最近では、Open Container Initiative により、コンテナー形式およびコンテナーランタイムのオープン標準が策定されています。Red Hat OpenShift Service on AWS および Kubernetes は、複数ホストのインストール間で OCI および Docker 形式のコンテナーのオーケストレーションを実行する機能を追加しています。
Red Hat OpenShift Service on AWS を使用する際にコンテナーランタイムと直接対話することはありませんが、それらの Red Hat OpenShift Service on AWS におけるロールやコンテナー内でのアプリケーションの機能を理解する上で、それらの機能および用語を理解しておくことは重要です。
podman などのツールは、コンテナーを直接実行し、管理するための docker
コマンドラインツールを置き換えるために使用できます。podman
を使用すると、Red Hat OpenShift Service on AWS と切り離してコンテナーの実験を行うことができます。
1.8. イメージストリームを使用する理由 リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームとそれに関連付けられたタグは、Red Hat OpenShift Service on AWS 内からコンテナーイメージを参照するための抽象化を提供します。イメージストリームとそのタグを使用して、利用可能なイメージを確認し、リポジトリーのイメージが変更される場合でも必要な特定のイメージを使用していることを確認できます。
イメージストリームには実際のイメージデータは含まれませんが、イメージリポジトリーと同様に、関連するイメージの単一の仮想ビューが提示されます。
ビルドおよびデプロイメントをそれぞれ実行し、ビルドおよびデプロイメントを、新規イメージが追加される際やこれに対応する際の通知をイメージストリームで確認できるように設定できます。
たとえば、デプロイメントで特定のイメージを使用していて、そのイメージの新規バージョンが作成される場合、デプロイメントを、そのイメージの新規バージョンを選択できるように自動的に実行きます。
デプロイメントまたはビルドで使用するイメージストリームタグが更新されない場合には、コンテナーイメージレジストリーのコンテナーイメージが更新されても、ビルドまたはデプロイメントは以前の、既知でおそらく適切であると予想されるイメージをそのまま使用します。
ソースイメージは以下のいずれかに保存できます。
- Red Hat OpenShift Service on AWS の統合レジストリー
- registry.redhat.io または quay.io などの外部レジストリー
- Red Hat OpenShift Service on AWS クラスターの他のイメージストリーム
ビルドまたはデプロイメント設定などのイメージストリームタグを参照するオブジェクトを定義する場合には、リポジトリーではなく、イメージストリームタグを参照します。アプリケーションのビルドまたはデプロイ時に、Red Hat OpenShift Service on AWS はイメージストリームタグを使用してリポジトリーにクエリーを送信し、イメージの関連付けられた ID を特定し、正確なイメージを使用します。
イメージストリームメタデータは他のクラスター情報と共に etcd インスタンスに保存されます。
イメージストリームの使用には、いくつかの大きな利点があります。
- コマンドラインを使用して再プッシュすることなく、タグ付けや、タグのロールバック、およびイメージの迅速な処理を実行できます。
- 新規イメージがレジストリーにプッシュされると、ビルドおよびデプロイメントをトリガーできます。また、Red Hat OpenShift Service on AWS には他のリソースの汎用トリガーがあります (Kubernetes オブジェクトなど)。
- 定期的な再インポートを実行するためにタグにマークを付けることができます。ソースイメージが変更されると、その変更は選択され、イメージストリームに反映されます。これにより、ビルドまたはデプロイメント設定に応じてビルドまたはデプロイメントフローがトリガーされます。
- 詳細なアクセス制御を使用してイメージを共有し、チーム間でイメージを迅速に分散できます。
- ソースイメージが変更されると、イメージストリームタグはイメージの既知の適切なバージョンをポイントしたままになり、アプリケーションが予期せずに損傷しないようにします。
- イメージストリームオブジェクトのパーミッションを使用して、イメージを表示し、使用できるユーザーにセキュリティーを設定できます。
- クラスターレベルでイメージを読み込んだり、リスト表示するパーミッションのないユーザーは、イメージストリームを使用してプロジェクトでタグ付けされたイメージを取得できます。
イメージストリームを 管理 し、Kubernetes リソースでイメージストリームを使用 し、イメージストリームの更新で更新をトリガー できます。
1.9. イメージストリームタグ リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームタグは、イメージストリームのイメージに対する名前付きポインターです。イメージストリームタグはコンテナーイメージタグに似ています。
1.10. イメージストリームイメージ リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームイメージは、これがタグ付けされている特定のイメージストリームから特定のコンテナーイメージを取得できるようにします。イメージストリームイメージは、特定のイメージの SHA ID に関するメタデータをプルする API リソースオブジェクトです。
1.11. イメージストリームトリガー リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームのトリガーは、イメージストリームタグの変更時に特定のアクションを生じさせます。たとえば、インポートにより、タグの値が変更され、これによりデプロイメント、ビルドまたはそれらをリッスンする他のリソースがある場合にトリガーが実行されます。
1.12. Cluster Samples Operator の使用方法 リンクのコピーリンクがクリップボードにコピーされました!
初期の起動時に、Operator はデフォルトサンプルを作成してイメージストリームおよびテンプレートの作成を開始します。Cluster Samples Operator は、openshift
namespace に保存されるサンプルイメージストリームおよびテンプレートを管理できます。
クラスター管理者は、Cluster Samples Operator を使用して次のことができます。
1.13. テンプレートについて リンクのコピーリンクがクリップボードにコピーされました!
テンプレートは、複製されるオブジェクトの定義です。テンプレート を使用して、設定を構築およびデプロイできます。
1.14. Ruby on Rails の使い方 リンクのコピーリンクがクリップボードにコピーされました!
開発者は、Ruby on Rails を使用して次のことができます。
アプリケーションを作成します。
- データベースを設定します。
- ウェルカムページを作成します。
- Red Hat OpenShift Service on AWS 向けにアプリケーションを設定します。
- アプリケーションを Git に保存します。
Red Hat OpenShift Service on AWS にアプリケーションをデプロイします。
- データベースサービスを作成します。
- フロントエンドサービスを作成します。
- アプリケーションのルートを作成します。
第2章 Cluster Samples Operator の概要 リンクのコピーリンクがクリップボードにコピーされました!
openshift
namespace で動作する Cluster Samples Operator は、Red Hat OpenShift Service on AWS イメージストリームと Red Hat OpenShift Service on AWS テンプレートをインストールおよび更新します。
Red Hat OpenShift Service on AWS 4.16 以降では、Cluster Samples Operator は非推奨になります。Cluster Samples Operator に、新規のテンプレート、サンプル、または非 Source-to-Image (非 S2I) イメージストリームは追加されません。ただし今後のリリースで Cluster Samples Operator が削除されるまで、既存の S2I ビルダーイメージストリームとテンプレートは引き続き更新されます。S2I イメージストリームとテンプレートには、次のものが含まれます。
- Ruby
- Python
- Node.js
- Perl
- PHP
- HTTPD
- Nginx
- EAP
- Java
- Webserver
- .NET
- Go
- Cluster Samples Operator は、非 S2I サンプル (イメージストリームとテンプレート) の管理とサポートを停止します。要件や将来の計画は、イメージストリームまたはテンプレートの所有者に問い合わせてください。さらに、list of the repositories hosting the image stream or templates を参照してください。
2.1. Cluster Samples Operator について リンクのコピーリンクがクリップボードにコピーされました!
Operator はインストール時に独自にデフォルト設定オブジェクトを作成し、その後にクイックスタートテンプレートを含む、サンプルのイメージストリームおよびテンプレートを作成します。
認証情報を必要とする他のレジストリーからのイメージストリームのインポートを容易にするには、クラスター管理者は、イメージのインポートに必要な Docker config.json
ファイルの内容を含む追加のシークレットを openshift
namespace に作成できます。
Cluster Samples Operator 設定はクラスター全体で使用されるリソースであり、デプロイメントは openshift-cluster-samples-operator
namespace 内に含められます。
Cluster Samples Operator のイメージには、関連付けられた Red Hat OpenShift Service on AWS リリースのイメージストリームおよびテンプレートの定義が含まれます。各サンプルが作成または更新されると、Cluster Samples Operator に Red Hat OpenShift Service on AWS のバージョンを示すアノテーションが追加されます。Operator はこのアノテーションを使用して、各サンプルをリリースバージョンに一致させるようにします。このインベントリーの外にあるサンプルは省略されるサンプルであるために無視されます。バージョンのアノテーションが変更または削除されると、Operator が管理するサンプルに変更が加えてもそれらの変更は自動的に元に戻されます。
Jenkins イメージはインストールからのイメージペイロードの一部であり、イメージストリームに直接タグ付けされます。
Cluster Samples Operator 設定リソースには、削除時に以下を消去するファイナライザーが含まれます。
- Operator 管理のイメージストリーム
- Operator 管理のテンプレート
- Operator が生成する設定リソース
- クラスターステータスのリソース
サンプルリソースの削除時に、Cluster Samples Operator はデフォルト設定を使用してリソースを再作成します。
2.1.1. Cluster Samples Operator の管理状態の使用 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Samples Operator はデフォルトで Managed
としてブートストラップされるか、グローバルプロキシーが設定されている場合にブートストラップされます。Managed
状態で、Cluster Samples Operator は、イメージストリームおよびイメージをレジストリーからプルし、必要なサンプルテンプレートがインストールされた状態になるように、リソースをアクティブに管理し、コンポーネントをアクティブな状態に維持します。
以下を含む特定の状況では、Cluster Samples Operator が Removed
としてそれ自体をブートストラップします。
- Cluster Samples Operator が、クリーンインストール後の初回起動から 3 分後に registry.redhat.io に到達できない場合。
- Cluster Samples Operator がこれが IPv6 ネットワーク上にあることを検出する場合。
Red Hat OpenShift Service on AWS の場合、デフォルトのイメージレジストリーは registry.access.redhat.com
または quay.io
です。
ただし、Cluster Samples Operator が IPv6 ネットワーク上にあることが検出され、かつ Red Hat OpenShift Service on AWS グローバルプロキシーが設定されている場合は、IPv6 チェックがすべてのチェックよりも優先されます。その結果、Cluster Samples Operator はそれ自体を Removed
としてブートストラップします。
現在、IPv6 インストールは registry.redhat.io によってサポートされていません。Cluster Samples Operator は、ほとんどのサンプルイメージストリームおよびイメージを registry.redhat.io からプルします。
2.1.1.1. ネットワークが制限されたインストール リンクのコピーリンクがクリップボードにコピーされました!
registry.redhat.io
にアクセスできない場合に Removed
としてすると、ネットワークの制限がすでに有効な場合にネットワークが制限されたインストールを容易にします。ネットワークアクセスが制限されている場合に Removed
としてートストラップすると、クラスター管理者がサンプルが必要かどうかを判別する時間をより長く確保できます。これは、Cluster Samples Operator は管理状態が Removed
に設定されている場合にサンプルのイメージストリームのインポートに失敗しているアラートを送信しないためです。Cluster Samples Operator が Managed
として起動し、サンプルイメージストリームのインストールを試みると、インポートに失敗している場合に初回インストールから 2 時間後にアラートが開始されます。
2.1.1.2. 初期のネットワークアクセスが設定された状態でのネットワークが制限されたインストール リンクのコピーリンクがクリップボードにコピーされました!
ネットワークが制限された環境のクラスターまたは非接続クラスターとすることが意図されたクラスターが、ネットワークアクセスがある状態で最初にインストールされた場合、Cluster Samples Operator はアクセス可能なために registry.redhat.io
からコンテンツをインストールします。Cluster Samples Operator を Removed
としてブートストラップして、必要なサンプルを判別するまでサンプルのインストールを遅らせる場合、イメージミラーのセットアップなどを行ってから、代替レジストリーで Samples Operator を使用し、ノードをカスタマイズする手順 (どちらも追加のリソースセクションにリンクされている) に従い、Cluster Samples Operator のデフォルト設定を上書きし、最初に Removed
として起動します。
以下の追加の YAML ファイルを、openshift-install create manifest
で作成される openshift
ディレクトリーに置く必要があります。
managementState: Removed
が設定された Cluster Samples Operator YAML ファイルのサンプル
2.1.2. Cluster Samples Operator でのイメージストリームのインポートの追跡およびエラー回復 リンクのコピーリンクがクリップボードにコピーされました!
サンプルイメージストリームの作成または更新後に、Cluster Samples Operator はそれぞれのイメージストリームタグのイメージインポートの進捗をモニターします。
インポートが失敗すると、Cluster Samples Operator はイメージストリームイメージインポート API を使用してインポートを再試行します。これは oc import-image
コマンドで使用されるのと同じ API であり、インポートの成功が確認されるまで約 15 分ごとに、またはイメージストリームのいずれかが skippedImagestreams
一覧に追加されるように Cluster Samples Operator の設定が変更されるか、管理状態が Removed
に変更される場合に再試行されます。
関連情報
-
Cluster Samples Operator がインストール時に削除される場合、Cluster Samples Operator を代替レジストリーと共に使用 し、コンテンツをインポートし、サンプルを取得するために Cluster Samples Operator を
Managed
に設定できるようにします。
2.2. Cluster Samples Operator からの非推奨のイメージストリームタグの削除 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Samples Operator は、ユーザーが非推奨のイメージストリームタグを使用するデプロイメントを持っている可能性があるため、非推奨のイメージストリームタグをイメージストリームに残します。
oc tag
コマンドでイメージストリームを編集して、非推奨のイメージストリームタグを削除できます。
サンプルプロバイダーがイメージストリームから削除した非推奨のイメージストリームタグは初期インストールに含まれません。
前提条件
-
oc
CLI がインストールされている。
手順
oc tag
コマンドでイメージストリームを編集して、非推奨のイメージストリームタグを削除します。oc tag -d <image_stream_name:tag>
$ oc tag -d <image_stream_name:tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Deleted tag default/<image_stream_name:tag>.
Deleted tag default/<image_stream_name:tag>.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
- 認証情報の詳細は、イメージプルシークレットの使用 を参照してください。
第3章 代替レジストリーでの Cluster Samples Operator の使用 リンクのコピーリンクがクリップボードにコピーされました!
最初にミラーレジストリーを作成して、別のレジストリーで Cluster Samples Operator を使用できます。
必要なコンテナーイメージを取得するには、インターネットへのアクセスが必要です。この手順では、ご使用のネットワークとインターネットのどちらにもアクセスできるミラーホストにミラーレジストリーを配置します。
3.1. ミラーレジストリーについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS のインストールとその後の製品更新に必要なイメージは、Red Hat Quay、JFrog Artifactory、Sonatype Nexus Repository、Harbor などのコンテナーミラーレジストリーにミラーリングできます。大規模なコンテナーレジストリーにアクセスできない場合は、mirror registry for Red Hat OpenShift を使用できます。これは Red Hat OpenShift Service on AWS サブスクリプションに含まれる小規模なコンテナーレジストリーです。
Red Hat Quay、mirror registry for Red Hat OpenShift、Artifactory、Sonatype Nexus リポジトリー、Harbor など、Dockerv2-2 をサポートする任意のコンテナーレジストリーを使用できます。選択したレジストリーに関係なく、インターネット上の Red Hat がホストするサイトから分離されたイメージレジストリーにコンテンツをミラーリングする手順は同じです。コンテンツをミラーリングした後に、各クラスターをミラーレジストリーからこのコンテンツを取得するように設定します。
OpenShift イメージレジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。
mirror registry for Red Hat OpenShift 以外のコンテナーレジストリーを選択する場合は、プロビジョニングするクラスター内のすべてのマシンからそのレジストリーにアクセスできる必要があります。レジストリーに到達できない場合、インストール、更新、またはワークロードの再配置などの通常の操作が失敗する可能性があります。そのため、ミラーレジストリーは可用性の高い方法で実行し、少なくとも Red Hat OpenShift Service on AWS の実稼働環境の可用性の条件を満たしている必要があります。
ミラーレジストリーに Red Hat OpenShift Service on AWS イメージを追加する場合は、2 つの方法で実行できます。インターネットとミラーレジストリーの両方にアクセスできるホストがあり、クラスターノードにアクセスできない場合は、そのマシンからコンテンツを直接ミラーリングできます。このプロセスは、connected mirroring (接続ミラーリング) と呼ばれます。このようなホストがない場合は、イメージをファイルシステムにミラーリングしてから、そのホストまたはリムーバブルメディアを制限された環境に配置する必要があります。このプロセスは、disconnected mirroring (非接続ミラーリング) と呼ばれます。
ミラーリングされたレジストリーの場合は、プルされたイメージのソースを表示するには、CRI-O ログで Trying to access
のログエントリーを確認する必要があります。ノードで crictl images
コマンドを使用するなど、イメージのプルソースを表示する他の方法では、イメージがミラーリングされた場所からプルされている場合でも、ミラーリングされていないイメージ名を表示します。
Red Hat は、Red Hat OpenShift Service on AWS でサードパーティーのレジストリーをテストしていません。
3.1.1. ミラーホストの準備 リンクのコピーリンクがクリップボードにコピーされました!
ミラーレジストリーを作成する前に、ミラーホストを準備する必要があります。
3.1.2. OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc
) をインストールすると、コマンドラインインターフェイスから Red Hat OpenShift Service on AWS を操作できます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して Red Hat OpenShift Service on AWS 4 のすべてのコマンドを実行することはできません。新しいバージョンの oc
をダウンロードしてインストールしてください。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの Red Hat OpenShift Service on AWS のダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4 Linux Clients エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの Red Hat OpenShift Service on AWS のダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの Red Hat OpenShift Service on AWS のダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4 macOS Clients エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
oc
コマンドを使用してインストールを確認します。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. イメージのミラーリングを可能にする認証情報の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat からミラーへのイメージのミラーリングを可能にするコンテナーイメージレジストリー認証情報ファイルを作成します。
前提条件
- 切断された環境で使用するミラーレジストリーを設定しました。
手順
インストールホストで以下の手順を実行します。
-
registry.redhat.io
プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。 次のコマンドを実行して、プルシークレットのコピーを JSON 形式で作成します。
cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json>
$ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。
プルシークレットの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ミラーレジストリーの base64 でエンコードされたユーザー名とパスワードまたはトークンを生成します。
echo -n '<user_name>:<password>' | base64 -w0
$ echo -n '<user_name>:<password>' | base64 -w0
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<user_name>
および<password>
には、レジストリーに設定したユーザー名およびパスワードを指定します。
出力例
BGVtbYk3ZHAtqXs=
BGVtbYk3ZHAtqXs=
Copy to Clipboard Copied! Toggle word wrap Toggle overflow JSON ファイルを編集し、レジストリーを記述するセクションをこれに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更済みのプルシークレットの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. Red Hat OpenShift Service on AWS イメージリポジトリーのミラーリング リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストールまたはアップグレード時に使用するために、Red Hat OpenShift Service on AWS イメージリポジトリーをお使いのレジストリーにミラーリングします。
前提条件
- ミラーホストがインターネットにアクセスできる。
- ネットワークが制限された環境で使用するミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできる。
- Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を組み込むように変更している。
- 自己署名証明書を使用する場合は、証明書にサブジェクトの別名を指定しています。
手順
ミラーホストで以下の手順を実行します。
- Red Hat OpenShift Service on AWS のダウンロードページ でインストールする Red Hat OpenShift Service on AWS のバージョンを確認し、Repository Tags ページで対応するタグを確認します。
必要な環境変数を設定します。
リリースバージョンをエクスポートします。
OCP_RELEASE=<release_version>
$ OCP_RELEASE=<release_version>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <release_version>
には、インストールする Red Hat OpenShift Service on AWS のバージョン (4.5.4
など) に対応するタグを指定します。ローカルレジストリー名とホストポートをエクスポートします。
LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
$ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <local_registry_host_name>
には、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port>
には、コンテンツの送信に使用するポートを指定します。ローカルリポジトリー名をエクスポートします。
LOCAL_REPOSITORY='<local_repository_name>'
$ LOCAL_REPOSITORY='<local_repository_name>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <local_repository_name>
には、ocp4/openshift4
などのレジストリーに作成するリポジトリーの名前を指定します。ミラーリングするリポジトリーの名前をエクスポートします。
PRODUCT_REPO='openshift-release-dev'
$ PRODUCT_REPO='openshift-release-dev'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実稼働環境のリリースの場合には、
openshift-release-dev
を指定する必要があります。パスをレジストリープルシークレットにエクスポートします。
LOCAL_SECRET_JSON='<path_to_pull_secret>'
$ LOCAL_SECRET_JSON='<path_to_pull_secret>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <path_to_pull_secret>
には、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。リリースミラーをエクスポートします。
RELEASE_NAME="ocp-release"
$ RELEASE_NAME="ocp-release"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実稼働環境のリリースは、
ocp-release
を指定する必要があります。クラスターのアーキテクチャーのタイプをエクスポートします。
ARCHITECTURE=<cluster_architecture>
$ ARCHITECTURE=<cluster_architecture>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
x86_64
、aarch64
、s390x
、またはppc64le
など、クラスターのアーキテクチャーを指定します。
ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。
REMOVABLE_MEDIA_PATH=<path>
$ REMOVABLE_MEDIA_PATH=<path>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 最初のスラッシュ (/) 文字を含む完全パスを指定します。
バージョンイメージをミラーレジストリーにミラーリングします。
ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。
- リムーバブルメディアをインターネットに接続しているシステムに接続します。
ミラーリングするイメージおよび設定マニフェストを確認します。
oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。 イメージをリムーバブルメディア上のディレクトリーにミラーリングします。
oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。
oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
$ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
REMOVABLE_MEDIA_PATH
の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。
重要oc image mirror
を実行すると、error: unable to retrieve source image
エラーが発生する場合があります。このエラーは、イメージレジストリーに存在しなくなったイメージへの参照がイメージインデックスに含まれている場合に発生します。イメージインデックスは、それらのイメージを実行しているユーザーがアップグレードグラフの新しいポイントへのアップグレードパスを実行できるように、古い参照を保持する場合があります。一時的な回避策として、--skip-missing
オプションを使用してエラーを回避し、イメージインデックスのダウンロードを続行できます。詳細は、Service Mesh Operator mirroring failed を参照してください。
ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。
以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。
oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な
imageContentSources
データが含まれます。直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。注記ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。
ミラーリングしたコンテンツに基づくインストールプログラムを作成するために、インストールプログラムを展開してリリースに固定します。
ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。
oc adm release extract -a ${LOCAL_SECRET_JSON} --icsp-file=<file> --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}" \ --insecure=true
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --icsp-file=<file> --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}" \ --insecure=true
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- オプション: ターゲットレジストリーの信頼を設定しない場合は、
--insecure=true
フラグを追加します。
ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下のコマンドを実行します。
oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要選択した Red Hat OpenShift Service on AWS のバージョンに適したイメージを確実に使用するために、ミラーリングしたコンテンツからインストールプログラムを展開する必要があります。
インターネット接続のあるマシンで、このステップを実行する必要があります。
installer-provisioned infrastructure を使用するクラスターの場合は、以下のコマンドを実行します。
openshift-install
$ openshift-install
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. 代替のレジストリーまたはミラーリングされたレジストリーでの Cluster Samples Operator イメージストリームの使用 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Samples Operator によって管理される openshift
namespace のほとんどのイメージストリームは、Red Hat レジストリーの registry.redhat.io にあるイメージを参照します。
cli
、installer
、must-gather
、および tests
イメージストリームはインストールペイロードの一部ですが、Cluster Samples Operator によって管理されません。これは、この手順で扱いません。
Cluster Samples Operator は、非接続環境では Managed
に設定する必要があります。イメージストリームをインストールするには、ミラーリングされたレジストリーが必要です。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - ミラーレジストリーのプルシークレットの作成。
手順
ミラーリングする特定のイメージストリームのイメージにアクセスします。
oc get is <imagestream> -n openshift -o json | jq .spec.tags[].from.name | grep registry.redhat.io
$ oc get is <imagestream> -n openshift -o json | jq .spec.tags[].from.name | grep registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なイメージストリームに関連付けられた registry.redhat.io のイメージをミラーリングします。
oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest
$ oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのイメージ設定オブジェクトを作成します。
oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config
$ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのイメージ設定オブジェクトに、ミラーに必要な信頼される CA を追加します。
oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge
$ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Samples Operator 設定オブジェクトの
samplesRegistry
フィールドを、ミラー設定で定義されたミラーの場所のhostname
の部分を含むように更新します。oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
$ oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記これは、イメージストリームのインポートプロセスでミラーまたは検索メカニズムが使用されないので必要になります。
Cluster Samples Operator 設定オブジェクトの
skippedImagestreams
フィールドにミラーリングされないイメージストリームを追加します。または、サンプルイメージストリームのいずれもサポートする必要がない場合は、Cluster Samples Operator を Cluster Samples Operator 設定オブジェクトのRemoved
に設定します。注記Cluster Samples Operator は、イメージストリームのインポートに失敗した場合にアラートを発行しますが、Cluster Samples Operator は定期的に再試行する場合もあれば、それらを再試行していないように見える場合もあります。
openshift
namespace のテンプレートの多くはイメージストリームを参照します。そのため、Removed
を使用してイメージストリームとテンプレートの両方を除去すると、イメージストリームのいずれかが欠落しているためにテンプレートが正常に機能しない場合にテンプレートの使用を試行する可能性がなくなります。
3.4.1. ミラーリングの Cluster Samples Operator のサポート リンクのコピーリンクがクリップボードにコピーされました!
インストール中に、Red Hat OpenShift Service on AWS は openshift-cluster-samples-operator
namespace に imagestreamtag-to-image
という名前の config map を作成します。imagestreamtag-to-image
config map には、各イメージストリームタグのエントリー (設定されるイメージ) が含まれます。
config map のデータフィールドにおける各エントリーのキーの形式は、<image_stream_name>_<image_stream_tag_name>
です。
Red Hat OpenShift Service on AWS の非接続インストールを実行すると、Cluster Samples Operator のステータスが Removed
に設定されます。これを Managed
に変更することを選択した場合、サンプルがインストールされます。
ネットワークが制限されている環境または切断されている環境でサンプルを使用するには、ネットワークの外部のサービスにアクセスする必要がある場合があります。サービスの例には、Github、Maven Central、npm、RubyGems、PyPi などがあります。場合によっては、Cluster Samples Operator のオブジェクトが必要なサービスに到達できるようにするために、追加の手順を実行する必要があります。
この config map は、イメージストリームをインポートするためにミラーリングする必要があるイメージの参照情報として使用できます。
-
Cluster Samples Operator が
Removed
に設定される場合、ミラーリングされたレジストリーを作成するか、使用する必要のある既存のミラーリングされたレジストリーを判別できます。 - 新しい config map をガイドとして使用し、ミラーリングされたレジストリーに必要なサンプルをミラーリングします。
-
Cluster Samples Operator 設定オブジェクトの
skippedImagestreams
リストに、ミラーリングされていないイメージストリームを追加します。 -
Cluster Samples Operator 設定オブジェクトの
samplesRegistry
をミラーリングされたレジストリーに設定します。 -
次に、Cluster Samples Operator を
Managed
に設定し、ミラーリングしたイメージストリームをインストールします。
詳細の手順は、代替のレジストリーまたはミラーリングされたレジストリーでの Cluster Samples Operator イメージストリームの使用 を参照してください。
第4章 イメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
使用可能な事前にビルドされたイメージを使用して独自のコンテナーイメージを作成する方法を確認します。このプロセスには、イメージの作成、イメージのメタデータの定義、イメージのテストおよびカスタムビルダーワークフローを使用した Red Hat OpenShift Service on AWS で使用するイメージの作成のベストプラクティスを理解することが含まれます。
4.1. コンテナーのベストプラクティスについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS で実行するコンテナーイメージを作成する場合には、イメージの作成者は、イメージの使いやすさの点で数多くのベストプラクティスを考慮する必要があります。イメージは変更不可で、そのままの状態で使用されることが意図されているため、以下のガイドラインは、イメージを使用しやすく、Red Hat OpenShift Service on AWS で簡単に使用できるようにするのに役立ちます。
4.1.1. コンテナーイメージの一般的なガイドライン リンクのコピーリンクがクリップボードにコピーされました!
以下のガイドラインは、イメージが Red Hat OpenShift Service on AWS で使用されるかどうかにかかわらず、コンテナーイメージの作成時に一般的に適用されます。
イメージの再利用
可能な場合は、FROM
ステートメントを使用し、適切なアップストリームイメージをベースとしてイメージを設定します。これにより、依存関係を直接更新する必要なく、イメージが更新時にアップストリームイメージからセキュリティー修正を簡単に取得できるようになります。
さらに、FROM
命令 (例: rhel:rhel7
) のタグを使用して、お使いのイメージがどのバージョンのイメージをベースとしているかを明確にします。アップストリームイメージの latest
バージョンを使用すると互換性に影響のある変更が組み込まれる可能性があるため、latest
以外のタグを使用することができます。
タグ内の互換性の維持
独自のイメージにタグを付ける場合には、タグ内で後方互換性が維持されるようにします。たとえば、image
という名前のイメージがあり、現時点でバージョン 1.0
が含まれている場合には、image:v1
のタグを指定します。イメージの更新時には、元のイメージとの互換性がある限り、新しいイメージに image:v1
のタグを付けることができ、このタグのダウンストリームのコンシューマーは、互換性に関する影響を被ることなく更新を取得できるようになります。
互換性のない更新を後にリリースした場合には、image:v2
などの新しいタグに切り替えます。これにより、ダウンストリームのコンシューマーはいつでも新しいバージョンに移行できますが、意図せずにこの互換性のない新規イメージによる影響を受けることはありません。image:latest
を使用するダウンストリームコンシューマーには、互換性のない変更が導入されるリスクがあります。
複数プロセスの回避
データベースや SSHD
など複数のサービスを 1 つのコンテナー内で起動しないようにしてください。コンテナーは軽量で、複数のプロセスをオーケストレーションするために簡単にリンクできるので、複数プロセスの実行は不要です。Red Hat OpenShift Service on AWS では、関連のあるイメージを 1 つの Pod にグループ化して、簡単に共存させ、共同管理することができます。
このように共存させることで、コンテナーはネットワークの namespace とストレージを通信用に共有できるようになります。また、イメージの更新頻度が低く、個別に更新されるので、更新による中断の可能性が低くなります。シグナル処理フローは、複数の起動したプロセスへのルーティングシグナルを管理する必要がないので、単一プロセスによって明確になります。
ラッパースクリプトでの exec
の使用
多くのイメージはラッパースクリプトを使用して、実行されるソフトウェアのプロセスを開始する前にいくつかの設定を行います。イメージがこのようなスクリプトを使用する場合、そのスクリプトは、スクリプトのプロセスがソフトウェアによって置き換えられるように exec
を使用します。exec
を使用しない場合、コンテナーランタイムによって送信されるシグナルが、ソフトウェアのプロセスではなくラッパースクリプトに送られます。これは望ましい動作ではありません。
一部のサーバーのプロセスを開始するラッパースクリプトがあるとします。podman run -i
などを使用してコンテナーを起動すると、それによりラッパースクリプトが実行され、次にプロセスが開始されます。CTRL+C
でコンテナーを閉じる必要があるとします。ラッパースクリプトがサーバープロセスを開始するために exec
を使用している場合、podman
は SIGINT をサーバープロセスに送信し、すべてが予想通りに機能します。ラッパースクリプトで exec
を使用しなかった場合、podman
はラッパースクリプトのプロセスに SIGINT を送信し、プロセスは何も生じなかったかのように実行し続けます。
また、コンテナー内で実行されると、プロセスは PID 1
として実行される点に留意してください。つまり、主なプロセスが中断された場合には、コンテナー全体が停止され、PID 1
プロセスから起動した子プロセスが終了します。
一時ファイルの消去
ビルドプロセスで作成される一時ファイルはすべて削除します。これには、ADD
コマンドで追加したファイルも含まれます。たとえば、yum install
の操作を実行してから、yum clean
コマンドを実行します。
yum
キャッシュがイメージレイヤーに残らないように、以下のように RUN
ステートメントを作成します。
RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y
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
RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y
上記のように記述すると、最初の yum
呼び出しにより、対象のレイヤーに追加のファイルが残り、yum clean
操作を後に実行してもこれらのファイルは削除できません。これらの追加ファイルは最終イメージでは確認できませんが、下位レイヤーには存在します。
現在のコンテナービルドプロセスでは、前のレイヤーで何かが削除された場合でも、後のレイヤーでコマンドを実行してイメージが使用する容量を縮小できません。ただし、これは今後変更される可能性があります。後のレイヤーでファイルが表示されていなくても rm
コマンドを実行したとしても、ダウンロードするイメージの全体のサイズを縮小することになりません。そのため、yum clean
の場合のように、可能な場合は後にレイヤーに書き込まれないように、ファイルの作成に使用したのと同じコマンドでファイルを削除することが最も適切と言えます。
また、単一の RUN
ステートメントで複数のコマンドを実行すると、イメージのレイヤー数が減り、ダウンロードと実行時間が短縮されます。
正しい順序での命令の指定
コンテナービルダーは Dockerfile
を読み取り、トップダウンで命令を実行します。命令が正常に実行されると、同じイメージが次回ビルドされるときや、別のイメージがビルドされる時に再利用することができるレイヤーが作成されます。Dockerfile
の上部にほとんど変更されない命令を配置することは非常に重要です。こうすることで、上位レイヤーで加えられた変更によってキャッシュが無効にならないので、同じイメージの次回のビルドをすばやく実行できます。
たとえば、反復するファイルをインストールするための ADD
コマンドと、パッケージを yum install
する RUN
コマンドが含まれる Dockerfile
で作業を行う場合には、ADD
コマンドを最後に配置することが最善の方法です。
FROM foo RUN yum -y install mypackage && yum clean all -y ADD myfile /test/myfile
FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile
これにより、myfile
を編集して podman build
または docker build
を返すたびに、システムは yum
コマンドのキャッシュされたレイヤーを再利用し、ADD
操作に対してのみ新規レイヤーを生成します。
代わりに Dockerfile
を以下のように作成した場合:
FROM foo ADD myfile /test/myfile RUN yum -y install mypackage && yum clean all -y
FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y
myfile
を変更して、podman build
または docker build
を再実行するたびに、ADD
操作は RUN
レイヤーのキャッシュを無効にするので、yum
操作も再実行する必要があります。
重要なポートのマーク付け
EXPOSE 命令は、ホストシステムで利用できるコンテナーおよび他のコンテナーにポートを作成します。ポートを podman run
の起動で公開されるように指定できますが、Dockerfile
で EXPOSE 命令を使用すると、ソフトウェアが実行する必要のあるポートを明示的に宣言することで、人間とソフトウェアの両方がイメージをより簡単に使用できるようになります。
-
公開されるポートは、イメージから作成されるコンテナーに関連付けられる
podman ps
の下に表示されます。 -
公開されるポートは、
podman inspect
によって返されるイメージのメタデータに表示されます。 - 公開されるポートは、1 つのコンテナーを別のコンテナーにリンクする際にリンクされます。
環境変数の設定
ENV
命令で環境変数を設定することが適切です。一例として、プロジェクトのバージョンを設定するなどが挙げられます。バージョンを設定することで、Dockerfile
を確認せずにバージョンを簡単に見つけ出すことができます。別の例としては、JAVA_HOME
など、別のプロセスで使用可能なシステムでパスを公開する場合などです。
デフォルトのパスワードの回避
デフォルトのパスワードは設定しないようにしてください。イメージを拡張して、デフォルトのパスワードを削除または変更するのを忘れることが多くあります。これは、実稼働環境で使用するユーザーに誰でも知っているパスワードが割り当てられると、セキュリティーの問題に発展する可能性があります。パスワードは、環境変数を使用して設定できます。
デフォルトのパスワードを設定することにした場合には、コンテナーの起動時に適切な警告メッセージが表示されるようにしてください。メッセージはデフォルトパスワードの値をユーザーに通知し、環境変数の設定など、パスワードの変更方法を説明するものである必要があります。
SSHD の回避
イメージで sshd
を実行しないようにしてください。ローカルホストで実行中のコンテナーにアクセスするには、podman exec
または docker exec
コマンドを使用できます。または、oc exec
コマンドまたは oc rsh
コマンドを使用して、Red Hat OpenShift Service on AWS クラスターで実行中のコンテナーにアクセスできます。イメージで sshd
をインストールし、実行すると、攻撃の経路が増え、セキュリティー修正が必要になります。
永続データ向けのボリュームの使用
イメージは、永続データ用に ボリューム を使用する必要があります。こうすることで、Red Hat OpenShift Service on AWS により、コンテナーを実行するノードにネットワークストレージがマウントされ、コンテナーが新しいノードに移動した場合に、ストレージはそのノードに再度割り当てられます。永続ストレージのすべての要件に対応するようにボリュームを使用することで、コンテナーが再起動されたり、移動されたりしても、コンテンツは保存されます。イメージがコンテナー内の任意の場所にデータを書き込む場合には、コンテンツは保存されない可能性があります。
コンテナーが破棄された後も保存する必要のあるデータはすべて、ボリュームに書き込む必要があります。コンテナーエンジンはコンテナーの readonly
フラグをサポートしており、このフラグを使用して、コンテナーの一時ストレージにデータが決して記述されないようにすることができます。イメージをこの機能に基づいて設計すると、この機能を後に利用することがより簡単になります。
Dockerfile
でボリュームを明示的に定義すると、イメージの利用者がイメージの実行時に定義する必要のあるボリュームがどれかを簡単に理解できるようになります。
Red Hat OpenShift Service on AWS でのボリュームの使用方法の詳細は、Kubernetes ドキュメント を参照してください。
永続ボリュームでも、イメージの各インスタンスには独自のボリュームがあり、ファイルシステムはインスタンス間で共有されません。つまり、ボリュームを使用してクラスターの状態を共有できません。
4.1.2. Red Hat OpenShift Service on AWS 固有のガイドライン リンクのコピーリンクがクリップボードにコピーされました!
以下は、Red Hat OpenShift Service on AWS で使用するためのコンテナーイメージの作成時に適用されるガイドラインです。
4.1.2.1. Source-To-Image (S2I) 向けのイメージの有効化 リンクのコピーリンクがクリップボードにコピーされました!
開発者が提供した Ruby コードを実行するように設計された Ruby イメージなど、サードパーティー提供のアプリケーションコードを実行することが目的のイメージの場合には、イメージを Source-to-Image (S2I) ビルドツールと連携できるようにすることができます。S2I は、インプットとして、アプリケーションのソースコードを受け入れるイメージを簡単に記述でき、アセンブルされたアプリケーションをアウトプットとして実行する新規イメージを簡単に生成することができるフレームワークです。
4.1.2.2. 任意のユーザー ID のサポート リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは Red Hat OpenShift Service on AWS は、任意に割り当てられたユーザー ID を使用してコンテナーを実行します。こうすることで、コンテナーエンジンの脆弱性が原因でコンテナーから出ていくプロセスに対して追加のセキュリティーを設定でき、ホストノードでパーミッションのエスカレーションが可能になります。
イメージが任意ユーザーとしての実行をサポートできるように、イメージ内のプロセスで記述されるディレクトリーやファイルは、root グループが所有し、このグループに対して読み取り/書き込みの権限を割り当てる必要があります。実行予定のファイルには、グループの実行権限も必要です。
以下を Dockerfile に追加すると、root グループのユーザーがビルドされたイメージでアクセスできるように、ディレクトリーおよびファイルのパーミッションが設定されます。
RUN chgrp -R 0 /some/directory && \ chmod -R g=u /some/directory
RUN chgrp -R 0 /some/directory && \
chmod -R g=u /some/directory
コンテナーユーザーは常に root グループのメンバーであるため、コンテナーユーザーはこれらのファイルに対する読み取り、書き込みが可能です。
コンテナーの機密領域のディレクトリーとファイルパーミッションを変更する場合は注意が必要です。/etc/passwd
ファイルなどの機密領域に変更を適用すると、意図しないユーザーによるこれらのファイルの変更が許可され、コンテナーまたはホストがセキュリティーリスクにさらされる可能性があります。CRI-O は、コンテナーの /etc/passwd
ファイルへに対する任意のユーザー ID の挿入をサポートしています。そのため、パーミッションを変更する必要はありません。
また、いずれのコンテナーイメージにも /etc/passwd
ファイルが存在しないはずです。存在する場合、CRI-O コンテナーランタイムはランダムな UID を /etc/passwd
ファイルに挿入できません。このような場合、コンテナーがアクティブな UID を解決する際に問題が発生する可能性があります。この要件を満たさない場合、特定のコンテナー化されたアプリケーションの機能に影響が及ぶ可能性があります。
さらに、コンテナーで実行中のプロセスは、特権のあるユーザーとして実行されていないので、特権のあるポート (1024 未満のポート) をリッスンできません。
4.1.2.3. イメージ間通信でのサービスの使用 リンクのコピーリンクがクリップボードにコピーされました!
データの保存や取得のためにデータベースイメージにアクセスする必要のある Web フロントエンドイメージなど、別のイメージが提供するサービスとイメージが通信する場合には、イメージは Red Hat OpenShift Service on AWS サービスを使用します。サービスは、コンテナーが停止、開始、または移動しても変更されない静的アクセスエンドポイントを提供します。さらに、サービスにより、要求が負荷分散されます。
4.1.2.4. 共通のライブラリーの提供 リンクのコピーリンクがクリップボードにコピーされました!
サードパーティーが提供するアプリケーションコードの実行を目的とするイメージの場合は、プラットフォーム用として共通に使用されるライブラリーをイメージに含めるようにしてください。とくに、プラットフォームで使用する共通のデータベース用のデータベースドライバーを設定してください。たとえば、Java フレームワークイメージを作成する場合に、MySQL や PostgreSQL には JDBC ドライバーを設定します。このように設定することで、アプリケーションのアセンブリー時に共通の依存関係をダウンロードする必要がなくなり、アプリケーションイメージのビルドがスピードアップします。また、すべての依存関係の要件を満たすためのアプリケーション開発者の作業が簡素化されます。
4.1.2.5. 設定での環境変数の使用 リンクのコピーリンクがクリップボードにコピーされました!
イメージのユーザーは、ダウンストリームイメージをイメージに基づいて作成しなくても、イメージを設定できます。つまり、ランタイム設定は環境変数を使用して処理されます。単純な設定の場合、実行中のプロセスは環境変数を直接使用できます。より複雑な設定や、これをサポートしないランタイムの場合、起動時に処理されるテンプレート設定ファイルを定義してランタイムを設定します。このプロセス時に、環境変数を使用して渡される値は設定ファイルで置き換えることも、この値を使用して、設定ファイルに指定するオプションを決定することもできます。
環境変数を使用して、コンテナーに証明書やキーなどのシークレットを渡すこともでき、これは推奨されています。環境変数を使用することで、シークレット値がイメージにコミットされたり、コンテナーイメージレジストリーに漏洩されることはありません。
環境変数を指定することで、イメージの利用者は、イメージ上に新しいレイヤーを作成することなく、データベースの設定、パスワード、パフォーマンスチューニングなどの動作をカスタマイズできます。Pod の定義時に環境変数の値を定義するだけで、イメージの再ビルドなしに設定を変更できます。
非常に複雑なシナリオの場合、ランタイム時にコンテナーにマウントされるボリュームを使用して設定を指定することも可能です。ただし、この方法を使用する場合には、必要なボリュームや設定が存在しない場合に明確なエラーメッセージが起動時に表示されるように、イメージが設定されている必要があります。
サービスエンドポイントの情報を渡す環境変数としてデータソースなどの設定を定義される点で、これはイメージ間の通信でのサービスの使用に関するトピックと関連しています。これにより、アプリケーションは、アプリケーションイメージを変更せずに、Red Hat OpenShift Service on AWS 環境に定義されているデータソースサービスを動的に使用できます。
さらに、コンテナーの cgroups
設定を確認して、調整します。これにより、イメージは利用可能なメモリー、CPU、他のリソースに合わせてチューニングが可能になります。たとえば、Java ベースのイメージは、制限を超えず、メモリー不足のエラーが表示されないように、cgroup
の最大メモリーパラメーターを基にヒープをチューニングします。
4.1.2.6. イメージのメタデータ設定 リンクのコピーリンクがクリップボードにコピーされました!
イメージのメタデータを定義することで、Red Hat OpenShift Service on AWS によるコンテナーイメージの使用が改善され、開発者が Red Hat OpenShift Service on AWS でイメージを使用しやすくなります。たとえば、メタデータを追加して、イメージに関する役立つ情報を提供したり、必要とされる他のイメージを提案したりできます。
4.1.2.7. クラスタリング リンクのコピーリンクがクリップボードにコピーされました!
イメージの複数のインスタンスを実行するとはどういうことかを十分に理解しておく必要があります。最も単純な例では、サービスの負荷分散機能は、イメージのすべてのインスタンスにトラフィックをルーティングします。ただし、セッションの複製などで、リーダーの選択やフェイルオーバーの状態を実行するには、多くのフレームワークが情報を共有する必要があります。
Red Hat OpenShift Service on AWS での実行時に、インスタンスでこのような通信を実現する方法を検討します。Pod 同士は直接通信できますが、Pod が起動、停止、移動するたびに IP アドレスが変更されます。そのため、クラスタリングスキームを動的にしておくことが重要です。
4.1.2.8. ロギング リンクのコピーリンクがクリップボードにコピーされました!
すべてのロギングを標準出力に送信することが推奨されます。Red Hat OpenShift Service on AWS はコンテナーから標準出力を収集し、表示が可能な中央ロギングサービスに送信します。ログコンテンツを分離する必要がある場合には、出力の接頭辞に適切なキーワードを指定して、メッセージをフィルタリングできるようにしてください。
お使いのイメージがファイルにロギングをする場合には、手動で実行中のコンテナーに入り、ログファイルを取得または表示する必要があります。
4.1.2.9. Liveness および Readiness プローブ リンクのコピーリンクがクリップボードにコピーされました!
イメージで使用可能な liveness および readiness プローブの例をまとめます。これらのプローブにより、処理の準備ができるまでトラフィックがコンテナーにルーティングされず、プロセスが正常でない状態になる場合にコンテナーが再起動されるので、ユーザーはイメージを安全にデプロイできます。
4.1.2.10. テンプレート リンクのコピーリンクがクリップボードにコピーされました!
イメージと共にテンプレートサンプルを提供することも検討してください。テンプレートがあると、ユーザーは、正しく機能する設定を指定してイメージをすばやく簡単にデプロイできるようになります。完全を期すため、テンプレートには、イメージに関連して記述した liveness および readiness プローブを含めるようにしてください。
4.2. イメージへのメタデータの組み込み リンクのコピーリンクがクリップボードにコピーされました!
イメージのメタデータを定義することで、Red Hat OpenShift Service on AWS によるコンテナーイメージの使用が改善され、開発者が Red Hat OpenShift Service on AWS でイメージを使用しやすくなります。たとえば、メタデータを追加して、イメージに関する役立つ情報を提供したり、必要とされる可能性のある他のイメージを提案したりできます。
このトピックでは、現在の一連のユースケースに必要なメタデータのみを定義します。他のメタデータまたはユースケースは、今後追加される可能性があります。
4.2.1. イメージメタデータの定義 リンクのコピーリンクがクリップボードにコピーされました!
Dockerfile
で LABEL
命令を使用して、イメージのメタデータを定義することができます。ラベルは、イメージやコンテナーに割り当てるキーと値のペアである点で環境変数と似ています。ただし、ラベルは、実行中のアプリケーションに表示されず、イメージやコンテナーをすばやく検索する場合にも使用できる点で、環境変数とは異なります。
LABEL
命令に関する詳細は、Docker ドキュメント を参照してください。
通常、ラベル名には namespace が使用されます。namespace は、対象のラベルを選択して使用するプロジェクトを反映するように設定されます。Red Hat OpenShift Service on AWS の場合、namespace は io.openshift
に設定され、Kubernetes の場合、namespace は io.k8s
に設定されます。
形式に関する詳細は、Docker のカスタムメタデータ に関するドキュメントを参照してください。
変数 | 説明 |
---|---|
| このラベルには、コンマ区切りの文字列値のリストとして表現されているタグのリストが含まれます。タグを使用して、コンテナーイメージを幅広い機能エリアに分類します。タグを使用すると、UI および生成ツールがアプリケーションの作成プロセスで適切なコンテナーイメージを提案しやすくなります。 LABEL io.openshift.tags mongodb,mongodb24,nosql
|
|
コンテナーイメージにすでにタグが指定されていない場合に、生成ツールと UI が適切な提案を行うのに使用するタグのリストを指定します。たとえば、コンテナーイメージに LABEL io.openshift.wants mongodb,redis
|
| このラベルは、コンテナーイメージの利用者に、このイメージが提供するサービスや機能に関する詳細情報を提供するのに使用できます。UI は、この説明とコンテナーイメージ名を使用して、人間が解読しやすい情報をエンドユーザーに提供します。 LABEL io.k8s.description The MySQL 5.5 Server with master-slave replication support
|
|
イメージは、この変数を使用して、スケーリングがサポートされていないことを示す場合があります。その後、UI はこれをそのイメージのコンシューマーに通知します。スケーリング不可にした場合は LABEL io.openshift.non-scalable true
|
| このラベルは、コンテナーイメージが正しく機能するにはどの程度リソースが必要かを提案します。UI でユーザーに対し、このコンテナーイメージをデプロイすると、ユーザークォータを超過する可能性があることを警告する場合があります。この値は、Kubernetes の数量と互換性がある必要があります。 LABEL io.openshift.min-memory 16Gi LABEL io.openshift.min-cpu 4
|
4.3. Source-to-Image によるソースコードからのイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
Source-to-Image (S2I) は、アプリケーションのソースコードを入力として取り、アセンブルされたアプリケーションを出力として実行する新規イメージを生成するイメージを簡単に作成できるようにするフレームワークです。
再生成可能なコンテナーイメージのビルドに S2I を使用する主な利点として、開発者の使い勝手の良さが挙げられます。ビルダーイメージの作成者は、イメージが最適な S2I パフォーマンスを実現できるように、ビルドプロセスと S2I スクリプトの基本的なコンセプト 2 点を理解する必要があります。
4.3.1. Source-to-Image ビルドプロセスについて リンクのコピーリンクがクリップボードにコピーされました!
ビルドプロセスは次の 3 つの基本要素で構成されます。これらを組み合わせて最終的なコンテナーイメージが作成されます。
- ソース
- Source-to-Image (S2I) スクリプト
- ビルダーイメージ
S2I は、最初の FROM
命令として、ビルダーイメージで Dockerfile を生成します。S2I によって生成される Dockerfile は Buildah に渡されます。
4.3.2. Source-to-Image スクリプトの作成方法 リンクのコピーリンクがクリップボードにコピーされました!
Source-to-Image (S2I) スクリプトは、ビルダーイメージ内でスクリプトを実行できる限り、どのプログラム言語でも記述できます。S2I は assemble
/run
/save-artifacts
スクリプトを提供する複数のオプションをサポートします。ビルドごとに、これらの場所はすべて、以下の順番にチェックされます。
- ビルド設定に指定されるスクリプト
-
アプリケーションソースの
.s2i/bin
ディレクトリーにあるスクリプト -
io.openshift.s2i.scripts-url
ラベルを含むデフォルトの URL にあるスクリプト
イメージで指定した io.openshift.s2i.scripts-url
ラベルも、ビルド設定で指定したスクリプトも、以下の形式のいずれかを使用します。
-
image:///path_to_scripts_dir
: S2I スクリプトが配置されているディレクトリーへのイメージ内の絶対パス。 -
file:///path_to_scripts_dir
: S2I スクリプトが配置されているディレクトリーへのホスト上の相対パスまたは絶対パス。 -
http(s)://path_to_scripts_dir
: S2I スクリプトが配置されているディレクトリーの URL。
スクリプト | 説明 |
---|---|
|
|
|
|
|
これらの依存関係は |
|
|
|
注記
|
S2I スクリプトの例
以下の S2I スクリプトの例は Bash で記述されています。各例では、tar
の内容が /tmp/s2i
ディレクトリーに展開されていることを前提としています。
assemble
スクリプト:
run
スクリプト:
run the application
#!/bin/bash
# run the application
/opt/application/run.sh
save-artifacts
スクリプト:
usage
スクリプト:
4.4. Source-to-Image イメージのテストについて リンクのコピーリンクがクリップボードにコピーされました!
Source-to-Image (S2I) ビルダーイメージの作成者は、S2I イメージをローカルでテストして、自動テストや継続的な統合に Red Hat OpenShift Service on AWS ビルドシステムを使用できます。
S2I ビルドを正常に実行するには、S2I に assemble
と run
スクリプトが必要です。S2I 外のコンテナーイメージを実行した場合に、save-artifacts
スクリプトがあると、ビルドのアーティファクトが再利用され、usage
スクリプトがあると、使用に関する情報がコンソールに出力されるようになります。
S2I イメージのテストは、ベースのコンテナーイメージを変更したり、コマンドが使用するツールが更新されたりした場合でも、上記のコマンドが正しく機能することを確認するのが目的です。
4.4.1. テスト要件について リンクのコピーリンクがクリップボードにコピーされました!
test
スクリプトは、基本的に test/run
に配置されます。このスクリプトは、Red Hat OpenShift Service on AWS S2I イメージビルダーが呼び出し、単純な Bash スクリプトか静的な Go バイナリーのいずれかの形式を取ることができます。
test/run
スクリプトは S2I ビルドを実行するので、S2I バイナリーを $PATH
で利用可能にしておく必要があります。必要に応じて、S2I README のインストール手順に従います。
S2I は、アプリケーションのソースコードおよびビルダーイメージを統合します。これをテストするには、ソースが実行可能なコンテナーイメージに変換されることを検証するためのサンプルアプリケーションのソースが必要です。サンプルアプリケーションは単純なものである必要がありますが、assemble
および run
スクリプトの重要な手順を実行できる必要があります。
4.4.2. スクリプトおよびツールの生成 リンクのコピーリンクがクリップボードにコピーされました!
S2I ツールは、新しい S2I イメージの作成プロセスを加速化する強力な生成ツールと共に提供されます。s2i create
コマンドでは、Makefile
以外に、必要とされる S2I スクリプトとテストツールすべてが生成されます。
s2i create <image_name> <destination_directory>
$ s2i create <image_name> <destination_directory>
生成された test/run
スクリプトは、より使いやすくするために調整する必要がありますが、このスクリプトを開発の開始段階で使用することが推奨されます。
s2i create
コマンドで生成した test/run
スクリプトでは、サンプルアプリケーションのソースを test/test-app
ディレクトリーに配置しておく必要があります。
4.4.3. ローカルでのテスト リンクのコピーリンクがクリップボードにコピーされました!
S2I イメージテストをローカルに実行する最も簡単な方法として、生成した Makefile
を使用することができます。
s2i create
コマンドを使用しない場合には、以下の Makefile
テンプレートをコピーして、IMAGE_NAME
パラメーターをお使いのイメージ名に置き換えることができます。
Makefile
の例
4.4.4. テストの基本的なワークフロー リンクのコピーリンクがクリップボードにコピーされました!
test
スクリプトは、テストするイメージをすでにビルドしていることが前提です。必要に応じて、以下のコマンドで S2I イメージを先にビルドしてください。以下のいずれかのコマンドを実行してください。
Podman を使用する場合は、以下のコマンドを実行します。
podman build -t <builder_image_name>
$ podman build -t <builder_image_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Docker を使用する場合は、以下のコマンドを実行します。
docker build -t <builder_image_name>
$ docker build -t <builder_image_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下の手順では、S2I イメージビルダーをテストするデフォルトのワークフローを説明しています。
usage
スクリプトが機能していることを確認します。Podman を使用する場合は、以下のコマンドを実行します。
podman run <builder_image_name> .
$ podman run <builder_image_name> .
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Docker を使用する場合は、以下のコマンドを実行します。
docker run <builder_image_name> .
$ docker run <builder_image_name> .
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
イメージをビルドします。
s2i build file:///path-to-sample-app _<BUILDER_IMAGE_NAME>_ _<OUTPUT_APPLICATION_IMAGE_NAME>_
$ s2i build file:///path-to-sample-app _<BUILDER_IMAGE_NAME>_ _<OUTPUT_APPLICATION_IMAGE_NAME>_
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション:
save-artifacts
をサポートする場合には、再度手順 2 を実行して、保存して復元するアーティファクトが正しく機能することを確認します。 コンテナーを実行します。
Podman を使用する場合は、以下のコマンドを実行します。
podman run <output_application_image_name>
$ podman run <output_application_image_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Docker を使用する場合は、以下のコマンドを実行します。
docker run <output_application_image_name>
$ docker run <output_application_image_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- コンテナーが実行され、アプリケーションが応答していることを確認します。
これらの手順を実行すると、通常はビルダーイメージが予想通りに機能しているかどうかが分かります。
4.4.5. イメージのビルドでの Red Hat OpenShift Service on AWS の使用 リンクのコピーリンクがクリップボードにコピーされました!
新しい S2I ビルダーイメージを設定する Dockerfile
と他のアーティファクトが準備できたら、それらを git リポジトリーに配置して、Red Hat OpenShift Service on AWS を使用し、イメージをビルドしてプッシュします。お使いのリポジトリーを参照する Docker ビルドを定義します。
Red Hat OpenShift Service on AWS インスタンスが公開 IP アドレスでホストされる場合、ビルドは、S2I ビルダーイメージ GitHub リポジトリーにプッシュするたびにトリガーされます。
ImageChangeTrigger
を使用して、更新した S2I ビルダーイメージに基づくアプリケーションの再ビルドをトリガーすることもできます。
第5章 イメージの管理 リンクのコピーリンクがクリップボードにコピーされました!
5.1. イメージの管理の概要 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS では、イメージのレジストリーの場所、イメージのレジストリーに関する認証要件、ビルドとデプロイメントの動作方法に応じて、イメージを操作し、イメージストリームをセットアップできます。
5.1.1. イメージの概要 リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームは、タグによって識別される任意の数のコンテナーイメージで構成されます。これはコンテナーイメージリポジトリーのように関連イメージの単一仮想ビューを提供します。
イメージストリームの監視により、ビルドおよびデプロイメントは新規イメージの追加または変更時に通知を受信し、それぞれビルドまたはデプロイメントを実行してこれに対応します。
5.2. イメージのタグ付け リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、Red Hat OpenShift Service on AWS のイメージストリームとそのタグを操作するために、コンテナーイメージのコンテキストでイメージタグを使用する方法の概要と手順を説明します。
5.2.1. イメージタグ リンクのコピーリンクがクリップボードにコピーされました!
イメージタグは、イメージストリーム内の他のイメージから特定のイメージを識別するリポジトリーのコンテナーイメージに適用されるラベルです。通常、タグはある種のバージョン番号を表します。たとえば、ここでは :v3.11.59-2
がタグになります。
registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2
registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2
イメージにタグを追加することができます。たとえば、イメージには :v3.11.59-2
および :latest
というタグが割り当てられる可能性があります。
Red Hat OpenShift Service on AWS には oc tag
コマンドがあります。これは docker tag
コマンドに似ていますが、イメージを直接操作するのではなく、イメージストリームを操作するものです。
5.2.2. イメージタグの規則 リンクのコピーリンクがクリップボードにコピーされました!
イメージは時間の経過と共に変化するもので、それらのタグはその変化を反映します。ほとんどの場合、イメージタグはビルドされる最新イメージを常に参照します。
v2.0.1-may-2019
のように、タグ名に非常に多くの情報が組み込まれる場合、タグはイメージの単一のリビジョンのみを参照し、更新されることはありません。デフォルトのイメージのプルーニングオプションを使用しても、このようなイメージは削除されません。
タグの名前が v2.0
である場合はイメージのリビジョンの数が多くなることが予想されます。これによりタグ履歴が長くなるため、イメージプルーナーが古くなり使われなくなったイメージを削除する可能性が高くなります。
タグの名前付け規則は各自で定めることができますが、ここでは <image_name>:<image_tag>
形式のいくつかの例を見てみましょう。
説明 | 例 |
---|---|
リビジョン |
|
アーキテクチャー |
|
ベースイメージ |
|
最新 (不安定な可能性がある) |
|
最新 (安定性がある) |
|
タグ名に日付を含める必要がある場合、古くなり使用されなくなったイメージおよび istags
を定期的に検査し、これらを削除してください。そうしないと、古いイメージを保持して、リソースの使用量が増大する可能性があります。
5.2.3. イメージストリームへのタグの追加 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS のイメージストリームは、タグで識別される 0 個以上のコンテナーイメージで構成されます。
利用できるタグにはさまざまな種類があります。デフォルトの動作では、特定の時点のイメージを指す permanent
タグが使用されます。permanent
タグが使用されている場合、参照元が変更されても、参照先のタグは変更されません。
tracking
タグの場合は、宛先タグのメタデータがソースタグのインポート時に更新されます。
手順
oc tag
コマンドを使用して、タグをイメージストリームに追加できます。oc tag <source> <destination>
$ oc tag <source> <destination>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
ruby
イメージストリームのstatic-2.0
タグをruby
イメージストリーム2.0
タグの現行のイメージを常に参照するように設定するには、以下を実行します。oc tag ruby:2.0 ruby:static-2.0
$ oc tag ruby:2.0 ruby:static-2.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
ruby
イメージストリームにstatic-2.0
という名前のイメージストリームタグが新たに作成されます。この新規タグは、oc tag
の実行時にruby:2.0
イメージストリームタグが参照したイメージ ID を直接参照し、これが参照するイメージが変更されることがありません。宛先タグがソースタグの変更時に更新されるようにするには、
--alias=true
フラグを使用します。oc tag --alias=true <source> <destination>
$ oc tag --alias=true <source> <destination>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
永続的なエイリアス (latest
または stable
など) を作成するには、tracking タグを使用します。このタグは単一イメージストリーム内でのみ適切に機能します。複数のイメージストリーム間で使用されるエイリアスを作成しようとするとエラーが生じます。
-
また、
--scheduled=true
フラグを追加して、宛先タグが定期的に更新 (再インポート) されるようにもできます。期間はシステムレベルでグローバルに設定できます。 --reference
フラグはインポートされないイメージストリームを作成します。このタグはソースの場所を参照しますが、これを永続的に参照します。タグ付けされたイメージを統合レジストリーから常に取得するように Red Hat OpenShift Service on AWS に指示する場合は、
--reference-policy=local
を使用します。レジストリーはプルスルー (pull-through) 機能を使用してイメージをクライアントに提供します。デフォルトで、イメージ Blob はレジストリーによってローカルにミラーリングされます。その結果、それらが次回必要となる場合により迅速にプルされます。また、このフラグは--insecure-registry
をコンテナーランタイムに指定しなくても、イメージストリームに非セキュアなアノテーションがあるか、タグに非セキュアなインポートポリシーがある限り、非セキュアなレジストリーからのプルを許可します。
5.2.4. タグのイメージストリームからの削除 リンクのコピーリンクがクリップボードにコピーされました!
タグをイメージストリームから削除できます。
手順
タグをイメージストリームから完全に削除するには、以下を実行します。
oc delete istag/ruby:latest
$ oc delete istag/ruby:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、以下を実行します。
oc tag -d ruby:latest
$ oc tag -d ruby:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5. イメージストリームでのイメージの参照 リンクのコピーリンクがクリップボードにコピーされました!
タグを使用してイメージストリームのイメージを参照するには、以下の参照タイプを使用します。
参照タイプ | 説明 |
---|---|
|
|
|
|
|
|
イメージストリーム定義のサンプルを表示すると、これらには ImageStreamTag
の定義と DockerImage
の参照が含まれていますが、ImageStreamImage
に関連するものは何も含まれていないことに気づくでしょう。
これは、ImageStreamImage
オブジェクトが、イメージをイメージストリームにインポートまたはタグ付けする際に、Red Hat OpenShift Service on AWS に自動的に作成されるためです。イメージストリームを作成するために使用するイメージストリーム定義で ImageStreamImage
オブジェクトを明示的に定義する必要はありません。
手順
所定のメージストリームおよびタグのイメージを参照するには、
ImageStreamTag
を使用します。<image_stream_name>:<tag>
<image_stream_name>:<tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 所定のイメージストリームおよびイメージの
sha
ID のイメージを参照するには、ImageStreamImage
を使用します。<image_stream_name>@<id>
<image_stream_name>@<id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <id>
は、ダイジェストとも呼ばれる特定イメージのイミュータブルな ID です。所定の外部レジストリーのイメージを参照または取得するには、
DockerImage
を使用します。openshift/ruby-20-centos7:2.0
openshift/ruby-20-centos7:2.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記タグが指定されていない場合、
latest
タグが使用されることが想定されます。サードパーティーのレジストリーを参照することもできます。
registry.redhat.io/rhel7:latest
registry.redhat.io/rhel7:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow またはダイジェストでイメージを参照できます。
centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. イメージプルポリシー リンクのコピーリンクがクリップボードにコピーされました!
Pod のそれぞれのコンテナーにはコンテナーイメージがあります。イメージを作成し、これをレジストリーにプッシュすると、イメージを Pod で参照できます。
5.3.1. イメージプルポリシーの概要 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS はコンテナーを作成する際に、コンテナーの imagePullPolicy
を使用して、コンテナーの起動前にイメージをプルする必要があるかどうかを判別します。imagePullPolicy
には以下の 3 つの値があります。
値 | 説明 |
---|---|
| 常にイメージをプルします。 |
| イメージがノード上にない場合にのみイメージをプルします。 |
| イメージをプルしません。 |
コンテナーの imagePullPolicy
パラメーターが指定されていない場合、Red Hat OpenShift Service on AWS はイメージのタグに基づいてこのパラメーターを設定します。
-
タグが
latest
の場合、Red Hat OpenShift Service on AWS はimagePullPolicy
をAlways
にデフォルト設定します。 -
それ以外の場合は、Red Hat OpenShift Service on AWS は
imagePullPolicy
をIfNotPresent
にデフォルト設定します。
5.4. イメージプルシークレットの使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift イメージレジストリーを使用し、同じプロジェクトにあるイメージストリームからプルしている場合は、Pod のサービスアカウントに適切なパーミッションがすでに設定されているために追加のアクションは不要です。
ただし、Red Hat OpenShift Service on AWS プロジェクト全体でイメージを参照する場合や、セキュリティー保護されたレジストリーからイメージを参照するなどの他のシナリオでは、追加の設定手順が必要になります。
イメージの プルシークレットは、Red Hat OpenShift Cluster Manager から取得 できます。このプルシークレットは pullSecret
と呼ばれます。
このプルシークレットを使用し、Red Hat OpenShift Service on AWS コンポーネントのコンテナーイメージを提供する組み込まれた認証局 (Quay.io および registry.redhat.io) によって提供されるサービスで認証できます。
5.4.1. Pod が複数のプロジェクト間でイメージを参照できるようにする設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift イメージレジストリーを使用している場合で project-a
の Pod が project-b
のイメージを参照できるようにするには、project-a
のサービスアカウントが project-b
の system:image-puller
ロールにバインドされている必要があります。
Pod サービスアカウントまたは namespace を作成するときは、サービスアカウントが Docker プルシークレットでプロビジョニングされるまで待ちます。サービスアカウントが完全にプロビジョニングされる前に Pod を作成すると、Pod は OpenShift イメージレジストリーにアクセスできません。
手順
project-a
の Pod がproject-b
のイメージを参照できるようにするには、project-a
のサービスアカウントをproject-b
のsystem:image-puller
ロールにバインドします。oc policy add-role-to-user \ system:image-puller system:serviceaccount:project-a:default \ --namespace=project-b
$ oc policy add-role-to-user \ system:image-puller system:serviceaccount:project-a:default \ --namespace=project-b
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このロールを追加すると、デフォルトのサービスアカウントを参照する
project-a
の Pod はproject-b
からイメージをプルできるようになります。project-a
のすべてのサービスアカウントにアクセスを許可するには、グループを使用します。oc policy add-role-to-group \ system:image-puller system:serviceaccounts:project-a \ --namespace=project-b
$ oc policy add-role-to-group \ system:image-puller system:serviceaccounts:project-a \ --namespace=project-b
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2. Pod が他のセキュリティー保護されたレジストリーからイメージを参照できるようにする設定 リンクのコピーリンクがクリップボードにコピーされました!
他のプライベートレジストリーレジストリーまたは保護されたレジストリーから保護されたコンテナーをプルするには、Docker や Podman などのコンテナークライアント認証情報からプルシークレットを作成し、それをサービスアカウントに追加する必要があります。
Docker と Podman は設定ファイルを使用して、保護されたレジストリーまたは保護されていないレジストリーへのログインに使用する認証の詳細を保存します。
-
Docker: Docker は、デフォルトで
$HOME/.docker/config.json
を使用します。 -
Podman: Podman は、デフォルトで
$HOME/.config/containers/auth.json
を使用します。
以前に保護されたレジストリーまたは保護されていないレジストリーにログインしたことがある場合、これらのファイルには認証情報が保存されます。
quay.io
や quay.io/<example_repository>
のような一意のパスがある場合、Docker と Podman の認証情報ファイルおよび関連するプルシークレットには、同一レジストリーへの複数の参照を含めることができます。ただし、Docker および Podman のいずれも、まったく同じレジストリーパスの複数エントリーはサポートしていません。
config.json
ファイルのサンプル
プルシークレットの例
5.4.2.1. プルシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
手順
既存の認証ファイルからシークレットを作成します。
.docker/config.json
を使用する Docker クライアントの場合は、次のコマンドを入力します。oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
$ oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow .config/containers/auth.json
を使用する Podman クライアントの場合は、次のコマンドを入力します。oc create secret generic <pull_secret_name> \ --from-file=<path/to/.config/containers/auth.json> \ --type=kubernetes.io/podmanconfigjson
$ oc create secret generic <pull_secret_name> \ --from-file=<path/to/.config/containers/auth.json> \ --type=kubernetes.io/podmanconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
セキュアなレジストリーの Docker 認証情報ファイルがまだない場合は、次のコマンドを実行してシークレットを作成できます。
oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>
$ oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.2. ワークロードでのプルシークレットの使用 リンクのコピーリンクがクリップボードにコピーされました!
プルシークレットを使用すると、ワークロードが次のいずれかの方法でプライベートレジストリーからイメージをプルできるようになります。
-
シークレットを
ServiceAccount
にリンクする。これにより、そのサービスアカウントを使用するすべての Pod にシークレットが自動的に適用されます。 -
ワークロード設定で
imagePullSecrets
を直接定義する。これは GitOps や ArgoCD などの環境に役立ちます。
手順
サービスアカウントにシークレットを追加することで、Pod のイメージをプルするためのシークレットを使用できます。サービスアカウントの名前は、Pod が使用するサービスアカウントの名前と一致する必要があることに注意してください。デフォルトのサービスアカウントは
default
です。次のコマンドを入力してプルシークレットを
ServiceAccount
にリンクします。oc secrets link default <pull_secret_name> --for=pull
$ oc secrets link default <pull_secret_name> --for=pull
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を確認するために、次のコマンドを入力します。
oc get serviceaccount default -o yaml
$ oc get serviceaccount default -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
シークレットをサービスアカウントにリンクする代わりに、Pod またはワークロード定義で直接参照することもできます。これは ArgoCD などの GitOps ワークフローに役立ちます。以下に例を示します。
Pod 仕様の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ArgoCD ワークフローの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.3. 委任された認証を使用したプライベートレジストリーからのプル リンクのコピーリンクがクリップボードにコピーされました!
プライベートレジストリーは認証を別個のサービスに委任できます。この場合、イメージプルシークレットは認証およびレジストリーのエンドポイントの両方に対して定義される必要があります。
手順
委任された認証サーバーのシークレットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プライベートレジストリーのシークレットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 イメージストリームの管理 リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームは、継続的な方法でコンテナーイメージの作成および更新を行う手段を提供します。イメージの改良により、タグを使用して新規バージョン番号を割り当て、変更を追跡できるようになりました。このドキュメントでは、イメージストリームの管理方法を説明します。
6.1. イメージストリームを使用する理由 リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームとそれに関連付けられたタグは、Red Hat OpenShift Service on AWS 内からコンテナーイメージを参照するための抽象化を提供します。イメージストリームとそのタグを使用して、利用可能なイメージを確認し、リポジトリーのイメージが変更される場合でも必要な特定のイメージを使用していることを確認できます。
イメージストリームには実際のイメージデータは含まれませんが、イメージリポジトリーと同様に、関連するイメージの単一の仮想ビューが提示されます。
ビルドおよびデプロイメントをそれぞれ実行し、ビルドおよびデプロイメントを、新規イメージが追加される際やこれに対応する際の通知をイメージストリームで確認できるように設定できます。
たとえば、デプロイメントで特定のイメージを使用していて、そのイメージの新規バージョンが作成される場合、デプロイメントを、そのイメージの新規バージョンを選択できるように自動的に実行きます。
デプロイメントまたはビルドで使用するイメージストリームタグが更新されない場合には、コンテナーイメージレジストリーのコンテナーイメージが更新されても、ビルドまたはデプロイメントは以前の、既知でおそらく適切であると予想されるイメージをそのまま使用します。
ソースイメージは以下のいずれかに保存できます。
- Red Hat OpenShift Service on AWS の統合レジストリー
- registry.redhat.io または quay.io などの外部レジストリー
- Red Hat OpenShift Service on AWS クラスターの他のイメージストリーム
ビルドまたはデプロイメント設定などのイメージストリームタグを参照するオブジェクトを定義する場合には、リポジトリーではなく、イメージストリームタグを参照します。アプリケーションのビルドまたはデプロイ時に、Red Hat OpenShift Service on AWS はイメージストリームタグを使用してリポジトリーにクエリーを送信し、イメージの関連付けられた ID を特定し、正確なイメージを使用します。
イメージストリームメタデータは他のクラスター情報と共に etcd インスタンスに保存されます。
イメージストリームの使用には、いくつかの大きな利点があります。
- コマンドラインを使用して再プッシュすることなく、タグ付けや、タグのロールバック、およびイメージの迅速な処理を実行できます。
- 新規イメージがレジストリーにプッシュされると、ビルドおよびデプロイメントをトリガーできます。また、Red Hat OpenShift Service on AWS には他のリソースの汎用トリガーがあります (Kubernetes オブジェクトなど)。
- 定期的な再インポートを実行するためにタグにマークを付けることができます。ソースイメージが変更されると、その変更は選択され、イメージストリームに反映されます。これにより、ビルドまたはデプロイメント設定に応じてビルドまたはデプロイメントフローがトリガーされます。
- 詳細なアクセス制御を使用してイメージを共有し、チーム間でイメージを迅速に分散できます。
- ソースイメージが変更されると、イメージストリームタグはイメージの既知の適切なバージョンをポイントしたままになり、アプリケーションが予期せずに損傷しないようにします。
- イメージストリームオブジェクトのパーミッションを使用して、イメージを表示し、使用できるユーザーにセキュリティーを設定できます。
- クラスターレベルでイメージを読み込んだり、リスト表示するパーミッションのないユーザーは、イメージストリームを使用してプロジェクトでタグ付けされたイメージを取得できます。
6.2. イメージストリームの設定 リンクのコピーリンクがクリップボードにコピーされました!
ImageStream
オブジェクトには以下の要素が含まれます。
イメージストリームオブジェクト定義
6.3. イメージストリームイメージ リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームイメージは、イメージストリームから特定のイメージ ID をポイントします。
イメージストリームイメージにより、タグ付けされている特定のイメージストリームからイメージに関するメタデータを取得できます。
イメージストリームにイメージをインポートまたはタグ付けすると、イメージストリームのイメージオブジェクトが Red Hat OpenShift Service on AWS に自動的に作成されます。イメージストリームを作成するために使用するイメージストリームイメージオブジェクトをイメージストリーム定義に明示的に定義する必要はありません。
イメージストリームのイメージは、リポジトリーからのイメージストリーム名とイメージ ID で構成されており、@
記号で区切られています。
<image-stream-name>@<image-id>
<image-stream-name>@<image-id>
ImageStream
オブジェクトのサンプルでイメージを参照する際、イメージストリームのイメージは以下のようになります。
origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
6.4. イメージストリームタグ リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームタグは、イメージストリームのイメージに対する名前付きポインターです。これは istag
として省略されます。イメージストリームタグは、指定のイメージストリームおよびタグのイメージを参照するか、取得するために使用されます。
イメージストリームタグは、ローカル、または外部で管理されるイメージを参照できます。これには、タグが参照したすべてのイメージのスタックとして表されるイメージの履歴が含まれます。新規または既存のイメージが特定のイメージストリームタグでタグ付けされる場合はいつでも、これは履歴スタックの最初の位置に置かれます。これまで先頭の位置を占めていたイメージは 2 番目の位置に置かれます。これにより、タグを過去のイメージに再び参照させるよう簡単にロールバックできます。
以下のイメージストリームタグは、ImageStream
オブジェクトからのものです。
履歴の 2 つのイメージを持つイメージストリームタグ
イメージストリームタグには permanent タグまたは tracking タグを使用できます。
- Permanent タグは、Python 3.5 などの特定バージョンのイメージを参照するバージョン固有のタグです。
tracking タグは別のイメージストリームタグに従う参照タグで、シンボリックリンクなどのように、フォローするイメージを変更するために更新される可能性があります。このような新規レベルでは後方互換性が確保されません。
たとえば、Red Hat OpenShift Service on AWS に付属する
latest
イメージストリームタグは、トラッキングタグです。これは、latest
イメージストリームタグのコンシューマーが、新規レべルが利用可能になるとイメージで提供されるフレームワークの最新レベルに更新されることを意味します。v3.10
へのlatest
イメージストリームタグはv3.11
に変更される可能性が常にあります。これらのlatest
イメージストリームタグは Dockerlatest
タグと異なる動作をすることに注意してください。この場合、latest
イメージストリームタグは Docker リポジトリーの最新イメージを参照しません。これは別のイメージストリームタグを参照し、これはイメージの最新バージョンではない可能性があります。たとえば、latest
イメージストリームタグがイメージのv3.10
を参照する場合、3.11
バージョンがリリースされてもlatest
タグはv3.11
に自動的に更新されず、これがv3.11
イメージストリームタグを参照するように手動で更新されるまでv3.10
を参照したままになります。注記トラッキングタグは単一のイメージストリームに制限され、他のイメージストリームを参照できません。
各自のニーズに合わせて独自のイメージストリームタグを作成できます。
イメージストリームタグは、コロンで区切られた、イメージストリームの名前とタグで構成されています。
<imagestream name>:<tag>
<imagestream name>:<tag>
たとえば、上記の ImageStream
オブジェクトのサンプルで sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
イメージを参照するには、イメージストリームタグは以下のようになります。
origin-ruby-sample:latest
origin-ruby-sample:latest
6.5. イメージストリーム変更トリガー リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームトリガーにより、ビルドおよびデプロイメントは、アップストリームの新規バージョンが利用可能になると自動的に起動します。
たとえば、ビルドおよびデプロイメントは、イメージストリームタグの変更時に自動的に起動します。これは、特定のイメージストリームタグをモニターし、変更の検出時にビルドまたはデプロイメントに通知することで実行されます。
6.6. イメージストリームの使用 リンクのコピーリンクがクリップボードにコピーされました!
以下のセクションでは、イメージストリームおよびイメージストリームタグを使用する方法を説明します。
デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。
デフォルトプロジェクトである default
、kube-public
、kube-system
、openshift
、openshift-infra
、openshift-node
、および openshift.io/run-level
ラベルが 0
または 1
に設定されているその他のシステム作成プロジェクトは、高い特権があるとみなされます。Pod セキュリティーアドミッション、Security Context Constraints、クラスターリソースクォータ、イメージ参照解決などのアドミッションプラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。
6.6.1. イメージストリームに関する情報の取得 リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームに関する一般的な情報およびこれがポイントするすべてのタグの詳細情報を取得することができます。
手順
イメージストリームに関する一般情報と、それが指しているすべてのタグに関する詳細情報を取得するには、次のコマンドを入力します。
oc describe is/<image-name>
$ oc describe is/<image-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc describe is/python
$ oc describe is/python
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のイメージストリームタグに関して利用可能なすべての情報を取得するには、次のコマンドを入力します。
oc describe istag/<image-stream>:<tag-name>
$ oc describe istag/<image-stream>:<tag-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc describe istag/python:latest
$ oc describe istag/python:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記表示されている以上の情報が出力されます。
次のコマンドを入力して、イメージストリームタグがサポートするアーキテクチャーまたはオペレーティングシステムを検出します。
oc get istag <image-stream-tag> -ojsonpath="{range .image.dockerImageManifests[*]}{.os}/{.architecture}{'\n'}{end}"
$ oc get istag <image-stream-tag> -ojsonpath="{range .image.dockerImageManifests[*]}{.os}/{.architecture}{'\n'}{end}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc get istag busybox:latest -ojsonpath="{range .image.dockerImageManifests[*]}{.os}/{.architecture}{'\n'}{end}"
$ oc get istag busybox:latest -ojsonpath="{range .image.dockerImageManifests[*]}{.os}/{.architecture}{'\n'}{end}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.2. イメージストリームへのタグの追加 リンクのコピーリンクがクリップボードにコピーされました!
追加タグをイメージストリームに追加できます。
手順
既存タグのいずれかを参照するタグを追加するには、`oc tag` コマンドを使用できます。
oc tag <image-name:tag1> <image-name:tag2>
$ oc tag <image-name:tag1> <image-name:tag2>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc tag python:3.5 python:latest
$ oc tag python:3.5 python:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Tag python:latest set to python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25.
Tag python:latest set to python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージストリームに、外部コンテナーイメージを参照するタグ (
3.5
) と、この最初のタグに基づいて作成されているために同じイメージを参照する別のタグ (latest
) の 2 つのタグが含まれることを確認します。oc describe is/python
$ oc describe is/python
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.3. 外部イメージのタグの追加 リンクのコピーリンクがクリップボードにコピーされました!
外部イメージのタグを追加することができます。
手順
タグ関連のすべての操作に
oc tag
コマンドを使用して、内部または外部イメージをポイントするタグを追加します。oc tag <repository/image> <image-name:tag>
$ oc tag <repository/image> <image-name:tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、このコマンドは
docker.io/python:3.6.0
イメージをpython
イメージストリームの3.6
タグにマップします。oc tag docker.io/python:3.6.0 python:3.6
$ oc tag docker.io/python:3.6.0 python:3.6
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Tag python:3.6 set to docker.io/python:3.6.0.
Tag python:3.6 set to docker.io/python:3.6.0.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部イメージのセキュリティーが保護されている場合、そのレジストリーにアクセスするために認証情報を使用してシークレットを作成する必要があります
6.6.4. イメージストリームタグの更新 リンクのコピーリンクがクリップボードにコピーされました!
別のタグをイメージストリームに反映するようタグを更新できます。
手順
タグを更新します。
oc tag <image-name:tag> <image-name:latest>
$ oc tag <image-name:tag> <image-name:latest>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、以下は
latest
タグを更新し、3.6
タグをイメージタグに反映させます。oc tag python:3.6 python:latest
$ oc tag python:3.6 python:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Tag python:latest set to python@sha256:438208801c4806548460b27bd1fbcb7bb188273d13871ab43f.
Tag python:latest set to python@sha256:438208801c4806548460b27bd1fbcb7bb188273d13871ab43f.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.5. イメージストリームタグの削除 リンクのコピーリンクがクリップボードにコピーされました!
古いタグをイメージストリームから削除できます。
手順
古いタグをイメージストリームから削除します。
oc tag -d <image-name:tag>
$ oc tag -d <image-name:tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc tag -d python:3.6
$ oc tag -d python:3.6
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Deleted tag default/python:3.6
Deleted tag default/python:3.6
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Cluster Samples Operator による非推奨のイメージストリームタグの処理方法の詳細は、Cluster Samples Operator からの非推奨のイメージストリームタグの削除 を参照してください。
6.6.6. イメージストリームタグの定期的なインポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
外部コンテナーイメージレジストリーを使用している場合、(最新のセキュリティー更新を取得する場合などに) イメージを定期的に再インポートするには、--scheduled
フラグを使用します。
手順
イメージインポートのスケジュール
oc tag <repository/image> <image-name:tag> --scheduled
$ oc tag <repository/image> <image-name:tag> --scheduled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc tag docker.io/python:3.6.0 python:3.6 --scheduled
$ oc tag docker.io/python:3.6.0 python:3.6 --scheduled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Tag python:3.6 set to import docker.io/python:3.6.0 periodically.
Tag python:3.6 set to import docker.io/python:3.6.0 periodically.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドを実行すると、Red Hat OpenShift Service on AWS がこの特定のイメージストリームタグを定期的に更新するようになります。この期間はクラスター全体のデフォルトで 15 分に設定されます。
定期的なチェックを削除するには、上記のコマンド再実行しますが、
--scheduled
フラグを省略します。これにより、その動作がデフォルトに再設定されます。oc tag <repositiory/image> <image-name:tag>
$ oc tag <repositiory/image> <image-name:tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7. イメージとイメージストリームのインポートと操作 リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、イメージストリームをインポートして操作する方法を説明します。
6.7.1. プライベートレジストリーからのイメージおよびイメージストリームのインポート リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームは、プライベートレジストリーからタグおよびイメージメタデータをインポートするように設定できます。これには認証が必要です。この手順は、Cluster Samples Operator が registry.redhat.io 以外からコンテンツをプルするために使用するレジストリーを変更する場合に適用されます。
セキュアでないレジストリーからインポートする場合には、シークレットに定義されたレジストリーの URL に :80
ポートの接尾辞を追加するようにしてください。追加していない場合にレジストリーからインポートしようとすると、このシークレットは使用されません。
手順
以下のコマンドを入力して、認証情報を保存するために使用する
secret
オブジェクトを作成する必要があります。oc create secret generic <secret_name> --from-file=.dockerconfigjson=<file_absolute_path> --type=kubernetes.io/dockerconfigjson
$ oc create secret generic <secret_name> --from-file=.dockerconfigjson=<file_absolute_path> --type=kubernetes.io/dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットが設定されたら、新規イメージストリームを作成するか、
oc import-image
コマンドを入力します。oc import-image <imagestreamtag> --from=<image> --confirm
$ oc import-image <imagestreamtag> --from=<image> --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インポートプロセス中、Red Hat OpenShift Service on AWS はシークレットを取得し、リモートパーティーに提供します。
6.7.2. マニフェストリストの操作 リンクのコピーリンクがクリップボードにコピーされました!
--import-mode
フラグを追加することにより、oc import-image
または oc tag
CLI コマンドを使用するときに、マニフェストリストの 1 つのサブマニフェストまたはすべてのマニフェストをインポートできます。
単一のサブマニフェストまたはマルチアーキテクチャーイメージを含むイメージストリームを作成するには、以下のコマンドを参照してください。
手順
次のコマンドを入力して、マルチアーキテクチャーイメージを含むイメージストリームを作成し、インポートモードを
PreserveOriginal
に設定します。oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='PreserveOriginal' --reference-policy=local --confirm
$ oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='PreserveOriginal' --reference-policy=local --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、次のコマンドを入力して、マニフェストリストを破棄し、単一のサブマニフェストをインポートする
Legacy
インポートモードでイメージをインポートします。oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='Legacy' --confirm
$ oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='Legacy' --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記--import-mode=
のデフォルト値はLegacy
です。この値を除外するか、Legacy
またはPreserveOriginal
のいずれかを指定しないと、単一のサブマニフェストがインポートされます。無効なインポートモードは次のエラーを返します:error: valid ImportMode values are Legacy or PreserveOriginal
。
制限
マニフェストリストの操作には、次の制限があります。
場合によっては、ユーザーがサブマニフェストを直接使用したい場合があります。
oc adm prune images
が実行されている場合、またはCronJob
プルーナーが実行されている場合、サブマニフェストリストが使用されていることを検出できません。その結果、oc adm prune images
またはCronJob
プルーナーを使用する管理者は、サブマニフェストを含むマニフェストリスト全体を削除する可能性があります。この制限を回避するには、代わりにタグ別またはダイジェスト別のマニフェストリストを使用できます。
6.7.2.1. マニフェストリストの定期的なインポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
マニフェストリストを定期的に再インポートするには、--scheduled
フラグを使用できます。
手順
次のコマンドを入力して、マニフェストリストを定期的に更新するようにイメージストリームを設定します。
oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='PreserveOriginal' --scheduled=true
$ oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='PreserveOriginal' --scheduled=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7.2.2. マニフェストリストのインポート時の SSL/TSL の設定 リンクのコピーリンクがクリップボードにコピーされました!
マニフェストリストをインポートするときに SSL/TSL を設定するには、--insecure
フラグを使用できます。
手順
--insecure=true
を設定すると、マニフェストリストのインポートで SSL/TSL 検証がスキップされます。以下に例を示します。oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='PreserveOriginal' --insecure=true
$ oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name> \ --import-mode='PreserveOriginal' --insecure=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7.3. --import-mode のアーキテクチャーの指定 リンクのコピーリンクがクリップボードにコピーされました!
--import-mode=
フラグを除外または含めることで、インポートしたイメージストリームをマルチアーキテクチャーとシングルアーキテクチャーの間で入れ替えることができます。
手順
次のコマンドを実行して、
--import-mode=
フラグを除外して、イメージストリームをマルチアーキテクチャーからシングルアーキテクチャーに更新します。oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name>
$ oc import-image <multiarch-image-stream-tag> --from=<registry>/<project_name>/<image-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、イメージストリームをシングルアーキテクチャーからマルチアーキテクチャーに更新します。
oc import-image <multiarch_image_stream_tag> --from=<registry>/<project_name>/<image_name> \ --import-mode='PreserveOriginal'
$ oc import-image <multiarch_image_stream_tag> --from=<registry>/<project_name>/<image_name> \ --import-mode='PreserveOriginal'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7.4. --import-mode の設定フィールド リンクのコピーリンクがクリップボードにコピーされました!
次の表に、--import-mode=
フラグで使用できるオプションを示します。
パラメーター | 説明 |
---|---|
レガシー |
|
PreserveOriginal | 指定すると、元のマニフェストが保持されます。マニフェスト一覧の場合は、マニフェストの一覧とそのすべてのサブマニフェストがインポートされます。 |
第7章 Kubernetes リソースでのイメージストリームの使用 リンクのコピーリンクがクリップボードにコピーされました!
イメージストリームは、Red Hat OpenShift Service on AWS のネイティブリソースであり、Build
リソースや DeploymentConfigs
リソースなど、Red Hat OpenShift Service on AWS で利用可能なすべてのネイティブリソースと連携します。これらは、Job
リソース、ReplicationController
リソース、ReplicaSet
リソース、Kubernetes Deployment
リソースなどのネイティブ Kubernetes リソースと共に機能することもできます。
7.1. Kubernetes リソースでのイメージストリームの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes リソースでイメージストリームを使用する場合、リソースと同じプロジェクトにあるイメージストリームのみを参照できます。イメージストリームの参照は、ruby:2.5
など、単一セグメントの値で構成されている必要があります。この場合、ruby
は 2.5
という名前のタグを持ち、参照するリソースと同じプロジェクトにあるイメージストリームの名前です。
デフォルトプロジェクトでワークロードを実行したり、デフォルトプロジェクトへのアクセスを共有したりしないでください。デフォルトのプロジェクトは、コアクラスターコンポーネントを実行するために予約されています。
デフォルトプロジェクトである default
、kube-public
、kube-system
、openshift
、openshift-infra
、openshift-node
、および openshift.io/run-level
ラベルが 0
または 1
に設定されているその他のシステム作成プロジェクトは、高い特権があるとみなされます。Pod セキュリティーアドミッション、Security Context Constraints、クラスターリソースクォータ、イメージ参照解決などのアドミッションプラグインに依存する機能は、高い特権を持つプロジェクトでは機能しません。
Kubernetes リソースでイメージストリームを有効にする方法は 2 つあります。
- 特定のリソースでイメージストリームの解決を有効にする。これにより、このリソースのみがイメージフィールドのイメージストリーム名を使用できます。
- イメージストリームでイメージストリームの解決を有効にする。これにより、このイメージストリームを参照するすべてのリソースがイメージフィールドのイメージストリーム名を使用できます。
手順
oc set image-lookup
を使用して、特定のリソース上のイメージストリームの解決またはイメージストリーム上のイメージストリームの解決を有効にすることができます。
すべてのリソースが
mysql
という名前のイメージストリームを参照できるようにするには、以下のコマンドを入力します。oc set image-lookup mysql
$ oc set image-lookup mysql
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
Imagestream.spec.lookupPolicy.local
フィールドが true に設定されます。イメージルックアップが有効なイメージストリーム
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 有効な場合には、この動作はイメージストリーム内のすべてのタグに対して有効化されます。
次に、イメージストリームをクエリーし、このオプションが設定されているかどうかを確認できます。
oc set image-lookup imagestream --list
$ oc set image-lookup imagestream --list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
特定のリソースでイメージルックアップを有効にすることができます。
mysql
という名前の Kubernetes デプロイメントがイメージストリームを使用できるようにするには、以下のコマンドを実行します。oc set image-lookup deploy/mysql
$ oc set image-lookup deploy/mysql
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
alpha.image.policy.openshift.io/resolve-names
アノテーションがデプロイメントに設定されます。イメージルックアップが有効にされたデプロイメント
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
イメージルックアップを無効にすることができます。
イメージルックアップを無効にするには、
--enabled=false
を渡します。oc set image-lookup deploy/mysql --enabled=false
$ oc set image-lookup deploy/mysql --enabled=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第8章 イメージストリームの変更時の更新のトリガー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS では、イメージストリームタグが新しいイメージを参照するように更新されたときに、古いイメージを使用していたリソースに新しいイメージをロールアウトするアクションを自動的に実行できます。イメージストリームタグを参照しているリソースのタイプに応じ、この動作はさまざまな方法で設定できます。
8.1. Red Hat OpenShift Service on AWS のリソース リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS のデプロイメント設定とビルド設定は、イメージストリームタグの変更によって自動的にトリガーできます。トリガーされたアクションは更新されたイメージストリームタグで参照されるイメージの新規の値を使用して実行できます。
8.2. Kubernetes リソースのトリガー リンクのコピーリンクがクリップボードにコピーされました!
API 定義の一部としてトリガーを制御するためのフィールドセットを含むデプロイメントおよびビルド設定とは異なり、Kubernetes リソースにはトリガー用のフィールドがありません。代わりに、Red Hat OpenShift Service on AWS のアノテーションを使用してトリガーを要求できます。
アノテーションは以下のように定義されます。
- 1
- 必須:
kind
は、トリガーするリソースであり、ImageStreamTag
である必要があります。 - 2
- 必須:
name
はイメージストリームタグの名前である必要があります。 - 3
- オプション:
namespace
はデフォルトでオブジェクトの namespace に設定されます。 - 4
- 必須:
fieldPath
は変更する JSON パスです。このフィールドは制限され、ID またはインデックスでコンテナーに正確に一致する JSON パス式のみを受け入れます。Pod の場合、JSON パスはspec.containers[?(@.name='web')].image
です。 - 5
- オプション:
paused
はトリガーが一時停止されるかどうかを意味し、デフォルト値はfalse
です。このトリガーを一時的に無効にするには、paused
をtrue
に設定します。
コア Kubernetes リソースの 1 つに Pod テンプレートとこのアノテーションの両方が含まれている場合、Red Hat OpenShift Service on AWS は、トリガーによって参照されるイメージストリームタグに現在関連付けられているイメージを使用してオブジェクトを更新しようとします。この更新は、指定の fieldPath
に対して実行されます。
Pod テンプレートおよびアノテーションの両方が含まれるコア Kubernetes リソースの例には、以下が含まれます。
-
CronJobs
-
Deployments
-
StatefulSets
-
DaemonSets
-
Jobs
-
ReplicationControllers
-
Pods
8.3. Kubernetes リソースでのイメージトリガーの設定 リンクのコピーリンクがクリップボードにコピーされました!
イメージトリガーをデプロイメントに追加する際に、oc set triggers
コマンドを使用できます。たとえば、この手順のコマンド例は、イメージ変更トリガーを example
という名前のデプロイメントに追加し、example:latest
イメージストリームタグの更新時に、デプロイメント内の web
コンテナーが新規の値で更新されるようにします。このコマンドは、デプロイメントリソースに正しい image.openshift.io/triggers
アノテーションを設定します。
手順
oc set triggers
コマンドを入力して Kubernetes リソースをトリガーします。oc set triggers deploy/example --from-image=example:latest -c web
$ oc set triggers deploy/example --from-image=example:latest -c web
Copy to Clipboard Copied! Toggle word wrap Toggle overflow トリガーアノテーションを使用したデプロイメントの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントが一時停止されない限り、この Pod テンプレートの更新により、デプロイメントはイメージの新規の値で自動的に実行されます。
第9章 ROSA with HCP のイメージ設定リソース リンクのコピーリンクがクリップボードにコピーされました!
以下の手順でイメージレジストリーを設定します。
9.1. ROSA with HCP のイメージコントローラー設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
image.config.openshift.io/cluster
リソースは、イメージの処理方法に関するクラスター全体の情報を保持します。このリソースは、存在しますが読み取り専用であり、ROSA CLI (rosa
) などのサポートされているツールを通じてのみ変更できます。唯一有効な正規の名前は cluster
です。このリソースは、Red Hat OpenShift Service on AWS Hosted Control Plane では、ROSA CLI (rosa
) コマンドを使用して設定できます。
DisableScheduledImport
、MaxImagesBulkImportedPerRepository
、MaxScheduledImportsPerMinute
、ScheduledImageImportMinimumIntervalSeconds
、InternalRegistryHostname
などのパラメーターは設定できません。
ROSA CLI のパラメーター | 説明 |
---|---|
|
イメージのプルおよびプッシュアクションが許可されるレジストリー。すべてのサブドメインを指定するには、ドメイン名に接頭辞としてアスタリスク ( |
|
有効な TLS 証明書を持たないか、HTTP 接続のみをサポートするレジストリーです。すべてのサブドメインを指定するには、ドメイン名に接頭辞としてアスタリスク ( |
|
イメージのプルおよびプッシュアクションが拒否されるレジストリー。すべてのサブドメインを指定するには、ドメイン名に接頭辞としてアスタリスク ( |
|
コンテナーランタイムがビルドおよび Pod のイメージへのアクセス時に個々のレジストリーを処理する方法を決定する設定が含まれます。たとえば、非セキュアなアクセスを許可するかどうかなどです。内部クラスターレジストリーの設定は含まれません。標準ユーザーがイメージのインポートに使用できるコンテナーイメージレジストリーを制限します。形式は、 |
| 信頼する追加の各レジストリー CA について、レジストリーホスト名をキーとして、PEM でエンコードされた証明書を値として含む JSON ファイル。 |
allowedRegistries
パラメーターが定義されている場合、明示的にリストされたレジストリーを除き、すべてのレジストリーがブロックされます。Pod の障害を防ぐために、環境内のペイロードイメージに必要な Red Hat レジストリーのリストが自動的にホワイトリストに登録されます。現在のリストは image-registry.openshift-image-registry.svc:5000,quay.io,registry.redhat.io
で構成されています。これは rosa describe cluster
コマンドを実行すると表示されます。
9.2. ROSA with HCP のイメージレジストリー設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの作成時にイメージレジストリー設定を指定できます。作成後に、クラスターのノードによって必要な設定が使用されます。
手順
次のコマンドを実行して、イメージレジストリーを使用して ROSA with HCP クラスターを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記allowedRegistries
、blockedRegistries
、またはinsecureRegistries
パラメーターを使用する場合、レジストリー内に個別のリポジトリーを指定できます。例:reg1.io/myrepo/myapp:latest
起こりうるセキュリティーリスクを軽減するために、非セキュアな外部レジストリーの使用を避けてください。パラメーター
allowedRegistries
とblockedRegistries
は相互に排他的です。
検証
次の
rosa describe
コマンドを実行して、イメージレジストリーが有効になっていることを確認します。rosa describe cluster --cluster=<cluster_name>
$ rosa describe cluster --cluster=<cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Allowed Registries
: イメージのプルおよびプッシュアクションが許可されるレジストリーのコンマ区切りリスト。- 2
Blocked Registries
: イメージのプルおよびプッシュアクションがブロックされるレジストリーのコンマ区切りリスト。パラメーターallowedRegistries
とblockedRegistries
は相互に排他的です。- 3
Insecure Registries
: 有効な TLS 証明書を持たないか、HTTP 接続のみをサポートするレジストリーのコンマ区切りリスト。- 4
Allowed Registries for Import
: 標準ユーザーがイメージをインポートに使用できるコンテナーイメージレジストリーを制限します。形式は、domainName:insecure
のコンマ区切りリストにする必要があります。- 5
domainName
: レジストリーのドメイン名を指定します。- 6
insecure
: レジストリーがセキュアか非セキュアかを示します。- 7
Platform Allowlist
: プラットフォームを機能させるためにホワイトリストに登録する必要があるレジストリーリストの ID への参照。- 8
Registries
: プラットフォームを機能させるためにホワイトリストに登録する必要があるレジストリーのリスト。- 9
Additional Trusted CA
: 信頼する追加の各レジストリー CA について、レジストリーホスト名をキーとして、PEM でエンコードされた証明書を値として含む JSON ファイル。
次のコマンドを実行して、ノードをリスト表示し、適用された変更を確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION ip-10-0-137-182.us-east-2.compute.internal Ready,SchedulingDisabled worker 65m v1.32.3 ip-10-0-188-96.us-east-2.compute.internal Ready worker 65m v1.32.3 ip-10-0-200-59.us-east-2.compute.internal Ready worker 63m v1.32.3
NAME STATUS ROLES AGE VERSION ip-10-0-137-182.us-east-2.compute.internal Ready,SchedulingDisabled worker 65m v1.32.3 ip-10-0-188-96.us-east-2.compute.internal Ready worker 65m v1.32.3 ip-10-0-200-59.us-east-2.compute.internal Ready worker 63m v1.32.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3. ROSA with HCP のイメージレジストリー設定の編集 リンクのコピーリンクがクリップボードにコピーされました!
rosa edit
コマンドを使用すると、イメージレジストリー設定を変更できます。
allowedRegistries
パラメーターが定義されている場合、明示的にリストされたレジストリーを除き、すべてのレジストリーがブロックされます。Pod の障害を防ぐために、環境内のペイロードイメージに必要な Red Hat レジストリーのリストが自動的にホワイトリストに登録されます。現在のリストは image-registry.openshift-image-registry.svc:5000,quay.io,registry.redhat.io
で構成されています。これは rosa describe cluster
コマンドを実行すると表示されます。
レジストリー関連のパラメーターを変更すると、すべてのマシンプールにロールアウトがトリガーされ、各ノードから Pod がドレインされた後、すべてのマシンプールノードが再作成されます。
手順
次のコマンドを実行して、クラスターのイメージレジストリーを更新または編集します。
rosa edit cluster --registry-config-insecure-registries <insecure_registries> \ --registry-config-allowed-registries <allowed_registries> \ --registry-config-allowed-registries-for-import <registry_name:insecure> \ --registry-config-additional-trusted-ca <additional_trusted_ca_file>
$ rosa edit cluster --registry-config-insecure-registries <insecure_registries> \ --registry-config-allowed-registries <allowed_registries> \ --registry-config-allowed-registries-for-import <registry_name:insecure> \ --registry-config-additional-trusted-ca <additional_trusted_ca_file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
? Changing any registry related parameter will trigger a rollout across all machinepools (all machinepool nodes will be recreated, following pod draining from each node). Do you want to proceed? Yes I: Updated cluster '<cluster_name>'
? Changing any registry related parameter will trigger a rollout across all machinepools (all machinepool nodes will be recreated, following pod draining from each node). Do you want to proceed? Yes I: Updated cluster '<cluster_name>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次の
rosa describe
コマンドを再度実行し、イメージレジストリーに加えた変更が更新されたかどうかを確認します。rosa describe cluster --cluster=<cluster_name>
$ rosa describe cluster --cluster=<cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Allowed Registries
: イメージのプルおよびプッシュアクションが許可されるレジストリーのコンマ区切りリスト。- 2
Blocked Registries
: イメージのプルおよびプッシュアクションがブロックされるレジストリーのコンマ区切りリスト。パラメーターallowedRegistries
とblockedRegistries
は相互に排他的です。- 3
Insecure Registries
: 有効な TLS 証明書を持たないか、HTTP 接続のみをサポートするレジストリーのコンマ区切りリスト。- 4
Allowed Registries for Import
: 標準ユーザーがイメージをインポートに使用できるコンテナーイメージレジストリーを制限します。形式は、domainName:insecure
のコンマ区切りリストにする必要があります。- 5
domainName
: レジストリーのドメイン名を指定します。- 6
insecure
: レジストリーがセキュアか非セキュアかを示します。- 7
Platform Allowlist
: プラットフォームを機能させるためにホワイトリストに登録する必要があるレジストリーリストの ID への参照。- 8
Registries
: プラットフォームを機能させるためにホワイトリストに登録する必要があるレジストリーのリスト。- 9
Additional Trusted CA
: 信頼する追加の各レジストリー CA について、レジストリーホスト名をキーとして、PEM でエンコードされた証明書を値として含む JSON ファイル。
9.3.1. ROSA with HCP のプラットフォーム許可リストの更新 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat レジストリーのリストは自動的に許可されます。これは rosa describe cluster を実行すると表示されます。このリストは、プラットフォームが正しく動作するように、定期的に更新されます。影響を受けるクラスターには、新しい許可リスト ID を含む通知が送信されます。その場合、ユーザーはこのパラメーターを使用して、以前の想定される ID から新しく想定される ID に更新する必要があります。次のコマンドを実行して、クラスターのイメージレジストリーを更新または編集します。
rosa edit cluster --registry-config-platform-allowlist <newID>
$ rosa edit cluster --registry-config-platform-allowlist <newID>
第10章 イメージの使用 リンクのコピーリンクがクリップボードにコピーされました!
10.1. イメージの使用の概要 リンクのコピーリンクがクリップボードにコピーされました!
以下のトピックを使用して、Red Hat OpenShift Service on AWS ユーザーが利用できるさまざまな Source-to-Image (S2I)、データベース、およびその他のコンテナーイメージを確認します。
Red Hat の公式コンテナーイメージは、registry.redhat.io の Red Hat レジストリーで提供されています。Red Hat OpenShift Service on AWS でサポートされている S2I、データベース、および Jenkins イメージは、Red Hat Quay Registry の openshift4
リポジトリーで提供されます。たとえば、quay.io/openshift-release-dev/ocp-v4.0-<address>
は OpenShift Application Platform イメージの名前です。
xPaaS ミドルウェアイメージは、Red Hat レジストリーの適切な製品リポジトリーで提供されていますが、接尾辞として -openshift
が付いています。たとえば、registry.redhat.io/jboss-eap-6/eap64-openshift
は JBoss EAP イメージの名前です。
このセクションで説明する Red Hat がサポートするイメージはすべて Red Hat Ecosystem Catalog のコンテナーイメージのセクション に記載されています。各イメージのすべてのバージョンについて、そのコンテンツや用途の詳細を確認できます。関連するイメージを参照または検索してください。
新しいバージョンのコンテナーイメージは、以前のバージョンの Red Hat OpenShift Service on AWS と互換性がありません。Red Hat OpenShift Service on AWS のバージョンに基づいて、正しいバージョンのコンテナーイメージを確認して使用します。
10.2. Source-to-Image リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Software Collections イメージを、Node.js、Perl、Python などの特定のランタイム環境に依存するアプリケーションの基盤として使用することができます。Java を使用するランタイム環境のリファレンスとして、Red Hat Java Source-to-Image for OpenShift ドキュメントを使用できます。これらのランタイムベースイメージの特殊なバージョンは Source-to-image (S2I) イメージと呼ばれています。S2I イメージを使用して、コードを、そのコードを実行できるベースイメージ環境に挿入することができます。
S2I イメージには、以下が含まれます。
- .NET
- Java
- Go
- Node.js
- Perl
- PHP
- Python
- Ruby
S2I イメージは、以下の手順で Red Hat OpenShift Service on AWS Web コンソールから直接使用できます。
- ログイン認証情報を使用して、Red Hat OpenShift Service on AWS Web コンソールにログインします。Red Hat OpenShift Service on AWS Web コンソールのデフォルトビューは、Administrator パースペクティブです。
- パースペクティブスイッチャーを使用して、Developer パースペクティブに切り替えます。
- +Add ビューで、Project ドロップダウンリストを使用して既存プロジェクトを選択するか、新規プロジェクトを作成します。
- Developer Catalog タイルの All services をクリックします。
- Type の下の Builder Images をクリックして、利用可能な S2I イメージを表示します。
S2I イメージは、Cluster Samples Operator からも入手できます。
10.2.1. Source-to-Image ビルドプロセスの概要 リンクのコピーリンクがクリップボードにコピーされました!
Source-to-Image (S2I) は、ソースコードをコンテナーに挿入してソースコードを実行可能にすることで、実行可能な状態のイメージを生成します。S2I では、以下の手順を実行します。
-
FROM <builder image>
コマンドを実行します。 - ソースコードをビルダーイメージの定義された場所にコピーします。
- ビルダーイメージから assemble スクリプトを実行します。
- デフォルトコマンドとしてビルダーイメージに run スクリプトを設定します。
Buildah は次にコンテナーイメージを作成します。
10.3. Source-to-Image イメージのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
Source-to-Image (S2I) ビルダーイメージには、assemble および run スクリプトが含まれますが、それらのスクリプトのデフォルト動作はすべてのユーザーに適している訳ではありません。デフォルトのスクリプトを含む S2I ビルダーの動作をカスタマイズできます。
10.3.1. イメージに埋め込まれたスクリプトの呼び出し リンクのコピーリンクがクリップボードにコピーされました!
ビルダーイメージは、最も一般的なユースケースを含む、独自のバージョンの source-to-image (S2I) スクリプトを提供します。これらのスクリプトで各自のニーズが満たされない場合に向け、S2I には .s2i/bin
ディレクトリーにカスタムのスクリプトを追加して上書きできる手段があります。ただし、カスタムのスクリプトを追加すると、標準のスクリプトを完全に置き換えてしまいます。スクリプトの置き換えは許容できる場合もありますが、場合によっては、イメージに含まれるスクリプトのロジックを保持しつつ、スクリプトの前後にコマンドをいくつか実行できる場合があります。標準的なスクリプトを再利用するには、カスタムのロジックを実行し、イメージ内のデフォルトのスクリプトに追加の作業を委任するラッパースクリプトを作成できます。
手順
ビルダーイメージ内のスクリプトの場所を判別するには、
io.openshift.s2i.scripts-url
ラベルの値を確認します。podman inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' wildfly/wildfly-centos7
$ podman inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' wildfly/wildfly-centos7
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
image:///usr/libexec/s2i
image:///usr/libexec/s2i
Copy to Clipboard Copied! Toggle word wrap Toggle overflow wildfly/wildfly-centos7
ビルダーイメージを検査し、スクリプトが/usr/libexec/s2i
ディレクトリーにあることを確認できます。他のコマンドでラップされた標準スクリプトのいずれかの呼び出しを含むスクリプトを作成します。
.s2i/bin/assemble
スクリプトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、メッセージを出力するカスタムの assemble スクリプトを表示し、イメージから標準の assemble スクリプトを実行して、assemble スクリプトの終了コードに応じて別のメッセージを出力します。
重要run スクリプトをラップする場合には、スクリプトの呼び出しに
exec
を実行して、シグナルが正しく処理されるようにする必要があります。exec
を使用すると、デフォルトのイメージ実行スクリプトを呼び出した後に追加でコマンドを実行できなくなります。.s2i/bin/run
スクリプト#!/bin/bash echo "Before running application" exec /usr/libexec/s2i/run
#!/bin/bash echo "Before running application" exec /usr/libexec/s2i/run
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.