Trident の保護実行フックを管理する
実行フックは、管理対象アプリのデータ保護操作と組み合わせて実行するように構成できるカスタム アクションです。たとえば、データベース アプリがある場合、実行フックを使用して、スナップショットの前にすべてのデータベース トランザクションを一時停止し、スナップショットが完了した後にトランザクションを再開できます。これにより、アプリケーションの一貫性のあるスナップショットが保証されます。
実行フックの種類
Trident protect は、実行できるタイミングに基づいて、次のタイプの実行フックをサポートしています。
-
事前スナップショット
-
スナップショット後
-
バックアップ前
-
バックアップ後
-
復元後
-
フェイルオーバー後
実行順序
データ保護操作が実行されると、実行フック イベントが次の順序で発生します。
-
適用可能なカスタム操作前実行フックは、適切なコンテナで実行されます。必要な数だけカスタム操作前フックを作成して実行できますが、操作前のこれらのフックの実行順序は保証されておらず、構成もできません。
-
該当する場合、ファイルシステムのフリーズが発生します。"Trident Protectを使用したファイルシステムのフリーズ設定の詳細"。
-
データ保護操作が実行されます。
-
該当する場合、凍結されたファイルシステムは凍結解除されます。
-
適用可能なカスタム操作後実行フックは、適切なコンテナで実行されます。必要な数だけカスタム操作後フックを作成して実行できますが、操作後のこれらのフックの実行順序は保証されておらず、構成もできません。
同じタイプ(たとえば、事前スナップショット)の実行フックを複数作成する場合、それらのフックの実行順序は保証されません。ただし、異なるタイプのフックの実行順序は保証されます。たとえば、さまざまな種類のフックがすべて含まれる構成の実行順序は次のとおりです。
-
スナップショット前のフックが実行されました
-
スナップショット後のフックが実行されました
-
バックアップ前のフックが実行されました
-
バックアップ後のフックが実行されました
|
|
上記の順序の例は、既存のスナップショットを使用しないバックアップを実行する場合にのみ適用されます。 |
|
|
実行フック スクリプトを実稼働環境で有効にする前に、必ずテストする必要があります。'kubectl exec' コマンドを使用すると、スクリプトを簡単にテストできます。実稼働環境で実行フックを有効にした後、結果のスナップショットとバックアップをテストして、一貫性があることを確認します。これを行うには、アプリを一時的な名前空間に複製し、スナップショットまたはバックアップを復元してから、アプリをテストします。 |
|
|
スナップショット前の実行フックによって Kubernetes リソースが追加、変更、または削除された場合、それらの変更はスナップショットまたはバックアップと、その後のすべての復元操作に含まれます。 |
カスタム実行フックに関する重要な注意事項
アプリの実行フックを計画するときは、次の点を考慮してください。
-
実行フックは、アクションを実行するためにスクリプトを使用する必要があります。複数の実行フックが同じスクリプトを参照できます。
-
Trident protect では、実行フックが使用するスクリプトを実行可能なシェル スクリプトの形式で記述する必要があります。
-
スクリプトのサイズは 96 KB に制限されています。
-
Trident protect は実行フックの設定と一致する基準を使用して、スナップショット、バックアップ、または復元操作に適用可能なフックを決定します。
|
|
実行フックは、多くの場合、実行対象のアプリケーションの機能を低下させたり完全に無効にしたりするため、カスタム実行フックの実行にかかる時間を常に最小限に抑えるようにする必要があります。関連する実行フックを使用してバックアップまたはスナップショット操作を開始したが、その後キャンセルした場合でも、バックアップまたはスナップショット操作がすでに開始されている場合は、フックは引き続き実行できます。つまり、バックアップ後の実行フックで使用されるロジックでは、バックアップが完了したと想定することはできません。 |
実行フックフィルター
アプリケーションの実行フックを追加または編集するときに、実行フックにフィルターを追加して、フックが一致するコンテナーを管理できます。フィルターは、すべてのコンテナーで同じコンテナー イメージを使用するが、各イメージを異なる目的で使用する可能性があるアプリケーション (Elasticsearch など) に役立ちます。フィルターを使用すると、実行フックが必ずしもすべての同一コンテナーではなく一部のコンテナーで実行されるシナリオを作成できます。単一の実行フックに対して複数のフィルターを作成すると、それらは論理 AND 演算子で結合されます。実行フックごとに最大 10 個のアクティブ フィルターを設定できます。
実行フックに追加する各フィルターは、正規表現を使用してクラスター内のコンテナを照合します。フックがコンテナに一致すると、フックはそのコンテナ上で関連付けられたスクリプトを実行します。フィルターの正規表現では正規表現 2 (RE2) 構文が使用されますが、一致リストからコンテナーを除外するフィルターの作成はサポートされていません。Trident Protectが実行フックフィルタの正規表現でサポートする構文については、以下を参照してください。 "正規表現2(RE2)構文のサポート" 。
|
|
復元またはクローン操作後に実行される実行フックに名前空間フィルターを追加し、復元またはクローンのソースと宛先が異なる名前空間にある場合、名前空間フィルターは宛先の名前空間にのみ適用されます。 |
実行フックの例
訪問 "NetApp Verda GitHub プロジェクト"Apache Cassandra や Elasticsearch などの一般的なアプリの実際の実行フックをダウンロードします。また、例を参照したり、独自のカスタム実行フックを構成するためのアイデアを入手したりすることもできます。
実行フックを作成する
Trident protect を使用して、アプリのカスタム実行フックを作成できます。実行フックを作成するには、所有者、管理者、またはメンバーの権限が必要です。
-
カスタムリソース(CR)ファイルを作成し、名前を付けます
trident-protect-hook.yaml。 -
Trident保護環境とクラスタ構成に合わせて次の属性を構成します。
-
metadata.name: (必須) このカスタム リソースの名前。環境に合わせて一意かつ適切な名前を選択してください。
-
spec.applicationRef: (必須) 実行フックを実行するアプリケーションの Kubernetes 名。
-
spec.stage: (必須) アクション中に実行フックを実行するステージを示す文字列。有効な値は次のとおりです。
-
プレ
-
投稿
-
-
spec.action: (必須) 指定された実行フック フィルターが一致すると仮定して、実行フックが実行するアクションを示す文字列。有効な値は次のとおりです。
-
Snapshot
-
バックアップ
-
リストア
-
フェイルオーバー
-
-
spec.enabled: (オプション) この実行フックが有効か無効かを示します。指定しない場合はデフォルト値は true になります。
-
spec.hookSource: (必須) base64 でエンコードされたフック スクリプトを含む文字列。
-
spec.timeout: (オプション) 実行フックの実行が許可される時間 (分) を定義する数値。最小値は 1 分で、指定されていない場合はデフォルト値は 25 分です。
-
spec.arguments: (オプション) 実行フックに指定できる引数の YAML リスト。
-
spec.matchingCriteria: (オプション) 実行フック フィルターを構成する基準キー値のペアのオプション リスト。実行フックごとに最大 10 個のフィルターを追加できます。
-
spec.matchingCriteria.type: (オプション) 実行フックのフィルタータイプを識別する文字列。有効な値は次のとおりです。
-
コンテナイメージ
-
コンテナ名
-
ポッド名
-
ポッドラベル
-
名前空間名
-
-
spec.matchingCriteria.value: (オプション) 実行フックのフィルター値を識別する文字列または正規表現。
YAMLの例:
apiVersion: protect.trident.netapp.io/v1 kind: ExecHook metadata: name: example-hook-cr namespace: my-app-namespace annotations: astra.netapp.io/astra-control-hook-source-id: /account/test/hookSource/id spec: applicationRef: my-app-name stage: Pre action: Snapshot enabled: true hookSource: IyEvYmluL2Jhc2gKZWNobyAiZXhhbXBsZSBzY3JpcHQiCg== timeout: 10 arguments: - FirstExampleArg - SecondExampleArg matchingCriteria: - type: containerName value: mysql - type: containerImage value: bitnami/mysql - type: podName value: mysql - type: namespaceName value: mysql-a - type: podLabel value: app.kubernetes.io/component=primary - type: podLabel value: helm.sh/chart=mysql-10.1.0 - type: podLabel value: deployment-type=production -
-
CR ファイルに正しい値を入力したら、CR を適用します。
kubectl apply -f trident-protect-hook.yaml
-
実行フックを作成し、括弧内の値を環境の情報に置き換えます。例えば:
tridentctl-protect create exechook <my_exec_hook_name> --action <action_type> --app <app_to_use_hook> --stage <pre_or_post_stage> --source-file <script-file> -n <application_namespace>
実行フックを手動で実行する
テスト目的で、または失敗後にフックを手動で再実行する必要がある場合は、実行フックを手動で実行できます。実行フックを手動で実行するには、所有者、管理者、またはメンバーの権限が必要です。
実行フックを手動で実行するには、次の 2 つの基本的な手順を実行します。
-
リソースのバックアップを作成します。これはリソースを収集してそれらのバックアップを作成し、フックが実行される場所を決定します。
-
バックアップに対して実行フックを実行する
ステップ1: リソースのバックアップを作成する
-
カスタムリソース(CR)ファイルを作成し、名前を付けます
trident-protect-resource-backup.yaml。 -
Trident保護環境とクラスタ構成に合わせて次の属性を構成します。
-
metadata.name: (必須) このカスタム リソースの名前。環境に合わせて一意かつ適切な名前を選択してください。
-
spec.applicationRef: (必須) リソース バックアップを作成するアプリケーションの Kubernetes 名。
-
spec.appVaultRef: (必須) バックアップ コンテンツが保存される AppVault の名前。
-
spec.appArchivePath: バックアップ コンテンツが保存される AppVault 内のパス。このパスを見つけるには、次のコマンドを使用できます。
kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'YAMLの例:
--- apiVersion: protect.trident.netapp.io/v1 kind: ResourceBackup metadata: name: example-resource-backup spec: applicationRef: my-app-name appVaultRef: my-appvault-name appArchivePath: example-resource-backup -
-
CR ファイルに正しい値を入力したら、CR を適用します。
kubectl apply -f trident-protect-resource-backup.yaml
-
括弧内の値を環境の情報に置き換えてバックアップを作成します。例えば:
tridentctl protect create resourcebackup <my_backup_name> --app <my_app_name> --appvault <my_appvault_name> -n <my_app_namespace> --app-archive-path <app_archive_path> -
バックアップのステータスを表示します。操作が完了するまで、この例のコマンドを繰り返し使用できます。
tridentctl protect get resourcebackup -n <my_app_namespace> <my_backup_name> -
バックアップが成功したことを確認します。
kubectl describe resourcebackup <my_backup_name>
ステップ2: 実行フックを実行する
-
カスタムリソース(CR)ファイルを作成し、名前を付けます
trident-protect-hook-run.yaml。 -
Trident保護環境とクラスタ構成に合わせて次の属性を構成します。
-
metadata.name: (必須) このカスタム リソースの名前。環境に合わせて一意かつ適切な名前を選択してください。
-
spec.applicationRef: (必須) この値が、手順 1 で作成した ResourceBackup CR のアプリケーション名と一致していることを確認します。
-
spec.appVaultRef: (必須) この値が、手順 1 で作成した ResourceBackup CR の appVaultRef と一致していることを確認します。
-
spec.appArchivePath: この値が、手順 1 で作成した ResourceBackup CR の appArchivePath と一致していることを確認します。
kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}' -
spec.action: (必須) 指定された実行フック フィルターが一致すると仮定して、実行フックが実行するアクションを示す文字列。有効な値は次のとおりです。
-
Snapshot
-
バックアップ
-
リストア
-
フェイルオーバー
-
-
spec.stage: (必須) アクション中に実行フックを実行するステージを示す文字列。このフック実行では、他のステージのフックは実行されません。有効な値は次のとおりです。
-
プレ
-
投稿
YAMLの例:
-
--- apiVersion: protect.trident.netapp.io/v1 kind: ExecHooksRun metadata: name: example-hook-run spec: applicationRef: my-app-name appVaultRef: my-appvault-name appArchivePath: example-resource-backup stage: Post action: Failover -
-
CR ファイルに正しい値を入力したら、CR を適用します。
kubectl apply -f trident-protect-hook-run.yaml
-
手動実行フックの実行リクエストを作成します。
tridentctl protect create exechooksrun <my_exec_hook_run_name> -n <my_app_namespace> --action snapshot --stage <pre_or_post> --app <my_app_name> --appvault <my_appvault_name> --path <my_backup_name> -
実行フックの実行ステータスを確認します。操作が完了するまでこのコマンドを繰り返し実行できます。
tridentctl protect get exechooksrun -n <my_app_namespace> <my_exec_hook_run_name> -
最終的な詳細とステータスを確認するには、exechooksrun オブジェクトを記述します。
kubectl -n <my_app_namespace> describe exechooksrun <my_exec_hook_run_name>