ArgoCD Applicationの同期後に何かしたい時にどうすればいい？
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、ArgoCDを使用したGitOpsの運用フローにおいて、同期の後処理(PostSync)を行う方法を説明し、特定のリソースのみの後処理に対して、いくつか現実的な解決策を提案します。
背景一般的なやり方ResourceHookSyncWave制約特定リソースの後処理はどうすればいい？1. 特定のリソースを別のApplicationで管理する2. ArgoEventsやCustomResourceの仕組み3. Notification Controllerを使う終わりに
背景
ArgoCDを使ったGitOpsの運用では、手動または自動で同期(Sync)されている運用が多いです。ArgoCDのApplicationは同期後、後処理が必要となることも多々あります。例えば、以下のようなシナリオが考えられます。
- デプロイ後特定のリソースの作成
- デプロイ後の様々な通知とテスト
- デプロイ後のCDNキャッシュパージ
こうしたニーズに応える一般的な方法は、ArgoCDのResource Hooks機能を利用することです。後処理自体をArgoCD 管理下のリソースの一部として管理したい場合は、SyncWaves利用して制御することもできます。
しかし、Resource HooksはApplication単位でしか動作できず、Application内の特定リソースを対象とする操作はできません。その際はいくつかの特殊な方法が必要です。
一般的なやり方
ResourceHook
Resource Hookは、リソースの同期プロセスをカスタマイズするための機能です。PreSync、Sync、PostSyncなどフックを使用して、同期プロセスの特定のタイミングでカスタムジョブを実行することができます。Applicationの後処理は、PostSyncのフックに該当します。
例えば、devという名前のArgoCD Applicationに後処理を追加する際には、以下のような構成で行うのが一般的です。
後処理用のリソースもApplicationの一部として管理され、 で認識されます。複数の後処理の実行順番を指定したい場合、 で設定できます。
SyncWave
SyncWavesは、リソースの同期順序を制御するための機能です。低い値が先に実行されます。通常リソースのsync-waveが0であるため、0より大きい数値にすれば、通常リソースより後の順序で同期することができます。
後処理のログとステータスを管理したい場合、後処理のリソース自体をArgoCD Application管理下のリソースとして管理する方法もあります。
制約
- Resource Hooksは、アプリケーション全体の同期を基準に動作するため、特定のリソースのみを対象とする操作することができません。
- 複雑な依存関係を持つシナリオでは、フックやWaveの設定が煩雑になります。特に特定のリソースに依存する場合、同期順序だけでは依存の前提などを処理できないこともあります。
特定リソースの後処理はどうすればいい？
現時点では、現実的な方法は三つあります。
1. 特定のリソースを別のApplicationで管理する
ArgoCD Applicationの分離によって、特定のリソースだけを別のArgoCD Applicationとして管理すれば、PostSyncやSyncWaveなどで後処理が実行しやすくなります。例えば、キャッシュクリアのためのジョブを別アプリケーションとして定義し、そのアプリケーションの同期後に実行します。
この方法は一番効果的ですが、複雑な依存関係を持つシナリオでは使用できず、かえって複雑になる可能性があります。
2. ArgoEventsやCustomResourceの仕組み
ArgoEventsを使用することで、特定のイベント(リソースのUpdate、特定Spec値の更新など)をトリガーとして処理を実行することができます。ArgoEventsは強力なツールです。標準リソース以外のCustomResourceでも細かく設定できます。
また、ArgoCD Application管理下のリソースは特定のCustomResourceの場合、そのCustomResourceの機能を使うことも良いチョイスです。
例えば、ArgoCD Applicationにおいて、Deployment/ConfigMapなどの標準リソースを直接扱わず、KubeVela Applicationを管理する例では、KubeVela Application Workflowを利用することがおすすめです。
全てのKubeVela Applicationは、デフォルトではKubeVela Applicationを適用するStepのWorkflowが標準実装されています。その後のStepに、ReadObjectやRequestなどのStepを組み合わせすれば、様々な目的は達成できます。
以下はKubeVela Applicationの適用後、Github ActionsをAPIでトリガーする例です。
3. Notification Controllerを使う
本来、ArgoCDのNotification Controllerは Applicationの同期イベントに基づいて通知を送信する目的です。WebhookのNotificationTypeを使えば、デプロイのプロセスに別の処理を組み込むことができます。
その原理は、ArgoCD ApplicationのStatusを一部利用し、Webhookで処理することです。
まず ArgoCD ApplicationのStatusの構成を見てみましょう。
の中に、直近の同期結果が保存されています。リソースの種類と名前を判別できる最低限の情報があるため、Webhook側でbodyの中身を自由に処理することができます。
以下はNotification Controllerでを送信するテンプレートとWebhookの一例です。
終わりに
本記事では、ArgoCDの後処理の方法について説明し、特定のリソースに対する現実的な解決策を提供しました。
個人的には、ArgoCDのResource Hooks機能はさらに増強して欲しいです。例えば 、 のようなことができれば、Notificationのような「邪道」は要らなくなるのでしょう。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
SRG では最近出たホットなIT技術や書籍などについてワイワイ雑談するポッドキャストを運営しています。ぜひ、作業のお供に聞いていただければ幸いです。
