Red Hat Quay Operator をデプロイする OpenShift 4.5 以降のクラスターへの特権付きアカウントが必要です。そのアカウントには、namespace をクラスタースコープで作成できる必要があります。

各 Red Hat Quay アプリケーション Pod には、以下のリソース要件があります。

Red Hat Quay Operator は、管理する Red Hat Quay デプロイメントごとに少なくとも 1 つのアプリケーション Pod を作成します。OpenShift クラスターにこれらの要件に必要なコンピュートリソースがあることを確認します。

デフォルトで、Red Hat Quay Operator は ObjectBucketClaim Kubernetes API を使用してオブジェクトストレージをプロビジョニングします。この API を消費すると、ベンダー固有の実装から Operator を分離します。Red Hat OpenShift Data Foundation は、この例で使用される NooBaa コンポーネントを介してこの API を提供します。

Red Hat Quay は、以下のサポートされるクラウドストレージオプションのいずれかを使用するように手動で設定できます。

設定オプション FEATURE_USER_INITIALIZE を true に設定し、API /api/v1/user/initialize を使用して最初のユーザーを作成できるようにします。この API エンドポイントは、既存の組織の OAuth アプリケーションによって生成される OAuth トークンを必要とする他のすべてのレジストリー API 呼び出しとは異なり、認証は必要ありません。

Quay をデプロイしたら、API を使用してユーザーを作成できます (例: quayadmin)。他のユーザーが作成されていない場合です。詳細は、API を使用した最初のユーザーの作成 のセクションを参照してください。

Quay レジストリー API への一般アクセス を許可するように、BROWSER_API_CALLS_XHR_ONLY を false に設定します。

デプロイメント後はユーザーを作成することはできませんが、最初のユーザーが完全なパーミッションを持つ管理者となるようにしておくと便利です。SUPER_USER 設定オブジェクトを使用すると、事前にこの設定を事前に設定できます。

スーパーユーザーを設定したら、新規ユーザーを作成する機能をスーパーユーザーグループに制限できます。ユーザー作成を制限するには、FEATURE_USER_CREATION を false に設定します。

適切な設定が含まれる config.yaml 設定ファイルを作成します。

...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
...

アンマネージドストレージの設定例については、本セクションで紹介しています。オブジェクトストレージの設定についての詳細は、Red Hat Quay 設定ガイドを参照してください。

DISTRIBUTED_STORAGE_CONFIG:
  s3Storage:
    - S3Storage
    - host: s3.us-east-2.amazonaws.com
      s3_access_key: ABCDEFGHIJKLMN
      s3_secret_key: OL3ABCDEFGHIJKLMN
      s3_bucket: quay_bucket
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - s3Storage

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: GOOGQIMFB3ABCDEFGHIJKLMN
          bucket_name: quay-bucket
          secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
          storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: azure_account_name_here
      azure_account_key: azure_account_key_here
      azure_container: azure_container_here
      sas_token: some/path/
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage

Operator が Quay のオブジェクトストレージを管理する必要がある場合は、クラスターが ObjectBucketClaim API 経由でオブジェクトストレージを提供できるようにする必要があります。Red Hat OpenShift Data Foundations (ODF) Operator を使用する場合は、サポートされるオプションを 2 つ使用できます。

スタンドアロンのインスタンスオプションを使用するには、以下の読み取りを続行します。ODF の実稼働デプロイメントについては、公式ドキュメント を参照してください。

DB_CONNECTION_ARGS 構造で必要な DB_URI フィールドおよび任意の接続引数を使用して、データベースへの接続を設定します。DB_CONNECTION_ARGS で定義されたキーと値のペアは汎用的なものも、データベース固有のものもあります。特に、SSL 設定は、デプロイするデータベースや、PostgreSQL および MySQL のサンプルによって異なります。

postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

DB_CONNECTION_ARGS:
  sslmode: verify-ca
  sslrootcert: /path/to/cacert

DB_CONNECTION_ARGS:
  ssl:
    ca: /path/to/cacert

推奨事項:

独自の TLS 証明書およびキーを追加するには、以下のように設定バンドルシークレットに追加します。

$ oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret

外部の Redis データベースを使用する場合は、QuayRegistry インスタンスでコンポーネントをアンマネージドに設定します。

BUILDLOGS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379

USER_EVENTS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379

HorizontalPodAutoscalers が Clair、Quay、Mirror Pod に追加され、負荷の急上昇時に自動的にスケーリングされるようになりました。

HPA はデフォルトで managed に設定され、Quay の Pod 数、Clair およびリポジトリーのミラーリングは 2 に設定されます。これにより、Operator 経由で Quay を更新/再設定する際や、イベントの再スケジュール時にダウンタイムを回避しやすくなります。

自動スケーリングを無効にするか、独自の HorizontalPodAutoscaler を作成する場合は、コンポーネントを単純に QuayRegistry インスタンスでアンマネージドとして指定します。

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: horizontalpodautoscaler
      managed: false

Operator が Route を作成しないようにするには、以下を実行します。

Quay Operator を単一 namespace にインストールする場合、モニターリングコンポーネントは 'unmanaged' に自動的に設定されます。このシナリオでモニターリングを有効にするには、「Operator が単一 namespace にインストールされている場合のモニターリングの有効化」 セクションを参照してください。

モニターリングを明示的に無効にするには、以下を実行します。

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: monitoring
      managed: false

ミラーリングを明示的に無効にするには、以下を実行します。

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: mirroring
      managed: false

oc get pods コマンドを使用して、デプロイされたコンポーネントを表示します。

$ oc get pods -n quay-enterprise

NAME                                                   READY   STATUS      RESTARTS   AGE
example-registry-clair-app-5ffc9f77d6-jwr9s            1/1     Running     0          3m42s
example-registry-clair-app-5ffc9f77d6-wgp7d            1/1     Running     0          3m41s
example-registry-clair-postgres-54956d6d9c-rgs8l       1/1     Running     0          3m5s
example-registry-quay-app-79c6b86c7b-8qnr2             1/1     Running     4          3m42s
example-registry-quay-app-79c6b86c7b-xk85f             1/1     Running     4          3m41s
example-registry-quay-app-upgrade-5kl5r                0/1     Completed   4          3m50s
example-registry-quay-config-editor-597b47c995-svqrl   1/1     Running     0          3m42s
example-registry-quay-database-b466fc4d7-tfrnx         1/1     Running     2          3m42s
example-registry-quay-mirror-6d9bd78756-6lj6p          1/1     Running     0          2m58s
example-registry-quay-mirror-6d9bd78756-bv6gq          1/1     Running     0          2m58s
example-registry-quay-postgres-init-dzbmx              0/1     Completed   0          3m43s
example-registry-quay-redis-8bd67b647-skgqx            1/1     Running     0          3m42s

デフォルトのデプロイメントでは、以下の実行中の Pod が表示されます。

HPA はデフォルトで managed に設定され、Quay の Pod 数、Clair およびリポジトリーのミラーリングは 2 に設定されます。これにより、Operator 経由で Quay を更新/再設定する際や、イベントの再スケジュール時にダウンタイムを回避しやすくなります。

$ oc get hpa -n quay-enterprise
NAME                           REFERENCE                                 TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
example-registry-clair-app     Deployment/example-registry-clair-app     16%/90%, 0%/90%   2         10        2          13d
example-registry-quay-app      Deployment/example-registry-quay-app      31%/90%, 1%/90%   2         20        2          13d
example-registry-quay-mirror   Deployment/example-registry-quay-mirror   27%/90%, 0%/90%   2         20        2          13d

API を使用して最初のユーザーを作成する場合には、以下の条件を満たしている必要があります。

デプロイメントの事前設定に関する詳細は、自動化のための Quay の事前設定 セクションを参照してください。

$  curl -X POST -k  https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass123", "email": "quayadmin@example.com", "access_token": true}'

{"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"}

$  curl -X POST -k  https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayuser2", "password":"quaypass123", "email": "quayuser2@example.com"}'

{"message":"Cannot initialize user in a non-empty database"}

 $  curl -X POST -k  https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"pass123", "email": "quayadmin@example.com"}'

{"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}

$ curl -X GET -k -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/superuser/users/

{
    "users": [
        {
            "kind": "user",
            "name": "quayadmin",
            "username": "quayadmin",
            "email": "quayadmin@example.com",
            "verified": true,
            "avatar": {
                "name": "quayadmin",
                "hash": "3e82e9cbf62d25dec0ed1b4c66ca7c5d47ab9f1f271958298dea856fb26adc4c",
                "color": "#e7ba52",
                "kind": "user"
            },
            "super_user": true,
            "enabled": true
        }
    ]
}

$ curl -X POST -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/ --data '{"name": "testorg", "email": "testorg@example.com"}'

"Created"

$ curl -X GET -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://min-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/testorg

{
    "name": "testorg",
    "email": "testorg@example.com",
    "avatar": {
        "name": "testorg",
        "hash": "5f113632ad532fc78215c9258a4fb60606d1fa386c91b141116a1317bf9c53c8",
        "color": "#a55194",
        "kind": "user"
    },
    "is_admin": true,
    "is_member": true,
    "teams": {
        "owners": {
            "name": "owners",
            "description": "",
            "role": "admin",
            "avatar": {
                "name": "owners",
                "hash": "6f0e3a8c0eb46e8834b43b03374ece43a030621d92a7437beb48f871e90f8d90",
                "color": "#c7c7c7",
                "kind": "team"
            },
            "can_view": true,
            "repo_count": 0,
            "member_count": 1,
            "is_synced": false
        }
    },
    "ordered_teams": [
        "owners"
    ],
    "invoice_email": false,
    "invoice_email_address": null,
    "tag_expiration_s": 1209600,
    "is_free_account": true
}

Red Hat Quay 3.6 は、デプロイメントフェーズで問題のトラブルシューティングを行うための新機能を提供します。QuayRegistry オブジェクトのステータスは、デプロイメント時にコンポーネントの正常性をモニターするのに役立ちます。これにより、発生する可能性のある問題のデバッグに役立ちます。

$ oc get quayregistry -n quay-enterprise -o yaml

デプロイメント直後に、QuayRegistry オブジェクトに基本設定が表示されます。

apiVersion: v1
items:
- apiVersion: quay.redhat.com/v1
  kind: QuayRegistry
  metadata:
    creationTimestamp: "2021-09-14T10:51:22Z"
    generation: 3
    name: example-registry
    namespace: quay-enterprise
    resourceVersion: "50147"
    selfLink: /apis/quay.redhat.com/v1/namespaces/quay-enterprise/quayregistries/example-registry
    uid: e3fc82ba-e716-4646-bb0f-63c26d05e00e
  spec:
    components:
    - kind: postgres
      managed: true
    - kind: clair
      managed: true
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: objectstorage
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
    - kind: monitoring
      managed: true
    - kind: tls
      managed: true
    configBundleSecret: example-registry-config-bundle-kt55s
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

oc get pods コマンドを使用して、デプロイされたコンポーネントの現在の状態を表示します。

$ oc get pods -n quay-enterprise

NAME                                                   READY   STATUS              RESTARTS   AGE
example-registry-clair-app-86554c6b49-ds7bl            0/1     ContainerCreating   0          2s
example-registry-clair-app-86554c6b49-hxp5s            0/1     Running             1          17s
example-registry-clair-postgres-68d8857899-lbc5n       0/1     ContainerCreating   0          17s
example-registry-quay-app-upgrade-h2v7h                0/1     ContainerCreating   0          9s
example-registry-quay-config-editor-5f646cbcb7-lbnc2   0/1     ContainerCreating   0          17s
example-registry-quay-database-66f495c9bc-wqsjf        0/1     ContainerCreating   0          17s
example-registry-quay-mirror-854c88457b-d845g          0/1     Init:0/1            0          2s
example-registry-quay-mirror-854c88457b-fghxv          0/1     Init:0/1            0          17s
example-registry-quay-postgres-init-bktdt              0/1     Terminating         0          17s
example-registry-quay-redis-f9b9d44bf-4htpz            0/1     ContainerCreating   0          17s

デプロイメントが進行中の間、QuayRegistry オブジェクトに現在のステータスが表示されます。この場合、データベースの移行が行われ、その他のコンポーネントはこれが完了するまで待機します。

  status:
    conditions:
    - lastTransitionTime: "2021-09-14T10:52:04Z"
      lastUpdateTime: "2021-09-14T10:52:04Z"
      message: all objects created/updated successfully
      reason: ComponentsCreationSuccess
      status: "False"
      type: RolloutBlocked
    - lastTransitionTime: "2021-09-14T10:52:05Z"
      lastUpdateTime: "2021-09-14T10:52:05Z"
      message: running database migrations
      reason: MigrationsInProgress
      status: "False"
      type: Available
    configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-btbkcg8dc9
    configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org
    lastUpdated: 2021-09-14 10:52:05.371425635 +0000 UTC
    unhealthyComponents:
      clair:
      - lastTransitionTime: "2021-09-14T10:51:32Z"
        lastUpdateTime: "2021-09-14T10:51:32Z"
        message: 'Deployment example-registry-clair-postgres: Deployment does not have minimum availability.'
        reason: MinimumReplicasUnavailable
        status: "False"
        type: Available
      - lastTransitionTime: "2021-09-14T10:51:32Z"
        lastUpdateTime: "2021-09-14T10:51:32Z"
        message: 'Deployment example-registry-clair-app: Deployment does not have minimum availability.'
        reason: MinimumReplicasUnavailable
        status: "False"
        type: Available
      mirror:
      - lastTransitionTime: "2021-09-14T10:51:32Z"
        lastUpdateTime: "2021-09-14T10:51:32Z"
        message: 'Deployment example-registry-quay-mirror: Deployment does not have minimum availability.'
        reason: MinimumReplicasUnavailable
        status: "False"
        type: Available

デプロイメントプロセスが正常に終了すると、QuayRegistry オブジェクトのステータスには正常でないコンポーネントが表示されません。

  status:
    conditions:
    - lastTransitionTime: "2021-09-14T10:52:36Z"
      lastUpdateTime: "2021-09-14T10:52:36Z"
      message: all registry component healthchecks passing
      reason: HealthChecksPassing
      status: "True"
      type: Available
    - lastTransitionTime: "2021-09-14T10:52:46Z"
      lastUpdateTime: "2021-09-14T10:52:46Z"
      message: all objects created/updated successfully
      reason: ComponentsCreationSuccess
      status: "False"
      type: RolloutBlocked
    configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-hg7gg7h57m
    configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org
    currentVersion: 3.6.0
    lastUpdated: 2021-09-14 10:52:46.104181633 +0000 UTC
    registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org
    unhealthyComponents: {}

設定エディターエンドポイントを参照し、設定ツールにアクセスする時に使用するユーザー名 (通常は quayconfig)、および対応するパスワードを入力します。

設定の更新例では、設定エディターツールを使用してスーパーユーザーを追加しています。

Operator の再設定後に、QuayRegistry の特定インスタンスの YAML タブで再デプロイの進捗を追跡できます (この場合は example-registry)。

ステータスが変わるたびに、データをリロードして更新されたバージョンを表示するように求められます。最終的に、Operator は変更を調整し、正常でないコンポーネントが報告されることはありません。

QuayRegistry の Events タブには、再デプロイに関連するイベントが表示されます。

再設定の影響を受ける namespace のすべてのリソースのストリーミングイベントは、Home → Events の OpenShift コンソールで利用できます。

新しい Pod が設定ツール用に作成され、新規シークレットが作成されるので、次回ログインの試行時に更新されたパスワードを使用する必要があります。

設定バンドルを使用して、更新された config.yaml ファイルにアクセスします。

OpenShift コンソールで、Monitoring → Dashboards に移動し、必要な Quay レジストリーインスタンスのダッシュボードを検索します。

ダッシュボードには、以下を含むさまざまな統計が表示されます。

UI で Monitoring → Metrics にアクセスすることで、Quay ダッシュボードの背後にある基礎となるメトリクスを表示できます。Expression フィールドにテキストの quay_ を入力し、利用可能なメトリクスの一覧を表示します。

quay_org_rows など、サンプルメトリクスを選択します。

このメトリクスには、レジストリー内の組織の数が表示されます。これはダッシュボードに直接表示されます。

Quay Pod が頻繁に再起動する場合はアラートが発生します。アラートは、コンソール UI の Monitoring → Alerting から Alerting ルールタブにアクセスし、Quay 固有のアラートを検索して設定できます。

QuayPodFrequentlyRestarting ルールの詳細を選択し、アラートを設定します。

OpenShift クラスターの Clair デプロイメントから clairctl プログラムを取得するには、以下のように oc cp コマンドを使用します。

$ oc -n quay-enterprise cp example-registry-clair-app-64dd48f866-6ptgw:/usr/bin/clairctl ./clairctl
$ chmod u+x ./clairctl

スタンドアロンの Clair のデプロイメントでは、以下のように podman cp コマンドを使用します。

$ sudo podman cp clairv4:/usr/bin/clairctl ./clairctl
$ chmod u+x ./clairctl

インターネットにアクセスできる Clair インスタンスから、適切な設定ファイルと共に clairctl を使用してアップデーターバンドルをエクスポートします。

$ ./clairctl --config ./config.yaml export-updaters updates.gz

アップデーターバンドルをエアギャップされた環境に転送した後に、clairctl を使用して、バンドルを OpenShift Operator によってデプロイされた Clair データベースにインポートします。

$ ./clairctl --config ./clair-config.yaml import-updaters updates.gz

この例で使用されるクラスターには、3 つのマスターノードと 6 つのワーカーノードがあります。

$ oc get nodes
NAME                                               STATUS   ROLES    AGE     VERSION
user1-jcnp6-master-0.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
user1-jcnp6-master-1.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
user1-jcnp6-master-2.c.quay-devel.internal         Ready    master   3h30m   v1.20.0+ba45583
user1-jcnp6-worker-b-65plj.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583
user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal   Ready    worker   3h22m   v1.20.0+ba45583
user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal   Ready    worker   3h21m   v1.20.0+ba45583

インフラストラクチャーに使用する最終的な 3 つのワーカーノードにラベルを付けます。

$ oc label node --overwrite user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra=
$ oc label node --overwrite user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra=
$ oc label node --overwrite user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra=

クラスターのノードを一覧表示すると、最後の 3 つのワーカーノードには infra のロールが追加されます。

$ oc get nodes
NAME                                               STATUS   ROLES          AGE     VERSION
user1-jcnp6-master-0.c.quay-devel.internal         Ready    master         4h14m   v1.20.0+ba45583
user1-jcnp6-master-1.c.quay-devel.internal         Ready    master         4h15m   v1.20.0+ba45583
user1-jcnp6-master-2.c.quay-devel.internal         Ready    master         4h14m   v1.20.0+ba45583
user1-jcnp6-worker-b-65plj.c.quay-devel.internal   Ready    worker         4h6m    v1.20.0+ba45583
user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal   Ready    worker         4h5m    v1.20.0+ba45583
user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal   Ready    worker         4h5m    v1.20.0+ba45583
user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583
user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583
user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal   Ready    infra,worker   4h6m    v1.20.0+ba45583

ただし、infra ノードがワーカーとして割り当てられると、ユーザーのワークロードが予期せず infra ノードに割り当てられる可能性があります。これを回避するには、infra ノードにテイントを適用し、制御したい Pod に許容値を追加します。

$ oc adm taint nodes user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule
$ oc adm taint nodes user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule
$ oc adm taint nodes user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule

Quay Operator を使用して Quay を展開している場合は、インストールした Operator と、デプロイのために作成した特定の名前空間を削除します。

以下の例のようにノードセレクターおよび容認を指定して Project リソースを作成します。

kind: Project
apiVersion: project.openshift.io/v1
metadata:
  name: quay-registry
  annotations:
    openshift.io/node-selector: 'node-role.kubernetes.io/infra='
    scheduler.alpha.kubernetes.io/defaultTolerations: >-
      [{"operator": "Exists", "effect": "NoSchedule", "key":
      "node-role.kubernetes.io/infra"}
      ]

oc apply コマンドを使用してプロジェクトを作成します。

$ oc apply -f quay-registry.yaml
project.project.openshift.io/quay-registry created

quay-registry namespace で作成された後続のリソースは、専用のインフラストラクチャーノードでスケジュールされます。

Quay Operator のインストール時に、適切なプロジェクト namespace を明示的に指定します (この場合は quay-registry)。これにより、Operator Pod 自体が 3 つのインフラストラクチャーノードのいずれかに到達します。

$ oc get pods -n quay-registry -o wide
NAME                                    READY   STATUS    RESTARTS   AGE   IP            NODE                                              
quay-operator.v3.4.1-6f6597d8d8-bd4dp   1/1     Running   0          30s   10.131.0.16   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal

前述のようにレジストリーを作成したら、デプロイメントが準備されるのを待ちます。Quay Pod を一覧表示する場合は、それらがインフラストラクチャー用としてラベルを付けた 3 つのノードにのみスケジュールされていることを確認できます。

$ oc get pods -n quay-registry -o wide
NAME                                                   READY   STATUS      RESTARTS   AGE     IP            NODE                                                
example-registry-clair-app-789d6d984d-gpbwd            1/1     Running     1          5m57s   10.130.2.80   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal
example-registry-clair-postgres-7c8697f5-zkzht         1/1     Running     0          4m53s   10.129.2.19   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal
example-registry-quay-app-56dd755b6d-glbf7             1/1     Running     1          5m57s   10.129.2.17   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal
example-registry-quay-config-editor-7bf9bccc7b-dpc6d   1/1     Running     0          5m57s   10.131.0.23   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal
example-registry-quay-database-8dc7cfd69-dr2cc         1/1     Running     0          5m43s   10.129.2.18   user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal
example-registry-quay-mirror-78df886bcc-v75p9          1/1     Running     0          5m16s   10.131.0.24   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal
example-registry-quay-postgres-init-8s8g9              0/1     Completed   0          5m54s   10.130.2.79   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal
example-registry-quay-redis-5688ddcdb6-ndp4t           1/1     Running     0          5m56s   10.130.2.78   user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal
quay-operator.v3.4.1-6f6597d8d8-bd4dp                  1/1     Running     0          22m     10.131.0.16   user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal

ServiceMonitor リソースを作成して、メトリクスをスクレープするように OpenShift Monitoring を設定します。

OpenShift コンソールでメトリクスには Monitoring → Metrics からアクセスできます。Expression フィールドにテキストの quay_ を入力し、利用可能なメトリクスの一覧を表示します。

たとえば、ユーザーをレジストリーに追加した場合は、quay-users_rows メトリクスを選択します。

数分後に (PVC のサイズによって異なる)、拡張されたサイズは PVC の Capacity フィールドに反映される必要があります。

数分後に、追加のストレージプールが Noobaa リソースに追加され、Red Hat Quay で利用できるようになります。

以下の環境変数は、コンポーネントイメージを上書きするために Operator で使用されます。

Operator Lifecycle Manager (OLM) を使用して Quay Operator をクラスターにインストールした場合は、ClusterServiceVersion オブジェクトを変更することで、マネージドコンポーネントのコンテナーイメージを簡単に上書きすることができます。これは、クラスター内で実行中の Operator を示す OLM の表現です。Kubernetes UI または kubectl/oc を使用して Quay Operator の ClusterServiceVersion を検索します。

$ oc get clusterserviceversions -n <your-namespace>

UI、oc edit、またはその他の方法を使用して Quay ClusterServiceVersion を変更し、上記の環境変数を追加して上書きイメージを参照します。

JSONPath: spec.install.spec.deployments[0].spec.template.spec.containers[0].env

- name: RELATED_IMAGE_COMPONENT_QUAY
  value: quay.io/projectquay/quay@sha256:c35f5af964431673f4ff5c9e90bdf45f19e38b8742b5903d41c10cc7f6339a6d
- name: RELATED_IMAGE_COMPONENT_CLAIR
  value: quay.io/projectquay/clair@sha256:70c99feceb4c0973540d22e740659cd8d616775d3ad1c1698ddf71d0221f3ce6
- name: RELATED_IMAGE_COMPONENT_POSTGRES
  value: centos/postgresql-10-centos7@sha256:de1560cb35e5ec643e7b3a772ebaac8e3a7a2a8e8271d9e91ff023539b4dfb33
- name: RELATED_IMAGE_COMPONENT_REDIS
  value: centos/redis-32-centos7@sha256:06dbb609484330ec6be6090109f1fa16e936afcf975d1cbc5fff3e6c7cae7542

これは Operator レベルで実行されるため、すべての QuayRegistry はこれらの同じオーバーライドを使用してデプロイされることに注意してください。

Quay をあるマイナーバージョンから次のマイナーバージョン (たとえば、3.4 → 3.5) に更新するには、Quay Operator の更新チャネルを変更する必要があります。

3.4.2 → 3.4.3 などの z ストリームのアップグレードの場合、更新は、ユーザーが最初にインストール時に選択した major-minor チャネルでリリースされます。z ストリームのアップグレードを実行する手順は、上記のように approvalStrategy によって異なります。承認戦略が Automatic に設定されている場合、Quay Operator は自動的に最新の z ストリームにアップグレードします。これにより、ダウンタイムがほとんどない (またはまったくない) 新しい z ストリームへの Quay の自動更新が行われます。それ以外の場合は、インストールを開始する前に更新を手動で承認する必要があります。

インストールされた Operator のサブスクリプションは、Operator の更新を追跡し、受信するために使用される更新チャネルを指定します。Quay Operator をアップグレードして新規チャネルからの更新の追跡および受信を開始するには、インストールされた Quay Operator の Subscription タブで更新チャネルを変更します。Automatic 承認ストラテジーのあるサブスクリプションの場合、アップグレードは自動的に開始し、インストールされた Operator を一覧表示したページでモニターできます。

インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合は、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。Quay Operator に保留中のアップグレードがある場合、このステータスは Installed Operators の一覧に表示されます。Quay Operator の Subscription タブで、インストール計画をプレビューし、アップグレードに利用可能なリソースとして一覧表示されるリソースを確認できます。問題がなければ、Approve をクリックし、Installed Operators を一覧表示したページに戻り、アップグレードの進捗をモニターします。

以下のイメージには、更新 Channel、Approval ストラテジー、Upgrade status および InstallPlan などの UI の Subscription タブが表示されています。

Installed Operator の一覧は、現在の Quay インストールの概要を提供します。

OpenShift コンソールでの Quay 3.6 のモニターリングのサポートを使用するには、Operator がすべての namespace でインストールされている必要があります。Operator を特定の namespace にインストールしている場合は、Operator 自体を削除し、アップグレードが実行されたら、これをすべての namespace に対して再インストールします。

Helm アーティファクトおよび OCI アーティファクトのサポートが、Red Hat Quay 3.6 でデフォルトで有効にされるようになりました。機能を明示的に有効にする必要がある場合 (機能がデフォルトで有効にされていないバージョンからアップグレードする場合など) は、以下のプロパティーを使用して OCI アーティファクトの使用を有効にするために、Quay デプロイメントを再設定する必要があります。

FEATURE_GENERAL_OCI_SUPPORT: true

QuayEcosystem から QuayRegistry への自動アップグレード時に問題が発生した場合は、以下の手順を実行して QuayEcosystem の使用に戻します。

Quay Operator は、QuayEcosystem コンポーネントの移行に失敗したり、サポートされていない場合、ログや status.conditions にエラーを報告します。管理対象外のすべてのコンポーネントの移行は、Kubernetes リソースを導入する必要はなく、必要なすべての値が Quay の config.yaml にすでに指定されているためです。

データベース

一時データベースはサポートされません (volumeSize フィールドを設定する必要があります)。

Redis

特別な設定は必要ありません。

External Access

パススルー Route アクセスのみが自動移行でサポートされます。他の方法には手動移行が必要です。

Clair

特別な設定は必要ありません。

オブジェクトストレージ

QuayEcosystem には管理オブジェクトストレージコンポーネントがないため、オブジェクトストレージには常に管理外のマークが付けられます。ローカルストレージはサポートされません。

リポジトリーのミラーリング

特別な設定は必要ありません。

関連情報