Quay Operator の使用による OpenShift への Red Hat Quay のデプロイ
Quay Setup 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 クラウドストレージを作成することもできます。以下は、サポートされているその他のクラウドストレージの一覧です。
- Amazon S3(Red Hat Quay の S3 バケットポリシーの設定に関する詳細は、S3 IAM バケットポリシー を参照してください)
- Azure Blob Storage
- Google Cloud Storage
- Ceph Object Gateway (RADOS)
- OpenStack Swift
- CloudFront + S3
- OpenShift Container Storage (NooBaa S3 Storage).(Configuring Red Hat OpenShift Container Storage for Red Hat Quay を参照してください)
サービス: 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 のインストール
- OpenShift コンソールから、Red Hat Quay を実行する新規 namespace を作成します。たとえば、Projects → Create Project と選択します。次に、名前 (この例では quay-enterprise が使用されます) を入力します。また、任意で Display Name および Description を入力します。次に、Create をクリックします。
- Operators → OperatorHub を選択し、Red Hat Quay Operator を選択します。コミュニティーバージョンが複数ある場合は、必ず Red Hat 認定 Operator を使用するようにし、コミュニティーバージョンは使用しないでください。
- Install を選択します。 Operator Subscription ページが表示されます。
以下を選択して Subscribe を選択します。
- Installation Mode: インストールする特定の namespace を選択します (デフォルトは quay-enterprise)。
- Update Channel: 更新チャネルの選択します (1 つのみ選択可能)。
- Approval Strategy: 自動の更新または手動の更新を承認するよう選択します。
- Subscribe を選択します。
4.3. Red Hat Quay エコシステムのデプロイ
- Quay.io から Quay および Clair コンテナーを取得するのに必要な認証情報を取得する方法については、Accessing Red Hat Quay のアーティクルを参照してください。次に、これらの認証情報をファイルに入れます。この例では、ローカルディレクトリーに config.json を作成します。
Red Hat Quay のデプロイに選択したプロジェクト (namespace) に移動します。
$ oc project quay-enterprise
以下のように、認証情報が含まれるシークレットを作成します。
$ oc create secret generic redhat-pull-secret \ --from-file=".dockerconfigjson=config.json" --type='kubernetes.io/dockerconfigjson'
カスタムリソースファイル (この例では、
quayecosystem_cr.yaml
) を作成するか、または quay-operator examples ページからこれをコピーします。この例では、デフォルト設定を使用します。apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayEcosystem metadata: name: example-quayecosystem spec: quay: imagePullSecretName: redhat-pull-secret
-
Customizing your Red Hat Quay cluster
セクションを確認し、変更する設定を選択します。 以下のように、カスタムリソースファイルから Quay エコシステムをデプロイします。
$ oc create -f quayecosystem_cr.yaml
カスタムリソースをデプロイすると、Red Hat Quay、PostgreSQL、および Redis サービスを含む Red Hat Quay クラスターが自動的に作成され、設定されます。
Red Hat Quay クラスターのステータスを確認するには、OpenShift Web コンソールにログインし、Projects を選択して
quay-enterprise
プロジェクトを選択して以下を確認します。
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 |
|
Quay コンポーネントの |
Quay |
|
追加の CA 証明書として自動的に処理される |
Clair |
|
|
Clair |
|
|
設定ファイルは 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
プロパティーを設定します。
外部アクセスのタイプ | 説明 | 注 |
| OpenShift で実行されている場合にのみ指定できます。 | |
| ||
|
dns ベースのホスト名または IP アドレスは、 | |
| 外部アクセスについての 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 を使用するには、以下を実行します。
以下を入力して Config Tool へのルートを取得します。
$ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ... example-quayecosystem-quay-config.example.com ...
-
Config Tool の HOST/PORT エントリーに
https://
を追加し、これを Web ブラウザーに入力します。 -
プロンプトが表示されたら、Config Tool のユーザー名およびパスワード (デフォルトでは
quayconfig
およびquay
) を使用してログインします。 -
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 にアップグレードするための基本的な手順です。
- 現在のデプロイメントに関連する設定をすべて文書化します。
- CR をコピーし、必要に応じて設定値を変更します。
-
oc delete -f deployment.yaml
を使用して現在のデプロイメントを削除します - この Pod はクラスター全体をスケールアップする前に必要なデータベースの移行を実行するため、必ず 1 つの quay Pod のみが起動されるようにします。
- 古い Quay Operator (v1.0.2 以前) のアンインストール
- 最新の Quay Operator のインストール(v3.3.4)
-
コマンド
oc create -f new_deployment.yaml
を実行して CR を作成します。 - すべての移行が完了するまで、quay Pod のログを監視します。
- この時点で、必要に応じて Red Hat Quay クラスターをスケールアップできます。
10.2.1. 既存の Red Hat Quay デプロイメントの文書化
スムーズなアップグレードを行うために、既存のデプロイメントを削除する 前に、使用可能なすべての設定の詳細があることを確認してください。Red Hat サポートに問い合わせる必要がある場合、この情報は、クラスターを元の状態に戻すのに必要な詳細として役に立ちます。少なくとも、以下の情報を収集する必要があります。
- 現在の Red Hat Quay デプロイメントの作成に使用されるカスタムリソース。
-
プロジェクトまたは namespace で
oc get QuayEcosystem -o yaml > quayecosystem.yaml
を実行する際の出力。 -
Quay、Clair、Quay の Config App、Postgres、Redis、および Clair の Postgres インスタンスへのアクセスに現在使用されているホスト名。これは、
oc get routes -o yaml > old_routes.yaml
または (loadbalancer を使用している場合は)oc get service
を実行して得られます。 - Quay および Clair Pod の Postgres インスタンスへの接続に必要な認証情報の詳細。
- AWS S3 などのデータ永続プロバイダーへの接続に必要な認証情報の詳細。
必要な証明書と共に
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. デプロイメントの再作成
この時点で、このアップグレードプロセスに記載されている以前のステップに基づいて、以下のが前提とされています。
- CR が更新され、最新 Operator のスキーマ (CRD) の差分が反映されている。
- Quay Operator v3.3.4 がプロジェクト/namespace にインストールされている。
- Red Hat Quay のデプロイに必要なシークレットが存在する。
- 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: 1
を replicas: 2
、またはその他の必要な数に変更します。
最後に、設定を保存し、関連する OpenShift シークレットは安全で、可能であれば暗号化されたバックアップに置かれることが推奨されます。
関連する OpenShift シークレットは、安全な、暗号化されたバックアップです。
第11章 Red Hat Quay の使用開始
Red Hat Quay の実行により、以下が可能になります。
- Quay ホームページから Tutorial を選択し、15 分間のチュートリアルを試します。チュートリアルでは、Quay にログインし、コンテナーを起動し、イメージを作成し、リポジトリーを表示し、Quay でリポジトリーのパーミッションを変更する方法について確認できます。
- Red Hat Quay リポジトリーの使用方法については、Use Red Hat Quay を参照してください。