第3章 レジストリーのセットアップ
3.1. レジストリーの概要
3.1.1. レジストリーについて
OpenShift Container Platform は、ソースコードからコンテナーイメージをビルドし、デプロイし、そのライフサイクルを管理することができます。これを有効にするために、OpenShift Container Platform は、イメージをローカルで管理するために OpenShift Container Platform 環境にデプロイできる内部の統合 Docker レジストリーを提供しています。
3.1.2. 統合レジストリーまたはスタンドアロンレジストリー
完全な OpenShift Container Platform クラスターの初回インストール時に、レジストリーはインストールプロセスで自動的にデプロイされている可能性があります。自動的にデプロイされていなかった場合やレジストリー設定のカスタマイズが追加で必要になる場合には、「既存クラスターへのレジストリーのデプロイ」を参照してください。
OpenShiftコンテナプラットフォームの完全な統合された部分として実行するために展開することができますが、OpenShiftコンテナプラットフォームのレジストリは、スタンドアロンのコンテナイメージレジストリとして別々にインストールすることもできます。
スタンドアロンレジストリーをインストールするには、スタンドアロンレジストリーのインストールの手順に従ってください。このインストールパスは、レジストリーと専用の Web コンソールを実行するオールインワンのクラスターをデプロイします。
3.2. 既存クラスターへのレジストリーのデプロイ
3.2.1. 概要
OpenShift Container Platform クラスターの初回インストール時に統合レジストリーが事前に自動的にデプロイされなかった場合や、正常に実行されず、既存のクラスターに再デプロイする必要がある場合は、以下のセクションで新規レジストリーをデプロイするためのオプションを参照してください。
スタンドアロンレジストリーをインストールしていない場合、このトピックは不要になります。
3.2.2. レジストリーのデプロイ
統合 Docker レジストリーをデプロイするには、クラスター管理者権限を持つユーザーとして oc adm registry
コマンドを使用します。以下は例になります。
$ oc adm registry --config=/etc/origin/master/admin.kubeconfig \1 --service-account=registry \2 --images='registry.access.redhat.com/openshift3/ose-${component}:${version}' 3
これでサービスとデプロイメント設定が作成されます。これらは共に docker-registry と呼ばれます。正常にデプロイされると、Pod が docker-registry-1-cpty9 などの名前付きで作成されます。
レジストリーの作成時に指定できるオプションの詳細の一覧を表示するには、以下を実行します。
$ oc adm registry --help
--fs-group
の値は、レジストリーが使用している SCC (通常は制限付き SCC) によって許可されている必要があります。
3.2.3. レジストリーを DaemonSet としてデプロイする
レジストリーを --daemonset
オプションを使用して DaemonSet
としてデプロイするには、 oc adm registry
コマンドを使用します。
デーモンセットでは、ノードが作成されるときに、指定されたポッドのコピーが含まれます。ノードが削除されると、ポッドはガベージコレクションされます。
DaemonSet
に関する詳細は、「Daemonset の使用」を参照してください。
3.2.4. レジストリーのコンピュートリソース
デフォルトでは、レジストリーはコンピュートリソースの要求や制限に関する設定がない状態で作成されます。実稼働環境では、レジストリーのデプロイメント設定を更新してレジストリー Pod のリソース要求や制限を設定しておくことが強く推奨されます。設定しない場合、レジストリー Pod は BestEffort Pod と判断されます。
要求や制限の設定に関する詳細は、「コンピュートリソース」を参照してください。
3.2.5. レジストリーのストレージ
レジストリーには、コンテナーのイメージとメタデータが格納されています。Pod をレジストリーと共に単純にデプロイする場合、Pod がすでに存在する場合に破棄される一時ボリュームが使用されます。この場合、誰かがビルドしたりレジストリーにプッシュしたりしたイメージは消えてしまいます。
以下のセクションでは、サポートされているレジストリーのストレージドライバーの一覧を示しています。詳細は、Docker レジストリーのドキュメントを参照してください。
次の一覧には、レジストリの構成ファイルで構成する必要があるストレージドライバが含まれています。
- ファイルシステム。ファイルシステムはデフォルトですので、設定の必要はありません。
- S3。詳細は、CloudFront の設定のドキュメントを参照してください。
- OpenStack Swift
- Google Cloud Storage (GCS)
- Microsoft Azure
- Aliyun OSS
レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。
以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。
サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。
3.2.5.1. 実稼働環境での使用
実稼働環境での使用の場合には、リモートボリュームを割り当てるか、または各自が選択した永続ストレージ方法を定義して使用します。
たとえば、既存の Persistent Volume Claim (永続ボリューム要求) を使用するには、以下を実行します。
$ oc volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \ --claim-name=<pvc_name> --overwrite
テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。
他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
3.2.5.1.1. Amazon S3 をストレージのバックエンドとして使用する
Amazon Simple Storage Service のストレージを内部 Docker レジストリーと共に使用する方法もあります。Amazon Simple Storage Service は AWS マネジメントコンソールで管理できるセキュアなクラウドストレージです。これを使用するには、レジストリーの設定ファイルを手動で編集し、レジストリー Pod にマウントする必要があります。ただし、設定を開始する前にアップストリームの推奨される手順を確認してください。
デフォルトの YAML 設定ファイルをベースとして取得し、storageセクションのfilesystemエントリーを、以下のように s3 エントリーに置き換えます。これにより、ストレージのセクションは以下のようになります。
storage: cache: layerinfo: inmemory delete: enabled: true s3: accesskey: awsaccesskey 1 secretkey: awssecretkey 2 region: us-west-1 regionendpoint: http://myobjects.local bucket: bucketname encrypt: true keyid: mykeyid secure: true v4auth: false chunksize: 5242880 rootdirectory: /s3/object/name/prefix
s3 のすべての設定オプションは、アップストリームのドライバー参照ドキュメントに記載されています。
レジストリー設定を上書きすると、設定ファイルを Pod にマウントするための追加の手順に進みます。
レジストリーが S3 ストレージのバックエンドで実行されると、問題が報告されます。
3.2.5.2. 非実稼働環境での使用
非実稼働環境の場合、--mount-host=<path>
オプションを使って、永続ストレージに使用するレジストリーのディレクトリーを指定します。次に、レジストリーのボリュームがホストのマウントとして、指定された <path>
に作成されます。
--mount-host
オプションは、レジストリーのコンテナーが実行されているノードからディレクトリーをマウントします。docker-registry デプロイメント設定をスケールアップすると、レジストリー Pod とコンテナーが別々のノードで実行され、2 つ以上のレジストリーコンテナーがそれぞれのローカルストレージと共に作成される可能性があります。これは予期しない動作を生じさせます。その後に繰り返される同一イメージのプル要求が最終的に到達するコンテナーによっては必ずしも成功しない場合があるためです。
--mount-host
オプションは、レジストリーコンテナーを特権モードで実行することを要求します。この要求は、ユーザーが --mount-host
を指定すると自動的に有効にされます。ただしデフォルトでは、すべての Pod が特権付きコンテナー を実行できる訳ではありません。それでもこのオプションの使用する必要がある場合は、レジストリーを作成してから、レジストリーがインストール時に作成された registry サービスアカウントを使用するように指定してください。
$ oc adm registry --service-account=registry \ --config=/etc/origin/master/admin.kubeconfig \ --images='registry.access.redhat.com/openshift3/ose-${component}:${version}' \ --mount-host=<path>
Docker レジストリー Pod は、ユーザー 1001 として実行されます。このユーザーは、ホストのディレクトリーへの書き込みができなければなりません。したがって、以下のコマンドでディレクトリーの所有権をユーザー ID 1001 に変更する必要がある場合があります。
$ sudo chown 1001:root <path>
3.2.6. レジストリーコンソールの有効化
OpenShift Container Platform は、統合レジストリーへの Web ベースのインターフェースを提供します。このレジストリーコンソールは、イメージの参照と管理を行うためのオプションのコンポーネントであり、Pod として実行されるステートレスサービスとしてデプロイされます。
OpenShift Container Platform をスタンドアロンレジストリーとしてインストールした場合、レジストリーコンソールはインストール時にすでにデプロイされ、そのセキュリティーが自動的に保護されています。
Cockpit がすでに実行されている場合、レジストリーコンソールとのポート競合 (デフォルトでは9090) を避けるために、次に進む前にこれをシャットダウンする必要があります。
3.2.6.1. レジストリーコンソールのデプロイ
最初にレジストリーを公開しておく必要があります。
デフォルトのプロジェクトにパススルールートを作成します。このルートは、以下の手順でレジストリーコンソールのアプリケーションを作成する際に必要になります。
$ oc create route passthrough --service registry-console \ --port registry-console \ -n default
レジストリーコンソールのアプリケーションをデプロイします。
<openshift_oauth_url>
を OpenShift Container Platform OAuth プロバイダー の URL に置き換えます。通常これはマスターになります。$ oc new-app -n default --template=registry-console \ -p OPENSHIFT_OAUTH_PROVIDER_URL="https://<openshift_oauth_url>:8443" \ -p REGISTRY_HOST=$(oc get route docker-registry -n default --template='{{ .spec.host }}') \ -p COCKPIT_KUBE_URL=$(oc get route registry-console -n default --template='https://{{ .spec.host }}')
注記レジストリーコンソールへのログインの試行時にリダイレクト URL が間違っていた場合は、
oc get oauthclients
で OAuth クライアントを確認してください。- 最後に、Webブラウザを使用してルートURIを使用してコンソールを表示します。
3.2.6.2. レジストリーコンソールのセキュリティー保護
デフォルトでは、レジストリーコンソールは、レジストリーコンソールのデプロイの手順ごとに手動でデプロイされる場合に自己署名 TLS 証明書を生成します。詳細は、「レジストリーコンソールのトラブルシューティング」を参照してください。
組織の署名済み証明書をシークレットボリュームとして追加する際には、以下の手順に従ってください。ここでは、証明書が oc
クライアントホストで利用可能であることを前提としています。
証明書とキーを含む .cert ファイルを作成します。以下を使用してファイルをフォーマットします。
- サーバー証明書と中間証明機関のための 1 つ以上数の BEGIN CERTIFICATE ブロック。
キーの BEGIN PRIVATE KEY または同種のものを含むブロック。キーは暗号化することができません。
例を以下に示します。
-----BEGIN CERTIFICATE----- MIIDUzCCAjugAwIBAgIJAPXW+CuNYS6QMA0GCSqGSIb3DQEBCwUAMD8xKTAnBgNV BAoMIGI0OGE2NGNkNmMwNTQ1YThhZTgxOTEzZDE5YmJjMmRjMRIwEAYDVQQDDAls ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDUzCCAjugAwIBAgIJAPXW+CuNYS6QMA0GCSqGSIb3DQEBCwUAMD8xKTAnBgNV BAoMIGI0OGE2NGNkNmMwNTQ1YThhZTgxOTEzZDE5YmJjMmRjMRIwEAYDVQQDDAls ... -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCyOJ5garOYw0sm 8TBCDSqQ/H1awGMzDYdB11xuHHsxYS2VepPMzMzryHR137I4dGFLhvdTvJUH8lUS ... -----END PRIVATE KEY-----
セキュリティーの保護されたレジストリーには、以下の SAN (サブジェクトの別名: Subject Alternative Names) 一覧が含まれているはずです。
2 つのサービスのホスト名。
例を以下に示します。
docker-registry.default.svc.cluster.local docker-registry.default.svc
サービス IP アドレス。
例を以下に示します。
172.30.124.220
以下のコマンドを使って Docker レジストリーのサービス IP アドレスを取得します。
oc get service docker-registry --template='{{.spec.clusterIP}}'
パブリックホスト名。
例を以下に示します。
docker-registry-default.apps.example.com
以下のコマンドを使って Docker レジストリーのパブリックホスト名を取得します。
oc get route docker-registry --template '{{.spec.host}}'
たとえば、サーバー証明書には以下のような SAN の詳細が記載されるはずです。
X509v3 Subject Alternative Name: DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98
レジストリーコンソールは、証明書を /etc/cockpit/ws-certs.d ディレクトリーから読み込み、拡張子 .cert が付いたファイルをアルファベット順で (最後から) 使用します。したがって .cert ファイルには、 OpenSSL スタイルでフォーマットされた PEM ブロックが少なくとも 2 つ含まれている必要があります。
証明書がない場合、自己署名証明書が
openssl
コマンドで作成され、0-self-signed.cert ファイルに保存されます。
シークレットを作成します。
$ oc create secret generic console-secret \ --from-file=/path/to/console.cert
このシークレットを registry-console デプロイメント設定に追加します。
$ oc volume dc/registry-console --add --type=secret \ --secret-name=console-secret -m /etc/cockpit/ws-certs.d
これにより、レジストリーコンソールの新規デプロイメントがトリガーされ、署名済み証明書が組み込まれます。
3.2.6.3. レジストリーコンソールのトラブルシューティング
3.2.6.3.1. デバッグモード
レジストリーコンソールのデバッグモードは環境変数を使用して有効にされます。以下のコマンドは、レジストリーコンソールをデバッグモードで再デプロイします。
$ oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper
デバッグモードを有効にすると、より詳細なログがレジストリーコンソールの Pod ログに表示されます。
3.2.6.3.2. SSL 証明書パスの表示
レジストリーコンソールが使用している証明書を確認するには、コマンドをコンソール Pod から実行します。
デフォルト のプロジェクトに Pod を一覧表示して、レジストリーコンソールの Pod 名を検索します。
$ oc get pods -n default NAME READY STATUS RESTARTS AGE registry-console-1-rssrw 1/1 Running 0 1d
直前のコマンドで取得した Pod 名を使って、cockpit-ws プロセスが使用している証明書パスを取得します。以下は、自動生成された証明書を使用しているコンソールの例です。
$ oc exec registry-console-1-rssrw remotectl certificate certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert
3.3. レジストリーへのアクセス
3.3.1. ログの表示
Docker レジストリーのログを表示するには、デプロイメント設定で oc logs
コマンドを使用します。
$ oc logs dc/docker-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
3.3.2. ファイルストレージ
タグとイメージメタデータは OpenShift Container Platform に格納されますが、レジストリーは、レイヤーと署名データを /registry にあるレジストリーコンテナーにマウントされているボリュームに格納します。oc exec
は特権付きコンテナーでは機能しないため、レジストリーの内容を確認するには、レジストリー Pod のコンテナーを格納しているノードに対して SSH を手動で実行し、コンテナー自体で docker exec
を実行します。
現在の Pod を一覧表示し、Docker レジストリーの Pod 名を検索します。
# oc get pods
次に、
oc describe
を使用して、コンテナーを実行しているノードのホスト名を検索します。# oc describe pod <pod_name>
必要なノードにログインします。
#ssh node.example.com
ノードホストのデフォルトプロジェクトから実行中のコンテナーを一覧表示し、Docker レジストリーのコンテナー ID を特定します。
#docker ps --filter = name = registry_docker-registry。* _ default_
oc rsh
コマンドを使用してレジストリーの内容を一覧表示します。# oc rsh dc/docker-registry find /registry /registry/docker /registry/docker/registry /registry/docker/registry/v2 /registry/docker/registry/v2/blobs 1 /registry/docker/registry/v2/blobs/sha256 /registry/docker/registry/v2/blobs/sha256/ed /registry/docker/registry/v2/blobs/sha256/ed/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810 /registry/docker/registry/v2/blobs/sha256/ed/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810/data 2 /registry/docker/registry/v2/blobs/sha256/a3 /registry/docker/registry/v2/blobs/sha256/a3/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4 /registry/docker/registry/v2/blobs/sha256/a3/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4/data /registry/docker/registry/v2/blobs/sha256/f7 /registry/docker/registry/v2/blobs/sha256/f7/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845 /registry/docker/registry/v2/blobs/sha256/f7/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845/data /registry/docker/registry/v2/repositories 3 /registry/docker/registry/v2/repositories/p1 /registry/docker/registry/v2/repositories/p1/pause 4 /registry/docker/registry/v2/repositories/p1/pause/_manifests /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256 /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures 5 /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256 /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810 /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810/link 6 /registry/docker/registry/v2/repositories/p1/pause/_uploads 7 /registry/docker/registry/v2/repositories/p1/pause/_layers 8 /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256 /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4 /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4/link 9 /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845 /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845/link
- 1
- このディレクトリーには、すべてのレイヤーと署名が Blob として格納されます。
- 2
- このファイルには、Blob の内容が含まれます。
- 3
- このディレクトリーには、すべてのイメージリポジトリーが格納されます。
- 4
- このディレクトリーは単一イメージリポジトリーの p1/pause 用です。
- 5
- このディレクトリーには、特定のイメージマニフェストリビジョンの署名が含まれます。
- 6
- このファイルには、Blob (署名データを含む) への参照が含まれます。
- 7
- このディレクトリーには、指定されたリポジトリーに対して現在アップロードされステージングされているすべてのレイヤーが含まれます。
- 8
- このディレクトリーには、このリポジトリーが参照するすべてのレイヤーへのリンクが含まれます。
- 9
- このファイルには、イメージを介してこのリポジトリーにリンクされている特定のレイヤーへの参照が含まれます。
3.3.3. レジストリーへの直接アクセス
さらに高度な使用方法として、レジストリーに直接アクセスし、docker
コマンドを起動することが可能です。これにより、docker push
や docker pull
などの操作で直接イメージをプッシュするか、または統合レジストリーからイメージをプルすることができます。これを実行するには、docker login
コマンドを使ってレジストリーにログインしている必要があります。実行できる操作は、以下のセクションで説明されているようにユーザーが持つ権限によって異なります。
3.3.3.1. ユーザーの前提条件
レジストリーに直接アクセスするには、使用するユーザーが、使用目的に応じて以下の前提条件を満たしている必要があります。
直接アクセスするには、ユーザーは選択するアイデンティティープロバイダーの通常ユーザーである必要があります。通常ユーザーは、レジストリーへのログインに必要なアクセストークンを生成できます。system:admin などのシステムユーザーはアクセストークンを取得できないため、レジストリーに直接アクセスすることはできません。
たとえば
HTPASSWD
認証を使用している場合は、以下のコマンドを使用してこれを作成することができます。# htpasswd /etc/origin/openshift-htpasswd <user_name>
docker pull
コマンドを使用する場合などにイメージをプルするには、ユーザーに registry-viewer ロールがなければなりません。このロールを追加するには、以下を実行します。$ oc policy add-role-to-user registry-viewer <user_name>
イメージの書き出しやプッシュを実行するには (
docker push
コマンドを使用する場合など)、ユーザーに registry-editor ロールが必要です。このロールを追加するには、以下を実行します。$ oc policy add-role-to-user registry-editor <user_name>
ユーザーパーミッションに関する詳細は、「ロールバインディングの管理」を参照してください。
3.3.3.2. レジストリーへのログイン
ユーザーが、レジストリーに直接アクセスできるための前提条件を満たしていることを確認してください。
レジストリーに直接ログインするには、以下を実行します。
OpenShift Container Platform に通常ユーザーとしてログインしていることを確認します。
$ oc login
アクセストークンを使用して Docker レジストリーにログインします。
docker login -u openshift -p $(oc whoami -t) <registry_ip>:<port>
ユーザー名の任意の値を渡すことができ、トークンには必要な情報がすべて含まれます。コロンを含むユーザー名を渡すとログインに失敗します。
3.3.3.3. イメージのプッシュとプル
レジストリーにログインすると、レジストリーに docker pull
および docker push
操作を実行できます。
任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。
以下の例では、以下を使用します。
コンポーネント |
値 |
<registry_ip> |
|
<port> |
|
<project> |
|
<image> |
|
<tag> |
省略 (デフォルトは |
任意のイメージをプルします。
$ docker pull docker.io/busybox
新規イメージに
<registry_ip>:<port>/<project>/<image>
形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするには OpenShift Container Platform のプル仕様に必ず表示されている必要があります。$ dockerタグdocker.io/busybox 172.30.124.220:5000/openshift/busybox
注記通常ユーザーには、指定されたプロジェクトの system:image-builder ロールが必要です。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。このロールが設定されていない場合には以下の手順の
docker push
が失敗します。新規プロジェクトを作成して busybox イメージをプッシュしてみることができます。新しくタグ付けされたイメージをレジストリーにプッシュします。
$ docker push 172.30.124.220:5000/openshift/busybox ... cf2616975b4a: Image successfully pushed Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55
3.3.4. レジストリーメトリクスへのアクセス
OpenShift Container レジストリーは、Prometheus メトリクス のエンドポイントを提供します。Prometheus はスタンドアロンのオープンソースシステムのモニタリングおよびアラートツールキットです。
メトリクスはレジストリーのエンドポイントの /extensions/v2/metrics パスに公開されます。ただし、このルートは最初に有効にされている必要があります。有効化の方法については、「レジストリー設定の拡張」を参照してください。
以下は、メトリクスクエリーの簡単な例です。
$ curl -s -u <user>:<secret> \ 1
http://172.30.30.30:5000/extensions/v2/metrics | grep openshift | head -n 10
# HELP openshift_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which OpenShift was built.
# TYPE openshift_build_info gauge
openshift_build_info{gitCommit="67275e1",gitVersion="v3.6.0-alpha.1+67275e1-803",major="3",minor="6+"} 1
# HELP openshift_registry_request_duration_seconds Request latency summary in microseconds for each operation
# TYPE openshift_registry_request_duration_seconds summary
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.5"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.9"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.99"} 0
openshift_registry_request_duration_seconds_sum{name="test/origin-pod",operation="blobstore.create"} 0
openshift_registry_request_duration_seconds_count{name="test/origin-pod",operation="blobstore.create"} 5
高度なクエリーと推奨されるビジュアライザーについては、アップストリームの Prometheus ドキュメントを参照してください。
3.4. レジストリーのセキュリティー保護および公開
3.4.1. 概要
デフォルトでは、OpenShift Container Platform レジストリーは、TLS 経由でトラフィックを提供できるようクラスターのインストール時にセキュリティー保護されます。サービスを外部に公開するために、パススルールートもデフォルトで作成されます。
何らかの理由でレジストリーが保護されていないか、または公開されていない場合は、これらを手動で実行する方法について以下のセクションを参照してください。
3.4.2. レジストリーを手動でセキュリティー保護する
レジストリーを手動でセキュリティー保護して TLS 経由でトラフィックを処理するには、以下を実行します。
- レジストリーをデプロイします。
レジストリーのサービス IP とポートを取得します。
$ oc get svc/docker-registry NAME LABELS SELECTOR IP(S) PORT(S) docker-registry docker-registry=default docker-registry=default 172.30.124.220 5000/TCP
既存のサーバー証明書を使用するか、またはキーと、指定された CA で署名された指定 IP およびホスト名に有効なサーバー証明書を作成します。レジストリーのサービス IP と docker-registry.default.svc.cluster.local ホスト名のサーバー証明書を作成するには、Ansible ホストインベントリーファイル (デフォルトでは /etc/ansible/hosts) に一覧表示されている最初のマスターから以下のコマンドを実行します。
$ oc adm ca create-server-cert \ --signer-cert=/etc/origin/master/ca.crt \ --signer-key=/etc/origin/master/ca.key \ --signer-serial=/etc/origin/master/ca.serial.txt \ --hostnames='docker-registry.default.svc.cluster.local,docker-registry.default.svc,172.30.124.220' \ --cert=/etc/secrets/registry.crt \ --key=/etc/secrets/registry.key
ルーターを外部に公開する場合、公開ルートのホスト名を
--hostnames
フラグに追加します。--hostnames='mydocker-registry.example.com,docker-registry.default.svc.cluster.local,172.30.124.220 \
ルートを外部にアクセス可能にするためにデフォルトの証明書を更新する際のその他詳細については、「レジストリーとルーター証明書の再デプロイ」を参照してください。
注記oc adm ca create-server-cert
コマンドは、2 年間有効な証明書を生成します。この期間は--expire-days
オプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。レジストリー証明書のシークレットを作成します。
$ oc create secret generic registry-certificates \ --from-file=/etc/secrets/registry.crt \ --from-file=/etc/secrets/registry.key
シークレットをレジストリー Pod のサービスアカウント (デフォルトのサービスアカウントなど) に追加します。
$ oc secrets link registry registry-certificates $ oc secrets link default registry-certificates
注記シークレットをそれを参照しているサービスアカウントのみに制限することは、デフォルトで無効にされています。つまり、マスターの設定ファイルで
serviceAccountConfig.limitSecretReferences
がfalse
(デフォルトの設定) に設定されている場合、シークレットをサービスにリンクさせる必要はありません。docker-registry
サービスを一時停止します。$ oc rollout pause dc / docker-registry
シークレットボリュームをレジストリーのデプロイメント設定に追加します。
$ oc volume dc/docker-registry --add --type=secret \ --secret-name=registry-certificates -m /etc/secrets
以下の環境変数をレジストリーのデプロイメント設定に追加して TLS を有効にします。
$ oc set env dc/docker-registry \ REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt \ REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.key
詳細は、「Docker ドキュメントのレジストリーの設定」セクションを参照してください。
レジストリーの liveness probe に使用されているスキームを HTTP から HTTPS に更新します。
$ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{ "name":"registry", "livenessProbe": {"httpGet": {"scheme":"HTTPS"}} }]}}}}'
レジストリーを OpenShift Container Platform 3.2 以降に初めてデプロイした場合は、レジストリーの readiness probe として使用されているスキームを HTTP から HTTPS に更新します。
$ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{ "name":"registry", "readinessProbe": {"httpGet": {"scheme":"HTTPS"}} }]}}}}'
docker-registry
サービスを再開します。$ oc rollout dc / docker-registryを再開する
レジストリーが TLS モードで実行されていることを検証します。最後の docker-registry のデプロイメントが完了するまで待機し、Docker ログでレジストリーコンテナーを確認します。
listening on :5000, tls
のエントリーが見つかるはずです。$ oc logs dc/docker-registry | grep tls time="2015-05-27T05:05:53Z" level=info msg="listening on :5000, tls" instance.id=deeba528-c478-41f5-b751-dc48e4935fc2
CA 証明書を Docker 証明書ディレクトリーにコピーします。これはクラスター内のすべてのノードで実行する必要があります。
$ dcertsdir=/etc/docker/certs.d $ destdir_addr=$dcertsdir/172.30.124.220:5000 $ destdir_name=$dcertsdir/docker-registry.default.svc.cluster.local:5000 $ sudo mkdir -p $destdir_addr $destdir_name $ sudo cp ca.crt $destdir_addr 1 $ sudo cp ca.crt $destdir_name
- 1
- ca.crt ファイルは、マスター上の /etc/origin/master/ca.crt のコピーです。
認証を使用している場合、
docker
のバージョンによっては、OS レベルで証明書を信頼するようにクラスターを設定することも必要になります。証明書をコピーします。
$ cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crt
以下を実行します。
$ update-ca-trust enable
/etc/sysconfig/docker ファイルのこの特定のレジストリーに対してのみ、
--insecure-registry
オプションを削除します。次にデーモンを再度読み込み、 docker サービスを再起動して設定の変更を反映させます。$ sudo systemctl daemon-reload $ sudo systemctl restart docker
docker
クライアント接続を検証します。レジストリーに対するdocker push
、またはレジストリーからのdocker pull
が正常に実行されるはずです。必ずこのレジストリーにログインしていることを確認してください。$ docker tag|push <registry/image> <internal_registry/project/image>
例を以下に示します。
$ docker pull busybox $ docker tag docker.io/busybox 172.30.124.220:5000/openshift/busybox $ docker push 172.30.124.220:5000/openshift/busybox ... cf2616975b4a: Image successfully pushed Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55
3.4.3. セキュアなレジストリーの手動による公開
OpenShift Container Platform レジストリーに OpenShift Container Platform クラスター内からログインする代わりに、最初にレジストリーのセキュリティーを保護し、それをルートで公開しておくことによって、これに外部からアクセスすることも可能です。この方法を使うと、ルートアドレスを使ってクラスターの外部からレジストリーにログインし、ルートのホストを使ってイメージにタグ付けしたり、イメージをプッシュしたりできます。
以下の前提条件に関するそれぞれの手順は、標準的なクラスターのインストール時にデフォルトで実行されます。これが実行されていない場合は、手動で実行してください。
パススルールートは、クラスターの初回インストール時にこのレジストリーについてデフォルトで作成されている必要があります。
ルートが存在するかどうかを確認します。
$ oc get route/docker-registry -o yaml apiVersion: v1 kind: Route metadata: name: docker-registry spec: host: <host> 1 to: kind: Service name: docker-registry 2 tls: termination: passthrough 3
注記Re-encrypt ルートはセキュアなレジストリーを公開するためにもサポートされています。
ルートが存在していない場合、
oc create route passthrough
コマンドで、レジストリーをルートのサービスとして指定してルートを作成します。デフォルトでは、作成したルートの名前はサービス名と同じです。docker-registry サービスの詳細を取得します。
$ oc get svc NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE docker-registry 172.30.69.167 <none> 5000/TCP docker-registry=default 4h kubernetes 172.30.0.1 <none> 443/TCP,53/UDP,53/TCP <none> 4h router 172.30.172.132 <none> 80/TCP router=router 4h
ルートを作成します。
$ oc create route passthrough \ --service=docker-registry \1 --hostname=<host> route "docker-registry" created 2
次に、ホストシステム上のレジストリーに使用されている証明書を信頼し、ホストによるイメージのプッシュおよびプルを許可する必要があります。参照される証明書は、レジストリーのセキュリティー保護を実行したときに作成されたものです。
$ sudo mkdir -p /etc/docker/certs.d/<host> $ sudo cp <ca_certificate_file> /etc/docker/certs.d/<host> $ sudo systemctl restart docker
レジストリーのセキュリティー保護の実行時に得られた情報を使ってレジストリーにログインします。ただし、ここではサービス IP ではなくルートで使用されているホスト名を指定します。セキュリティーが保護され、公開されているレジストリーにログインする際は、必ず
docker login
コマンドのレジストリーを指定してください。# docker login -e user@company.com \ -u f83j5h6 \ -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \ <host>
これでルートのホストを使ってイメージのタグ付けとプッシュを実行できます。たとえば、
test
という名前のプロジェクトにあるbusybox
イメージをタグ付けし、プッシュするには、以下を実行します。$ oc get imagestreams -n test NAME DOCKER REPO TAGS UPDATED $ docker pull busybox $ docker tag busybox <host>/test/busybox $ docker push <host>/test/busybox The push refers to a repository [<host>/test/busybox] (len: 1) 8c2e06607696: Image already exists 6ce2e90b0bc7: Image successfully pushed cf2616975b4a: Image successfully pushed Digest: sha256:6c7e676d76921031532d7d9c0394d0da7c2906f4cb4c049904c4031147d8ca31 $ docker pull <host>/test/busybox latest: Pulling from <host>/test/busybox cf2616975b4a: Already exists 6ce2e90b0bc7: Already exists 8c2e06607696: Already exists Digest: sha256:6c7e676d76921031532d7d9c0394d0da7c2906f4cb4c049904c4031147d8ca31 Status: Image is up to date for <host>/test/busybox:latest $ oc get imagestreams -n test NAME DOCKER REPO TAGS UPDATED busybox 172.30.11.215:5000/test/busybox latest 2 seconds ago
注記イメージストリームにはルート名とポートではなく、レジストリーサービスの IP アドレスとポートが設定されます。詳細は
oc get imagestreams
を参照してください。
3.4.4. 非セキュアなレジストリーを手動で公開する
レジストリーのセキュリティーを確保してレジストリーを公開する代わりに、OpenShift Container Platform の非稼働環境に、セキュアでないレジストリーを簡単に公開できます。これにより、SSL 証明書を使用せずにレジストリーへの外部ルートを作成することができます。
非実稼働環境以外では、非セキュアなレジストリーを外部アクセスに公開すべきではありません。
非セキュアなレジストリーを公開するには、以下を実行します。
レジストリーを公開します。
# oc expose service docker-registry --hostname=<hostname> -n default
以下の JSON ファイルが作成されます。
apiVersion: v1 kind: Route metadata: creationTimestamp: null labels: docker-registry: default name: docker-registry spec: host: registry.example.com port: targetPort: "5000" to: kind: Service name: docker-registry status: {}
ルートが正常に作成されたことを確認します。
# oc get route NAME HOST/PORT PATH SERVICE LABELS INSECURE POLICY TLS TERMINATION docker-registry registry.example.com docker-registry docker-registry=default
レジストリーの健全性を確認します。
$ curl -v http://registry.example.com/healthz
HTTP 200 / OK メッセージが表示されるはずです。
レジストリーを公開したら、ポート番号を
OPTIONS
エントリーに追加して /etc/sysconfig/docker ファイルを更新します。以下は例になります。OPTIONS='--selinux-enabled --insecure-registry=172.30.0.0/16 --insecure-registry registry.example.com:80'
重要上記のオプションは、ログインしようとしているクライアントに追加してください。
また、Docker がクライアント上で実行されていることも確認してください。
公開されている非セキュアなレジストリーにログインする際に、docker login
コマンドでレジストリーを指定していることを確認します。以下は例になります。
# docker login -e user@company.com \ -u f83j5h6 \ -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \ <host>
3.5. レジストリー設定の拡張
3.5.1. レジストリー IP アドレスの維持
OpenShift Container Platform はサービス IP アドレスによって統合レジストリーを参照します。したがって docker-registry サービスを削除し、再作成しようとする場合、古い IP アドレスを新しいサービスで再利用するように調整すると、完全に透過的な移行が可能になります。新規 IP アドレスを取得することが避けられない場合は、マスターのみを再起動してクラスターの中断を最小限に抑えられます。
- アドレスの再利用
- IP アドレスを再利用するには、古い docker-registry サービスの IP アドレスを削除する前に保存し、新たに割り当てられた IP アドレスを、新しい docker-registry サービスに保存されているアドレスに置き換えるように調整します。
サービスの
clusterIP
を書き留めておきます。$ oc get svc/docker-registry -o yaml | grep clusterIP:
サービスを削除します。
$ oc delete svc / docker-registry dc / docker-registry
レジストリーの定義を registry.yaml に作成し、
<options>
を、たとえば「非実稼働環境での使用」のセクションの手順 3 で使用されているものなどに置き換えます。$ oc adm registry <options> -o yaml > registry.yaml
-
registry.yaml を編集し、そこで
Service
を検索して、clusterIP
を手順 1 で書き留めたアドレスに変更します。 変更した registry.yaml を使ってレジストリーを作成します。
$ oc create -f registry.yaml
- マスターの再起動
IP アドレスを再利用できない場合、古い IP アドレスを含むプル仕様を使った操作は失敗します。クラスターの中断を最小限に抑えるには、マスターを再起動する必要があります。
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
これで、古い IP アドレスを含む古いレジストリー URL がキャッシュからクリアされます。
注記クラスター全体を再起動すると、Pod に不要なダウンタイムが発生し、実質、キャッシュのクリアが行われないので、これは推奨していません。
3.5.2. Docker レジストリーのホワイトリスト化
Docker レジストリーのホワイトリストを指定すると、OpenShift Container Platform ユーザーがダウンロードして入手できるイメージやテンプレートのセットをキュレートできます。このキュレートされたセットは、1 つまたは複数の Docker レジストリーに保管され、その後ホワイトリストに追加されます。ホワイトリストを使用する場合、OpenShift Container Platform からアクセスできるのは指定されたレジストリーのみで、その他すべてのレジストリーはデフォルトでアクセスが拒否されます。
ホワイトリストを設定するには、以下を実行します。
/etc/sysconfig/docker ファイルを編集し、すべてのレジストリーをブロックします。
BLOCK_REGISTRY = ' - ブロックレジストリ=すべて'
BLOCK_REGISTRY
行のコメント解除が必要となる場合があります。同じファイルで、アクセスを許可するレジストリーを追加します。
ADD_REGISTRY='--add-registry=<registry1> --add-registry=<registry2>'
レジストリーへのアクセスの許可
ADD_REGISTRY = ' - add-registry = registry.access.redhat.com'
上記の例では、Red Hat カスタマーポータルで入手できるイメージへのアクセスを制限しています。
ホワイトリストが設定されると、ホワイトリストにない Docker レジストリーからプルしようとすると、許可されていないレジストリーであることを示すエラーメッセージが表示されます。
3.5.3. レジストリーのホスト名の設定
内部参照と外部参照の両方でレジストリが認識されるホスト名とポートを構成できます。これにより、イメージストリームは画像のホスト名ベースのプッシュ/プル仕様を提供し、イメージのコンシューマはレジストリサービスのIPからの変更から隔離され、イメージストリームとその参照がクラスタ間で移植可能になる可能性があります。
クラスター内でレジストリーを参照するために使用されるホスト名を設定するには、マスター設定ファイルの imagePolicyConfig
セクションで internalRegistryHostname
を設定します。外部のホスト名は、同じ場所で externalRegistryHostname
の値を設定することで管理されます。
イメージポリシーの設定
imagePolicyConfig: internalRegistryHostname: docker-registry.default.svc.cluster.local:5000 externalRegistryHostname: docker-registry.mycompany.com
レジストリー自体は、同じ内部ホスト名の値で設定する必要があります。これは、レジストリーのデプロイメント設定で REGISTRY_OPENSHIFT_SERVER_ADDR
環境変数を設定するか、またはレジストリー設定の OpenShift セクションで値を設定することで実行できます。
レジストリーで TLS を有効にしている場合、サーバー証明書にはレジストリーの参照に使用されるホスト名が含まれている必要があります。ホスト名をサーバー証明書に追加する方法については、「レジストリーのセキュリティー保護」を参照してください。
3.5.4. レジストリー設定の上書き
統合レジストリーのデフォルトの設定 (デフォルトでは実行中のレジストリーコンテナーの /config.yml にあります) は、独自の カスタム設定で上書きできます。
このファイルのアップストリームの設定オプションも環境変数を使って上書きできます。ミドルウェアのセクションは、環境変数を使って上書きできるオプションがごく少数であるため例外とします。特定の設定オプションを上書きする方法についてこちらを参照してください。
レジストリー設定ファイルの直接的な管理を可能にし、ConfigMap
を使って更新された設定をデプロイするには、以下を実行します。
- レジストリーをデプロイします。
必要に応じて、レジストリー設定ファイルをローカルで編集します。以下は、レジストリーにデプロイされている初期 YAML ファイルです。サポートされているオプションを確認してください。
レジストリー設定ファイル
version: 0.1 log: level: debug http: addr: :5000 storage: cache: blobdescriptor: inmemory filesystem: rootdirectory: /registry delete: enabled: true auth: openshift: realm: openshift middleware: registry: - name: openshift repository: - name: openshift options: acceptschema2: true pullthrough: true enforcequota: false projectcachettl: 1m blobrepositorycachettl: 10m storage: - name: openshift openshift: version: 1.0 metrics: enabled: false secret: <secret>
各ファイルの内容を保持する
ConfigMap
をこのディレクトリーに作成します。$ oc create configmap registry-config \ --from-file=</path/to/custom/registry/config.yml>/
registry-config ConfigMap をボリュームとしてレジストリーのデプロイメント設定に追加し、カスタム設定ファイルを /etc/docker/registry/ にマウントします。
$ oc volume dc/docker-registry --add --type=configmap \ --configmap-name=registry-config -m /etc/docker/registry/
以下の環境変数をレジストリーのデプロイメント設定に追加して、直前の手順の設定パスを参照するようにレジストリーを更新します。
$ oc set env dc/docker-registry \ REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.yml
上記の手順は、必要な設定を行えるように繰り返し実行される場合があります。たとえば、トラブルシューティング時に、デバッグ モードに切り換えるよう設定が一時的に更新される場合があります。
既存の設定を更新するには、以下を実行します。
この手順を実行すると、現在デプロイされているレジストリー設定が上書きされます。
- ローカルのレジストリー設定ファイル config.yml を編集します。
registry-config configmap を削除します。
$ oc delete configmap registry-config
更新された設定ファイルを参照するよう configmap を再作成します。
$ oc create configmap registry-config\ --from-file=</path/to/custom/registry/config.yml>/
更新された設定を読み取るためにレジストリーを再デプロイします。
$ oc rollout latest docker-registry
設定ファイルをソース管理リポジトリーに保持します。
3.5.5. レジストリー設定の参照
アップストリームの docker ディストリビューションライブラリーでは、多数の設定オプションを利用できます。ただし、すべての設定オプションがサポートされているか、または有効にされているわけではありません。このセクションは、レジストリー設定を上書きする際の参考としてご利用ください。
このファイルのアップストリームの設定オプションも環境変数を使って上書きできます。ただし、ミドルウェアのセクションは、環境変数を使って上書きすることはできません。特定の設定オプションを上書きする方法についてこちらを参照してください。
3.5.5.1. ログ
アップストリームのオプションはサポートされています。
例:
log: level: debug formatter: text fields: service: registry environment: staging
3.5.5.2. フック
メールフックはサポートされていません。
3.5.5.3. ストレージ
以下のセクションでは、サポートされているレジストリーのストレージドライバーの一覧を示しています。詳細は、Docker レジストリーのドキュメントを参照してください。
次の一覧には、レジストリの構成ファイルで構成する必要があるストレージドライバが含まれています。
- ファイルシステム。ファイルシステムはデフォルトですので、設定の必要はありません。
- S3。詳細は、CloudFront の設定のドキュメントを参照してください。
- OpenStack Swift
- Google Cloud Storage (GCS)
- Microsoft Azure
- Aliyun OSS
レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。
以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。
サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。
一般的なストレージ構成オプション
storage:
delete:
enabled: true 1
redirect:
disable: false
cache:
blobdescriptor: inmemory
maintenance:
uploadpurging:
enabled: true
age: 168h
interval: 24h
dryrun: false
readonly:
enabled: false
- 1
- このエントリーは、イメージのプルーニングが正常に機能するために必須です。
3.5.5.4. 認証
認証オプションは変更することができません。openshift の拡張がサポートされている唯一のオプションです。
auth: openshift: realm: openshift
3.5.5.5. ミドルウェア
リポジトリーのミドルウェアの拡張を使用して、OpenShift Container Platform やイメージプロキシーとの対話を行う OpenShift Container Platform ミドルウェアの設定を行うことができます。
middleware: registry: - name: openshift 1 repository: - name: openshift 2 options: acceptschema2: true 3 pullthrough: true 4 mirrorpullthrough: true 5 enforcequota: false 6 projectcachettl: 1m 7 blobrepositorycachettl: 10m 8 storage: - name: openshift 9
- 1 2 9
- これらの入力は必須です。これらの入力によって必要なコンポーネントが読み込まれていることを確認できます。これらの値は変更しないでください。
- 3
- レジストリーへのプッシュ時に manifest schema v2 を格納できます。詳細は、こちらを参照してください。
- 4
- レジストリーがリモート Blob のプロキシーとして機能できるようにします。詳細は、 こちらを参照してください。
- 5
- レジストリーキャッシュの Blob がリモートレジストリーから提供されるようにし、その後の迅速なアクセスを可能にします。Blob の初回アクセス時にミラーリングが開始されます。このオプションは、プルスルーが無効にされている場合は機能しません。
- 6
- ターゲットに設定されているプロジェクトで定義されているサイズ制限を超える Blob のアップロードを防止します。
- 7
- レジストリーにキャッシュされている制限の有効期限のタイムアウト。値が小さいほど、制限の変更がレジストリーに伝播するまでの時間が短くなります。ただし、レジストリーは制限をサーバーからより頻繁に照会するため、結果としてプッシュは遅くなります。
- 8
- Blob とリポジトリー間の記憶されている関連付けの有効期限のタイムアウト。値が高いほどルックアップが高速になり、レジストリー操作がより効率的になる可能性が高くなります。一方、アクセスできなくなったユーザーにイメージレイヤーを提供するリスクと同様にメモリー使用量も上昇します。
3.5.5.5.1. CloudFront ミドルウェア
CloudFront ミドルウェア拡張は、CloudFront CDN ストレージプロバイダーである AWS をサポートするために追加することができます。CloudFront ミドルウェアは、イメージコンテンツの海外への配信を高速化します。Blob は世界中の複数のエッジロケーションに配信されます。クライアントは常に最小の待機時間でエッジにアクセスできます。
CloudFront ミドルウェア拡張を使用できるストレージは S3 ストレージのみです。また、使用できるのは Blob が提供されている間のみです。したがって、高速化できるのは Blob のダウンロードのみで、アップロードは高速化しません。
以下は、CloudFront ミドルウェアを含む S3 ストレージドライバーの最小限の設定例です。
version: 0.1 log: level: debug http: addr: :5000 storage: cache: blobdescriptor: inmemory delete: enabled: true s3: 1 accesskey: BJKMSZBRESWJQXRWMAEQ secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS region: us-east-1 bucket: docker.myregistry.com auth: openshift: realm: openshift middleware: registry: - name: openshift repository: - name: openshift storage: - name: cloudfront 2 options: baseurl: https://jrpbyn0k5k88bi.cloudfront.net/ 3 privatekey: /etc/docker/cloudfront-ABCEDFGHIJKLMNOPQRST.pem 4 keypairid: ABCEDFGHIJKLMNOPQRST 5 - name: openshift
- 1
- S3 ストレージは、CloudFront ミドルウェアに関係なく同じ方法で設定する必要があります。
- 2
- CloudFront ストレージミドルウェアは、OpenShift ミドルウェアより前に一覧表示される必要があります。
- 3
- CloudFront ベースの URL。AWS マネジメントコンソールでは、これは CloudFront ディストリビューションの Domain Name として一覧表示されます。
- 4
- AWS のプライベートキーが格納されているファイルシステムの場所。Amazon EC2 のキーペアと混同しないよう注意してください。信頼される署名者の CloudFront キーペアの作成については、AWS ドキュメントを参照してください。このファイルは、レジストリー Pod にシークレットとしてマウントする必要があります。
- 5
- CloudfrontキーペアのID。
3.5.5.5.2. ミドルウェア設定オプションの上書き
middleware セクションは、環境変数を使って上書きできません。ただし例外がいくつかあります。以下は例になります。
middleware: repository: - name: openshift options: acceptschema2: true 1 pullthrough: true 2 mirrorpullthrough: true 3 enforcequota: false 4 projectcachettl: 1m 5 blobrepositorycachettl: 10m 6
- 1
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ACCEPTSCHEMA2
で上書きできる設定オプション。manifest schema v2 をマニフェストの Put 要求で 受け入れる機能を有効にします。認識される値はtrue
とfalse
(以下の他のすべてのブール変数に適用されます) になります。 - 2
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PULLTHROUGH
で上書きできる設定オプション。リモートレジストリーのプロキシーモードを有効にします。 - 3
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_MIRRORPULLTHROUGH
で上書きできる設定オプション。リモート Blob が提供されている場合、レジストリーに対して Blob をローカルにミラーリングするように指示します。 - 4
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA
で上書きできる設定オプション。クォータ実施をオンまたはオフにする機能を有効にします。デフォルトでは、クォータの実施はオフになっています。 - 5
- 環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PROJECTCACHETTL
で上書きできる設定オプション。プロジェクトのクォータオブジェクトのエビクションタイムアウトを指定します。有効な時間文字列 (例:2m
) を取ります。空白の場合は、デフォルトのタイムアウトが取得されます。ゼロ (0m
) の場合、キャッシングは無効にされます。 - 6
- 環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_BLOBREPOSITORYCACHETTL
で上書きできる設定オプション。Blob と含まれているレポジトリーの関連付けについてのエビクションタイムアウトを指定します。値のフォーマットはprojectcachettl
のケースと同じです。
3.5.5.5.3. イメージのプルスルー
この機能を有効にすると、Blob がローカルに存在しない限り、レジストリーは要求された Blob をリモートレジストリーから取得しようと試みます。リモートの候補は、クライアントがプルする イメージストリームの状態で保存された DockerImage エントリーから算出されます。このエントリーのすべての固有のリモートレジストリーの参照は Blob が見つかるまで繰り返し試行されます。
プルスルーは、プルされているイメージのイメージストリームタグが存在する場合にのみ発生します。たとえば、プルされているイメージが docker-registry.default.svc:5000/yourproject/yourimage:prod
である場合、レジストリーは、プロジェクト yourproject
で yourimage:prod
という名前のイメージストリームタグを検索します。タグが見つかると、レジストリーはそのイメージストリームタグに関連付けられた dockerImageReference
を使ってイメージのプルを試行します。
プルスルーを実行すると、レジストリーは、参照されているイメージストリームタグに関連付けられたプロジェクトにあるプル認証情報を使用します。また、この機能を使用すると、ユーザーは、イメージを参照しているイメージストリームタグにアクセスできる限り、アクセスに必要な認証情報を持たないレジストリーのイメージをプルすることができます。
使用しているレジストリーに、プルスルーの実行対象である外部レジストリーを信頼するのに必要な証明書があることを確認してください。証明書は Pod の /etc/pki/tls/certs ディレクトリーに配置する必要があります。証明書は設定マップまたはシークレットを使ってマウントできます。ここで、/etc/pki/tls/certs ディレクトリー全体を置き換える必要があることに注意してください。新しい証明書を組み込み、マウントするシークレットまたは設定マップのシステム証明書を置き換えます。
デフォルトでは、イメージストリームタグは Source
の参照ポリシータイプを使用することに注意してください。これは、イメージストリームの参照がイメージのプル仕様に対して解決される場合、使用される仕様はイメージのソースを参照することを意味します。外部レジストリーでホストされているイメージであれば、外部レジストリーが参照され、この結果としてリソースは外部レジストリーでイメージを参照し、プルします。この場合、registry.access.redhat.com/openshift3/jenkins-2-rhel7
とプルスルーは適用されません。イメージストリームを参照しているリソースが内部レジストリーを参照しているプル仕様を使用するようにするには、イメージストリームタグは Local
の参照ポリシータイプを使用する必要があります。詳細は、「参照ポリシー」を参照してください。
この機能はデフォルトでオンになっています。ただし、設定オプションを使って無効にすることができます。
デフォルトでは、この方法で提供されるすべてのリモート Blob は、mirrorpullthrough
が無効にされていない限りローカルに格納され、その後のアクセスが高速になります。ミラーリング機能の欠点はストレージの使用量が増えることにあります。
ミラーリングは、クライアントがBLOBの少なくとも1バイトをフェッチしようとすると開始されます。実際に必要となる前に特定のイメージを統合レジストリにプリフェッチするには、次のコマンドを実行します。
$ oc get imagestreamtag/${IS}:${TAG} -o jsonpath='{ .image.dockerImageLayers[*].name }' | \ xargs -n1 -I {} curl -H "Range: bytes=0-1" -u user:${TOKEN} \ http://${REGISTRY_IP}:${PORT}/v2/default/mysql/blobs/{}
OpenShift Container Platform のミラーリング機能をアップストリームの レジストリーのプルスルーキャッシュ機能と混同しないようにしてください。これらは似ていますが、全く異なる機能です。
3.5.5.5.4. Manifest Schema v2 サポート
各イメージには、Blob を記述するマニフェスト、それを実行するための命令、および追加のメタデータがあります。マニフェストはバージョン管理されており、バージョンごとに構造やフィールドが異なります。同一イメージが複数のマニフェストバージョンで表現されます。それぞれのバージョンはそれぞれ異なるダイジェストがあります。
現在サポートされているレジストリーは manifest v2 schema 1 (schema1) と manifest v2 schema 2 (schema2) です。前者は古くなっていますが、今後もしばらくはサポートされます。
各種の Docker クライアントとの互換性の問題に注意する必要があります。
- Docker クライアントのバージョン 1.9 以前は、schema1 のみをサポートしています。このクライアントがプルまたはプッシュするマニフェストはレガシースキーマになります。
- Docker クライアントのバージョン 1.10 は、schema1 と schema2 の両方をサポートしています。デフォルトでは、新しい方のスキーマをサポートする場合はこちらをレジストリーにプッシュします。
イメージを schema1 で格納するレジストリーは、常にイメージを変更せずにクライアントに返します。Schema2 は新規の Docker クライアントにのみ変更しない状態で移動します。古いクライアントの場合は、オンザフライで schema1 に変換されます。
これにより、大きな影響が想定されます。たとえば、新規 Docker クライアントでレジストリーにプッシュされたイメージは、古い Docker のダイジェストでプルすることはできません。格納されたイメージのマニフェストは schema2 であり、そのダイジェストはこのバージョンのマニフェストをプルする場合にのみ使用できるためです。
このため、レジストリーはデフォルトでは schema2 を格納しないように設定されています。これにより、すべての Docker クライアントはクライアントのバージョンに関係なく、プッシュされたイメージをレジストリーからプルできます。
すべてのレジストリークライアントが schema2 をサポートしていることを確認できたら、そのサポートをレジストリーで有効にすることができます。特定のオプションについては、上記の「ミドルウェア設定の参照」を参照してください。
3.5.5.6. OpenShift
このセクションでは、OpenShift Container Platform に特有の機能のグローバル設定について説明します。今後のリリースでは、 Middleware セクションにある openshift
関連の設定は廃止される予定です。
現在、このセクションではレジストリーメトリクスの収集を設定できます。
openshift: version: 1.0 1 server: addr: docker-registry.default.svc 2 metrics: enabled: false 3 secret: <secret> 4 requests: read: maxrunning: 10 5 maxinqueue: 10 6 maxwaitinqueue 2m 7 write: maxrunning: 10 8 maxinqueue: 10 9 maxwaitinqueue 2m 10
- 1
- このセクションの設定バージョンを指定する必須エントリー。サポートされている値は
1.0
のみです。 - 2
- レジストリーのホスト名。マスターで設定されている値と同じ値に設定される必要があります。これは環境変数
REGISTRY_OPENSHIFT_SERVER_ADDR
で上書きされる可能性があります。 - 3
- メトリクスの収集を有効にするには
true
に設定します。これはブール環境変数REGISTRY_OPENSHIFT_METRICS_ENABLED
で上書きされる可能性があります。 - 4
- クライアント要求の承認に使用されるシークレット。メトリクスのクライアントは これを
Authorization
ヘッダーでベアラートークンとして使用します。環境変数REGISTRY_OPENSHIFT_METRICS_SECRET
で上書きできます。 - 5
- 同時に行えるプル要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXRUNNING
で上書きできます。ゼロは無制限を意味します。 - 6
- キューに入れられるプル要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXINQUEUE
で上書きできます。ゼロは無制限を意味します。 - 7
- 拒否されるまでのキューにあるプル要求の最大待機時間。環境変数
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXWAITINQUEUE
で上書きできます。ゼロは無制限を意味します。 - 8
- 同時に行えるプッシュ要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXRUNNING
で上書きできます。ゼロは無制限を意味します。 - 9
- キューにあるプッシュ要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXINQUEUE
で上書きできます。ゼロは無制限を意味します。 - 10
- 拒否されるまでのキューにあるプッシュ要求の最大待機時間。環境変数
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXWAITINQUEUE
で上書きできます。ゼロは無制限を意味します。
使用状況の情報については レジストリーメトリクスへのアクセスを参照してください。
3.5.5.7. レポート (Reporting)
レポート (Reporting) はサポートされていません。
3.5.5.8. HTTP
アップストリームのオプションはサポートされています。環境変数を使って設定を変更する方法についてはこちらを参照してください。変更の必要があるのは tls セクションのみです。以下は例になります。
http: addr: :5000 tls: certificate: /etc/secrets/registry.crt key: /etc/secrets/registry.key
3.5.5.9. 通知
アップストリームのオプションはサポートされています。REST API リファレンス はより包括的な統合オプションを提供します。
例:
notifications: endpoints: - name: registry disabled: false url: https://url:port/path headers: Accept: - text/plain timeout: 500 threshold: 5 backoff: 1000
3.5.5.10. Redis
Redis はサポートされていません。
3.5.5.11. 健全性
アップストリームのオプションはサポートされています。レジストリーのデプロイメント設定は、 /healthz で統合されたヘルスチェックを提供します。
3.5.5.12. プロキシー
プロキシー設定は有効にできません。この機能は OpenShift Container Platform リポジトリーのミドルウェア拡張、pullthrough: true で提供されます。
3.5.5.13. キャッシュ
統合レジストリーは、データをアクティブにキャッシュして、速度の遅い外部リソースに対する呼び出しの回数を減らします。キャッシュには 2 種類あります。
- Blob のメタデータのキャッシュに使用されるストレージキャッシュ。このキャッシュには有効期限がなく、データは明示的に削除されるまで残り続けます。
- アプリケーションキャッシュには、Blob とリポジトリーの関連付けが含まれます。このキャッシュ内のデータには有効期限があります。
キャッシュを完全にオフににするには設定を変更する必要があります。
version: 0.1 log: level: debug http: addr: :5000 storage: cache: {} 1 openshift: version: 1.0 cache: disabled: true 2 blobrepositoryttl: 10m
3.6. 既知の問題
3.6.1. 概要
以下は、統合レジストリーのデプロイまたは使用時の既知の問題です。
3.6.2. 共有 NFS ボリュームとスケーリングされたレジストリーの使用時のイメージのプッシュエラー
スケーリングされたレジストリーを共有 NFS ボリュームで使用すると、イメージのプッシュ時に以下のいずれかのエラーが発生することがあります。
-
digest invalid: provided digest did not match uploaded content
-
blob upload unknown
-
blob upload invalid
これらのエラーは、Docker のイメージのプッシュの試行時に内部レジストリーサービスによって返されます。その原因は、ノード間のファイル属性の同期に起因します。NFS クライアント側のキャッシング、ネットワーク待機時間およびレイヤーサイズなどはすべて、デフォルトのラウンドロビンロードバランシング設定を使用してイメージをプッシュする際に発生するエラーの要因になる可能性があります。
このような障害の可能性を最小限に抑えるには、以下の手順を実行します。
docker-registry サービスの
sessionAffinity
がClientIP
に設定されていることを確認します。$ oc get svc / docker-registry --template = '{{。spec.sessionAffinity}}'
これにより
ClientIP
が返されるはずです。ClientIP は OpenShift Container Platform の最近のバージョンのデフォルトです。これが返されない場合は、以下のように変更してください。$ oc patch svc / docker-registry -p '{' spec ':{' sessionAffinity ':' ClientIP '}}'
-
NFS サーバー上のレジストリーボリュームの NFS エクスポート行に
no_wdelay
オプションが一覧表示されていることを確認します。no_wdelay
オプションは、サーバーによる書き込みの遅延を防ぎ、このレジストリーの要件である、書き込み直後の読み取りの整合性を大幅に改善します。
テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。
他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
3.6.3. 内部で管理されたイメージのプルに失敗し「見つかりません (not found)」のエラーが表示される
このエラーは、プルされたイメージがプルされているイメージストリームとは異なるイメージストリームにプッシュされた場合に発生します。これは、ビルドされたイメージを任意のイメージストリームに再タグ付けすることによって発生します。
$ oc tag srcimagestream:latest anyproject/pullimagestream:latest
その後、次のようなイメージ参照を使用して引き出します。
internal.registry.url:5000 / anyproject / pullimagestream:latest
Dockerを手動でプルするときにも同様のエラーが発生します。
Error: image anyproject/pullimagestream:latest not found
このエラーを防ぐには、内部で管理されたイメージのタグ付けを完全に避けるか、またはビルドしたイメージを必要な namespace に 手動で再プッシュします。
3.6.4. S3 ストレージでのイメージのプッシュが失敗し「500 内部サーバーエラー (500 Internal Server Error)」と表示される
レジストリーが S3 ストレージのバックエンドで実行されると、問題が報告されます。 Docker レジストリーへのプッシュは、以下のエラーを出して失敗することがあります。
Received unexpected HTTP status: 500 Internal Server Error
これをデバッグするには、レジストリーのログを表示する必要があります。ログで、プッシュの失敗時に発生した同様のエラーメッセージを探します。
time="2016-03-30T15:01:21.22287816-04:00" level=error msg="unknown error completing upload: driver.Error{DriverName:\"s3\", Enclosed:(*url.Error)(0xc20901cea0)}" http.request.method=PUT ... time="2016-03-30T15:01:21.493067808-04:00" level=error msg="response completed with error" err.code=UNKNOWN err.detail="s3: Put https://s3.amazonaws.com/oso-tsi-docker/registry/docker/registry/v2/blobs/sha256/ab/abe5af443833d60cf672e2ac57589410dddec060ed725d3e676f1865af63d2e2/data: EOF" err.message="unknown error" http.request.method=PUT ... time="2016-04-02T07:01:46.056520049-04:00" level=error msg="error putting into main store: s3: The request signature we calculated does not match the signature you provided. Check your key and signing method." http.request.method=PUT atest
このようなエラーを確認した場合には、Amazon S3 サポートにお問い合わせください。リージョンや特定のバケットで問題がある可能性があります。
3.6.5. イメージのプルーニングの失敗
イメージのプルーニング時に以下のエラーが発生した場合:
BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob
さらに、レジストリーのログに以下の情報が含まれている場合。
error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported
上記に該当する場合、お使いのカスタム設定ファイルにはストレージセクションに必須のエントリー、つまり true に設定された storage:delete:enabled
が含まれていないことを意味します。これらを追加し、レジストリーを再デプロイして、再度イメージプルーニングの操作を行ってください。