7.2. イメージ設定内容の設定

image.config.openshift.io/cluster リソースを編集してイメージレジストリーの設定を行うことができます。Machine Config Operator (MCO) は、レジストリーへの変更について image.config.openshift.io/cluster を監視し、変更を検出するとノードを再起動します。

手順

  1. image.config.openshift.io/cluster カスタムリソースを編集します。

    $ oc edit image.config.openshift.io/cluster

    以下は、image.config.openshift.io/cluster リソースの例になります。

    apiVersion: config.openshift.io/v1
    kind: Image1
    metadata:
      annotations:
        release.openshift.io/create-only: "true"
      creationTimestamp: "2019-05-17T13:44:26Z"
      generation: 1
      name: cluster
      resourceVersion: "8302"
      selfLink: /apis/config.openshift.io/v1/images/cluster
      uid: e34555da-78a9-11e9-b92b-06d6c7da38dc
    spec:
      allowedRegistriesForImport:2
        - domainName: quay.io
          insecure: false
      additionalTrustedCA:3
        name: myconfigmap
      registrySources:4
        insecureRegistries:5
        - insecure.com
        blockedRegistries:6
        - untrusted.com
    status:
      internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    Image: イメージの処理方法についてのクラスター全体の情報を保持します。正規名および唯一の有効な名前となるのは cluster です。
    2
    allowedRegistriesForImport: 標準ユーザーがイメージのインポートに使用するコンテナーイメージレジストリーを制限します。この一覧を、有効なイメージを含むものとしてユーザーが信頼し、アプリケーションのインポート元となるレジストリーに設定します。イメージまたは ImageStreamMappings を API 経由で作成するパーミッションを持つユーザーは、このポリシーによる影響を受けません。通常、これらのパーミッションを持っているのはクラスター管理者のみです。
    3
    additionalTrustedCA: ImageStream importpod image pullopenshift-image-registry pullthrough、およびビルドの処理時に信頼される必要のある追加の CA が含まれる ConfigMap の参照です。この ConfigMap の namespace は openshift-config です。ConfigMap の形式では、信頼する追加のレジストリー CA についてレジストリーのホスト名をキーとして使用し、PEM 証明書を値として使用します。
    4
    registrySources: コンテナーランタイムがビルドおよび Pod のイメージへのアクセス時に個々のレジストリーを処理する方法を決定する設定が含まれます。たとえば、非セキュアなアクセスを許可するかどうかを設定します。内部クラスターレジストリーの設定は含まれません。
    5
    insecureRegistries: 有効な TLS 証明書を持たないか、または HTTP 接続のみをサポートするレジストリーです。
    6
    blockedRegistries: イメージのプルおよびプッシュアクションについてブラックリスト化されます。他のすべてのレジストリーは許可されます。

7.2.1. イメージレジストリーアクセス用の追加のトラストストアの設定

image.config.openshift.io/cluster リソースには、イメージレジストリーのアクセス時に信頼される追加の認証局が含まれる ConfigMap への参照を含めることができます。

前提条件

  • CA は PEM でエンコードされている必要があります。

手順

ConfigMap を openshift-config namespace に作成し、その名前を image.config.openshift.io リソースの AdditionalTrustedCA で使用し、追加の CA を指定することができます。

ConfigMap キーは、この CA が信頼されるポートを持つレジストリーのホスト名であり、base64 エンコード証明書が信頼する追加の各レジストリー CA についての値になります。

イメージレジストリー CA の ConfigMap の例

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

1
レジストリーにポートがある場合 (例: registry-with-port.example.com:5000)、「:」は .. に置き換える必要があります。

以下の手順で追加の CA を設定することができます。

  1. 追加の CA を設定するには、以下を実行します。

    $ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
    $ oc edit image.config.openshift.io cluster
    spec:
      additionalTrustedCA:
        name: registry-config

7.2.2. 非セキュアなレジストリーのインポートとレジストリーのブロック

image.config.openshift.io/cluster カスタムリソース (CR) を編集して、非セキュアなレジストリーを追加するか、レジストリーをブロックできます。OpenShift Container Platform は、この CR への変更をクラスター内のすべてのノードに適用します。

有効な TLS 証明書を持たない、または HTTP 接続のみをサポートするレジストリーなど、非セキュアな外部レジストリーは使用しないでください。

手順

  1. image.config.openshift.io/cluster カスタムリソースを編集します。

    $ oc edit image.config.openshift.io/cluster

    以下は、image.config.openshift.io/cluster リソースの例になります。

    apiVersion: config.openshift.io/v1
    kind: Image
    metadata:
      annotations:
        release.openshift.io/create-only: "true"
      creationTimestamp: "2019-05-17T13:44:26Z"
      generation: 1
      name: cluster
      resourceVersion: "8302"
      selfLink: /apis/config.openshift.io/v1/images/cluster
      uid: e34555da-78a9-11e9-b92b-06d6c7da38dc
    spec:
      allowedRegistriesForImport:
        - domainName: quay.io
          insecure: false
      additionalTrustedCA:
        name: myconfigmap
      registrySources:
        insecureRegistries:1
        - insecure.com
        blockedRegistries:2
        - untrusted.com
        allowedRegistries:
        - quay.io 3
    status:
      internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    非セキュアなレジストリーを指定します。
    2
    イメージのプルおよびプッシュアクションについてブラックリストに指定する必要のあるレジストリーを指定します。他のすべてのレジストリーは許可されます。blockedRegistries または allowedRegistries のいずれかを設定できますが、両方を設定することはできません。
    3
    イメージのプルおよびプッシュアクションについて許可する必要のあるレジストリーを指定します。他のすべてのレジストリーは拒否されます。blockedRegistries または allowedRegistries のいずれかを設定できますが、両方を設定することはできません。

    Machine Config Operator (MCO) は、レジストリーへの変更について image.config.openshift.io/cluster を監視し、変更を検出するとノードを再起動します。レジストリーへの変更は、各ノードの /host/etc/containers/registries.conf ファイルに表示されます。

    cat /host/etc/containers/registries.conf
    [registries]
      [registries.search]
        registries = ["registry.access.redhat.com", "docker.io"]
      [registries.insecure]
        registries = ["insecure.com"]
      [registries.block]
        registries = ["untrusted.com"]

7.2.3. イメージレジストリーのリポジトリーミラーリングの設定

コンテナーレジストリーのリポジトリーミラーリングの設定により、以下が可能になります。

  • ソースイメージのレジストリーのリポジトリーからイメージをプルする要求をリダイレクトするように OpenShift Container Platform クラスターを設定し、これをミラーリングされたイメージレジストリーのリポジトリーで解決できるようにします。
  • 各ターゲットリポジトリーに対して複数のミラーリングされたリポジトリーを特定し、1 つのミラーがダウンした場合に別のミラーを使用できるようにします。

以下は、OpenShift Container Platform のリポジトリーミラーリングの属性の一部です。

  • イメージプルには、レジストリーのダウンタイムに対する回復性があります
  • ネットワークが制限された環境のクラスターは、重要な場所 (quay.io など) からイメージをプルするように要求でき、会社のファイアウォールの背後にあるレジストリーが要求されたイメージを提供するようにできます。
  • イメージのプル要求時にレジストリーへの接続が特定の順序で試行され、通常は永続レジストリーが最後に試行されます。
  • 入力したミラー情報は、OpenShift Container Platform クラスターの全ノードの /etc/containers/registries.conf ファイルに追加されます。
  • ノードがソースリポジトリーからイメージの要求を行うと、要求されたコンテンツを見つけるまで、ミラーリングされた各リポジトリーに対する接続を順番に試行します。すべてのミラーで障害が発生した場合、クラスターはソースリポジトリーに対して試行します。成功すると、イメージはノードにプルされます。

リポジトリーミラーリングのセットアップは次の方法で実行できます。

  • OpenShift Container Platform インストール時: OpenShift Container Platform が必要とするコンテナーイメージをプルし、それらのイメージを会社のファイアウォールの内側に配置すると、制限されたネットワーク内にあるデータセンターに OpenShift Container Platform をインストールできます。詳細は、OpenShift Container Platform イメージレジストリーのミラーリングについて参照してください。
  • OpenShift Container Platform のインストール後: OpenShift Container Platform インストール時にミラーリングを設定しなくても、ImageContentSourcePolicy オブジェクトを使用して後で設定することができます。

以下の手順では、インストール後のミラーを設定し、以下を識別する ImageContentSourcePolicy オブジェクトを作成します。

  • ミラーリングするコンテナーイメージリポジトリーのソース
  • ソースリポジトリーから要求されたコンテンツを提供する各ミラーリポジトリーの個別のエントリー。

前提条件

  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセスがあること。

手順

  1. ミラーリングされたリポジトリーを設定します。これを実行するには、以下のいずれかを行います。

    • Repository Mirroring in Red Hat Quay」で説明されているように、Red Hat Quay でミラーリングされたリポジトリーを設定します。Red Hat Quay を使用すると、あるリポジトリーから別のリポジトリーにイメージをコピーでき、これらのリポジトリーを一定期間繰り返し自動的に同期することもできます。
    • skopeo などのツールを使用して、ソースディレクトリーからミラーリングされたリポジトリーにイメージを手動でコピーします。

      たとえば、Red Hat Enterprise Linux (RHEL 7 または RHEL 8) システムに skopeo RPM パッケージをインストールした後、以下の例に示すように skopeo コマンドを使用します。

      $ skopeo copy \
         docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
         docker://example.io/ubi8/ubi-minimal

      この例では、example.io いう名前のコンテナーイメージレジストリーと example という名前のイメージリポジトリーがあり、そこに registry.access.redhat.com から ubi8/ubi-minimal イメージをコピーします。レジストリーを作成した後、OpenShift Container Platform クラスターを設定して、ソースリポジトリーで作成される要求をミラーリングされたリポジトリーにリダイレクトできます。

  2. OpenShift Container Platform クラスターにログインします。
  3. ImageContentSourcePolicy ファイル (例: registryrepomirror.yaml) を作成し、ソースとミラーを固有のレジストリー、およびリポジトリーのペアとイメージのものに置き換えます。

    apiVersion: operator.openshift.io/v1alpha1
    kind: ImageContentSourcePolicy
    metadata:
      name: ubi8repo
    spec:
      repositoryDigestMirrors:
      - mirrors:
        - example.io/example/ubi-minimal1
        source: registry.access.redhat.com/ubi8/ubi-minimal2
      - mirrors:
        - example.com/example/ubi-minimal
        source: registry.access.redhat.com/ubi8/ubi-minimal
    1
    イメージレジストリーおよびリポジトリーの名前を示します。
    2
    ミラーリングされているコンテンツが含まれるレジストリーおよびリポジトリーを示します。
  4. 新しい ImageContentSourcePolicy を作成します。

    $ oc create -f registryrepomirror.yaml

    ImageContentSourcePolicy が作成されると、新しい設定が各ノードにデプロイされ、ソースリポジトリーへの要求のためにミラーリングされたリポジトリーの使用をすぐに開始します。

  5. ミラーリングされた設定が機能することを確認するには、ノードのいずれかに移動します。以下は例になります。

    1. ノードの一覧を表示します。

      $ oc get node

      出力例

      NAME                           STATUS                     ROLES    AGE  VERSION
      ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.16.2
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.16.2
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.16.2
      ip-10-0-147-35.ec2.internal    Ready,SchedulingDisabled   worker   7m   v1.16.2
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.16.2
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.16.2

      変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。

    2. デバッグプロセスを開始します。

      $ oc debug node/ip-10-0-147-35.ec2.internal

      出力例

      Starting pod/ip-10-0-147-35ec2internal-debug ...
      To use host binaries, run `chroot /host`

    3. ノードのファイルにアクセスします。

      sh-4.2# chroot /host
    4. /etc/containers/registries.conf ファイルをチェックして、変更が行われたことを確認します。

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      [[registry]]
        location = "registry.access.redhat.com/ubi8/"
        insecure = false
        blocked = false
        mirror-by-digest-only = true
        prefix = ""
      
        [[registry.mirror]]
          location = "example.io/example/ubi8-minimal"
          insecure = false
      
        [[registry.mirror]]
          location = "example.com/example/ubi8-minimal"
          insecure = false
    5. ソースからノードにイメージダイジェストをプルし、ミラーによって実際に解決されているかどうかを確認します。ImageContentSourcePolicy はイメージダイジェストのみをサポートし、イメージタグはサポートしません。

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

リポジトリーのミラーリングのトラブルシューティング

リポジトリーのミラーリング手順が説明どおりに機能しない場合は、リポジトリーミラーリングの動作方法についての以下の情報を使用して、問題のトラブルシューティングを行うことができます。

  • 最初に機能するミラーは、プルされるイメージを指定するために使用されます。
  • メインレジストリーは、他のミラーが機能していない場合にのみ使用されます。
  • システムコンテキストによって、Insecure フラグがフォールバックとして使用されます。
  • /etc/containers/registries ファイルの形式が最近変更されました。現在のバージョンはバージョン 2 で、TOML 形式です。