16.2.2.4. GitOps ZTP を使用した OADP Operator のインストールと設定
アップグレードを開始する前に、GitOps ZTP を使用して OADP Operator をインストールして設定します。
手順
ztp-site-generateコンテナーイメージから次の CR を抽出し、source-crディレクトリーにプッシュします。OadpSubscriptionNS.yamlファイルの例:apiVersion: v1 kind: Namespace metadata: name: openshift-adp annotations: ran.openshift.io/ztp-deploy-wave: "2" labels: kubernetes.io/metadata.name: openshift-adpOadpSubscriptionOperaGroup.yamlファイルの例:apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: redhat-oadp-operator namespace: openshift-adp annotations: ran.openshift.io/ztp-deploy-wave: "2" spec: targetNamespaces: - openshift-adpOadpSubscription.yamlファイルの例:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: redhat-oadp-operator namespace: openshift-adp annotations: ran.openshift.io/ztp-deploy-wave: "2" spec: channel: stable-1.4 name: redhat-oadp-operator source: redhat-operators sourceNamespace: openshift-marketplace installPlanApproval: Manual status: state: AtLatestKnownOadpOperatorStatus.yamlファイルの例:apiVersion: operators.coreos.com/v1 kind: Operator metadata: name: redhat-oadp-operator.openshift-adp annotations: ran.openshift.io/ztp-deploy-wave: "2" status: components: refs: - kind: Subscription namespace: openshift-adp conditions: - type: CatalogSourcesUnhealthy status: "False" - kind: InstallPlan namespace: openshift-adp conditions: - type: Installed status: "True" - kind: ClusterServiceVersion namespace: openshift-adp conditions: - type: Succeeded status: "True" reason: InstallSucceededディレクトリー構造の例:
├── kustomization.yaml ├── sno │ ├── example-cnf.yaml │ ├── common-ranGen.yaml │ ├── group-du-sno-ranGen.yaml │ ├── group-du-sno-validator-ranGen.yaml │ └── ns.yaml ├── source-crs │ ├── OadpSubscriptionNS.yaml │ ├── OadpSubscriptionOperGroup.yaml │ ├── OadpSubscription.yaml │ ├── OadpOperatorStatus.yaml共通の
PolicyGenTemplateに CR を追加します。apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: name: "example-common-latest" namespace: "ztp-common" spec: bindingRules: common: "true" du-profile: "latest" sourceFiles: - fileName: OadpSubscriptionNS.yaml policyName: "subscriptions-policy" - fileName: OadpSubscriptionOperGroup.yaml policyName: "subscriptions-policy" - fileName: OadpSubscription.yaml policyName: "subscriptions-policy" - fileName: OadpOperatorStatus.yaml policyName: "subscriptions-policy" [...]ターゲットクラスター専用の
DataProtectionApplicationCR と S3 シークレットを作成します。ztp-site-generateコンテナーイメージから次の CR を抽出し、source-crディレクトリーにプッシュします。OadpDataProtectionApplication.yamlファイルの例:apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dataprotectionapplication namespace: openshift-adp annotations: ran.openshift.io/ztp-deploy-wave: "100" spec: configuration: restic: enable: false velero: defaultPlugins: - aws - openshift resourceTimeout: 10m backupLocations: - velero: config: profile: "default" region: minio s3Url: $url insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" provider: aws default: true credential: key: cloud name: cloud-credentials objectStorage: bucket: $bucketName prefix: $prefixName status: conditions: - reason: Complete status: "True" type: Reconciled-
イメージベースのアップグレードでは、永続ボリュームの内容がアップグレード後も保持され再利用されるため、
spec.configuration.restic.enable をfalseに設定する必要があります。 -
bucket は、S3 バックエンドで作成されるバケット名を定義します。プレフィックスは、バケット内に自動的に作成されるサブディレクトリーの名前を定義します。バケットと接頭辞の組み合わせは、それらの間の干渉を避けるために、各ターゲットクラスターごとに一意である必要があります。各ターゲットクラスターに一意のストレージディレクトリーを確保するには、Red Hat Advanced Cluster Management のハブテンプレート機能を使用できます (例:prefix: {{hub .ManagedClusterName hub}})。
OadpSecret.yamlファイルの例:apiVersion: v1 kind: Secret metadata: name: cloud-credentials namespace: openshift-adp annotations: ran.openshift.io/ztp-deploy-wave: "100" type: OpaqueOadpBackupStorageLocationStatus.yamlファイルの例:apiVersion: velero.io/v1 kind: BackupStorageLocation metadata: name: dataprotectionapplication-1 namespace: openshift-adp annotations: ran.openshift.io/ztp-deploy-wave: "100" status: phase: AvailableBackupStorageLocationリソースの名前の値は、対応するDataProtectionApplicationリソースと一致する特定の命名規則に従う必要があります。-
名前は
、<DataProtectionApplication.metadata.name>-<index> のパターンを使用する必要があります。 -
<index>は、DataProtectionApplicationリソースのspec.backupLocationsフィールド内の対応するエントリーの位置を表します。ポジションは1から始まります。 -
OadpDataProtectionApplication.yamlファイル内のDataProtectionApplicationリソースのmetadata.name値を変更する場合は、BackupStorageLocationリソースのmetadata.nameフィールドも新しい値に合わせて更新する必要があります。
OadpBackupStorageLocationStatus.yamlCR は、OADP によって作成されたバックアップストレージの場所の可用性を確認します。-
イメージベースのアップグレードでは、永続ボリュームの内容がアップグレード後も保持され再利用されるため、
オーバーライドを使用して、サイトの
PolicyGenTemplateに CR を追加します。apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: name: "example-cnf" namespace: "ztp-site" spec: bindingRules: sites: "example-cnf" du-profile: "latest" mcp: "master" sourceFiles: ... - fileName: OadpSecret.yaml policyName: "config-policy" data: cloud: <your_credentials> - fileName: OadpDataProtectionApplication.yaml policyName: "config-policy" spec: backupLocations: - velero: config: region: minio s3Url: <your_S3_URL> profile: "default" insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" provider: aws default: true credential: key: cloud name: cloud-credentials objectStorage: bucket: <your_bucket_name> prefix: <cluster_name> - fileName: OadpBackupStorageLocationStatus.yaml policyName: "config-policy"
ここでは、以下のようになります。
あなたの認証情報- S3 ストレージバックエンドの認証情報を指定します。
OadpDataProtectionApplication.yaml-
OadpDataProtectionApplicationCR に複数のbackupLocationsエントリーが定義されている場合は、ステータス追跡のために、対応するOadpBackupStorageLocationCR がそれぞれの場所に追加されていることを確認します。追加の各OadpBackupStorageLocationCR の名前が、OadpBackupStorageLocationStatus.yamlファイルの例で説明されている正しいインデックスでオーバーライドされていることを確認してください。 あなたの S3URL- S3 互換バケットの URL を指定します。
バケットとプレフィックス-
bucketは、S3 バックエンドで作成されるバケット名を定義します。prefixは、bucket内に自動的に作成されるサブディレクトリーの名前を定義します。bucketとprefixの組み合わせは、それらの間の干渉を避けるために、各ターゲットクラスターごとに一意である必要があります。各ターゲットクラスターに一意のストレージディレクトリーを確保するには、Red Hat Advanced Cluster Management のハブテンプレート機能を使用できます (例:prefix: {{hub .ManagedClusterName hub}})。