Quay Operator の使用による OpenShift への Red Hat Quay のデプロイ

Red Hat Quay 3.3

Quay Setup Operator の使用による OpenShift への Red Hat Quay のデプロイ

概要

Red Hat Quay Operator の使用による OpenShift クラスターへの Red Hat Quay のデプロイ

序文

Red Hat Quay は、エンタープライズレベルの品質の高いコンテナーレジストリー製品です。Red Hat Quay を使用してコンテナーイメージをビルドし、保存してから、企業全体にデプロイできるようにします。

Red Hat は、OpenShift に Red Hat Quay をデプロイするための 2 つのアプローチをサポートしています。

  • Quay Operator を使用した OpenShift への Red Hat Quay のデプロイ: Quay Operator は、Red Hat Quay クラスターをデプロイし、管理する簡単な方法を提供します。これは OpenShift への Red Hat Quay のデプロイで優先される手順であり、この手順については本書で説明します。
  • Red Hat Quay オブジェクトを個別にデプロイ: この手順では、Red Hat Quay クラスターを設定するために個別にデプロイする yaml ファイルのセットを提供します。この手順はいずれは非推奨になる予定です。

Red Hat Quay v3.3 の時点で、この Operator は Quay Setup Operator から Quay Operator に変更されました。 この変更は、Operator が Red Hat Quay のデプロイに使用するだけでなく、Red Hat Quay クラスターの継続的な設定およびメンテナーンスにも使用できるようになったために行われました。

第1章 概要

Red Hat Quay の機能には以下が含まれます。

  • 高可用性
  • Geo-replication
  • リポジトリーのミラーリング
  • Docker v2、スキーマ 2 (multiarch) のサポート
  • 継続的インテグレーション
  • Clair によるセキュリティースキャン
  • カスタムログのローテーション
  • ダウンタイムなしのガベージコレクション
  • 24 時間年中無休のサポート

Red Hat Quay は以下のサポートを提供します。

  • 複数の認証およびアクセス方法
  • 複数のストレージバックエンド
  • Quay、Clair、およびストレージバックエンドのカスタム証明書
  • アプリケーションレジストリー
  • コンテナーイメージの複数の異なるタイプ

第2章 アーキテクチャー

Red Hat Quay は、複数のコアコンポーネントで設定されています。

  • データベース: Red Hat Quay で、(イメージストレージ用にではなく) プライマリーメタデータストレージとして使用されます。
  • Redis(キー、値ストア): ライブビルダーログおよび Red Hat Quay チュートリアルを保存します。
  • Quay(コンテナーレジストリー): Pod の複数のコンポーネントで設定される quay コンテナーをサービスとして実行します。
  • Clair: コンテナーイメージで脆弱性の有無をスキャンし、修正を提案します。

サポートされるデプロイメントでは、以下のストレージタイプのいずれかを使用する必要があります。

  • パブリッククラウドストレージ: パブリッククラウド環境では、Amazon S3 (AWS 用) や Google Cloud Storage (Google Cloud 用) などのクラウドプロバイダーのオブジェクトストレージを使用する必要があります。
  • プライベートクラウドストレージ: プライベートクラウドでは、Ceph RADOS や OpenStack Swift などの S3 または Swift 準拠のオブジェクトストアが必要です。
警告

実稼働環境の設定にローカルマウントされたディレクトリーのストレージエンジンを使用しないでください。マウントされた NFS ボリュームはサポートされません。ローカルストレージは Red Hat Quay のテスト専用のインストールに使用されることが意図されています。

第3章 OpenShift での Red Hat Quay の前提条件

以下に、OpenShift デプロイメントで Red Hat Quay を開始する前に知っておく必要があるいくつかの点を示します。

  • OpenShift クラスター: Red Hat Quay をデプロイする OpenShift 4.2 以降のクラスターへの特権付きアカウントが必要です。そのアカウントでは、namespace をクラスタースコープで作成できる必要があります。
  • ストレージ: AWS クラウドストレージが以下の手順で例として使用されます。また、high availability Red Hat Quay deployment ガイドの Set up Ceph セクションの手順を使用して Ceph クラウドストレージを作成することもできます。以下は、サポートされているその他のクラウドストレージの一覧です。

  • サービス: OpenShift クラスターには、以下のコンテナー化されたサービスを実行するのに十分な容量が必要です。

    • データベース :Red Hat Quay の実稼働環境での使用には、エンタープライズレベルの品質の高いデータベースを使用することをお勧めします。本書では、PostgreSQL が例として使用されています。オプションには以下が含まれます。

      • Crunchy Data PostgreSQL Operator: Red Hat による直接のサポートはありませんが、Red Hat Quay と使用できるように Crunchy Data から CrunchDB Operator を利用できます。この経路を使用する場合、Crunchy Data とのサポート契約が必要であり、Operator およびそのデータベースに関する使用方法のガイダンスや問題について Crunchy Data と直接連携する必要があります。
      • 組織に高可用性 (HA) データベースがすでにある場合、Red Hat Quay でそのデータベースを使用できます。サードパーティーのデータベースおよびその他のコンポーネントのサポートについての詳細は、Red Hat Quay Support Policy を参照してください。
    • Key-value データベース: Redis は、ライブビルダーログと Red Hat Quay チュートリアルのコンテンツを Red Hat Quay 設定に提供するために使用されます。
    • Red Hat Quay: quay コンテナーは、Red Hat Quay レジストリーを管理する機能を提供します。
    • Clair: clair-jwt コンテナーは、レジストリーの Clair スキャンサービスを提供します。

第4章 Red Hat Quay のデプロイ

この手順は以下を実行します。

  • OperatorHub から OpenShift への Red Hat Quay Operator のインストール
  • Quay Operator を使用した OpenShift への Red Hat Quay クラスターのデプロイ

Red Hat Quay Operator をデプロイする前に、多くの設定を変更することができます。Operator は Red Hat Quay 設定ツールをバイパスして、起動プロセス全体を自動化します。Operator の自動化された設定を省略することを選択して、設定ツールを直接使用することもできます。

Red Hat Quay 3.3 の時点で、Quay Setup Operator の名前は Quay Operator に変更されています。機能が Operator に追加され、デプロイメント後に Red Hat Quay クラスターを維持し、更新するために Operator を使用できるようになりました。更新は Operator から直接行うか、または Red Hat Quay Config Tool を使用して実行できます。

前提条件

  • OpenShift 4.2(以降) クラスター
  • OpenShift クラスターへのクラスタースコープの管理者権限

4.1. 実稼働デプロイメント

非実稼働デプロイメントの場合、デフォルトを使用して Red Hat Quay クラスターをすぐに稼働させることができます。実稼働環境デプロイメントの場合には、本書で後述するすべての設定オプションを確認する必要があります。ただし、これらについては、少なくとも以下の点を考慮する必要があります。

  • スーパーユーザーパスワード: デフォルトのスーパーユーザーパスワードを変更します。
  • 設定ツールのパスワード: Red Hat Quay Config Tool のパスワードをデフォルトから変更します。
  • Quay イメージ: 利用可能な場合は、現在の Operator に関連付けられた quay イメージを後の quay イメージに置き換えます。
  • レプリカ数: 予想される需要に応じてレプリカ数を増やし、実行される quay コンテナーのインスタンスの数を設定します。
  • メモリー要求: 予想される要求に基づいて、quay コンテナーに割り当てるメモリー量を選択します。
  • CPU 要求: 予想される要求に基づいて割り当てる CPU の量を選択します。
  • Quay データベース: OpenShift クラスター外の既存の PostgreSQL データベースおよび商用サポートのあるデータベースの使用を検討します。
  • ストレージバックエンド: 信頼でき、サポートされているストレージバックエンドを選択します。実稼働デプロイメントでは、ローカルストレージと NFS ストレージはサポートされません。
  • 証明書: Red Hat Quay と通信し、ストレージや LDAP サービスなどの他のサービスにアクセスするために独自の証明書を提供します。

4.2. Red Hat Quay Operator のインストール

  1. OpenShift コンソールから、Red Hat Quay を実行する新規 namespace を作成します。たとえば、Projects → Create Project と選択します。次に、名前 (この例では quay-enterprise が使用されます) を入力します。また、任意で Display Name および Description を入力します。次に、Create をクリックします。
  2. Operators → OperatorHub を選択し、Red Hat Quay Operator を選択します。コミュニティーバージョンが複数ある場合は、必ず Red Hat 認定 Operator を使用するようにし、コミュニティーバージョンは使用しないでください。
  3. Install を選択します。 Operator Subscription ページが表示されます。
  4. 以下を選択して Subscribe を選択します。

    • Installation Mode: インストールする特定の namespace を選択します (デフォルトは quay-enterprise)。
    • Update Channel: 更新チャネルの選択します (1 つのみ選択可能)。
    • Approval Strategy: 自動の更新または手動の更新を承認するよう選択します。
  5. Subscribe を選択します。

4.3. Red Hat Quay エコシステムのデプロイ

  1. Quay.io から Quay および Clair コンテナーを取得するのに必要な認証情報を取得する方法については、Accessing Red Hat Quay のアーティクルを参照してください。次に、これらの認証情報をファイルに入れます。この例では、ローカルディレクトリーに config.json を作成します。
  2. Red Hat Quay のデプロイに選択したプロジェクト (namespace) に移動します。

    $ oc project quay-enterprise
  3. 以下のように、認証情報が含まれるシークレットを作成します。

    $ oc create secret generic redhat-pull-secret \
        --from-file=".dockerconfigjson=config.json" --type='kubernetes.io/dockerconfigjson'
  4. カスタムリソースファイル (この例では、 quayecosystem_cr.yaml) を作成するか、または quay-operator examples ページからこれをコピーします。この例では、デフォルト設定を使用します。

    apiVersion: redhatcop.redhat.io/v1alpha1
    kind: QuayEcosystem
    metadata:
      name: example-quayecosystem
    spec:
      quay:
        imagePullSecretName: redhat-pull-secret
  5. Customizing your Red Hat Quay cluster セクションを確認し、変更する設定を選択します。
  6. 以下のように、カスタムリソースファイルから Quay エコシステムをデプロイします。

    $ oc create -f quayecosystem_cr.yaml

    カスタムリソースをデプロイすると、Red Hat Quay、PostgreSQL、および Redis サービスを含む Red Hat Quay クラスターが自動的に作成され、設定されます。

  7. Red Hat Quay クラスターのステータスを確認するには、OpenShift Web コンソールにログインし、Projects を選択して quay-enterprise プロジェクトを選択して以下を確認します。

    The Red Hat Quay Operator deployed in OpenShift

Red Hat Quay が実行されている場合、以下のように Red Hat Quay 設定の使用を開始します。

  • 以下のように、新規の Red Hat Quay クラスターへのルートを取得します。

    $ oc get route example-quayecosystem-quay
    NAME                       HOST/PORT
       PATH                 SERVICES PORT   TERMINATION            WILDCARD
    ...
    example-quayecosystem-quay example-quayecosystem-quay-example.com
       example-quayecosystem-quay    8443   passthrough/Redirect   None
  • ルートを使用して、スーパーユーザーの認証情報 (ユーザー名は quay、パスワードは password) でログインするか、または次のセクションで説明されているように認証情報を変更します。

この時点で、Red Hat Quay クラスターの使用を開始できます。クラスターをさらに設定するには、以下のいずれかを実行できます。

  • Config Tool を使用して、Red Hat Quay クラスターの設定を手動で変更します。(Config ツールは実行を継続し、oc get route example-quayecosystem-quay-config を入力してルートを利用可能にできます。)
  • 以下のセクションで説明されているように、Operator で Red Hat Quay を変更します。

追加リソース

  • Red Hat Quay Operator についての詳細は、アップストリームの quay-operator プロジェクトを参照してください。

第5章 Red Hat Quay クラスターのカスタマイズ

シークレットおよび QuayEcosystem カスタムリソースを作成するだけでデフォルトの Red Hat Quay 設定を実行できますが、以下のセクションではデフォルトの設定を変更する方法について説明します。

5.1. Red Hat Quay 認証情報の変更

Red Hat Quay Operator はデフォルトの管理認証情報を設定します。デフォルトのスーパーユーザーおよび設定認証情報を確認し、必要に応じて変更します。

5.1.1. Red Hat Quay スーパーユーザー認証情報

Red Hat Quay スーパーユーザー認証情報を使用すると、Red Hat Quay デプロイメントのユーザー、プロジェクト、およびその他のコンポーネントを管理できます。以下に、スーパーユーザー認証情報がデフォルトでどのように設定されているかを示します。

  • Username: quay
  • Password: password
  • Email: quay@redhat.com

スーパーユーザー認証情報を変更するには、新規のシークレットを作成します。

$ oc create secret generic <secret_name> \
   --from-literal=superuser-username=<username> \
   --from-literal=superuser-password=<password> \
   --from-literal=superuser-email=<email>

スーパーユーザーのパスワードは 8 文字以上である必要があります。

注記

各種のプロパティー間の一貫性を確保するために、QuayEcosystem オブジェクトの quay プロパティーの superusers フィールドを設定することが推奨されます。以下の Superusers セクションを参照してください。

5.1.2. Red Hat Quay 設定の認証情報

Red Hat Quay 専用デプロイメントは、Red Hat Quay 設定を管理するために実行されます。その設定へのルートを使用し、以下の認証情報でログインします。

  • Username: quayconfig
  • Password: quay

ユーザー名を変更することはできませんが、以下のようにパスワードを変更できます。

$ oc create secret generic quay-config-app \
      --from-literal=config-app-password=<password>

5.2. PostgreSQL データベースを使用した永続ストレージの提供

PostgreSQL リレーショナルデータベースは、デフォルトで Red Hat Quay の永続ストアとして使用されます。PostgreSQL は namespace 内の Operator によってデプロイされることも、既存のインスタンスを利用することもできます。現在の namespace 内でインスタンスのプロビジョニングを行うかどうかについては、 QuayEcosystem 内のサーバープロパティーが定義されているかどうかによって決まります。

以下のオプションは、PostgreSQL データベースを設定するのに利用できるオプションの一部です。

プロパティー

説明

image

データベースイメージの場所

volumeSize

Kubernetes の容量単位のボリュームのサイズ

注記

データベースの永続ストレージは、 volumeSize プロパティーが Operator によってプロビジョニングされる際に指定される場合にのみプロビジョニングされることに注意してください。

以下のように値を定義します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    database:
      volumeSize: 10Gi

5.3. データベース認証情報の指定

サーバーにアクセスするための認証情報は、Secret で指定されるか、または Operator によってプロビジョニングされる際に指定され、以下のデフォルト値を使用します。

  • Username: quay
  • Password: quay
  • Root Password: quayAdmin
  • Database Name: quay

代替値を定義するには、以下のようにシークレットを作成します。

oc create secret generic <secret_name> \
    --from-literal=database-username=<username> \
    --from-literal=database-password=<password> \
    --from-literal=database-root-password=<root-password> \
    --from-literal=database-name=<database-name>

以下に示されるように、QuayEcosystem カスタムリソースのシークレットの名前を参照します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    database:
      credentialsSecretName: <secret_name>

5.3.1. 既存の PostgreSQL データベースインスタンスの使用

Operator がプロジェクトに PostgreSQL のインスタンスをデプロイする代わりに、サーバーフィールドの場所と先のセクションで説明されているアクセスのための認証情報を指定して既存のインスタンスを利用できます。以下の例は、リモート PostgreSQL インスタンスへの接続を指定する方法を示しています。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    database:
      credentialsSecretName: <secret_name>
      server: postgresql.databases.example.com

5.4. レジストリーストレージバックエンドの選択

Red Hat Quay は、イメージの保管を目的として複数のバックエンドをサポートしており、各種のローカルおよびクラウドストレージオプションで設定されます。以下のセクションでは、これらのバックエンドを使用するように Red Hat Quay Operator を設定する方法の概要を説明します。

5.4.1. ストレージバックエンドの概要

Red Hat Quay のストレージは、バックエンドの配列が含まれる QuayEcosystem リソースの quay プロパティー内の registryBackend フィールドを使用して設定できます。複数のバックエンドを定義する機能は、イメージのレプリケーションと高可用性を可能にします。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: backend1
        s3:
        ...

registryBackend の定義はオプションのフィールドであり、省略される場合は、LocalStorage が設定されます (一時的。必要な場合は PersistentVolume を使用して有効にできます)。

5.4.2. 機密性の高いストレージの値

多くの場合、ストレージにアクセスするには、機密性の高い値を使用する必要があります。このような設定を必要とする各バックエンドは Secret に含まれ、バックエンドの credentialsSecretName プロパティー内で定義できます。

レジストリーバックエンドのプロパティーを特定のバックエンド内で宣言する代わりに、以下のように値をシークレットに追加することができます。

oc create secret generic s3-credentials \
   --from-literal=accessKey=<accessKey> \
   --from-literal=secretKey=<secretKey>

値がシークレットにある状態で、バックエンドで明示的に宣言されたプロパティーを削除することができます。

各バックエンドでサポートされるプロパティーのタイプに関する詳細は、以下のレジストリーバックエンドの詳細を参照してください。

5.4.3. ストレージのレプリケーション

レジストリーストレージを複数のバックエンドにレプリケートするためにサポートを利用できます。ストレージのレプリケーションを有効にするには、enableStorageReplication プロパティーを true の値に設定します。個々のレジストリーバックエンドは、 replicateByDefault プロパティーを true の値に設定することにより、デフォルトでレプリケートされるように設定することもできます。選択可能なレプリケーションオプションを示す詳細な設定が以下に表示されます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    enableStorageReplication: true
    registryBackends:
      - name: azure-ussouthcentral
        credentialsSecretName: azure-ussouthcentral-registry
        replicateByDefault: true
        azure:
          containerName: quay
      - name: azure-seasia
        credentialsSecretName: azure-seasia-registry
        replicateByDefault: true
        azure:
          containerName: quay
注記

レプリケートされたストレージのサポートはローカルレジストリーバックエンドには利用できず、検証フェーズでエラーが生じます。

5.4.4. レジストリーストレージバックエンドのタイプ

以下のレジストリーストレージバックエンドを 1 つ以上定義して、Red Hat Quay レジストリーの基礎となるストレージを指定できます。

5.4.4.1. ローカルストレージ

以下は、local ストレージを使用するようにレジストリーを設定する例です (ローカルストレージは実稼働デプロイメントではサポートされないことに注意してください)。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: local
        local:
          storagePath: /opt/quayregistry

以下は、local レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

サポートされる認証情報シークレット

必須

storagePath

ストレージディレクトリー

No

No

5.4.4.2. 永続ローカルストレージの設定

デフォルトでは、Red Hat Quay はローカルストレージに一時ボリュームを使用します。データの損失を回避するために、永続ストレージが必要です。PersistentVolume を使用してイメージを保存できるようにするには、quay プロパティーの下に registryStorage パラメーターを指定します。

以下の例では、PersistentVolumeClaim が 10Gi のストレージを要求するプロジェクトと ReadWriteOnce アクセスモードで作成されます。デフォルト値は ReadWriteMany です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    imagePullSecretName: redhat-pull-secret
    registryStorage:
      persistentVolumeAccessModes:
        - ReadWriteOnce
      persistentVolumeSize: 10Gi

また、ストレージクラスは persistentVolumeStorageClassName プロパティーを使用して指定できます。

5.4.4.3. Amazon Web Services (S3)

以下は、Amazon Web Services で S3 ストレージを使用するようにレジストリーを設定する例です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: s3
        s3:
          accessKey: <accessKey>
          bucketName: <bucketName>
          secretKey: <secretKey
          host: <host>

以下は、s3 レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

サポートされる認証情報シークレット

必須

storagePath

ストレージディレクトリー

No

No

bucketName

S3 バケット

No

Yes

accessKey

AWS アクセスキー

Yes

Yes

secretKey

AWS シークレットキー

Yes

Yes

host

S3 ホスト

No

No

port

S3 ポート

No

No

5.4.4.4. Microsoft Azure ストレージ

以下は、Microsoft Azure プラットフォームで Blob ストレージを使用するようにレジストリーを設定する例です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: azure
        azure:
          containerName: <containerName>
          accountName: <accountName>
          accountKey: <accountKey>

以下は、azure レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

認証情報シークレットのサポート

必須

storagePath

ストレージディレクトリー

No

No

containerName

Azure ストレージコンテナー

No

Yes

accountName

Azure アカウント名

No

Yes

accountKey

Azure アカウントキー

No

Yes

sas_token

Azure SAS トークン

No

No

5.4.4.5. Google Cloud storage

以下は、Google Cloud Platform で Blob ストレージを使用するようにレジストリーを設定する例です。

apiVersion: redhatcop.redhat.io/v1alpha1azure
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: googleCloud
        googleCloud:
        accessKey: <accessKey>
        secretKey: <secretKey>
        bucketName: <bucketName>

以下は、googlecloud レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

サポートされる認証情報シークレット

必須

storagePath

ストレージディレクトリー

No

No

accessKey

クラウドアクセスキー

Yes

Yes

secretKey

クラウドシークレットキー

Yes

Yes

bucketName

GCS バケット

No

Yes

5.4.4.6. NooBaa (RHOCS) ストレージ

以下は、NooBaa (Red Hat OpenShift Container Storage) ストレージを使用するようにレジストリーを設定する例です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: rhocs
        rhocs:
          hostname: <hostname>
          secure: <secure>
          accessKey: <accessKey>
          secretKey: <secretKey>
          bucketName: <bucketName>

以下は、rhocs レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

サポートされる認証情報シークレット

必須

storagePath

ストレージディレクトリー

No

No

hostname

NooBaa Server Hostname

No

Yes

port

カスタムポート

No

No

secure

セキュア (Is Secure)

No

No

secretKey

シークレットキー

Yes

Yes

bucketName

バケット名

No

Yes

5.4.4.7. RADOS ストレージ

以下は、RADOS ストレージを使用するようにレジストリーを設定する例です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: rados
        rados:
          hostname: <hostname>
          secure: <is_secure>
          accessKey: <accessKey>
          secretKey: <secretKey>
          bucketName: <bucketName>

以下は、rados レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

サポートされる認証情報シークレット

必須

storagePath

ストレージディレクトリー

No

No

hostname

RADOS サーバーホスト名

No

Yes

port

カスタムポート

No

No

secure

セキュア (Is Secure)

No

No

accessKey

アクセスキー

Yes

Yes

secretKey

シークレットキー

Yes

Yes

bucketName

バケット名

No

Yes

5.4.4.8. Swift (OpenStack) ストレージ

以下は、Swift ストレージを使用するようにレジストリーを設定する例です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: swift
        swift:
          authVersion: <authVersion>
          authURL: <authURL>
          container: <container>
          user: <user>
          password: <password>
          caCertPath: <caCertPath>
          osOptions:
            object_storage_url: <object_storage_url>
            user_domain_name: <user_domain_name>
            project_id: <project_id>

以下は、swift レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

サポートされる認証情報シークレット

必須

storagePath

ストレージディレクトリー

No

No

authVersion

Swift 認証バージョン

No

Yes

authURL

Swift 認証 URL

No

Yes

container

Swift コンテナー名

No

Yes

user

ユーザー名

Yes

Yes

password

キー/パスワード

Yes

Yes

caCertPath

CA 証明書ファイル名

No

No

tempURLKey

一時 URL キー

No

No

osOptions

OS オプション

Yes

Yes

5.4.4.9. CloudFront (S3) ストレージ

以下は、Amazon Web Services で S3 ストレージを使用するようにレジストリーを設定する例です。

注記

既知の問題により、CloudFront 設定は現在 CR を使用して行うことができません。ただし、Red Hat Quay Config Tool を使用してこれを管理することができます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    registryBackends:
      - name: s3
        s3:
          accessKey: <accessKey>
          bucketName: <bucketName>
          secretKey: <secretKey>
          host: <host>
          distributionDomain: <distributionDomain>
          key_ID: <key_ID>
          privateKeyFilename: <privateKeyFilename>

以下は、cloudfrontS3 レジストリーバックエンドのプロパティーの包括的な一覧です。

プロパティー

説明

サポートされる認証情報シークレット

必須

storagePath

ストレージディレクトリー

No

No

bucketName

S3 バケット

No

Yes

accessKey

AWS アクセスキー

Yes

Yes

secretKey

AWS シークレットキー

Yes

Yes

host

S3 ホスト

No

No

port

S3 ポート

No

No

distributionDomain

CloudFront ディストリビューションドメイン名

No

Yes

keyID

CloudFront キー ID

No

Yes

privateKeyFilename

CloudFront プライベートキー

No

Yes

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

Red Hat Quay は、外部レジストリーのコンテンツと完全に一致するコンテナーイメージリポジトリーを作成する機能を提供します。この機能は、以下のように enableRepoMirroring: true を設定して有効にできます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    enableRepoMirroring: true

以下の追加オプションも利用できます。

  • repoMirrorTLSVerify: HTTPS を必要とし、ミラーリング時に Quay レジストリーの証明書を検証します。
  • repoMirrorServerHostname: skopeo copy コマンドで使用される URL
  • repoMirrorEnvVars: リポジトリーミラーコンテナーに適用される環境変数
  • repoMirrorResources: リポジトリーミラーコンテナーに適用されるコンピュートリソース

5.6. 設定ファイルの挿入

Red Hat Quay および Clair の設定に関連するファイルは、起動時に挿入されるように指定できます。一般的な例としては、証明書、プライベートキー、および設定ファイルなどがあります。Quay Operator は、1 つ以上のアセットを指定できる QuayEcosystem オブジェクトの quay または clair プロパティーの configFiles プロパティー内でのこれらのアセットの挿入をサポートします。

type プロパティーでは、2 種類の設定ファイルを指定できます。

  • config: 設定ファイル
  • extraCaCert: quay コンテナーのよって信頼される証明書

以下の表は、configFiles が挿入される場所を示しています。

コンポーネント

タイプ

挿入する場所

Quay

config

Quay コンポーネントの /conf/stack ディレクトリーにマウントされます。

Quay

extraCaCert

追加の CA 証明書として自動的に処理される quay-enterprise-config-secret に追加されます。

Clair

config

/clair/config ディレクトリーに追加

Clair

extraCaCert

/etc/pki/ca-trust/source/anchors/ ディレクトリーに追加

設定ファイルは Secrets 内に値として保存されます。ここでは、この機能を活用できる方法をいくつか説明します。

最初のステップでは、これらのファイルが含まれるシークレットを作成します。以下のコマンドは、プライベートキーの追加方法を示しています。

$ oc create secret generic quayconfigfile --from-file=<path_to_file>

シークレットが作成されると、設定ファイルが含まれるシークレットを以下のように QuayEcosystem オブジェクトで参照できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    configFiles:
      - secretName: quayconfigfile

デフォルトでは、config タイプが想定されます。シークレットの内容に、信頼される証明書として追加する必要のある証明書が含まれる場合は、以下のようにそのタイプを extraCaCert として指定します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    configFiles:
      - secretName: quayconfigfile
        type: extraCaCert

シークレット内の個々のキーを参照し、以下のように files プロパティーを使用して設定に追加されるリソースを微調整できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    configFiles:
      - secretName: quayconfigfile
        files:
          - key: myprivatekey.pem
            filename: cloudfront.pem
          - key: myExtraCaCert.crt
            type: extraCaCert

上記の例では、2 つのファイルが quayconfigfile というシークレットに追加されていることが前提となっています。シークレットに追加されたファイル myprivatekey.pem は、パス /conf/stack/cloudfront.pem で quay pod にマウントされます。これは設定ファイルのタイプであり、Pod に展開される必要のあるカスタムファイル名を指定するためです。myExtraCaCert.crt ファイルは、パス /conf/stack/extra_certs/myExtraCert.crt 内の Quay pod に追加されます。

注記

files プロパティー内の type プロパティーは、configFiles プロパティーの値を上書きします。

5.7. 自動設定の省略

デフォルトで、Operator は Red Hat Quay の自動設定プロセスを完了するように設定されています。これは、以下に示されるように skipSetup フィールドを true に設定することで省略できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    skipSetup: true

5.8. 外部アクセスの方法

Ingress の数多くの OpenShift および Kubernetes の方法で Quay にアクセスするためのサポートを利用できます。OpenShift で実行されている場合、ルートLoadBalancer サービス および Ingress が使用されている場合に使用されます。

外部アクセスの設定を定義するプロパティーはすべて externalAccess プロパティー内で管理できます。外部アクセスのタイプを指定するには、以下の表で選択可能なオプションの 1 つを使用して、externalAccess 内に type プロパティーを設定します。

外部アクセスのタイプ

説明

Route

OpenShift ルート

OpenShift で実行されている場合にのみ指定できます。

LoadBalancer

LoadBalancer サービス

 

NodePort

NodePort サービス

dns ベースのホスト名または IP アドレスは、quay リソースの hostname プロパティーを使用して指定する 必要 があります。

Ingress

Ingress

外部アクセスについての Kubernetes ネイティブソリューション

type を指定する方法の例を以下に示します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    externalAccess:
      type: LoadBalancer

5.8.1. NodePorts

デフォルトで、NodePort タイプのサービスは 30000-32767 の間でランダムに割り当てられるネットワークポートが割り当てられます。リソースの予測的な割り当てをサポートするために、Quay および Quay Config の NodePort サービスは以下のように nodePort を使用して定義できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    externalAccess:
      type: NodePort
      nodePort: 30100
      hostname: quay.example.com

hostname フィールドは、Quay サーバーが利用可能になる場所 (DNS または IP) を参照するように指定する必要があります。必要に応じて、tke サービスに割り当てられるポート番号が自動的に追加されます。

5.8.2. Ingress

Ingress は OpenShift ルートと同様の概念を使用しますが、外部トラフィックを管理する Ingress コントローラーの別個のデプロイが必要です。さまざまな Ingress コントローラーを使用でき、実装に固有のプロパティーは、通常 Ingress リソースのアノテーションを使用して定義されます。

以下は、Nginx コントローラーに固有のアノテーションを使用して外部アクセスの Ingress タイプを定義する方法の例です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    externalAccess:
      type: Ingress
      annotations:
        nginx.ingress.kubernetes.io/ssl-passthrough: "true"
        nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
      hostname: quay.example.com

アノテーションは、configAnnotations プロパティーを使用して Config Ingress にも適用できます。

hostname フィールドは、Quay サーバーが利用可能になる場所を参照するように指定する必要があります。

5.9. Red Hat Quay ルートの指定

Red Hat Quay では、OpenShift ルートを使用して Ingress を有効にします。このルートのホスト名は、OpenShift クラスターの設定に応じて自動的に生成されます。または、このルートのホスト名は、以下に示すように hostname プロパティーを externalAccess フィールドで使用して明示的に指定できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    externalAccess:
      hostname: example-quayecosystem-quay-quay-enterprise.apps.openshift.example.com

5.10. Red Hat Quay 設定ルートの指定

開発プロセスで、Red Hat Quay サーバーのプロビジョニングおよび設定をテストする必要がある場合があります。デフォルトで、Operator は内部サービスを使用して設定 Pod と通信します。ただし、クラスターの外部で実行している場合は、設定プロセスが使用できるホスト名の場所を指定する必要があります。

configHostname を以下のように指定します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    externalAccess:
      configHostname: example-quayecosystem-quay-config-quay-enterprise.apps.openshift.example.com

5.11. SSL 証明書の指定

Red Hat Quay は、セキュアなレジストリーとして SSL 証明書を使用し、エコシステム内のさまざまなコンポーネント間の通信のセキュリティーを保護します。Quay ユーザーインターフェイスおよびコンテナーレジストリーへのトランスポートは SSL 証明書を使用して保護されます。これらの証明書は、OpenShift ルートが TLS 終端タイプの Passthrough で設定されている状態で起動時に生成されます。

5.11.1. ユーザーによって提供される証明書

Operator が証明書を生成する代わりに SSL 証明書を指定し、使用することができます。証明書はシークレットに指定でき、その後それは QuayEcosystem カスタムリソースで参照されます。

証明書とキーを含むシークレットを作成します。

oc create secret tls custom-quay-ssl \
   --key=<ssl_private_key> --cert<ssl_certificate>

証明書を含むシークレットは、以下に示すように externalAccess プロパティー内で定義されている tls というプロパティーの下の secretName を使用して参照されます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    externalAccess:
      tls:
        secretName: custom-quay-ssl
        termination: passthrough

5.12. TLS 終端

Red Hat Quay は、SSL 証明書を使用して接続を保護するように設定できます。デフォルトで、SSL 通信は Red Hat Quay で終了します。証明書の使用を完全に省略するなど、SSL 終端を設定する方法は複数あります。TLS 終端は、以下のように termination プロパティーによって決定されます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    externalAccess:
      tls:
        termination: passthrough

上記の例は、Red Hat Quay に適用されるデフォルト設定です。以下の表に示されるように、代替オプションを選択することもできます。

TLS 終端タイプ

説明

passthrough

SSL 通信が Quay で終了する

デフォルト設定

edge

SSL 通信が Quay に到達する前に終了するquay に到達するトラフィックは暗号化されない (HTTP)

 

none

すべての通信が暗号化されない

 

第6章 初期設定後の設定デプロイメント

デフォルトで、Red Hat Quay Config Tool Pod は、初期設定プロセス後も実行されたままになります。Config Tool Pod を設定後に削除されるように設定するには、Red Hat Quay オブジェクト内の keepConfigDeployment プロパティーを以下のように false に設定できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    keepConfigDeployment: false

6.1. スーパーユーザー

Quay のスーパーユーザーは、昇格した権限を持ち、サーバーを管理することができます。デフォルトでは、ユーザー名が quay のスーパーユーザーが作成されます。サーバーの管理を支援するために、追加のスーパーユーザーが必要になる場合があります。スーパーユーザーの詳細な一覧は、以下のように quay オブジェクトの superusers フィールドに指定することができます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    superusers:
      - jim
      - joe

複数のスーパーユーザーが指定されている場合、Red Hat Quay の初期セットアップ時に、前述のようにシークレット内で指定されない限り、指定される最初のユーザーが設定されます。初期設定後、パスワードは Red Hat Quay 自体で管理され、デフォルト値またはシークレットで指定される値は使用されません。

6.2. Redis パスワードの設定

デフォルトで、Operator で管理される Redis インスタンスは、パスワードなしでデプロイされます。パスワードを指定するには、キー password にパスワードを含むシークレットを作成して指定できます。以下のコマンドを使用してシークレットを作成できます。

$ oc create secret generic <secret_name> \
   --from-literal=password=<password>

シークレットは、次に示すように credentialsSecretName を使用して redis セクション内で指定できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  redis:
    credentialsSecretName: <secret_name>

6.3. Clair イメージスキャンの有効化

Clair は、アプリケーションコンテナーの脆弱性評価ツールです。Clair と Red Hat Quay との統合を自動的にプロビジョニングし、設定するためのサポートを利用できます。Clair をデプロイするために、このフィールド内で enabled:true と共に clair といるプロパティーを QuayEcosystem オブジェクトで指定できます。以下に例を示します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay: {}
  clair:
    enabled: true

Red Hat Quay Operator は、QuayEcosystem カスタムリソースにパラメーターが指定されていない場合に、パラメーター sslmode=disable で Clair データベース接続の文字列を設定します。SSL 対応 の Postgres データベースがある場合や他のパラメーターを追加する必要がある場合は、connectionParameters オブジェクトの下に key: value ペアを文字列として指定します (例: connect_timeout: '10')。

例を以下に示します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay: {}
  clair:
    enabled: true
    database:
      connectionParameters:
        sslmode: require
        connect_timeout: '10'

サポートされる接続文字列パラメーター:

  • sslmode: SSL を使用するかどうか (デフォルトは disable ですが、これは libpq のデフォルトではありません)
  • connect_timeout: 接続の最大待機時間 (秒単位)。ゼロまたは指定しない場合は、無制限に待機します。
  • sslcert: Cert ファイルの場所。このファイルには、PEM エンコードされたデータが含まれている必要があります。
  • SSLKey: キーファイルの場所。このファイルには、PEM エンコードされたデータが含まれている必要があります。
  • sslrootcert: ルート証明書ファイルの場所。このファイルには、PEM エンコードされたデータが含まれている必要があります。

sslmode の有効な値は以下の通りです。

  • disable: SSL なし
  • require: 常に SSL (検証を省略)
  • verify-ca: 常に SSL (サーバーによって提示される証明書が信頼される CA で署名されていることを検証する)
  • verify-full : 常に SSL (サーバーによって提示される証明が信頼される CA によって署名されており、サーバーホスト名が証明書の名前と一致することを検証する)

6.3.1. Clair の更新間隔

Clair は、独自の内部データベースを構築するために CVE データベースを定期的にクエリーします。デフォルトで、この値は 500m に設定されます。以下に示すように updateInterval プロパティーを設定して、チェックの時間間隔を変更できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay: {}
  clair:
    enabled: true
    updateInterval: "60m"

上記の設定では、Clair が 60 分ごとに更新されます。

6.4. 共通属性の設定

以下の各コンポーネントは、ランタイム実行をカスタマイズするために指定できる同様のプロパティーのセットを公開します。

  • Red Hat Quay
  • Red Hat Quay の設定
  • Red Hat Quay PostgreSQL
  • Redis
  • Clair
  • Clair PostgreSQL

6.4.1. イメージプルのシークレット

先のセクションで参照されているように、イメージのプルシークレットは、プロパティー imagePullSecret を使用して、保護されているレジストリーからイメージに対して認証情報が含まれるシークレットの名前を指定できます。

6.4.2. イメージ

Quay エコシステムの各コンポーネントの別のイメージまたはソースの場所を使用する必要がある場合があります。最も一般的なユースケースとしては、公共のインターネットから送信されるもののではなく、必要なイメージをすべて含むイメージレジストリーを使用することができます。各コンポーネントには、関連するイメージの場所を参照できる image というプロパティーがあります。

以下は、カスタマイズされたイメージの場所を指定する方法の例です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    image: myregistry.example.com/quay/quay:v99.1.0

6.4.3. コンピュートリソース

メモリーや CPU などの コンピュートリソース は、 PodTemplate の他の値と同じ形式で指定できます。requests および limits の CPU およびメモリーの値は、resources というプロパティーで指定できます。

注記

QuayConfiguration デプロイメントの場合、 configResources は、quay プロパティーの下で参照される必要のあるプロパティーです。

コンピュートリソースを指定する方法の例を以下に示します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    resources:
      requests:
        memory: 512Mi

6.4.4. プローブ

readiness および liveness プローブ は、PodTemplate の他の値と同じ形式で指定できます。

以下は、readinessProbe および livenessProbe を指定する方法です。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    livenessProbe:
      initialDelaySeconds: 120
      httpGet:
        path: /health/instance
        port: 8443
        scheme: HTTPS
    readinessProbe:
      initialDelaySeconds: 10
      httpGet:
        path: /health/instance
        port: 8443
        scheme: HTTPS
注記

いずれかのプロパティーの値が指定されていない場合は、事前に設定されたデフォルト値が適用されます。

6.4.5. ノードセレクター

QuayEcosystem のコンポーネントは、Kubernetes クラスターで利用可能なノードのサブセットのみにデプロイする必要がある場合があります。この機能は、以下のように nodeSelector プロパティーを使用して各リソースに設定できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    nodeSelector:
      node-role.kubernetes.io/infra: true

6.4.6. デプロイメントストラテジー

各コアコンポーネントは、Kubernetes Deployments で設定されています。このリソースは、新しいバージョンがリリースされる方法をサポートします。この Operator は、RollingUpdate および Recreate ストラテジーの使用をサポートします。いずれの値も、以下のように必要なリソースで deploymentStrategy プロパティーを使用して定義できます。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    deploymentStrategy: RollingUpdate
注記

定義された値がない場合は、 RollingUpdate ストラテジーを使用します。

6.4.7. 環境変数

Operator によって自動的に設定される環境変数のほかに、ユーザーは管理されるリソースをカスタマイズするために、独自の環境変数セットを定義できます。各コアコンポーネントには、環境変数を定義できる envVars というプロパティーが含まれます。以下に例を示します。

apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayEcosystem
metadata:
  name: example-quayecosystem
spec:
  quay:
    envVars:
      - name: FOO
        value: bar
注記

Quay 設定 Pod の環境変数は、quay リソースに configEnvVars プロパティーを指定して管理できます。

警告

ユーザー定義の環境変数は、Operator によって管理される環境変数よりも優先されます。競合するキーが使用されると、望ましくない結果が生じる可能性があります。

第7章 Red Hat Quay の設定 (デプロイメント後)

Quay Operator が Red Hat Quay をデプロイした後、デフォルトで Config Tool は実行を継続します。次に、Config Tool または Red Hat Quay Operator 自体を使用して Red Hat Quay デプロイメントを更新し、維持することができます。

7.1. 設定ツールの使用

Red Hat Quay Config Tool は、Red Hat Quay クラスターでの数多くの設定を有効にし、または変更するための Web UI を提供します。Config Tool を使用するには、以下を実行します。

  1. 以下を入力して Config Tool へのルートを取得します。

    $ oc get route
    NAME  HOST/PORT                                      PATH SERVICES PORT TERMINATION WILDCARD
    ...   example-quayecosystem-quay-config.example.com  ...
  2. Config Tool の HOST/PORT エントリーに https:// を追加し、これを Web ブラウザーに入力します。
  3. プロンプトが表示されたら、Config Tool のユーザー名およびパスワード (デフォルトでは quayconfig および quay) を使用してログインします。
  4. Modify configuration for this cluster を選択します。

この時点で、選択した設定を変更できます。これを実行した後に、Save Configuration Changes を選択します。以下は、Config Tool の使用について知っておく必要がある点になります。

  • 実行する大半の変更についてその正確さが確認されます。たとえば、サービスの場所を変更する場合、Config Tool は設定を保存する前にそのサービスに到達できることを確認します。設定が失敗すると、保存する前に設定を変更することができます。
  • 正確さを確認した後、変更の編集を継続するか、また変更を完了するかを選択できます。
  • 変更を加えてからそれらの変更が受け入れられると、それらはクラスター内のすべての Red Hat Quay インスタンスにデプロイされます。これらの Pod を手動で停止したり、再起動したりする必要はありません。

7.2. Red Hat Quay Operator の使用

Red Hat Quay Operator を使用して Red Hat Quay クラスターを更新すると、Web UI でクリックしなくても変更をデプロイすることができます。以下は、Operator での設定の変更について知っておく必要のある点になります。

  • Red Hat Quay Operator で直接設定を変更する場合、同じレベルのエラーチェックは実行されません。たとえば、サービスに誤ったアドレスを指定する場合、そのサービスへの接続は失敗する可能性があり、OpenShift 経由でその問題を追跡する必要があります。
  • 変更を行った後に、これらの変更は Red Hat Quay インスタンスに自動的に適用されません。変更を有効にするには、Red Hat Quay Pod を手動で再起動する必要があります。

第8章 トラブルシューティング

Operator の実行、設定、および使用の問題を解決するために、以下の手順を使用できます。

8.1. 初期セットアップ時のエラー

QuayEcosystem カスタムリソースは、Red Hat Quay のデプロイメントおよび設定のステータスの進捗状況の提供を試みます。以下に示すように、 config pod のログメッセージを表示して、セットアッププロセスのエラーに関する追加情報を見つけることができます。

$ oc logs $(oc get pods -l=quay-enterprise-component=config -o name)

OpenShift コンソールから、Red Hat Quay クラスター用に作成された Pod およびデプロイメントをたどることができます。

第9章 ローカル開発

以下の手順に従って、機能をローカルで開発できます。cluster-admin パーミッションを持つクラスターを使用して開発を行うことが推奨されます。

リポジトリーのクローンを作成してから、go mod を使用してすべての依存関係を解決します。

$ export GO111MODULE=on
$ go mod vendor

operator-sdk を使用して Operator をローカルに実行します。

$ operator-sdk up local --namespace=quay-enterprise

第10章 Red Hat Quay のアップグレード

Red Hat Quay Operator v3.3.4 には、v1.0.2 以降の多くの変更点があります。アップグレードプロセスに影響を及ぼす最も注目すべき点に、CRD に対する後方互換性のない変更があります。最終的に、Operator を使用して Red Hat Quay をデプロイするために使用される CR(カスタムリソース) は随時変更する必要がある場合があります。

10.1. アップグレードの前提条件

デプロイメントでサポートされている永続層およびデータベースを使用していることを確認します。

データベース。Operator によって実行される実稼働 Red Hat Quay デプロイメントは、Operator によって作成された Postgres インスタンスまたは OpenShift ボリュームに依存するべきでは ありません

Operator によって作成された Postgres インスタンスまたは OpenShift ボリュームを使用している場合、古い Operator の削除によってデータベースおよびボリュームの削除が段階的に実行されるため、アップグレードパスはサポートされません。データをサポートされているストレージメカニズムに手動で移行することはできますが、これは通常の、サポートされているアップグレードパスの範囲外です。

このアップグレードパスは破壊的な影響を与える可能性があり、ロールバックが保証されている訳ではないため、ステップを実施する前にガイド全体を確認してください。

10.2. アップグレードプロセスの概要

以下は、最初にデプロイした Red Hat Quay クラスターを v1.0.2 Quay Setup Operator から v3.3.4 Quay Operator にアップグレードするための基本的な手順です。

  1. 現在のデプロイメントに関連する設定をすべて文書化します。
  2. CR をコピーし、必要に応じて設定値を変更します。
  3. oc delete -f deployment.yaml を使用して現在のデプロイメントを削除します
  4. この Pod はクラスター全体をスケールアップする前に必要なデータベースの移行を実行するため、必ず 1 つの quay Pod のみが起動されるようにします。
  5. 古い Quay Operator (v1.0.2 以前) のアンインストール
  6. 最新の Quay Operator のインストール(v3.3.4)
  7. コマンド oc create -f new_deployment.yaml を実行して CR を作成します。
  8. すべての移行が完了するまで、quay Pod のログを監視します。
  9. この時点で、必要に応じて Red Hat Quay クラスターをスケールアップできます。

10.2.1. 既存の Red Hat Quay デプロイメントの文書化

スムーズなアップグレードを行うために、既存のデプロイメントを削除する 前に、使用可能なすべての設定の詳細があることを確認してください。Red Hat サポートに問い合わせる必要がある場合、この情報は、クラスターを元の状態に戻すのに必要な詳細として役に立ちます。少なくとも、以下の情報を収集する必要があります。

  1. 現在の Red Hat Quay デプロイメントの作成に使用されるカスタムリソース。
  2. プロジェクトまたは namespace で oc get QuayEcosystem -o yaml > quayecosystem.yaml を実行する際の出力。
  3. Quay、Clair、Quay の Config App、Postgres、Redis、および Clair の Postgres インスタンスへのアクセスに現在使用されているホスト名。これは、oc get routes -o yaml > old_routes.yaml または (loadbalancer を使用している場合は) oc get service を実行して得られます。
  4. Quay および Clair Pod の Postgres インスタンスへの接続に必要な認証情報の詳細。
  5. AWS S3 などのデータ永続プロバイダーへの接続に必要な認証情報の詳細。
  6. 必要な証明書と共に config.yaml を含む Red Hat Quay 設定シークレットのバックアップ。これは認証情報を使用して実行できます。

    $ oc get secret quay-enterprise-config-secret -o yaml > config-secret.yaml

10.2.2. CR の更新

変更を行う前に、元のカスタムリソース (CR) のバックアップが作成されていることを確認します。

デプロイメントで特定のネットワーク関連の設定値を指定しない場合、この手順は必要ない可能性があります。ドキュメントを参照し、現在の CR の設定オプションが Quay Operator v3.3.4 について依然として正確であることを確認してください。

LoadBalancer の使用やカスタムホスト名の指定など、ネットワークの管理に関連するオプションを指定している場合には、最新のドキュメントを参照して Quay Operator v3.3.4 に含まれるスキーマでこれらを更新してください。

Quay または Clair に使用されるイメージを上書きしている場合は、Quay Operator v3.3.4 はとくに Quay v3.3.4 および Clair v3.3.4 をサポートする点に留意してください。これらのイメージの上書きを削除して、デプロイメントでサポートされている最新の Quay および Clair を使用することが推奨されます。その他のイメージはサポートされない場合があります。

10.2.3. 既存のデプロイメントの削除

警告

この手順では、Red Hat Quay デプロイメント全体を削除します。十分な注意を払い、クラスターを再作成するために必要な手順をすべて理解してから、既存のデプロイメントを削除してください。

Quay Operator v3.3.4 は、公式の Red Hat チャンネルを使用して提供されるようになりました。以前のバージョンでは、Quay Operator v1.0.2(以下) はコミュニティーチャネルを使用して提供されていました。さらに、Red Hat Quay v3.3.4 は自動アップグレードパスを提供しないため、Red Hat Quay デプロイメントと Quay Operator を完全に削除し、置き換える必要があります。

ただし、重要なデータは Postgres データベースとストレージバックエンドに保存されるため、両方の適切なバックアップを確保することが推奨されます。

準備ができたら、以下のコマンドを実行して既存のデプロイメントを削除します。

$ oc delete -f deployment.yaml

Quay および Clair Pod はすべて Redis Pod と共に削除されます。この時点で、Red Hat Quay クラスターは完全に停止し、アクセスできなくなります。この期間はイメージにアクセスできなくなるため、ユーザーにメンテナーンス期間について通知することが推奨されます。

10.2.4. quay Pod のみが起動していることを確認します。

Red Hat Quay Pod を起動すると、それらはデータベースを参照し、必要なデータベーススキーマの変更がすべて適用されているかどうかを判別します。スキーマの変更が適用されていない場合(Red Hat Quay v3.2 から v3.3.4 へのアップグレード時にこの状態になる可能性が高い)、Quay Pod はすべての移行の実行を自動的に開始します。複数の Red Hat Quay インスタンスが同時に実行されている場合、すべてのインスタンスがデータベースを同時に更新したり、変更したりする可能性があり、これにより予期しない問題が生じる可能性があります。

移行が適切に実行されるようにするには、起動する Quay レプリカを複数指定しないでください。Quay Pod レプリカのデフォルトの数量は 1 であるため、これを変更しない限り、ここで行う必要のあることはありません。

10.2.5. Quay Operator のアンインストール

すべての Red Hat Quay 関連のデプロイメントおよび Pod が namespace 内に存在しないことを確認します。その他の Red Hat Quay デプロイメントがインストールされた Quay Operator v1.0.2(以前) に依存していないことを確認します。oc get pod および oc get deployment を入力し、これらが存在しないことを確認します。

OpenShift を使用して、 Operators > Installed Operators ページに移動します。UI には、Operator を削除するオプションが表示されます。

10.2.6. 新規 Quay Operator のインストール

以前のバージョンでは、Quay Operator(v1.0.2 以前) はコミュニティー版 Operator Hub カタログを使用して提供されていました。最新リリースでは、Quay Operator は公式の Red Hat チャンネルでリリースされます。

OpenShift コンソールで、 Operators > OperatorHub に移動してから、単純に Quay を検索します。複数の同様の結果がヒットする場合には、正しい Quay Operator v3.3.4 を選択してください。install をクリックし、Operator をインストールするために適切な namespace/プロジェクトを選択します。

10.2.7. デプロイメントの再作成

この時点で、このアップグレードプロセスに記載されている以前のステップに基づいて、以下のが前提とされています。

  1. CR が更新され、最新 Operator のスキーマ (CRD) の差分が反映されている。
  2. Quay Operator v3.3.4 がプロジェクト/namespace にインストールされている。
  3. Red Hat Quay のデプロイに必要なシークレットが存在する。
  4. CR は 1 つの Quay Pod レプリカを定義するか、または (デフォルトで 1 に設定される) Quay レプリカの数を指定しません。

準備が整ったら、以下のコマンドを実行して QuayEcosystem を作成します。

$ oc create -f new_deployment.yaml

この時点で、Quay Operator は Redis、Quay Config Application、および最後に (単一の) Quay Pod のデプロイを開始します。

10.2.8. データベーススキーマ更新の進捗のモニターリング

Quay v3.2 から Quay v3.3 にアップグレードする場合、Quay がデータベースにスキーマの更新を実行する必要があります。これらは Quay Pod のログで確認できます。

データベースの移行が完了していることを確認するまで、追加の手順を実行しないでください。

10.2.9. データベーススキーマ更新の進捗のモニターリング

Red Hat Quay v3.2 から Red Hat Quay v3.3 にアップグレードする場合、Quay がデータベースにスキーマの更新を実行する必要があります。これらは Quay Pod のログで確認できます。

データベースの移行が完了していることを確認するまで、追加の手順を実行しないでください。

注記

これらの移行は Pod のログの初期段階で実行されるため、それらについて見落とす可能性があります。

10.2.10. Red Hat Quay クラスターのアップグレードの最終処理

Red Hat Quay の最新リリースおよびオプションの Clair が Openshift クラスターにデプロイされるため、必要に応じて設定とスケーリングを検証することができます。

このプロセスの最初のステップで収集された文書を参照し、現在の設定の結果を設定と比較できます。

プロセス。ホスト名に細心の注意を払い、すべてのログを確認し、Quay Operator によって指摘またはキャッチされていない可能性のある問題について検索します。

また、お使いの環境でスモークテストを手短に実行し、主要な機能が予想通りに機能することを確認することも推奨されています。1 つのテスト例として、既存および新規イメージでレジストリーからのプッシュおよびプルを実行することが含まれます。別のとして、登録ユーザーとして Red Hat Quay UI にアクセスし、予想される TLS 証明書が使用されることを確認できます。

予想される TLS 証明書が使用されていることを確認します。Quay Operator を使用して自己署名 TLS 証明書を生成する場合は、新規証明書がこのプロセスで作成されている可能性があることに注意してください。

Red Hat Quay レジストリーのスケーリングに複数のレプリカが必要な場合、レプリカ数を必要な数に変更することができます。たとえば、quay pod をスケールアウトするには、oc edit quayecosystem demo-quayecosystem を実行してから、 replicas: 1replicas: 2、またはその他の必要な数に変更します。

最後に、設定を保存し、関連する OpenShift シークレットは安全で、可能であれば暗号化されたバックアップに置かれることが推奨されます。

関連する OpenShift シークレットは、安全な、暗号化されたバックアップです。

第11章 Red Hat Quay の使用開始

Red Hat Quay の実行により、以下が可能になります。

  • Quay ホームページから Tutorial を選択し、15 分間のチュートリアルを試します。チュートリアルでは、Quay にログインし、コンテナーを起動し、イメージを作成し、リポジトリーを表示し、Quay でリポジトリーのパーミッションを変更する方法について確認できます。
  • Red Hat Quay リポジトリーの使用方法については、Use Red Hat Quay を参照してください。

その他のリソース