自動化の停止はすべての変更の禁止ではない
一言でいうと
自動同期の停止は、すべての変更を禁止するロックではありません。何を止めて、何がまだ可能なのかを、証拠とともに運用手順に書いておく必要があります。
なぜ必要なのか
デプロイをいったん止めてから、重要な点検を始めました。ところが誰かが手動の同期を押して、新しい設定が反映されました。 自動同期を切ったので誰も変更できないと考えていたなら、事故の原因を誤って説明することになります。自動化のポリシーは、 調整器が自分でいつ動くかを決めるものです。ユーザーのリクエストの権限や、ほかのデプロイ経路をすべて取り除く仕組みではありません。
メンテナンスモードという言葉は、チームによって意味が違います。Gitの比較は続けて適用だけを止めるのか、手動の適用も 禁止するのか、ユーザーのトラフィックを止めるのかで、それぞれ異なります。画面のボタン1つにこれらすべての意味を持たせると、 人によって異なる状態を思い浮かべたまま作業することになります。このラボでは、比較・自動適用・手動適用を分けて観測します。
どう動くのか
親のテンプレートで子の自動化を切ったあと、GitにConfigMapの値twoをコミットします。Applicationは新しいコミットを 比較してOutOfSyncを表示できますが、実際のConfigMapには以前の値oneが残ることがあります。 これは、リポジトリを読めなかったという意味ではありません。sync.revisionは新しいコミットを指していて、実際のデータだけが古い値の 状況なので、比較と適用を分離した状態です。Gitの読み取りの失敗であれば、conditionとrevisionも別に調査する必要があります。
| 問い | 確認する根拠 | これだけでは分からないこと |
|---|---|---|
| 新しいGitを読んだか | 現在のsync.revision | 実際のデータが適用されたか |
| 自動適用が切れているか | enabled=falseと繰り返しの観測 | 手動適用の権限までブロックされているか |
| 手動適用ができたか | operationの結果と実際の値 | その後に自動適用が再び有効になったか |
| 正常な自動化に復帰したか | 親・子のポリシーと、新しいGitの実際の反映 | すべての外部の運用経路が検証されたか |
次に、同じコミットを明示的に手動で同期します。enabled=falseを維持したまま、実際のデータがtwoに 変わったなら、自動化の停止と変更の禁止が違うことを、自分で確認したことになります。operationStateのrevisionとphase、 initiatedByの情報、ConfigMapのデータとUIDを一緒に見ます。initiatedByのusernameは、リクエストに載せられる メタデータなので、その文字列だけで、認証された行為者のアイデンティティを証明したとは主張しません。 事前の実験では、手動のリクエストのあとに、以前のautomated=trueという表示が一緒に残ることもありました。この表示だけに頼らず、 APIが受け入れたoperationの受領記録、要求したrevision、適用の前後のデータをつなげて、実際の動作を判断します。
kubectlでArgo CDに同期を要求するとき、operationはspecの中ではなく、Applicationの最上位のフィールドです。 このリクエストも実際の適用を引き起こします。dry-runや読み取りの照会と混同しないでください。このラボでは、正確なコミットを 指定し、pruneとforceは使いません。比較用のConfigMapとApplicationのUIDは、最後まで維持されます。 運用で同じリクエストを許可するかどうかは、RBAC、承認の手順、同期ウィンドウ、ほかのデプロイ経路まで一緒にレビューする必要があります。
現場での姿
すべての子を止める代わりに、特定のApplicationだけを一時的に手動で運用する必要が生じることもあります。ApplicationSetの ignoreApplicationDifferencesは、親が比較から除外する子のフィールドを宣言する手段です。nameを 指定すれば特定の子に限定でき、jsonPointersで対象のフィールドを絞れます。このラボでは、 enabledというフィールド1つだけを例外にします。syncPolicy全体やsourceを無造作に除外すると、はるかに広いドリフトを 見逃すことがあります。
この例外は、ApplicationSetとApplicationの間の比較を変えます。ApplicationとConfigMapの間のGitの 差を無視せよという設定ではありません。名前にignoreが含まれているからといって、すべてのignore系の設定の対象が同じわけではありません。 誰が誰を比較するときに、どのフィールドを見ないのかを、文章に書き下してみてください。対象を省略した例外のドキュメントは、 問題の解決よりも、新たな誤解を生みやすいものです。
例外には終了の条件も必要です。誰が解除するのか、いつまで維持するのか、解除のあとにどんな新しい変更で自動 適用を検証するのかを決めます。単に現在の画面がSyncedだからという理由で、自動化が復旧したと結論づけることはできません。 手動ですでに合わせておいた状態もSyncedだからです。このラボでは、例外を取り除いて子が親のtrueに従うようにし、 Gitの3つ目の値threeが自動で反映されるかを確認します。以前の成功を、新しい検証の根拠として再利用しません。
リストの中のフィールドを例外にするときは、別の落とし穴もあります。ApplicationSetが使うMergePatchは、変更された リストを丸ごと置き換えることがあり、ほかの項目の変更によって、例外にした値まで上書きされることがあります。このラボでは、単一の sourceとスカラーのenabledフィールドに範囲を絞ります。multi-sourceの配列のあらゆる変更の組み合わせまで安全だと 一般化せず、その場合は公式ドキュメントの制限と実際の適用結果を、追加で確認する必要があります。
次のラボですること
Gitが変わっても自動適用されない状態を3回観測し、同じコミットの手動適用と比較します。名前のある 狭い例外を一時的に使ってから取り除き、新しいGitの変更で自動化を検証します。3回の短い観測は、学習用のサンプルであって、 無期限の変更禁止の証明ではありません。最後のレポートには、自動化の停止と全体のデプロイのブロック、内部の観測と運用上の保証を 区別して書きます。グローバルなコントローラーを止めたり、ほかのチームの権限を変えたりしなくても、この違いを学べます。
公式ドキュメント
- kubectlでの同期の要求: operationと結果のフィールドの位置を確認してください。
- ApplicationSetの変更制御: 特定の子の例外とMergePatchの制限を読んでください。