22.9. SiteConfig リソースを使用した高度なマネージドクラスター設定
				SiteConfig カスタムリソース (CR) を使用して、インストール時にマネージドクラスターにカスタム機能と設定をデプロイできます。
			
22.9.1. GitOps ZTP パイプラインでの追加インストールマニフェストのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
					GitOps Zero Touch Provisioning (ZTP) パイプラインのインストールフェーズに追加するマニフェストセットを定義できます。これらのマニフェストは SiteConfig カスタムリソース (CR) にリンクされ、インストール時にクラスターに適用されます。インストール時に MachineConfig CR を含めると、インストール作業が効率的になります。
				
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
 
手順
- GitOps ZTP パイプラインがクラスターインストールのカスタマイズ使用する、追加のマニフェスト CR のセットを作成します。
 カスタム
/siteconfigディレクトリーに、追加のマニフェスト用のサブディレクトリー/custom-manifestを作成します。以下の例は、/custom-manifestフォルダーを持つ/siteconfigのサンプルを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記全体で使用されているサブディレクトリー名
/custom-manifestおよび/extra-manifestは、名前の例にすぎません。これらの名前を使用する必要はなく、これらのサブディレクトリーに名前を付ける方法に制限はありません。この例では、/extra-manifestは、ztp-site-generateコンテナーの/extra-manifestの内容を保存する Git サブディレクトリーを指します。- 
							カスタムの追加マニフェスト CR を 
siteconfig/custom-manifestディレクトリーに追加します。 SiteConfigCR で、extraManifests.searchPathsフィールドにディレクトリー名を入力します。例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 
							
SiteConfig、/extra-manifest、および/custom-manifestCR を保存し、サイト設定リポジトリーにプッシュします。 
					クラスターのプロビジョニング中に、GitOps ZTP パイプラインは、/custom-manifest ディレクトリー内の CR を、extra-manifest/ に保存されている追加マニフェストのデフォルトのセットに追加します。
				
						バージョン 4.14 以降、extraManifestPath には非推奨の警告が表示されます。
					
						extraManifestPath は引き続きサポートされていますが、extraManifests.searchPaths を使用することを推奨します。SiteConfig ファイルで extraManifests.searchPaths を定義すると、GitOps ZTP パイプラインはサイトのインストール中に ztp-site-generate コンテナーからマニフェストを取得しません。
					
						Siteconfig CR で extraManifestPath と extraManifests.searchPaths の両方を定義した場合は、extraManifests.searchPaths に定義された設定が優先されます。
					
						/extra-manifest の内容を ztp-site-generate コンテナーから抽出し、GIT リポジトリーにプッシュすることを強く推奨します。
					
22.9.2. SiteConfig フィルターを使用したカスタムリソースのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
					フィルターを使用すると、SiteConfig カスタムリソース (CR) を簡単にカスタマイズして、GitOps Zero Touch Provisioning (ZTP) パイプラインのインストールフェーズで使用する他の CR を追加または除外できます。
				
					SiteConfig CR の inclusionDefault 値として include または exclude を指定し、さらに、含めたり除外したりする特定の extraManifest RAN CR のリストを指定することもできます。inclusionDefault を include に設定すると、GitOps ZTP パイプラインはインストール中に /source-crs/extra-manifest 内のすべてのファイルを適用します。inclusionDefault を exclude に設定すると、その逆になります。
				
					デフォルトで含まれている /source-crs/extra-manifest フォルダーから個々の CR を除外できます。以下の例では、インストール時に /source-crs/extra-manifest/03-sctp-machine-config-worker.yaml CR を除外するようにカスタムのシングルノード OpenShift SiteConfig CR を設定します。
				
また、いくつかのオプションのフィルタリングシナリオも説明されています。
前提条件
- 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
 
手順
GitOps ZTP パイプラインが
03-sctp-machine-config-worker.yamlCR ファイルを適用しないようにするには、SiteConfigCR で次の YAML を適用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow GitOps ZTP パイプラインは、インストール中に
03-sctp-machine-config-worker.yamlCR をスキップします。/source-crs/extra-manifest内の他のすべての CR が適用されます。SiteConfigCR を保存し、変更をサイト設定リポジトリーにプッシュします。GitOps ZTP パイプラインは、
SiteConfigフィルター命令に基づいて適用する CR を監視および調整します。オプション: クラスターのインストール中に GitOps ZTP パイプラインがすべての
/source-crs/extra-manifestCR を適用しないようにするには、SiteConfigCR で次の YAML を適用します。- clusterName: "site1-sno-du" extraManifests: filter: inclusionDefault: exclude- clusterName: "site1-sno-du" extraManifests: filter: inclusionDefault: excludeCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: インストール中にすべての
/source-crs/extra-manifestRAN CR を除外し、代わりにカスタム CR ファイルを含めるには、カスタムSiteConfigCR を編集してカスタムマニフェストフォルダーとincludeファイルを設定します。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例は、カスタムフォルダー構造を示しています。
siteconfig ├── site1-sno-du.yaml └── user-custom-manifest └── custom-sctp-machine-config-worker.yamlsiteconfig ├── site1-sno-du.yaml └── user-custom-manifest └── custom-sctp-machine-config-worker.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
22.9.3. SiteConfig CR を使用してノードを削除する リンクのコピーリンクがクリップボードにコピーされました!
					SiteConfig カスタムリソース (CR) を使用すると、ノードを削除して再プロビジョニングできます。この方法は、手動でノードを削除するよりも効率的です。
				
前提条件
- 必要なインストールおよびポリシー CR を生成するようにハブクラスターを設定している。
 - カスタムサイト設定データを管理できる Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
 
手順
SiteConfigCR を更新してbmac.agent-install.openshift.io/remove-agent-and-node-on-delete=trueアノテーションを追加し、変更を Git リポジトリーにプッシュします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
BareMetalHostオブジェクトにアノテーションが付けられていることを確認します。oc get bmh -n <managed-cluster-namespace> <bmh-object> -ojsonpath='{.metadata}' | jq -r '.annotations["bmac.agent-install.openshift.io/remove-agent-and-node-on-delete"]'oc get bmh -n <managed-cluster-namespace> <bmh-object> -ojsonpath='{.metadata}' | jq -r '.annotations["bmac.agent-install.openshift.io/remove-agent-and-node-on-delete"]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
true
trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfigCR を更新してcrSuppression.BareMetalHostアノテーションを含めることで、BareMetalHostCR の生成を抑制します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 
							変更を Git リポジトリーにプッシュし、プロビジョニング解除が開始するまで待ちます。
BareMetalHostCR のステータスがdeprovisioningに変更されるはずです。BareMetalHostのプロビジョニング解除が完了し、完全に削除されるまで待ちます。 
検証
次のコマンドを実行して、ワーカーノードの
BareMetalHostおよびAgentCR がハブクラスターから削除されていることを確認します。oc get bmh -n <cluster-ns>
$ oc get bmh -n <cluster-ns>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get agent -n <cluster-ns>
$ oc get agent -n <cluster-ns>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、スポーククラスターからノードレコードが削除されたことを確認します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記シークレットを操作している場合は、シークレットを削除するのが早すぎると、ArgoCD が削除後に再同期を完了するためにシークレットを必要とするため、問題が発生する可能性があります。現在の ArgoCD 同期が完了したら、ノードのクリーンアップ後にのみシークレットを削除します。
次のステップ
						ノードを再プロビジョニングするには、以前に SiteConfig に追加された変更を削除し、変更を Git リポジトリーにプッシュして、同期が完了するまで待機します。これにより、ワーカーノードの BareMetalHost CR が再生成され、ノードの再インストールがトリガーされます。