19.12. GitOps ZTP の更新
GitOps Zero Touch Provisioning (ZTP) インフラストラクチャーは、ハブクラスター、Red Hat Advanced Cluster Management (RHACM)、および OpenShift Container Platform マネージドクラスターとは別に更新できます。
新しいバージョンが利用可能になったら、Red Hat OpenShift GitOps Operator を更新できます。GitOps ZTP プラグインを更新するときは、参照設定で更新されたファイルを確認し、変更が要件を満たしていることを確認してください。
19.12.1. GitOps ZTP 更新プロセスの概要
以前のバージョンの GitOps ZTP インフラストラクチャーを実行している、完全に機能するハブクラスターの GitOps Zero Touch Provisioning (ZTP) を更新できます。更新プロセスにより、マネージドクラスターへの影響が回避されます。
推奨コンテンツの追加など、ポリシー設定を変更すると、更新されたポリシーが作成され、マネージドクラスターにロールアウトして調整する必要があります。
GitOps ZTP インフラストラクチャーを更新するためのストラテジーの概要は次のとおりです。
-
既存のすべてのクラスターに
ztp-done
ラベルを付けます。 - ArgoCD アプリケーションを停止します。
- 新しい GitOps ZTP ツールをインストールします。
- Git リポジトリーで必要なコンテンツおよびオプションの変更を更新します。
- アプリケーション設定を更新して再起動します。
19.12.2. アップグレードの準備
次の手順を使用して、GitOps Zero Touch Provisioning (ZTP) アップグレードのためにサイトを準備します。
手順
- GitOps ZTP で使用するために Red Hat OpenShift GitOps を設定するために使用されるカスタムリソース (CR) を持つ GitOps ZTP コンテナーの最新バージョンを取得します。
次のコマンドを使用して、
argocd/deployment
ディレクトリーを抽出します。$ mkdir -p ./update
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13 extract /home/ztp --tar | tar x -C ./update
/update
ディレクトリーには、次のサブディレクトリーが含まれています。-
update/extra-manifest
:SiteConfig
CR が追加のマニフェストconfigMap
を生成するために使用するソース CR ファイルが含まれています。 -
update/source-crs
には、PolicyGenTemplate
CR が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれています。 -
update/argocd/deployment
には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。 -
update/argocd/example
: 推奨される設定を表すSiteConfig
およびPolicyGenTemplate
ファイルの例が含まれています。
-
clusters-app.yaml
ファイルおよびpolicies-app.yaml
ファイルを更新して、Git リポジトリーのアプリケーションおよび URL、ブランチ、およびパスを反映します。アップグレードにポリシーの廃止につながる変更が含まれている場合は、アップグレードを実行する前に、廃止されたポリシーを削除する必要があります。
/update
フォルダー内の設定およびデプロイソース CR と、フリートサイト CR を管理する Git リポジトリーとの間の変更を比較します。必要な変更をサイトリポジトリーに適用してプッシュします。重要GitOps ZTP を最新バージョンに更新するときは、
update/argocd/deployment
ディレクトリーからサイトリポジトリーに変更を適用する必要があります。古いバージョンのargocd/deployment/
ファイルは使用しないでください。
19.12.3. 既存クラスターのラベル付け
既存のクラスターがツールの更新の影響を受けないようにするには、既存のすべてのマネージドクラスターに ztp-done
ラベルを付けます。
この手順は、Topology Aware Lifecycle Manager (TALM) でプロビジョニングされていないクラスターを更新する場合にのみ適用されます。TALM でプロビジョニングするクラスターには、自動的に ztp-done
というラベルが付けられます。
手順
local-cluster!=true
など、GitOps Zero Touch Provisioning (ZTP) でデプロイされたマネージドクラスターを一覧表示するラベルセレクターを見つけます。$ oc get managedcluster -l 'local-cluster!=true'
結果のリストに、GitOps ZTP でデプロイされたすべてのマネージドクラスターが含まれていることを確認してから、そのセレクターを使用して
ztp-done
ラベルを追加します。$ oc label managedcluster -l 'local-cluster!=true' ztp-done=
19.12.4. 既存の GitOps ZTP アプリケーションの停止
既存のアプリケーションを削除すると、Git リポジトリー内の既存のコンテンツに対する変更は、ツールの新しいバージョンが利用可能になるまでロールアウトされません。
deployment
ディレクトリーからのアプリケーションファイルを使用します。アプリケーションにカスタム名を使用した場合は、まずこれらのファイルの名前を更新します。
手順
clusters
アプリケーションで非カスケード削除を実行して、生成されたすべてのリソースをそのまま残します。$ oc delete -f update/argocd/deployment/clusters-app.yaml
policies
アプリケーションでカスケード削除を実行して、以前のすべてのポリシーを削除します。$ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge
$ oc delete -f update/argocd/deployment/policies-app.yaml
19.12.5. Git リポジトリーに必要な変更
ztp-site-generate
コンテナーを以前のリリースの GitOps Zero Touch Provisioning (ZTP) から 4.10 以降にアップグレードする場合は、Git リポジトリーのコンテンツに関する追加の要件があります。これらの変更を反映するには、リポジトリー内の既存のコンテンツを更新する必要があります。
PolicyGenTemplate
ファイルに必要な変更を加えます。すべての
PolicyGenTemplate
ファイルは、ztp
で始まるNamespace
で作成する必要があります。これにより、GitOps ZTP アプリケーションは、Red Hat Advanced Cluster Management (RHACM) が内部でポリシーを管理する方法と競合することなく、GitOps ZTP によって生成されたポリシー CR を管理できるようになります。kustomization.yaml
ファイルをリポジトリーに追加します。すべての
SiteConfig
およびPolicyGenTemplate
CR は、それぞれのディレクトリー ツリーの下にあるkustomization.yaml
ファイルに含める必要があります。以下に例を示します。├── policygentemplates │ ├── site1-ns.yaml │ ├── site1.yaml │ ├── site2-ns.yaml │ ├── site2.yaml │ ├── common-ns.yaml │ ├── common-ranGen.yaml │ ├── group-du-sno-ranGen-ns.yaml │ ├── group-du-sno-ranGen.yaml │ └── kustomization.yaml └── siteconfig ├── site1.yaml ├── site2.yaml └── kustomization.yaml
注記generator
セクションにリストされているファイルには、SiteConfig
またはPolicyGenTemplate
CR のみが含まれている必要があります。既存の YAML ファイルにNamespace
などの他の CR が含まれている場合、これらの他の CR を別のファイルに取り出して、resources
セクションにリストする必要があります。PolicyGenTemplate
kustomization ファイルには、すべてのPolicyGenTemplate
YAML ファイルがgenerator
セクションに含まれ、Namespace
CR がresource
セクションに含まれている必要があります。以下に例を示します。apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: - common-ranGen.yaml - group-du-sno-ranGen.yaml - site1.yaml - site2.yaml resources: - common-ns.yaml - group-du-sno-ranGen-ns.yaml - site1-ns.yaml - site2-ns.yaml
SiteConfig
kustomization ファイルには、すべてのSiteConfig
YAML ファイルがgenerator
セクションおよびリソースの他の CR に含まれている必要があります。apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: - site1.yaml - site2.yaml
pre-sync.yaml
ファイルおよびpost-sync.yaml
ファイルを削除します。OpenShift Container Platform 4.10 以降では、
pre-sync.yaml
およびpost-sync.yaml
ファイルは不要になりました。update/deployment/kustomization.yaml
CR は、ハブクラスターでのポリシーのデプロイを管理します。注記SiteConfig
ツリーとPolicyGenTemplate
ツリーの両方の下に、一連のpre-sync.yaml
ファイルおよびpost-sync.yaml
ファイルがあります。推奨される変更の確認および組み込み
各リリースには、デプロイされたクラスターに適用される設定に推奨される追加の変更が含まれる場合があります。通常、これらの変更により、OpenShift プラットフォーム、追加機能、またはプラットフォームのチューニングが改善された CPU の使用率が低下します。
ネットワーク内のクラスターのタイプに適用可能なリファレンス
SiteConfig
およびPolicyGenTemplate
CR を確認します。これらの例は、GitOps ZTP コンテナーから抽出したargocd/example
ディレクトリーにあります。
19.12.6. 新規 GitOps ZTP アプリケーションのインストール
展開した argocd/deployment
ディレクトリーを使用し、アプリケーションがサイトの Git リポジトリーをポイントすることを確認してから、deployment ディレクトリーの完全なコンテンツを適用します。ディレクトリーのすべての内容を適用すると、アプリケーションに必要なすべてのリソースが正しく設定されます。
手順
update/argocd/deployment/
ディレクトリーに以前に展開したパッチファイルを使用して、ハブクラスターの ArgoCD インスタンスにパッチを適用するには、以下のコマンドを入力します。$ oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file update/argocd/deployment/argocd-openshift-gitops-patch.json
argocd/deployment
ディレクトリーの内容を適用するには、以下のコマンドを入力します。$ oc apply -k update/argocd/deployment
19.12.7. GitOps ZTP 設定の変更のロールアウト
推奨される変更を実装したために設定の変更がアップグレードに含まれていた場合、アップグレードプロセスの結果、ハブクラスターの一連のポリシー CR が Non-Compliant
状態になります。GitOps Zero Touch Provisioning (ZTP) バージョン 4.10 以降の ztp-site-generate
コンテナーの場合、これらのポリシーは inform
モードに設定されており、ユーザーが追加の手順を実行しないとマネージドクラスターにプッシュされません。これにより、クラスターへの潜在的に破壊的な変更を、メンテナンスウィンドウなどでいつ変更が行われたか、および同時に更新されるクラスターの数に関して管理できるようになります。
変更をロールアウトするには、TALM ドキュメントの詳細に従って、1 つ以上の ClusterGroupUpgrade
CR を作成します。CR には、スポーククラスターにプッシュする Non-Compliant
ポリシーのリストと、更新に含めるクラスターのリストまたはセレクターが含まれている必要があります。
関連情報
- Topology Aware Lifecycle Manager (TALM) については、Topology Aware Lifecycle Manager 設定について を参照してください。
-
ClusterGroupUpgrade
CR の作成は、自動作成された ZTP の ClusterGroupUpgrade CR について を参照してください。