自動化を止めたのに、誰が戻した？

目標

ApplicationSetがApplicationを合わせるループと、ApplicationがGitを実際のオブジェクトに合わせるループを区別します。

なぜ重要なのか

子で自動化を切っても、親が再び有効にすることがあり、自動適用を切っても、手動のリクエストは適用されることがあります。本番のLabHubや外部リポジトリは変更しません。個人VMのcgoa-appset-ownership Namespace、親1つ・子1つ・独立したApplication 1つ・小さなConfigMap 2つだけを使います。 Namespace・ApplicationSet・Applicationを削除しないでください。グローバルなコントローラー・RBAC・ネットワーク・セキュリティの設定も変えません。 55分のラボです。期限が切れる前に、必要なら時間を延長し、観測を保管してください。セッションが終了すると、VMとファイルは回収されます。

用意されている環境とヘルパー

親はcgoa-appset-ownership、子はcgoa-appset-ownership-alpha、独立した対照群はcgoa-appset-ownership-sentinelです。 Gitは/srv/cgoa-appset-ownership、VM内部のリモートは/srv/bare/cgoa-appset-ownership.gitです。子はapps/alpha、対照群はsentinelディレクトリを読みます。外部のGitや本番のAPIは使いません。親のApplicationSet自体は、/root/cgoa-appset-ownership-source.jsonをヘルパーが直接適用するブートストラップです。親まで、上位のApplicationがGitで管理する3つ目のループを実装した環境ではありません。受講生のファイルは/root/cgoa-appsetにあります。課題のkey=valueは説明であり、JSONファイルは形式の例に従ってください。 python3 /opt/fixtures/cgoa_appset_lab.py observeは、現在の親・子・Git・ConfigMapを読みます。 complete Nは、作成した答案をレビューして、限定された動作と実際の観測を記録します。 2は子のトグル、3は親の停止、4はGitの変更、5は手動適用、6は親の狭い例外、7は例外の終了と新しいGitです。 git showで、変更したファイルとコミットの系譜を確認してください。Gitの変更はステップ4・7でのみ行われます。 solve Nは、正解の表示と同じで、ない現在の答案だけを埋めます。既存の誤答・部分的な答案は修正しません。 prepare Nは、前のステップだけを準備し、現在の答案は作りません。grade Nは読み取りだけを行い、変更を再実行しません。

ステップ

baseline.jsonからparent.uidとchild.uidを読んでください。ownership.jsonのparent_uidとchild_uidに該当の文字列を書き、complete 1を実行します。observation-1.jsonで、child.ownersが同じ親のUIDを指していて、sentinelは独立したApplicationであることを確認してください。ConfigMapの追跡用アノテーションは、どのApplicationが管理しているかを示します。
child.jsonに、target_uid=基準のchild UIDを文字列で、enabled=falseとexpected_reverted=trueをブール値で書き、complete 2を実行してください。effect.patch_receiptのfalseと、result.snapshot.childのtrueを比較します。同じUIDなのにresourceVersionが違うかを確認してください。リクエスト自体が拒否された場合と、親が元に戻した場合を区別します。
parent.jsonに、change_source=parent-templateを文字列で、enabled=falseをブール値で書き、complete 3を実行してください。ヘルパーが、親の元の宣言ファイルを修正して適用します。親と子のenabledがどちらもfalseで、データoneが維持されている3つのサンプルを読んでください。独立したsentinelのポリシーとデータは変わってはいけません。
git.jsonに、release=two、expected_live=oneを文字列で、will_apply_automatically=falseをブール値で書き、complete 4を実行してください。Gitのapps/alpha/config.jsonだけが変わります。新しいSHAがchild.status.sync.revisionに現れるものの、OutOfSyncで、実際の値はoneである3つのサンプルを確認します。新しいコミットを読めなかった障害とは異なります。
observation-4.jsonのresult.snapshot.revisionを読んでください。manual.jsonに、revision=そのSHA、child_uid=基準の子のUIDを文字列で、manual_allowed=trueをブール値で書き、complete 5を実行します。レビューしたコミットに対する手動のoperationを要求します。effect.request_receiptと、実際のデータtwo、依然としてfalseのenabledを突き合わせてください。リクエストのメタデータだけで、ユーザー認証を証明することはありません。
exception.jsonに、app_name=cgoa-appset-ownership-alpha、json_pointer=/spec/syncPolicy/automated/enabledを文字列で、parent_enabled=trueとchild_enabled=falseをブール値で書き、complete 6を実行してください。親のテンプレートはtrueですが、名前が指定された1つのフィールドの例外のために、子はfalseのまま残ります。親のignoreApplicationDifferencesと3つの観測を読んでください。
resume.jsonにremove_exception=trueをブール値で、release=threeを文字列で書き、complete 7を実行します。例外を取り除いたあと、親と子のenabledがtrueであることを確認し、新しいGitコミットを作ります。実際のデータthreeと、現在のコミットのoperationの成功を確認してください。以前の手動の成功や、既存のSyncedだけで、自動化への復帰を判定することはありません。
decision.jsonに、automatic_resumed=true、manual_blocked=false、all_paths_frozen=false、samples_guarantee=falseをブール値で書き、complete 8を実行してください。親・子・ConfigMapのUIDと、独立したsentinelが保持されているかを確認します。自動化の停止、全体の変更禁止、短いサンプルと長期的な保証を区別して報告してください。

参考と限界

完了の入力と観測を、直接直さないでください。前のステップのファイルも、あとの採点の根拠です。 pendingのジャーナルが残った場合、中断されたリクエストを自動で再実行することはありません。資料を保管して、新しいラボで始めてください。リクエストは完了したのに観測だけが失敗した場合は、同じコミットで観測だけを再試行し、同じ適用を繰り返しません。ステップ3・4・6は、間隔を置いた3つのサンプルです。これは、すべての経路の変更禁止や、無期限のメンテナンスの保証ではありません。 initiatedByはリクエストのメタデータです。手動かどうかは、リクエストの受領記録・ポリシー・同じコミットの実際の変更を一緒に見て判断します。ハッシュは、うっかり記録を上書きしたことを検知しますが、同じVMのrootによるあらゆる偽造を防ぐセキュリティ上の保証ではありません。採点は60秒、前のステップの準備は90秒の予算です。待機はcompleteが担当します。 ApplicationSetの変更制御・ kubectlでの同期の要求

2つの調整ループの所有者を確認する

baseline.jsonからparent.uidとchild.uidを読んでください。ownership.jsonのparent_uidとchild_uidに該当の文字列を書き、complete 1を実行します。observation-1.jsonで、child.ownersが同じ親のUIDを指していて、sentinelは独立したApplicationであることを確認してください。ConfigMapの追跡用アノテーションは、どのApplicationが管理しているかを示します。

ownerReferencesの名前だけでなく、UIDを確認してください。

子で切ったのに再び有効になる現象を観測する

child.jsonに、target_uid=基準のchild UIDを文字列で、enabled=falseとexpected_reverted=trueをブール値で書き、complete 2を実行してください。effect.patch_receiptのfalseと、result.snapshot.childのtrueを比較します。同じUIDなのにresourceVersionが違うかを確認してください。リクエスト自体が拒否された場合と、親が元に戻した場合を区別します。

patchの応答の値と、あとで読んだ値を並べて見てください。

親のテンプレートで自動化を停止する

parent.jsonに、change_source=parent-templateを文字列で、enabled=falseをブール値で書き、complete 3を実行してください。ヘルパーが、親の元の宣言ファイルを修正して適用します。親と子のenabledがどちらもfalseで、データoneが維持されている3つのサンプルを読んでください。独立したsentinelのポリシーとデータは変わってはいけません。

子ではなく、その子を生成するtemplateを確認してください。

Gitの比較と自動適用の違いを確認する

git.jsonに、release=two、expected_live=oneを文字列で、will_apply_automatically=falseをブール値で書き、complete 4を実行してください。Gitのapps/alpha/config.jsonだけが変わります。新しいSHAがchild.status.sync.revisionに現れるものの、OutOfSyncで、実際の値はoneである3つのサンプルを確認してください。新しいコミットを読めなかった障害とは異なります。

現在の比較のrevisionと、実際のConfigMapのデータは、別の証拠です。

自動化を切ったまま手動で同期する

observation-4.jsonのresult.snapshot.revisionを読んでください。manual.jsonに、revision=そのSHA、child_uid=基準の子のUIDを文字列で、manual_allowed=trueをブール値で書き、complete 5を実行してください。レビューしたコミットに対する手動のoperationを要求します。effect.request_receiptと、実際のデータtwo、依然としてfalseのenabledを突き合わせてください。リクエストのメタデータだけで、ユーザー認証を証明することはありません。

operationは、Applicationの最上位のリクエストのフィールドです。

特定の子の1つのフィールドだけを一時的な例外にする

exception.jsonに、app_name=cgoa-appset-ownership-alpha、json_pointer=/spec/syncPolicy/automated/enabledを文字列で、parent_enabled=trueとchild_enabled=falseをブール値で書き、complete 6を実行してください。親のテンプレートはtrueですが、名前が指定された1つのフィールドの例外のために、子はfalseのまま残ります。親のignoreApplicationDifferencesと3つの観測を読んでください。

nameとjsonPointerを一緒に限定してください。

例外を取り除いて、新しい変更で自動化を検証する

resume.jsonにremove_exception=trueをブール値で、release=threeを文字列で書き、complete 7を実行してください。例外を取り除いたあと、親と子のenabledがtrueであることを確認し、新しいGitコミットを作ります。実際のデータthreeと、現在のコミットのoperationの成功を確認してください。以前の手動の成功や、既存のSyncedだけで、自動化への復帰を判定することはありません。

新しいGitの目標に対する、実際の反映が必要です。

メンテナンスモードの範囲と限界を報告する

decision.jsonに、automatic_resumed=true、manual_blocked=false、all_paths_frozen=false、samples_guarantee=falseをブール値で書き、complete 8を実行してください。親・子・ConfigMapのUIDと、独立したsentinelが保持されているかを確認します。自動化の停止、全体の変更禁止、短いサンプルと長期的な保証を区別して報告してください。

自動適用を切っても、手動の権限までなくなるわけではありません。