第13章 イメージの管理

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>

さらに --scheduled=true フラグを追加して宛先タグが定期的に更新 (再インポートなど) されるようにできます。期間はシステムレベルで「グローバルに設定」できます。詳細は、「タグおよびイメージメタデータのインポート」を参照してください。

--reference フラグはインポートされないイメージストリームを作成します。このタグは単にソースの場所を参照しますが、これを永続的に参照します。

Docker に対して、統合レジストリーからタグ付けされたイメージを常にフェッチするよう指示するには、--reference-policy=local を使用します。レジストリーは「プルスルー (pull-through) 機能」を使用してイメージをクライアントに提供します。デフォルトで、イメージ Blob はレジストリーによってローカルにミラーリングされるので、イメージ Blob が次回必要になると、より早くプルされます。またこのフラグは --insecure-registry を Docker デーモンに指定しなくても、イメージストリームに「セキュアでないアノテーション」があるか、またはタグに「セキュアでないインポートポリシー」がある限り、セキュアでないレジストリーからもプルできます。

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

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

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

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

タグ名に日付を含める必要がある場合、古くなり使用されなくなったイメージおよび istags を定期的に検査し、これらを削除してください。そうしないと、古いイメージによるリソース使用量が増大する可能性があります。

タグをイメージストリームから完全に削除するには、以下を実行します。

$ oc delete istag/ruby:latest

または以下を実行します。

$ oc tag -d ruby:latest

以下の参照タイプを使用して、イメージをイメージストリームで参照できます。

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

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

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

$ oc export isimage <image_stream_name>@<id>

$ oc describe is <image_stream_name>

たとえば、ruby イメージストリームから ruby@3a335d7 の名前および ID を使って 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

内部レジストリーを使用している場合で 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-b

.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>

$ 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

イメージストリームは、自己署名型の証明書を使って署名されたものを使用する場合や、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

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

イメージストリームは、プライベートレジストリーからタグおよびイメージメタデータをインポートするように設定できます。これには認証が必要です。

これを設定するには、認証情報を保存するために使用されるシークレットを作成する必要があります。oc create secret コマンドを使用してシークレットを作成する方法については、「Pod が他のセキュリティー保護されたレジストリーからイメージを参照できるようにする」を参照してください。

シークレットが設定されたら、次に新規イメージストリームを作成するか、または oc import-image コマンドを使用します。インポートプロセスで OpenShift Container Platform はシークレットを取得してリモートパーティーに提供します。

インポート元となっているレジストリーが標準の認証局で署名されていない証明書を使用している場合に、システムがレジストリーの証明書または署名認証局を信頼するように明示的に設定する必要があります。これには 、レジストリーインポートコントローラーを実行するホストシステム (通常はマスターノード) に CA 証明書またはレジストリー証明書を追加してください。

証明書または CA 証明書は、ホストシステムの /etc/pki/tls/certs または /etc/pki/ca-trust にそれぞれ追加する必要があります。また証明書の変更を反映するには、update-ca-trust コマンドを Red Hat ディストリビューションで実行して、マスターサービスを再起動する必要があります。

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

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

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

イメージストリームはイメージを内部レジストリーに手動でプッシュすると自動的に作成されます。これは OpenShift Container Platform 内部レジストリーを使用している場合にのみ可能です。

この手順を実行する前に、以下の条件を満たしている必要があります。

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

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

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 テンプレートが更新されると自動的に、新しいイメージの値でデプロイメントが実行されます。