Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第13章 イメージの管理
13.1. 概要
「イメージストリーム」は、タグで識別される数多くの「コンテナーイメージ」で構成されます。これは Docker イメージリポジトリーのような関連イメージの単一仮想ビューを提供します。
イメージストリームの監視により、ビルドおよびデプロイメントは新規イメージの追加または変更時に通知を受信し、それぞれビルドまたはデプロイメントを実行してこれに対応します。
イメージのレジストリーが置かれる場所やレジストリー関連の認証要件、およびビルドやデプロイメントで必要とされる動作が何であるかによって、イメージと対話し、イメージストリームをセットアップする方法は異なり、数多くの方法でこれらを実行することができます。以下のセクションではこれらのトピックについて扱います。
13.2. イメージのタグ付け
OpenShift Container Platform イメージストリームとそのタグを使用する前に、コンテナーイメージのコンテキストにおけるイメージタグ全般について理解しておくと便利です。
コンテナーイメージにはその内容を直感的に判別できるようにする名前 (タグ) を追加できます。タグの一般的な使用例として、イメージに含まれるもののバージョンを指定するために使用できます。ruby という名前のイメージがある場合、Ruby の 2.0 バージョン用に 2.0 という名前のタグを使用したり、リポジトリー全体における最新のビルドされたイメージを示す latest というタグを使用したりすることができます。
docker CLI を使用してイメージと直接対話する場合、docker tag コマンドを使用してタグを追加できます。基本的に、この操作は複数の部分で構成されるエイリアスをイメージに追加する操作です。これらの複数の部分には以下が含まれます。
<registry_server>/<user_name>/<image_name>:<tag>
上記の <user_name> の部分は、イメージが内部レジストリー (OpenShift Container レジストリー) を使用して OpenShift Container Platform 環境に保存される場合には、「プロジェクト」または「namespace」も参照することがあります。
OpenShift Container Platform は docker tag コマンドに似た oc tag コマンドを提供しますが、これらはイメージ上で直接動作するのではなくイメージストリームで動作します。
docker CLI を使用してイメージに直接タグ付けする方法についての詳細は、Red Hat Enterprise Linux 7 の『Getting Started with Containers』ドキュメントを参照してください。
13.2.1. タグのイメージストリームへの追加
OpenShift Container Platform のイメージストリームはタグで識別されるゼロまたは 1 つ以上のコンテナーイメージで構成されることに留意した上で、oc tag コマンドを使用してタグをイメージストリームに追加することができます。
$ oc tag <source> <destination>
たとえば、ruby イメージストリームの static-2.0 タグを ruby イメージストリーム 2.0 タグの現行のイメージを常に参照するように設定するには、以下を実行します。
$ oc tag ruby:2.0 ruby:static-2.0
これにより、ruby イメージストリームに static-2.0 という名前のイメージストリームタグが新たに作成されます。この新規タグは、oc tag の実行時に ruby:2.0 イメージストリームタグが参照したイメージ ID を直接参照し、これが参照するイメージが変更されることがありません。
各種のタグを利用できます。デフォルト動作では、特定の時点の特定のイメージを参照する 永続 タグを使用します。ソースが変更されても新規 (宛先) タグは変更されません。
トラッキング タグの場合は、宛先タグのメタデータがソースタグのインポート時に更新されます。宛先タグがソースタグの変更時に常に更新されるようにするには、--alias=true フラグを使用します。
$ oc tag --alias=true <source> <destination>
永続的なエイリアス (latest または stable など) を作成するには トラッキング タグを使用します。このタグは単一イメージストリーム内で のみ 適切に機能します。複数のイメージストリーム間で使用されるエイリアスを作成しようとするとエラーが生じます。
さらに --scheduled=true フラグを追加して宛先タグが定期的に更新 (再インポートなど) されるようにできます。期間はシステムレベルで「グローバルに設定」できます。詳細は、「タグおよびイメージメタデータのインポート」を参照してください。
--reference フラグはインポートされないイメージストリームを作成します。このタグは単にソースの場所を参照しますが、これを永続的に参照します。
Docker に対して、統合レジストリーからタグ付けされたイメージを常にフェッチするよう指示するには、--reference-policy=local を使用します。レジストリーは「プルスルー (pull-through) 機能」を使用してイメージをクライアントに提供します。デフォルトで、イメージ Blob はレジストリーによってローカルにミラーリングされるので、イメージ Blob が次回必要になると、より早くプルされます。またこのフラグは --insecure-registry を Docker デーモンに指定しなくても、イメージストリームに「セキュアでないアノテーション」があるか、またはタグに「セキュアでないインポートポリシー」がある限り、セキュアでないレジストリーからもプルできます。
13.2.2. 推奨されるタグ付け規則
イメージは時間の経過と共に変化するもので、それらのタグはその変化を反映します。イメージタグはビルドされる最新イメージを常に参照します。
タグ名にあまりにも多くの情報が組み込まれる場合には (例: v2.0.1-may-2016)、タグはイメージの 1 つのリビジョンのみを参照し、更新されることがなくなります。デフォルトのイメージのプルーニングオプションを使用しても、このようなイメージは削除されません。非常に大規模なクラスターでは、イメージが修正されるたびに新規タグが作成される設定の場合に、古くなって久しいイメージのタグメタデータが過剰になり、etcd データストアがいっぱいになる可能性があります。
一方、タグの名前が v2.0 である場合はイメージリビジョンの数が多くなることが予想されます。これにより「タグ履歴」が長くなるため、イメージプルーナーが、過去の使われなくなったイメージを削除する可能性が高くなります。詳細は、「イメージのプルーニング」を参照してください。
タグの名前付け規則は各自で定めることができますが、ここでは <image_name>:<image_tag> 形式のいくつかの例を見てみましょう。
表13.1 イメージタグの名前付け規則
| 説明 | 例 |
|---|---|
|
リビジョン |
|
|
アーキテクチャー |
|
|
ベースイメージ |
|
|
最新 (不安定な可能性がある) |
|
|
最新 (安定性がある) |
|
タグ名に日付を含める必要がある場合、古くなり使用されなくなったイメージおよび istags を定期的に検査し、これらを削除してください。そうしないと、古いイメージによるリソース使用量が増大する可能性があります。
13.2.3. タグのイメージストリームからの削除
タグをイメージストリームから完全に削除するには、以下を実行します。
$ oc delete istag/ruby:latest
または以下を実行します。
$ oc tag -d ruby:latest
13.2.4. イメージストリームでのイメージの参照
以下の参照タイプを使用して、イメージをイメージストリームで参照できます。
ImageStreamTagは、所定のイメージストリームおよびタグのイメージを参照し、取得するために使用されます。この名前は以下の規則に基づいて付けられます。<image_stream_name>:<tag>
ImageStreamImageは、所定のイメージストリームおよびイメージ名のイメージを参照し、取得するために使用されます。この名前は以下の規則に基づいて付けられます。<image_stream_name>@<id>
<id>は、ダイジェストとも呼ばれる特定イメージのイミュータブルな ID です。DockerImageは、所定の外部レジストリーのイメージを参照し、取得するために使用されます。この名前は、以下のような標準の Docker プル仕様 に基づいて付けられます。openshift/ruby-20-centos7:2.0
注記タグが指定されていない場合、latest タグが使用されることが想定されます。
サードパーティーのレジストリーを参照することもできます。
registry.access.redhat.com/rhel7:latest
またはダイジェストでイメージを参照できます。
centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
CentOS イメージストリームのサンプル などのイメージストリーム定義のサンプルを表示する場合、それらには ImageStreamTag の定義や DockerImage の参照が含まれる一方で、ImageStreamImage に関連するものは何も含まれていないことに気づかれることでしょう。
これは、イメージストリームでのイメージのインポートまたはイメージのタグ付けを行う場合は常に ImageStreamImage オブジェクトが OpenShift Container Platform に自動的に作成されるためです。イメージストリームを作成するために使用するイメージストリーム定義で ImageStreamImage オブジェクトを明示的に定義する必要はありません。
イメージのオブジェクト定義は、イメージストリーム名および ID を使用し、ImageStreamImage 定義を取得して確認することができます。
$ oc export isimage <image_stream_name>@<id>
以下を実行して所定のイメージストリームの有効な <id> 値を確認することができます。
$ oc describe is <image_stream_name>
たとえば、ruby イメージストリームから ruby@3a335d7 の名前および ID を使って ImageStreamImage を検索します。
ImageStreamImage で取得されるイメージオブジェクトの定義
$ oc export isimage ruby@3a335d7
apiVersion: v1
image:
dockerImageLayers:
- name: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
size: 0
- name: sha256:ee1dd2cb6df21971f4af6de0f1d7782b81fb63156801cfde2bb47b4247c23c29
size: 196634330
- name: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
size: 0
- name: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
size: 0
- name: sha256:ca062656bff07f18bff46be00f40cfbb069687ec124ac0aa038fd676cfaea092
size: 177723024
- name: sha256:63d529c59c92843c395befd065de516ee9ed4995549f8218eac6ff088bfa6b6e
size: 55679776
dockerImageMetadata:
Architecture: amd64
Author: SoftwareCollections.org <sclorg@redhat.com>
Config:
Cmd:
- /bin/sh
- -c
- $STI_SCRIPTS_PATH/usage
Entrypoint:
- container-entrypoint
Env:
- 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: {}
Image: d9c3abc5456a9461954ff0de8ae25e0e016aad35700594714d42b687564b1f51
Labels:
build-date: 2015-12-23
io.k8s.description: Platform for building and running Ruby 2.2 applications
io.k8s.display-name: Ruby 2.2
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
ContainerConfig: {}
Created: 2016-01-26T21:07:27Z
DockerVersion: 1.8.2-el7
Id: 57b08d979c86f4500dc8cad639c9518744c8dd39447c055a3517dc9c18d6fccd
Parent: d9c3abc5456a9461954ff0de8ae25e0e016aad35700594714d42b687564b1f51
Size: 430037130
apiVersion: "1.0"
kind: DockerImage
dockerImageMetadataVersion: "1.0"
dockerImageReference: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
metadata:
creationTimestamp: 2016-01-29T13:17:45Z
name: sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
resourceVersion: "352"
uid: af2e7a0c-c68a-11e5-8a99-525400f25e34
kind: ImageStreamImage
metadata:
creationTimestamp: null
name: ruby@3a335d7
namespace: openshift
selflink: /oapi/v1/namespaces/openshift/imagestreamimages/ruby@3a335d7
13.3. Kubernetes リソースでのイメージストリームの使用
OpenShift Container Platform のネイティブリソースであるイメージストリームは、「ビルド」または「デプロイメント」などの OpenShift Container Platform で利用可能なネイティブリソースの残りすべてと、追加設定なしで連携します。現時点で、イメージストリームは「ジョブ」、「レプリケーションコントローラー」、レプリカセットまたは「Kubernetes デプロイメント」などのネイティブの Kubernetes リソースと連携させることも可能です。
クラスター管理者は使用可能な「リソースを正確に設定」することができます。
この機能が有効な場合、リソースの image フィールドにイメージストリームの参照を配置することができます。この機能を使用する場合、リソースと同じプロジェクトにあるイメージストリームのみを参照することができます。イメージストリームの参照は、単一セグメントの値で構成される必要があります。たとえば ruby:2.4 の場合、ruby は 2.4 という名前のタグを持ち、参照するリソースと同じプロジェクトにあるイメージストリームの名前になります。
この機能を有効にする 2 つの方法があります。
- 特定のリソースでイメージストリームの解決を有効にする。これにより、このリソースのみがイメージフィールドのイメージストリーム名を使用できます。
- イメージストリームでイメージストリームの解決を有効にする。これにより、このイメージストリームを参照するすべてのリソースがイメージフィールドのイメージストリーム名を使用できます。
上記の操作のいずれも oc set image-lookup を使用して実行できます。たとえば、以下のコマンドはすべてのリソースが mysql という名前のイメージストリームを参照できるようにします。
$ oc set image-lookup mysql
これにより、Imagestream.spec.lookupPolicy.local フィールドが true に設定されます。
イメージルックアップが有効なイメージストリーム
apiVersion: v1
kind: ImageStream
metadata:
annotations:
openshift.io/display-name: mysql
name: mysql
namespace: myproject
spec:
lookupPolicy:
local: true
有効な場合には、この動作はイメージストリーム内のすべてのタグに対して有効化されます。
以下を使用してイメージストリームをクエリーし、このオプションが設定されているかどうかを確認できます。
$ oc set image-lookup
さらに、特定のリソースでイメージルックアップを有効にすることもできます。以下のコマンドは mysql という名前の Kubernetes デプロイメントがイメージストリームを使用できるようにします。
$ oc set image-lookup deploy/mysql
これにより、alpha.image.policy.openshift.io/resolve-names アノテーションがデプロイメントに設定されます。
イメージルックアップが有効にされたデプロイメント
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
namespace: myproject
spec:
replicas: 1
template:
metadata:
annotations:
alpha.image.policy.openshift.io/resolve-names: '*'
spec:
containers:
- image: mysql:latest
imagePullPolicy: Always
name: mysql
イメージルックアップを無効にするには、--enabled=false を渡します。
$ oc set image-lookup deploy/mysql --enabled=false
13.4. イメージプルポリシー
Pod のそれぞれのコンテナーにはコンテナーイメージがあります。イメージを作成し、これをレジストリーにプッシュすると、イメージを Pod で参照できます。
OpenShift Container Platform はコンテナーを作成すると、コンテナーの imagePullPolicy を作成して、コンテナーの起動前にイメージをプルする必要があるかどうかを決定します。imagePullPolicy には以下の 3 つの値を使用できます。
-
Always: 常にイメージをプルします。 -
IfNotPresent: イメージがノード上にない場合にのみイメージをプルします。 -
Never: イメージをプルしません。
コンテナーの imagePullPolicy パラメーターが指定されていない場合、OpenShift Container Platform はイメージのタグに基づいてこれを設定します。
-
タグが 最新 の場合、OpenShift Container Platform は
imagePullPolicyをAlwaysにデフォルト設定します。 -
それ以外の場合に、OpenShift Container Platform は
imagePullPolicyをIfNotPresentにデフォルト設定します。
13.5. 内部レジストリーへのアクセス
イメージのプッシュまたはプルを実行するために OpenShift Container Platform の内部レジストリーに直接アクセスできます。たとえば、これは イメージの手動プッシュによってイメージストリームを作成する場合や、単にイメージに対して docker pull を直接実行する場合に役立ちます。
内部レジストリーは OpenShift Container Platform API と同じ「トークン」を使用して認証します。内部レジストリーに対して docker login を実行するには、任意のユーザー名およびメールを選択できますが、パスワードは有効な OpenShift Container Platform トークンである必要があります。
内部レジストリーにログインするには、以下を実行します。
OpenShift Container Platform にログインします。
$ oc login
アクセストークンを取得します。
$ oc whoami -t
トークンを使用して内部レジストリーにログインします。docker をシステムにインストールしておく必要があります。
$ docker login -u <user_name> -e <email_address> \ -p <token_value> <registry_server>:<port>注記使用するレジストリー IP またはホスト名およびポートが不明な場合は、クラスター管理者に問い合わせてください。
イメージをプルするには、要求される imagestreams/layers に対する get 権限が、この認証済みのユーザーに割り当てられている必要があります。また、イメージをプッシュするには、認証済みのユーザーに、要求される imagestreams/layers に対する update 権限が割り当てられている必要があります。
デフォルトで、プロジェクトのすべてのサービスアカウントは同じプロジェクトの任意のイメージをプルする権限を持ち、builder サービスアカウントには同じプロジェクトの任意のイメージをプッシュする権限を持ちます。
13.6. イメージプルシークレットの使用
承認されていないユーザーが特定イメージにアクセスできないように、「Docker レジストリー」のセキュリティー保護することができます。「OpenShift Container Platform の内部レジストリーを使用」し、同じプロジェクトにあるイメージストリームからプルしている場合は、Pod のサービスアカウントに適切なパーミッションがすでに設定されているので、追加のアクションは不要です。
ただし、OpenShift Container Platform プロジェクト全体でイメージを参照する場合や、セキュリティー保護されたレジストリーからイメージを参照するなどの他のシナリオでは、追加の設定手順が必要になります。以下のセクションでは、それらのシナリオと必要な手順について詳しく説明します。
13.6.1. Pod が複数のプロジェクト間でのイメージを参照できるようにする設定
内部レジストリーを使用している場合で 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このロールを追加した後に、デフォルトのサービスアカウントを参照する project-a の Pod は project-b からイメージをプルできるようになります。
project-a のすべてのサービスアカウントにアクセスを許可するには、グループを使用します。
$ oc policy add-role-to-group \
system:image-puller system:serviceaccounts:project-a \
--namespace=project-b13.6.2. Pod が他のセキュアなレジストリーからイメージを参照できるようにする設定
.dockercfg ファイル (または新規 Docker クライアントの場合は $HOME/.docker/config.json) は、ユーザーがセキュア/非セキュアなレジストリーに事前にログインしている場合にそのユーザーの情報を保存する Docker 認証情報ファイルです。
OpenShift Container Platform の内部レジストリーにないセキュリティー保護されたコンテナーイメージをプルするには、Docker 認証情報で プルシークレット を作成し、これをサービスアカウントに追加する必要があります。
セキュリティー保護されたレジストリーの .dockercfg ファイルがある場合、以下を実行してそのファイルからシークレットを作成できます。
$ oc create secret generic <pull_secret_name> \
--from-file=.dockercfg=<path/to/.dockercfg> \
--type=kubernetes.io/dockercfgまたは、$HOME/.docker/config.json ファイルがある場合は以下を実行します。
$ oc create secret generic <pull_secret_name> \
--from-file=.dockerconfigjson=<path/to/.docker/config.json> \
--type=kubernetes.io/dockerconfigjsonセキュリティー保護されたレジストリーの Docker 認証情報がない場合は、以下を実行してシークレットを作成できます。
$ oc create secret docker-registry <pull_secret_name> \
--docker-server=<registry_server> \
--docker-username=<user_name> \
--docker-password=<password> \
--docker-email=<email>Pod のイメージをプルするためのシークレットを使用するには、そのシークレットをサービスアカウントに追加する必要があります。この例では、サービスアカウントの名前は Pod が使用するサービスアカウントの名前に一致している必要があります。default はデフォルトのサービスアカウントです。
$ oc secrets link default <pull_secret_name> --for=pull
ビルドイメージのプッシュおよびプルにシークレットを使用するには、シークレットは Pod 内でマウント可能である必要があります。以下でこれを実行できます。
$ oc secrets link builder <pull_secret_name>
13.6.2.1. 委任された認証を使用したプライベートレジストリーからのプル
プライベートレジストリーは認証を別個のサービスに委任できます。この場合、イメージプルシークレットは認証およびレジストリーのエンドポイントの両方に対して定義されている必要があります。
Red Hat Container Catalog のサードパーティーのイメージは Red Hat Connect Partner Registry (registry.connect.redhat.com) から提供されます。このレジストリーは認証を sso.redhat.com に委任するため、以下の手順が適用されます。
委任された認証サーバーのシークレットを作成します。
$ oc create secret docker-registry \ --docker-server=sso.redhat.com \ --docker-username=developer@example.com \ --docker-password=******** \ --docker-email=unused \ redhat-connect-sso secret/redhat-connect-ssoプライベートレジストリーのシークレットを作成します。
$ oc create secret docker-registry \ --docker-server=privateregistry.example.com \ --docker-username=developer@example.com \ --docker-password=******** \ --docker-email=unused \ private-registry secret/private-registry
Red Hat Connect Partner Registry (registry.connect.redhat.com) は自動生成される dockercfg シークレットタイプを受け入れません (BZ#1476330)。汎用のファイルベースのシークレットは docker login コマンドで生成されるファイルを使用して作成する必要があります。
$ docker login registry.connect.redhat.com --username developer@example.com Password: ************* Login Succeeded $ oc create secret generic redhat-connect --from-file=.dockerconfigjson=.docker/config.json $ oc secrets link default redhat-connect --for=pull
13.7. タグおよびイメージメタデータのインポート
イメージストリームは、外部 Docker イメージレジストリーのイメージリポジトリーからタグおよびイメージメタデータをインポートするように設定できます。これは複数の異なる方法で実行できます。
oc import-imageコマンドで--fromオプションを使用してタグとイメージ情報を手動でインポートできます。$ oc import-image <image_stream_name>[:<tag>] --from=<docker_image_repo> --confirm
以下に例を示します。
$ oc import-image my-ruby --from=docker.io/openshift/ruby-20-centos7 --confirm The import completed successfully. Name: my-ruby Created: Less than a second ago Labels: <none> Annotations: openshift.io/image.dockerRepositoryCheck=2016-05-06T20:59:30Z Docker Pull Spec: 172.30.94.234:5000/demo-project/my-ruby Tag Spec Created PullSpec Image latest docker.io/openshift/ruby-20-centos7 Less than a second ago docker.io/openshift/ruby-20-centos7@sha256:772c5bf9b2d1e8... <same>
また、latest だけではなくイメージのすべてのタグをインポートするには
--allフラグを追加することもできます。OpenShift Container Platform のほとんどのオブジェクトの場合と同様に、CLI を使用して JSON または YAML 定義を作成し、これをファイルに保存してからオブジェクトを作成できます。
spec.dockerImageRepositoryフィールドをイメージの Docker プル仕様に設定します。apiVersion: "v1" kind: "ImageStream" metadata: name: "my-ruby" spec: dockerImageRepository: "docker.io/openshift/ruby-20-centos7"
次にオブジェクトを作成します。
$ oc create -f <file>
外部 Docker レジストリーのイメージを参照するイメージストリームを作成する場合、OpenShift Container Platform は短時間で外部レジストリーと通信し、イメージについての最新情報を取得します。
タグおよびイメージメタデータの同期後に、イメージストリームオブジェクトは以下のようになります。
apiVersion: v1
kind: ImageStream
metadata:
name: my-ruby
namespace: demo-project
selflink: /oapi/v1/namespaces/demo-project/imagestreams/my-ruby
uid: 5b9bd745-13d2-11e6-9a86-0ada84b8265d
resourceVersion: '4699413'
generation: 2
creationTimestamp: '2016-05-06T21:34:48Z'
annotations:
openshift.io/image.dockerRepositoryCheck: '2016-05-06T21:34:48Z'
spec:
dockerImageRepository: docker.io/openshift/ruby-20-centos7
tags:
-
name: latest
annotations: null
from:
kind: DockerImage
name: 'docker.io/openshift/ruby-20-centos7:latest'
generation: 2
importPolicy: { }
status:
dockerImageRepository: '172.30.94.234:5000/demo-project/my-ruby'
tags:
-
tag: latest
items:
-
created: '2016-05-06T21:34:48Z'
dockerImageReference: 'docker.io/openshift/ruby-20-centos7@sha256:772c5bf9b2d1e8e80742ed75aab05820419dc4532fa6d7ad8a1efddda5493dc3'
image: 'sha256:772c5bf9b2d1e8e80742ed75aab05820419dc4532fa6d7ad8a1efddda5493dc3'
generation: 2
タグおよびイメージメタデータを同期するため、タグをスケジュールに応じて外部レジストリーのクエリーを実行できるよう設定できます。これは、「タグのイメージストリームへの追加」で説明されているように --scheduled=true フラグを oc tag コマンドに設定して実行できます。
または、タグの定義で importPolicy.scheduled を true に設定することもできます。
apiVersion: v1
kind: ImageStream
metadata:
name: ruby
spec:
tags:
- from:
kind: DockerImage
name: openshift/ruby-20-centos7
name: latest
importPolicy:
scheduled: true13.7.1. 非セキュアなレジストリーからのイメージのインポート
イメージストリームは、自己署名型の証明書を使って署名されたものを使用する場合や、HTTPS ではなく単純な HTTP を使用する場合など、非セキュアなイメージレジストリーからタグおよびイメージメタデータをインポートするように設定できます。
これを設定するには、openshift.io/image.insecureRepository アノテーションを追加し、これを true に設定します。この設定はレジストリーへの接続時の証明書の検証をバイパスします。
kind: ImageStream
apiVersion: v1
metadata:
name: ruby
annotations:
openshift.io/image.insecureRepository: "true" 1
spec:
dockerImageRepository: my.repo.com:5000/myimage- 1
openshift.io/image.insecureRepositoryアノテーション true に設定します。
このオプションは統合レジストリーに対して、イメージの提供時にイメージストリームでタグ付けされた外部イメージについて非セキュアなトランスポートにフォールバックするよう指示しますが、これにはリスクが伴います。可能な場合には、istag にのみ非セキュアのマークを付けてこのリスクを回避します。
13.7.1.1. イメージストリームタグのポリシー
13.7.1.1.1. 非セキュアなタグのインポートポリシー
上記のアノテーションは、特定の ImageStream のすべてのイメージおよびタグに適用されます。より詳細な制御を実行するために、ポリシーを「istags」に設定できます。タグの定義の importPolicy.insecure を true に設定すると、このタグが付けられたイメージについてのみセキュアでないトランスポートへのフォールバックが許可されます。
特定の istag 下のイメージについてのセキュアでないトランスポートへのフォールバックは、イメージストリームにセキュアでないアノテーションが付けられるか、または istag にセキュアでないインポートポリシーが設定されている場合に有効になります。importPolicy.insecure` が false に設定されていると、イメージストリームのアノテーションは上書きできません。
13.7.1.1.2. 参照ポリシー
参照ポリシーにより、このイメージストリームタグを参照するリソースがどこからイメージをプルするかを指定できます。これはリモートイメージ (外部レジストリーからインポートされるもの) にのみ適用されます。Local と Source のオプションから選択できます。
Source ポリシーはクライアントに対し、イメージのソースレジストリーから直接プルするように指示します。統合レジストリーは、イメージがクラスターによって管理されていない限り使用されません (これは外部イメージではありません)。このポリシーがデフォルトポリシーになります。
Local ポリシーはクライアントに対し、常に統合レジストリーからプルするように指示します。これは Docker デーモンの設定を変更せずに外部の非セキュアなレジストリーからプルする場合に役立ちます。
このポリシーはイメージストリームタグの使用にのみ適用されます。外部レジストリーの場所を使用してイメージを直接参照したり、プルしたりするコンポーネントまたは操作は内部レジストリーにリダイレクトされません。
このレジストリーの機能はリモートイメージをクライアントに提供します。この機能はデフォルトで有効にされており、ローカルの参照ポリシーが使用されるようにするには有効にされている必要があります。さらにすべての Blob は後のアクセスを速めるためにミラーリングされます。
イメージストリームタグの仕様でポリシーを referencePolicy.type として設定できます。
ローカル参照ポリシーが設定されたセキュアでないタグの例
kind: ImageStream
apiVersion: v1
metadata:
name: ruby
tags:
- from:
kind: DockerImage
name: my.repo.com:5000/myimage
name: mytag
importPolicy:
insecure: true 1
referencePolicy:
type: Local 2
13.7.2. プライベートレジストリーからのイメージのインポート
イメージストリームは、プライベートレジストリーからタグおよびイメージメタデータをインポートするように設定できます。これには認証が必要です。
これを設定するには、認証情報を保存するために使用されるシークレットを作成する必要があります。oc create secret コマンドを使用してシークレットを作成する方法については、「Pod が他のセキュリティー保護されたレジストリーからイメージを参照できるようにする」を参照してください。
シークレットが設定されたら、次に新規イメージストリームを作成するか、または oc import-image コマンドを使用します。インポートプロセスで OpenShift Container Platform はシークレットを取得してリモートパーティーに提供します。
セキュアでないレジストリーからインポートする場合には、シークレットに定義されたレジストリーの URL に :80 ポートのサフィックスを追加するようにしてください。追加していない場合にレジストリーからインポートしようとすると、このシークレットは使用されません。
13.7.3. 外部レジストリーの信頼される証明書の追加
インポート元となっているレジストリーが標準の認証局で署名されていない証明書を使用している場合に、システムがレジストリーの証明書または署名認証局を信頼するように明示的に設定する必要があります。これには 、レジストリーインポートコントローラーを実行するホストシステム (通常はマスターノード) に CA 証明書またはレジストリー証明書を追加してください。
証明書または CA 証明書は、ホストシステムの /etc/pki/tls/certs または /etc/pki/ca-trust にそれぞれ追加する必要があります。また証明書の変更を反映するには、update-ca-trust コマンドを Red Hat ディストリビューションで実行して、マスターサービスを再起動する必要があります。
13.7.4. 複数のプロジェクト間でのイメージのインポート
イメージストリームは、異なるプロジェクトから内部レジストリーのタグおよびイメージメタデータをインポートするように設定できます。推奨される方法としては、「タグのイメージストリーム」で説明されている oc tag コマンドを使用できます。
$ oc tag <source_project>/<image_stream>:<tag> <new_image_stream>:<new_tag>
別の方法として、プル仕様を使用して他のプロジェクトからイメージを手動でインポートすることもできます。
以下の方法については使用しないことを強く推奨します。この使用は oc tag の使用だけでは不十分な場合にのみに使用する必要があります。
最初に、他のプロジェクトにアクセスするために必要なポリシーを追加します。
$ oc policy add-role-to-group \ system:image-puller \ system:serviceaccounts:<destination_project> \ -n <source_project>これにより、
<destination_project>が<source_project>からイメージをプルできます。ポリシーが有効な場合、イメージを手動でインポートできます。
$ oc import-image <new_image_stream> --confirm \ --from=<docker_registry>/<source_project>/<image_stream>
13.7.5. イメージの手動プッシュによるイメージストリームの作成
イメージストリームはイメージを内部レジストリーに手動でプッシュすると自動的に作成されます。これは OpenShift Container Platform 内部レジストリーを使用している場合にのみ可能です。
この手順を実行する前に、以下の条件を満たしている必要があります。
- プッシュ先となる宛先プロジェクトがすでに存在している必要がある。
-
ユーザーはそのプロジェクトで
{get, update} "imagestream/layers"を実行する権限がある必要があります。さらに、イメージストリームが存在していない場合、ユーザーはそのプロジェクトで{create} "imagestream"を実行する権限がなければなりません。プロジェクト管理者にはこれらを実行するパーミッションがあります。
system:image-pusher ロールは新規イメージストリームの作成パーミッションを付与せず、既存イメージストリームにイメージをプッシュするパーミッションのみを付与するため、ユーザーに追加パーミッションが付与されない場合、存在していないイメージストリームにイメージをプッシュするためにこのパーミッションを使用することはできません。
イメージを手動でプッシュしてイメージストリームを作成するには、以下を実行します。
- まず、内部レジストリーにログインします。
次に、適切な内部レジストリーの場所を使用してイメージにタグを付けます。たとえば、docker.io/centos:centos7 イメージをローカルにプルしている場合は以下を実行します。
$ docker tag docker.io/centos:centos7 172.30.48.125:5000/test/my-image
最後に、イメージを内部レジストリーにプッシュします。以下は例になります。
$ docker push 172.30.48.125:5000/test/my-image The push refers to a repository [172.30.48.125:5000/test/my-image] (len: 1) c8a648134623: Pushed 2bf4902415e3: Pushed latest: digest: sha256:be8bc4068b2f60cf274fc216e4caba6aa845fff5fa29139e6e7497bb57e48d67 size: 6273
イメージストリームが作成されていることを確認します。
$ oc get is NAME DOCKER REPO TAGS UPDATED my-image 172.30.48.125:5000/test/my-image latest 3 seconds ago
13.8. イメージストリームの変更時の更新のトリガー
イメージストリームタグが新規イメージを参照するように更新される場合、OpenShift Container Platform は、古いイメージを使用していたリソースに新規イメージをロールアウトするためのアクションを自動的に実行します。イメージストリームタグを参照しているリソースのタイプに応じ、この設定はさまざまな方法で実行できます。
13.8.1. OpenShift リソース
OpenShift DeploymentConfigs および BuildConfigs は ImageStreamTags への変更によって自動的にトリガーされます。トリガーされたアクションは更新された ImageStreamTag で参照されるイメージの新規の値を使用して実行されます。この機能の使用方法についての詳細は、BuildConfig トリガーおよび DeploymentConfig トリガーについての説明を参照してください。
13.8.2. Kubernetes リソース
API 定義の一部としてトリガーを制御するためのフィールドセットを含む DeploymentConfigs および BuildConfigs とは異なり、Kubernetes リソースにはトリガー用のフィールドがありません。その代わりに、OpenShift Container Platform はアノテーションを使用してユーザーがトリガーを要求できるようにします。アノテーションは以下のように定義されます。
Key: image.openshift.io/triggers
Value: array of triggers, where each item has the schema:
[
{
"from" :{
"kind": "ImageStreamTag", // required, the resource to trigger from, must be ImageStreamTag
"name": "example:latest", // required, the name of an ImageStreamTag
"namespace": "myapp", // optional, defaults to the namespace of the object
},
// required, JSON path to change
// Note that this field is limited today, and only accepts a very specific set
// of inputs (a JSON path expression that precisely matches a container by ID or index).
// For pods this would be "spec.containers[?(@.name='web')].image".
"fieldPath": "spec.template.spec.containers[?(@.name='web')].image",
// optional, set to true to temporarily disable this trigger.
"paused": "false"
},
...
]
OpenShift Container Platform が Pod テンプレート (CronJobs、Deployments、StatefulSets、DaemonSets、Jobs、ReplicaSets、ReplicationControllers、および Pods のみ) とこのアノテーションの両方が指定されたコアの Kubernetes リソースを検出すると、トリガーが参照する ImageStreamTag に関連付けられているイメージを使用してオブジェクトの更新を試行します。この更新は、指定の fieldPath に対して実行されます。
以下の例では、トリガーは example:latest イメージストリームタグの更新時に実行されます。実行時に、オブジェクトの Pod テンプレートにある web コンテナーへのイメージ参照が、新しいイメージの値に更新されます。Pod テンプレートがデプロイメント定義の一部である場合には、Pod テンプレートへの変更はデプロイメントを自動的にトリガーされて、新規イメージがロールアウトされます。
image.openshift.io/triggers=[{"from":{"kind":"ImageStreamTag","name":"example:latest"},"fieldPath":"spec.template.spec.containers[?(@.name='web')].image"}]
イメージトリガーをデプロイメントに追加する時に、oc set triggers コマンドも使用できます。たとえば、以下のコマンドは example という名前のデプロイメントにイメージ変更トリガーを追加し、example:latest イメージストリームタグが更新されるとデプロイメント内の web コンテナーがイメージの新規の値で更新されます。
$ oc set triggers deploy/example --from-image=example:latest -c web
デプロイメントが一時停止されない限り、この Pod テンプレートが更新されると自動的に、新しいイメージの値でデプロイメントが実行されます。
13.9. イメージストリーム定義の記述
イメージストリーム全体に対するイメージストリームの定義を記述して、複数のイメージストリームを定義できます。これにより、oc コマンドを実行せずに異なるクラスターに定義を配信することができます。
イメージストリームの定義は、インポートするイメージストリームや固有のタグに関する情報を指定します。
イメージストリームオブジェクトの定義
apiVersion: v1
kind: ImageStream
metadata:
name: ruby
annotations:
openshift.io/display-name: Ruby 1
spec:
tags:
- name: '2.0' 2
annotations:
openshift.io/display-name: Ruby 2.0 3
description: >- 4
Build and run Ruby 2.0 applications on CentOS 7. For more information
about using this builder image, including OpenShift considerations,
see
https://github.com/sclorg/s2i-ruby-container/tree/master/2.0/README.md.
iconClass: icon-ruby 5
sampleRepo: 'https://github.com/sclorg/ruby-ex.git' 6
tags: 'builder,ruby' 7
supports: 'ruby' 8
version: '2.0' 9
from:
kind: DockerImage 10
name: 'docker.io/openshift/ruby-20-centos7:latest' 11
- 1
- イメージストリーム全体での簡単でユーザーフレンドリーな名前。
- 2
- タグはバージョンとして参照されます。タグはドロップダウンメニューに表示されます。
- 3
- イメージストリーム内のこのタグのユーザーフレンドリーな名前です。これは簡単で、バージョン情報が含まれている必要があります (該当する場合)。
- 4
- タグの説明。これにはユーザーがイメージの提供内容を把握できる程度の詳細情報が含まれます。これには追加の説明へのリンクを含めることができます。説明をいくつかの文に制限します。
- 5
- このタグ用に表示するアイコン。可能な場合は既存のロゴアイコンから選択します。FontAwesome および Patternfly のアイコンも使用できます。または、イメージストリームを使用する OpenShift Contaiter Platform クラスターに追加できる「CSS カスタマイズ」でアイコンを指定します。存在するアイコンクラスを指定する必要があります。これを指定しないと、汎用アイコンへのフォールバックができなくなります。
- 6
- このイメージストリームタグをビルダーイメージタグとして使用してビルドでき、サンプルアプリケーションを実行するために使用されるソースリポジトリーの URL です。
- 7
- 8
- このイメージがサポートする言語。この値は builder イメージを指定されるソースリポジトリーに一致させるように
oc new-appの起動時に使用されます。 - 9
- このタグのバージョン情報。
- 10
- このイメージストリームタグが参照するオブジェクトのタイプ。有効な値は
DockerImage、ImageStreamTagおよびImageStreamImageです。 - 11
- このイメージストリームタグがインポートするオブジェクト。
ImageStream に定義可能なフィールドに関する詳しい情報は、「Imagestream API」および「magestreamTag API」を参照してください。