レジストリー

Azure Red Hat OpenShift 4

Azure Red Hat OpenShift 4 のレジストリーの設定

Red Hat OpenShift Documentation Team

概要

本書では、Azure Red Hat OpenShift 4 の内部レジストリーを設定し、管理する方法について説明します。また、Azure Red Hat OpenShift 4 に関連付けられたレジストリーの概要も提供します。

第1章 イメージレジストリー

1.1. 統合 Azure Red Hat OpenShift レジストリー

Azure Red Hat OpenShift は、クラスター上の標準ワークロードとして実行されるコンテナーイメージレジストリーでビルドを提供します。このレジストリーはインフラストラクチャー Operator によって設定され、管理されます。これはユーザーがワークロードを実行するイメージを管理するために追加設定なしで使用できるソリューションを提供し、既存のクラスターインフラストラクチャーの上部で実行されます。このレジストリーは、他のクラスターワークロードのようにスケールアップまたはスケールダウンでき、特定のインフラストラクチャーのプロビジョニングを必要としません。さらに、これはクラスターのユーザー認証および認可システムに統合されるため、イメージを作成し、取得するためのアクセスは、イメージリソースでユーザーのパーミッションを定義することによって制御できることを意味します。

通常、レジストリーはクラスター上にビルドされたイメージの公開ターゲットとして、またクラスター上で実行されるワークロードのイメージのソースとして使用されます。新規イメージがレジストリーにプッシュされると、クラスターにはその新規イメージについて通知され、他のコンポーネントは更新されたイメージに応答し、これを使用できます。

イメージデータは 2 つの場所に保存されます。実際のイメージデータは、クラウドストレージまたはファイルシステムボリュームなどの設定可能なストレージの場所に格納されます。標準のクラスター API によって公開され、アクセス制御を実行するために使用されるイメージメタデータは、標準的な API リソース、とくにイメージおよびイメージストリームとして保存されます。

第2章 Azure Red Hat OpenShift のイメージレジストリー Operator

2.1. クラウドプラットフォームおよび OpenStack のイメージレジストリー

イメージレジストリー Operator は、Azure Red Hat OpenShift レジストリーの単一インスタンスをインストールし、レジストリーストレージのセットアップを含む、レジストリーのすべての設定を管理します。

注記

ストレージは、AWS、GCP、Azure または OpenStack にインストーラーでプロビジョニングされるインフラストラクチャークラスターをインストールする場合にのみ自動的に設定されます。

コントロールプレーンのデプロイ後、Operator はクラスターで検出される設定に基づいてデフォルトの configs.imageregistry.operator.openshift.io リソースインスタンスを作成します。

完全な configs.imageregistry.operator.openshift.io リソースを定義するのに利用できる情報が十分にない場合、その不完全なリソースが定義され、Operator は足りない情報を示す情報を使ってリソースのステータスを更新します。

イメージレジストリー Operator は openshift-image-registry namespace で実行され、その場所のレジストリーインスタンスも管理します。レジストリーのすべての設定およびワークロードリソースはその namespace に置かれます。

第3章 レジストリーオプション

Azure Red Hat OpenShift はイメージをソースコードからビルドし、それらをデプロイし、それらのライフサイクルを管理できます。これを可能にするため、 Azure Red Hat OpenShift は内部の統合コンテナーイメージレジストリーを提供しています。このレジストリーは Azure Red Hat OpenShift 環境にデプロイでき、ここからイメージをローカルで管理できます。

3.1. 統合 Azure Red Hat OpenShift レジストリー

Azure Red Hat OpenShift は、クラスター上の標準ワークロードとして実行されるコンテナーイメージレジストリーでビルドを提供します。このレジストリーはインフラストラクチャー Operator によって設定され、管理されます。これはユーザーがワークロードを実行するイメージを管理するために追加設定なしで使用できるソリューションを提供し、既存のクラスターインフラストラクチャーの上部で実行されます。このレジストリーは、他のクラスターワークロードのようにスケールアップまたはスケールダウンでき、特定のインフラストラクチャーのプロビジョニングを必要としません。さらに、これはクラスターのユーザー認証および認可システムに統合されるため、イメージを作成し、取得するためのアクセスは、イメージリソースでユーザーのパーミッションを定義することによって制御できることを意味します。

通常、レジストリーはクラスター上にビルドされたイメージの公開ターゲットとして、またクラスター上で実行されるワークロードのイメージのソースとして使用されます。新規イメージがレジストリーにプッシュされると、クラスターにはその新規イメージについて通知され、他のコンポーネントは更新されたイメージに応答し、これを使用できます。

イメージデータは 2 つの場所に保存されます。実際のイメージデータは、クラウドストレージまたはファイルシステムボリュームなどの設定可能なストレージの場所に格納されます。標準のクラスター API によって公開され、アクセス制御を実行するために使用されるイメージメタデータは、標準的な API リソース、とくにイメージおよびイメージストリームとして保存されます。

3.2. サードパーティーレジストリー

Azure Red Hat OpenShift はサードパーティーレジストリーからのイメージを使用してコンテナーを作成できますが、これらのレジストリーは統合 Azure Red Hat OpenShift レジストリーと同じイメージ通知のサポートを提供する訳ではありません。このため、Azure Red Hat OpenShift はイメージストリームの作成時にリモートレジストリーからタグをフェッチします。

フェッチされたタグの更新は、oc import-image <stream> を実行するだけで簡単に実行できます。新規イメージが検出されると、以前に記述されたビルドとデプロイメントの応答が生じます。

3.2.1. 認証

Azure Red Hat OpenShift はユーザーが指定する認証情報を使用してプライベートイメージリポジトリーにアクセスするためにレジストリーと通信できます。これにより、Azure Red Hat OpenShift はイメージのプッシュ/プルをプライベートリポジトリーへ/から実行できます。

3.3. Red Hat Quay レジストリー

エンタープライズ向けの高品質なコンテナーイメージレジストリーを必要とされる場合、Red Hat Quay をホストされたサービスとして、また独自のデータセンターやクラウド環境にインストールするソフトウェアとしてご利用いただけます。Red Hat Quay の高度なレジストリーには、geo レプリケーション、イメージのスキャニング、およびイメージのロールバック機能が含まれます。

Quay.io サイトにアクセスし、独自のホストされる Quay レジストリーアカウントをセットアップします。その後、Quay チュートリアルに従って Quay レジストリーにログインし、イメージの管理を開始します。

Red Hat Quay レジストリーへのアクセスは、任意のリモートコンテナーイメージレジストリーと同様に Azure Red Hat OpenShift から実行できます。

3.4. 認証で有効にされる Red Hat レジストリー

Red Hat Container Catalog で利用可能なすべてのコンテナーイメージはイメージレジストリーの registry.redhat.io でホストされます。

レジストリー registry.redhat.io では、イメージおよび Azure Red Hat OpenShift でホストされるコンテンツへのアクセスに認証が必要です。新規レジストリーへの移行後も、既存レジストリーはしばらく利用可能になります。

注記

Azure Red Hat OpenShift はイメージを registry.redhat.io からプルするため、これを使用できるようにクラスターを設定する必要があります。

新規レジストリーは、以下の方法を使用して認証に標準の OAuth メカニズムを使用します。

  • 認証トークン。管理者によって生成されるこれらのトークンは、システムにコンテナーイメージレジストリーに対する認証機能を付与するサービスアカウントです。サービスアカウントはユーザーアカウントの変更による影響を受けないため、トークンの認証方法は信頼性があり、回復性があります。これは、実稼働クラスター用にサポートされている唯一の認証オプションです。
  • Web ユーザー名およびパスワード。これは、access.redhat.com などのリソースへのログインに使用する標準的な認証情報のセットです。Azure Red Hat OpenShift でこの認証方法を使用することはできますが、これは実稼働デプロイメントではサポートされません。この認証方法の使用は、Azure Red Hat OpenShift 外のスタンドアロンのプロジェクトに制限されます。

ユーザー名およびパスワード、または認証トークンのいずれかの認証情報を使用して podman login を使用し、新規レジストリーのコンテンツにアクセスします。

すべてのイメージストリームは新規レジストリーを参照します。レジストリーにはアクセスするために認証が必要であるため、Samples Operator は samples-registry-credentials シークレットを作成します。

認証情報は 2 つの場所に配置する必要があります。

  • OpenShift namespace。OpenShift namespace のイメージストリームがインポートできるように、認証情報は OpenShift namespace になければなりません。
  • ホスト。Kubernetes でイメージをプルする際にホストの認証情報を使用するため、認証情報はホスト上になければなりません。

第4章 レジストリーへのアクセス

ログおよびメトリクスの表示やレジストリーのセキュリティー保護および公開などの、レジストリーへのアクセスについての各種の方法について、以下のセクションを参照してください。

レジストリーに直接アクセスし、podman コマンドを起動することが可能です。これにより、podman pushpodman pull などの操作で統合レジストリーへ/からイメージを直接プッシュまたはプルすることができます。これを実行するには、oc login コマンドを使ってレジストリーにログインしている必要があります。実行できる操作は、以下のセクションで説明されているようにユーザーが持つパーミッションによって異なります。

前提条件

  • アイデンティティープロバイダー (IDP) を設定しておく必要があります。
  • podman pull コマンドを使用する場合などにイメージをプルするには、ユーザーに registry-viewer ロールがなければなりません。このロールを追加するには、以下を実行します。

    $ oc policy add-role-to-user registry-viewer <user_name>
  • イメージの書き出しやプッシュを実行するには (podman push コマンドを使用する場合など)、ユーザーに registry-editor ロールが必要です。このロールを追加するには、以下を実行します。

    $ oc policy add-role-to-user registry-editor <user_name>

4.1. クラスターからレジストリーへの直接アクセス

クラスター内からレジストリーにアクセスすることができます。

手順

内部ルートを使用して、クラスターからレジストリーにアクセスします。

  1. アクセストークンを使用してコンテナーイメージレジストリーにログインします。

    $ podman login -u $(oc whoami) -p $(oc whoami -t) $(oc -n openshift-image-registry get route default-route -o jsonpath='{.spec.host}')

    以下のようなログインを確認するメッセージが表示されるはずです。

    Login Succeeded!
    注記

    ユーザー名には任意の値を指定でき、トークンには必要な情報がすべて含まれます。コロンが含まれるユーザー名を指定すると、ログインに失敗します。

    イメージレジストリー Operator はルートを作成するため、 default-route-openshift-image-registry.<cluster_name> のようになります。

  2. レジストリーに対して podman pull および podman push 操作を実行します。

    重要

    任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。

    次の例では、以下を使用します。

    Component

    <project>

    openshift

    <image>

    image

    <tag>

    省略 (デフォルトは latest)

    1. 任意のイメージをプルします。

      $ podman pull name.io/image
    2. 新規イメージに <registry_url>:<project>/<image> 形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするために Azure Red Hat OpenShift のプル仕様に表示される必要があります。

      $ podman tag name.io/image $(oc -n openshift-image-registry get route default-route -o jsonpath='{.spec.host}')/openshift/image
      注記

      指定されたプロジェクトについて system:image-builder ロールを持っている必要があります。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。このロールが設定されていない場合には次の手順の podman push が失敗します。 新規プロジェクトを作成し、イメージをプッシュしてテストできます。

    3. 新しくタグ付けされたイメージをレジストリーにプッシュします。

      $ podman push $(oc -n openshift-image-registry get route default-route -o jsonpath='{.spec.host}')/openshift/image

4.2. レジストリーの内容の表示

管理者として、レジストリーの内容を確認することができます。

前提条件

  • 管理者としてログインします。

手順

  1. プロジェクト openshift-image-registry の下で Pod を確認します。

    # oc get pods
    NAME READY STATUS RESTARTS AGE
    cluster-image-registry-operator-764bd7f846-qqtpb 1/1 Running 0 78m
    image-registry-79fb4469f6-llrln 1/1 Running 0 77m
    node-ca-hjksc 1/1 Running 0 73m
    node-ca-tftj6 1/1 Running 0 77m
    node-ca-wb6ht 1/1 Running 0 77m
    node-ca-zvt9q 1/1 Running 0 74m

4.3. レジストリーログの表示

oc logs コマンドを使用してレジストリーのログを表示することができます。

手順

  1. デプロイメントで oc logs コマンドを使用して、コンテナーイメージレジストリーのログを表示します。

    $ oc logs deployments/image-registry
    2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
    2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
    2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
    2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
    2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

4.4. レジストリーメトリクスへのアクセス

OpenShift Container レジストリーは、Prometheus メトリクスのエンドポイントを提供します。Prometheus はスタンドアロンのオープンソースのシステムモニタリングおよびアラートツールキットです。

メトリクスは、レジストリーエンドポイントの /extensions/v2/metrics パスに公開されます。

手順

メトリクスクエリーの実行またはクラスターロールの使用という、メトリクスにアクセスするための 2 つの方法を使用できます。

メトリクスクエリー

  1. 以下のようにメトリクスクエリーを実行します。

    $ curl --insecure -s -u <user>:<secret> \ 1
        https://image-registry.openshift-image-registry.svc:5000/extensions/v2/metrics | grep imageregistry | head -n 20
    # HELP imageregistry_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which the image registry was built.
    # TYPE imageregistry_build_info gauge
    imageregistry_build_info{gitCommit="9f72191",gitVersion="v3.11.0+9f72191-135-dirty",major="3",minor="11+"} 1
    # HELP imageregistry_digest_cache_requests_total Total number of requests without scope to the digest cache.
    # TYPE imageregistry_digest_cache_requests_total counter
    imageregistry_digest_cache_requests_total{type="Hit"} 5
    imageregistry_digest_cache_requests_total{type="Miss"} 24
    # HELP imageregistry_digest_cache_scoped_requests_total Total number of scoped requests to the digest cache.
    # TYPE imageregistry_digest_cache_scoped_requests_total counter
    imageregistry_digest_cache_scoped_requests_total{type="Hit"} 33
    imageregistry_digest_cache_scoped_requests_total{type="Miss"} 44
    # HELP imageregistry_http_in_flight_requests A gauge of requests currently being served by the registry.
    # TYPE imageregistry_http_in_flight_requests gauge
    imageregistry_http_in_flight_requests 1
    # HELP imageregistry_http_request_duration_seconds A histogram of latencies for requests to the registry.
    # TYPE imageregistry_http_request_duration_seconds summary
    imageregistry_http_request_duration_seconds{method="get",quantile="0.5"} 0.01296087
    imageregistry_http_request_duration_seconds{method="get",quantile="0.9"} 0.014847248
    imageregistry_http_request_duration_seconds{method="get",quantile="0.99"} 0.015981195
    imageregistry_http_request_duration_seconds_sum{method="get"} 12.260727916000022
    1
    <user> は任意ですが、<secret> はレジストリー設定で指定された値と一致していなければなりません。

クラスターロール

  1. メトリクスにアクセスするために必要なクラスターロールがない場合、これを作成します。

    $ cat <<EOF |
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: prometheus-scraper
    rules:
    - apiGroups:
      - image.openshift.io
      resources:
      - registry/metrics
      verbs:
      - get
    EOF
    $ oc create -f -
  2. このロールをユーザーに追加し、以下のコマンドを実行します。

    $ oc adm policy add-cluster-role-to-user prometheus-scraper <username>
  3. クラスターロールを使用してメトリクスにアクセスします。設定ファイルのメトリクスに対応する部分は以下のようになります。

    openshift:
      version: 1.0
      metrics:
        enabled: true
    ...

追加リソース

第5章 レジストリーの公開

デフォルトで、Azure Red Hat OpenShift レジストリーのセキュリティーは、TLS 経由でトラフィックを送信できるようにクラスターのインストール時に保護されます。以前のバージョンの Azure Red Hat OpenShift とは異なり、レジストリーはインストール時にクラスター外に公開されません。

5.1. セキュアなレジストリーの手動による公開

クラスター内から Azure Red Hat OpenShift レジストリーにログインするのではなく、外部からレジストリーにアクセスできるように、このレジストリーをルートで公開します。この方法を使うと、ルートアドレスを使ってクラスターの外部からレジストリーにログインし、ルートのホストを使ってイメージにタグ付けしたり、イメージをプッシュしたりできます。

前提条件

  • 以下の前提条件は自動的に実行されます。

    • レジストリー Operator をデプロイします。
    • Ingress Operator をデプロイします。

手順

configs.imageregistry.operator.openshift.io リソースで DefaultRoute パラメーターを使用するか、またはカスタムルートを使用してルートを公開することができます。

DefaultRoute を使用してレジストリーを公開するには、以下を実行します。

  1. DefaultRouteTrue に設定します。

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. Podman でログインします。

    $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false $HOST 1
    1
    --tls-verify=false は、ルートのクラスターのデフォルト証明書が信頼されない場合に必要になります。Ingress Operator で、信頼されるカスタム証明書をデフォルト証明書として設定できます。

カスタムルートを使用してレジストリーを公開するには、以下を実行します。

  1. ルートの TLS キーでシークレットを作成します。

    $ oc create secret tls public-route-tls \
        -n image-registry \
        --cert=</path/to/tls.crt> \
        --key=</path/to/tls.key>

    この手順はオプションです。シークレットを作成しない場合、ルートは Ingress Operator からデフォルトの TLS 設定を使用します。

  2. レジストリー Operator では、以下のようになります。

    spec:
      routes:
        - name: public-routes
          hostname: myregistry.mycorp.organization
          secretName: public-route-tls
    ...

    レジストリーのルートのカスタム TLS 設定を指定している場合は secretName のみを設定します。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat 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 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.

このページには機械翻訳が使用されている場合があります (詳細はこちら)。