Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第13章 イメージの管理

13.1. 概要

イメージストリーム は、タグで識別される数多くの コンテナーイメージ で構成されます。これはコンテナーイメージリポジトリーのような関連イメージの単一仮想ビューを提供します。

イメージストリームの監視により、ビルドおよびデプロイメントは新規イメージの追加または変更時に通知を受信し、それぞれビルドまたはデプロイメントを実行してこれに対応します。

イメージのレジストリーが置かれる場所やレジストリー関連の認証要件、およびビルドやデプロイメントで必要とされる動作が何であるかによって、イメージと対話し、イメージストリームをセットアップする方法は異なり、数多くの方法でこれらを実行することができます。以下のセクションではこれらのトピックについて扱います。

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 はレジストリーによってローカルにミラーリングされます。その結果、それらが次回必要となる場合により迅速にプルされます。またこのフラグは --insecure-registry を Docker デーモンに指定しなくても、イメージストリームに 非セキュアなアノテーション があるか、またはタグに 非セキュアなインポートポリシーがある限り、非セキュアなレジストリーからのプルを許可します。

13.2.2. 推奨されるタグ付け規則

イメージは時間の経過と共に変化するもので、それらのタグはその変化を反映します。イメージタグはビルドされる最新イメージを常に参照します。

タグ名にあまりにも多くの情報が組み込まれる場合 (例: v2.0.1-may-2016)、タグはイメージの 1 つのリビジョンのみを参照し、更新されることがなくなります。デフォルトのイメージのプルーニングオプションを使用しても、このようなイメージは削除されません。非常に大規模なクラスターでは、イメージが修正されるたびに新規タグが作成される設定の場合、古くなって久しいイメージの余分のタグメタデータで etcd データストアが一杯になる可能性があります。

一方、タグの名前が v2.0 である場合はイメージリビジョンの数が多くなることが予想されます。これによりタグ履歴が長くなるため、イメージプルーナーが古くなり使われなくなったイメージを削除する可能性が高くなります。詳細は、「イメージのプルーニング」を参照してください。

タグの名前付け規則は各自で定めることができますが、ここでは <image_name>:<image_tag> 形式のいくつかの例を見てみましょう。

表13.1 イメージタグの名前付け規則

説明

リビジョン

myimage:v2.0.1

アーキテクチャー

myimage:v2.0-x86_64

ベースイメージ

myimage:v1.2-centos7

最新 (不安定な可能性がある)

myimage:latest

最新 (安定性がある)

myimage:stable

タグ名に日付を含める必要がある場合、古くなり使用されなくなったイメージおよび 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.redhat.io/rhel7:latest

    またはダイジェストでイメージを参照できます。

    centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e

CentOS イメージストリームのサンプル などのイメージストリーム定義のサンプルを表示する場合、それらには ImageStreamTag の定義や DockerImage の参照が含まれる一方で、ImageStreamImage に関連するものは何も含まれていないことに気づかれることでしょう。

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

イメージのオブジェクト定義は、イメージストリーム名および ID を使用し、ImageStreamImage 定義を取得して確認することができます。

$ oc get -o yaml --export isimage <image_stream_name>@<id>
注記

以下を実行して所定のイメージストリームの有効な <id> 値を確認することができます。

$ oc describe is <image_stream_name>

たとえば、ruby イメージストリームから ruby@3a335d7 の名前および ID を使って ImageStreamImage を検索します。

ImageStreamImage で取得されるイメージオブジェクトの定義

$ oc get -o yaml --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.5 の場合、ruby2.5 という名前のタグを持ち、参照するリソースと同じプロジェクトにあるイメージストリームの名前になります。

この機能を有効にする 2 つの方法があります。

  1. 特定のリソースでイメージストリームの解決を有効にする。これにより、このリソースのみがイメージフィールドのイメージストリーム名を使用できます。
  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: イメージをプルしません。
注意

グローバルビルド設定で forcePull フラグを有効にして、ビルドが開始されるたびに、レジストリーからイメージの更新を強制できます。これにより、すべてのビルドでイメージアクセスのチェックが強制的に実行され、ユーザーがアクセスパーミッションを持たないイメージのローカルキャッシュにアクセスする可能性がなくなります。

コンテナーの imagePullPolicy パラメーターが指定されていない場合、OpenShift Container Platform はイメージのタグに基づいてこれを設定します。

  1. タグが 最新 の場合、OpenShift Container Platform は imagePullPolicyAlways にデフォルト設定します。
  2. それ以外の場合に、OpenShift Container Platform は imagePullPolicyIfNotPresent にデフォルト設定します。
注記

Never イメージプルポリシーを使用する場合、プライベートイメージが AlwaysPullImages 受付コントローラーとそれらのイメージをプルするための認証情報を使用する Pod によってのみ使用されるようにできます。

13.5. 内部レジストリーへのアクセス

イメージのプッシュまたはプルを実行するために OpenShift Container Platform の内部レジストリーに直接アクセスできます。たとえば、これは イメージの手動プッシュによってイメージストリームを作成する場合や、単にイメージに対して docker pull を直接実行する場合に役立ちます。

内部レジストリーは OpenShift Container Platform API と同じ トークン を使用して認証します。内部レジストリーに対して docker login を実行するには、任意のユーザー名およびメールを使用できますが、パスワードは有効な OpenShift Container Platform トークンである必要があります。

内部レジストリーにログインするには、以下を実行します。

  1. OpenShift Container Platform にログインします。

    $ oc login
  2. アクセストークンを取得します。

    $ oc whoami -t
  3. トークンを使用して内部レジストリーにログインします。docker をシステムにインストールしておく必要があります。

    $ docker login -u <user_name> -e <email_address> \
        -p <token_value> <registry_server>:<port>
    注記

    使用するレジストリー IP またはホスト名およびポートが不明な場合は、クラスター管理者に問い合わせてください。

イメージをプルするには、要求される imagestreams/layers に対する get 権限が、この認証済みのユーザーに割り当てられている必要があります。また、イメージをプッシュするには、認証済みのユーザーに、要求される imagestreams/layers に対する update 権限が割り当てられている必要があります。

デフォルトで、プロジェクトのすべてのサービスアカウントは同じプロジェクトの任意のイメージをプルする権限を持ち、builder サービスアカウントには同じプロジェクトの任意のイメージをプッシュする権限を持ちます。

13.5.1. リポジトリーの一覧表示

リポジトリーまたはイメージストリーム名の一覧表示は /v2/_catalog エンドポイントでサポートされます。

唯一の要件として、認証されたユーザーにはクラスター全体での imagestreams に対して list 権限が必要になります。

イメージストリームを一覧表示するためのパーミッションをユーザーに付与するには、以下を実行します。

$ oc adm policy add-cluster-role-to-user registry-viewer user

リポジトリーを一覧表示するには、以下を実行します。

$ oc login -u user
$ curl -v -u unused:$(oc whoami -t) https://<registry_server>:<port>/v2/_catalog?n=100
重要

この API 呼び出しは、クラスターに多数のイメージストリームが含まれる場合に多くのコストがかかります。すべてのイメージストリームを一覧表示するのではなく、ページネーションを使用することが推奨されます。

13.6. イメージプルシークレットの使用

Docker レジストリー のセキュリティーを保護し、承認されていないユーザーが特定イメージにアクセスできないようにすることができます。OpenShift Container Platform の内部レジストリーを使用し、同じプロジェクトにあるイメージストリームからプルしている場合は、Pod のサービスアカウントに適切なパーミッションがすでに設定されているために追加のアクションは不要です。

ただし、OpenShift Container Platform プロジェクト全体でイメージを参照する場合や、セキュリティー保護されたレジストリーからイメージを参照するなどの他のシナリオでは、追加の設定手順が必要になります。以下のセクションでは、それらのシナリオと必要な手順について詳しく説明します。

13.6.1. Pod が複数のプロジェクト間でのイメージを参照できるようにする設定

内部レジストリーを使用している場合で project-a の Pod が project-b のイメージを参照できるようにするには、project-a のサービスアカウントが project-bsystem: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-b

13.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 に委任するため、以下の手順が適用されます。

  1. 委任された認証サーバーのシークレットを作成します。

    $ 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
  2. プライベートレジストリーのシークレットを作成します。

    $ 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. タグおよびイメージメタデータのインポート

イメージストリームは、外部コンテナーイメージレジストリーのイメージリポジトリーからタグおよびイメージメタデータをインポートするように設定できます。これは複数の異なる方法で実行できます。

  • 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.scheduledtrue に設定することもできます。

apiVersion: v1
kind: ImageStream
metadata:
  name: ruby
spec:
  tags:
  - from:
      kind: DockerImage
      name: openshift/ruby-20-centos7
    name: latest
    importPolicy:
      scheduled: true

13.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 にのみ非セキュアのマークを付けてこのリスクを回避します。

重要

上記の定義はタグおよびイメージメタデータのインポートのみに適用されます。このイメージがクラスターで使用されるようにするには (docker pull を実行できるようにするには)、以下のいずれかが該当している必要があります。

  1. 各ノードには Docker が dockerImageRepository のレジストリーの部分に一致する --insecure-registry フラグで設定されている。詳細は、「Host Preparation」を参照してください。
  2. istag 仕様では referencePolicy.typeLocal に設定されている。詳細は、「参照ポリシー」を参照してください。

13.7.1.1. イメージストリームタグのポリシー

13.7.1.1.1. 非セキュアなタグのインポートポリシー

上記のアノテーションは、特定の ImageStream のすべてのイメージおよびタグに適用されます。より詳細な制御を実行するために、ポリシーを istags に設定できます。タグの定義の importPolicy.insecuretrue に設定すると、このタグ下のイメージについてのみ非セキュアなトランスポートへのフォールバックが許可されます。

注記

特定の istag 下のイメージについてのセキュアでないトランスポートへのフォールバックは、イメージストリームにセキュアでないアノテーションが付けられるか、または istag にセキュアでないインポートポリシーが設定されている場合に有効になります。importPolicy.insecurefalse に設定されていると、イメージストリームのアノテーションは上書きできません。

13.7.1.1.2. 参照ポリシー

参照ポリシーにより、このイメージストリームタグを参照するリソースがどこからイメージをプルするかを指定できます。これは外部レジストリーからインポートされるイメージにのみ適用されます。LocalSource のオプションから選択できます。

Source ポリシーはクライアントに対し、イメージのソースレジストリーから直接プルするように指示します。統合レジストリーは、イメージがクラスターによって管理されていない限り使用されません (これは外部イメージではありません)。このポリシーがデフォルトポリシーになります。

Local ポリシーはクライアントに対し、常に統合レジストリーからプルするように指示します。これは Docker デーモンの設定を変更せずに外部の非セキュアなレジストリーからプルする場合に役立ちます。

このポリシーはイメージストリームタグの使用にのみ適用されます。外部レジストリーの場所を使用してイメージを直接参照したり、プルしたりするコンポーネントまたは操作は内部レジストリーにリダイレクトされません。

The pull-through feature of the registry serves the remote image to the client. This feature, which is on by default, must be enabled for the local reference policy to be used. Additionally, by default, all the blobs are mirrored for faster access later.

イメージストリームタグの仕様でポリシーを 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

1
該当レジストリーへの非セキュアな接続を使用するようタグ mytag を設定します。
2
外部イメージをプルするために統合レジストリーを使用するよう mytag を設定します。参照ポリシータイプが Source に設定されている場合、クライアントはイメージを my.repo.com:5000/myimage から直接フェッチします。

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 ディストリビューションで実行して、マスターサービスを再起動する必要があります。

マスター設定ファイルの「イメージポリシー設定」セクションで AdditionalTrustedCA パラメーターを設定することにより、レジストリーインポートコントローラーに、証明書の別のファイルシステムのパスをポイントさせることもできます。

13.7.4. 複数のプロジェクト間でのイメージのインポート

イメージストリームは、異なるプロジェクトから内部レジストリーのタグおよびイメージメタデータをインポートするように設定できます。推奨される方法としては、「タグのイメージストリーム」で説明されている oc tag コマンドを使用できます。

$ oc tag <source_project>/<image_stream>:<tag> <new_image_stream>:<new_tag>

別の方法として、プル仕様を使用して他のプロジェクトからイメージを手動でインポートすることもできます。

警告

以下の方法は使用しないことを強く推奨します。この使用は oc tag を使用するだけでは不十分な場合にのみに使用する必要があります。

  1. 最初に、他のプロジェクトにアクセスするために必要なポリシーを追加します。

    $ oc policy add-role-to-group \
        system:image-puller \
        system:serviceaccounts:<destination_project> \
        -n <source_project>

    これにより、<destination_project><source_project> からイメージをプルできます。

  2. ポリシーが有効な場合、イメージを手動でインポートできます。

    $ 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 ロールは新規イメージストリームの作成パーミッションを付与せず、既存イメージストリームにイメージをプッシュするパーミッションのみを付与するため、ユーザーに追加パーミッションが付与されない場合、存在していないイメージストリームにイメージをプッシュするためにこのパーミッションを使用することはできません。

イメージを手動でプッシュしてイメージストリームを作成するには、以下を実行します。

  1. まず、内部レジストリーにログインします。
  2. 次に、適切な内部レジストリーの場所を使用してイメージにタグを付けます。たとえば、docker.io/centos:centos7 イメージをローカルにプルしている場合は以下を実行します。

    $ docker tag docker.io/centos:centos7 172.30.48.125:5000/test/my-image
  3. 最後に、イメージを内部レジストリーにプッシュします。以下は例になります。

    $ 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
  4. イメージストリームが作成されていることを確認します。

    $ oc get is
    NAME       DOCKER REPO                        TAGS      UPDATED
    my-image   172.30.48.125:5000/test/my-image   latest    3 seconds ago

13.8. イメージの転送

イメージをあるコンテナーイメージレジストリーから別のコンテナーイメージレジストリーに移動するには、oc image mirror コマンドを使用します。イメージはローカルに保存されることなく、レジストリーからレジストリーにストリーミングされます。

たとえば、イメージを Docker Hub から統合レジストリーにコピーするには、以下のコマンドを使用します。

$ oc image mirror docker.io/library/busybox:latest 172.30.0.0/16/myproject/toybox:latest
重要

docker.io を送信元および宛先で使用する場合、docker.io および library コンポーネントを省略することはできません。最新のタグを取得する必要がある場合は、latest を省略しないでください。

イメージを一度に複数の場所にコピーすることができます。これを実行するには、複数の宛先を指定する必要があります。

$ oc image mirror 172.30.0.0/16/myproject/busybox:latest docker.io/myrepository/busybox:stable docker.io/myrepository/toybox:dev
注記

oc image mirror は OpenShift Container Platform クラスター内ではなく、ローカルに実行されます。そのため、oc image mirror には送信元と宛先レジストリーへのアクセスが必要になります。

コンテナーイメージレジストリーでイメージをプルまたはプッシュするための認証が必要な場合、docker login コマンドを使用して手動でログインしてから、oc image mirror コマンドを実行する必要があります。Jenkins エージェントイメージ内でコマンドを使用しているなどの理由で docker バイナリーおよびデーモンへのアクセスがない場合、oc image mirror を起動する前に、ユーザーのホームディレクトリーの有効な認証情報を含む .docker/config.json ファイルを手動で指定することができます。

13.9. イメージストリーム変更時の更新のトリガー

イメージストリームタグが新規イメージを参照するように更新される場合、OpenShift Container Platform は、古いイメージを使用していたリソースに新規イメージをロールアウトするためのアクションを自動的に実行します。イメージストリームタグを参照しているリソースのタイプに応じ、この設定はさまざまな方法で実行できます。

13.9.1. OpenShift リソース

OpenShift DeploymentConfigs および BuildConfigs は ImageStreamTags への変更によって自動的にトリガーされます。トリガーされたアクションは更新された ImageStreamTag で参照されるイメージの新規の値を使用して実行されます。この機能の使用方法についての詳細は、BuildConfig トリガーおよび DeploymentConfig トリガーについての説明を参照してください。

13.9.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.10. イメージストリーム定義の記述

イメージストリーム全体に対するイメージストリームの定義を記述して、複数のイメージストリームを定義できます。これにより、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
イメージストリームタグが関連付けられるカテゴリーです。このタグがカタログに表示されるには、ビルダータグが必要です。これを提供されているカタログカテゴリーのいずれかに関連付けるタグを追加します。コンソールの 定数ファイルにある CATALOG_CATEGORIESid および categoryAliases を参照してください。カテゴリーはクラスター全体に対してカスタマイズすることもできます。
8
このイメージがサポートする言語。この値は builder イメージを指定されるソースリポジトリーに一致させるように oc new-app の起動時に使用されます。
9
このタグのバージョン情報。
10
このイメージストリームタグが参照するオブジェクトのタイプ。有効な値は DockerImageImageStreamTag および ImageStreamImage です。
11
このイメージストリームタグがインポートするオブジェクト。

ImageStream に定義できるフィールドについての詳細は、「Imagestream API」および「ImagestreamTag API」を参照してください。