Argo CDは緑色なのに注文画面は500

目標

Gitの同期と業務の成功を区別し、設定が消費されるタイミングまで確認して、Gitで復旧します。

なぜ重要なのか

望ましい設定がデプロイされていても、その設定自体が間違っていたり、実行中のプロセスが読み込んでいなかったりすることがあります。本物のArgo CD・k3s・nginxを使い、readinessは200で業務パスは500という合成障害を調査します。外部の決済・ユーザーデータ・本番のLabHubを呼び出したり変更したりすることはありません。個人VMのcgoa-business-health Namespaceだけを使います。グローバルなコントローラー・セキュリティ・ネットワークの設定は変更しないでください。 55分のラボです。期限が切れる前に、必要なら時間を延長し、必要なファイルは別に保管してください。セッションが終了すると、VMとファイルは回収されます。

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

Gitの作業用リポジトリは/srv/cgoa-business-health、bareリポジトリは/srv/bare/cgoa-business-health.gitです。 Argo CDは、VM内部のgitdサービスから、mainのappディレクトリを読みます。外部のGiteaや本番のGitは使いません。ラボのサーバーは、non-root、capability drop ALL、読み取り専用のルート、RuntimeDefault、サービスアカウントトークンの未マウントで実行します。 nginxイメージはVMの準備中に取得するので、最初の学習ステップでダウンロードを待つことはありません。受講生のファイルは/root/cgoa-healthに置きます。課題のkey=value表記は説明であり、ファイルは形式の例のようにJSONで作成してください。 python3 /opt/fixtures/cgoa_health_lab.py observeは、現在のGit・API・マウントされたファイル・応答を読みます。 complete Nは、作成したNステップの答案を検証して、実際の観測を保存します。ステップ4と6でのみ、限定されたGitの変更を行います。 git show --statおよびgit showで、変更内容を自分で確認してください。自分でリポジトリを直接修正した場合、ヘルパーは上書きせずに停止します。 solve Nは、正解の表示と同じで、ない現在の答案を埋めます。既存の誤答や部分的な答案は修正しません。 prepare Nは、ない前のステップだけを準備します。現在のNステップの答案は作りません。grade Nは、ファイル・Git・Kubernetesを読み取るだけです。

ステップ

個人VMの/srv/cgoa-business-healthでgit rev-parse HEADを確認してください。revision.jsonのrevisionに実際のSHA文字列を書き、complete 1を実行してください。observation-1.jsonのローカルのGit・リモートのmain・Argo CDのrevisionが一致し、リソースのアイデンティティが保存されます。
observeで/healthzと業務の/の応答を読んでください。http.jsonに数値のreadiness=200、business=500を書き、complete 2を実行してください。observation-2.jsonに、実際のHTTPコードと本文のサンプル3組が残ります。Healthyを業務の成功と解釈しないでください。
git show HEAD:app/resources.jsonのnginx.confと実際の応答を突き合わせてください。diagnosis.jsonにcause=application-config、probe_scope=process、fix_source=gitを文字列として書き、complete 3を実行してください。外部APIやDNSを実際の原因として書いてはいけません。
config.jsonに数値のstatus=200と文字列のbody=checkout readyを作成し、complete 4を実行してください。ヘルパーが、ConfigMapだけを修正したGitコミットを作ってmainにpushします。observation-4.jsonで、新しいrevisionと新しいConfigMapが反映されたものの、以前のPodと500の応答が維持されているかを調べてください。git showで、Deploymentが変更されていないことも確認します。
observation-4.jsonのconfigmap.data.nginx.confとmounted_config、以前のPodのUIDを比較してください。consumption.jsonに文字列のmode=subPath、ブール値のpod_replaced=false、restart_required=trueを書き、complete 5を実行してください。このラボでの新しいPodへの交換方式で必要な動作を答えます。ただ待つだけでsubPathの更新を期待しないでください。
observation-4.jsonのconfigmap.data.nginx.confのバイト列をUTF-8でエンコードして、SHA-256を計算してください。rollout.jsonのchecksumに、計算した64桁の文字列を書き、complete 6を実行してください。2つ目のGitコミットは、spec.template.metadata.annotationsのchecksum/configだけを変更します。新しいPodとマウントされたファイル、業務の200の応答を、observation-6.jsonに保存します。
observation-6.jsonでgit_revisionとpod.metadata.uidを調べてください。verification.jsonに、revisionとpod_uidを該当の文字列で、business=200を数値で、deployment_replaced=falseをブール値で書き、complete 7を実行してください。実際の応答3組をもう一度観測し、ApplicationとDeploymentのUIDが維持されていることを確認します。
前の観測とGitの系譜を根拠に、decision.jsonにrecovered=true、availability_guaranteed=falseをブール値で、config_strategy=versioned-rollout、next_check=external-pathを文字列で書いてください。complete 8で最終の観測を保存します。内部のサンプルの成功と、外部のDNS・TLS・認証および長期的な可用性の保証を区別してください。

参考

Podの名前だけでなく、UID、ConfigMapのデータとマウントされたファイル、HTTPコードと本文を一緒に見てください。 Gitの設定コミットとテンプレートコミットの親子関係は、観測のgit_parentsに残ります。成功した観測は編集しないでください。 checksum/configはテンプレートを変更するための約束事であり、自動で設定を監視するKubernetesの組み込み機能ではありません。 3回の内部のHTTP応答は、学習用のサンプルです。外部ユーザーの経路と長期間の可用性を検証したものではありません。部分的な入力は保存されます。誤答がある場合は、課題と突き合わせて自分で修正してから、completeをもう一度実行してください。 Gitの操作の途中で中断されてpendingの記録が残った場合、自動で過去の成功を作ることはありません。資料を保管して、新しいラボで始めてください。ハッシュは、うっかり記録を上書きしたことは検知しますが、同じVMのrootによる全体的な偽造を防ぐセキュリティ上の保証ではありません。採点60秒・前のステップの準備90秒の予算を守ります。実際の収束待ちは、採点ではなくcompleteで行います。公式のConfigMap・ Argo CD health

Gitと実際の同期コミットを結び付ける

個人VMの/srv/cgoa-business-healthでgit rev-parse HEADを確認してください。revision.jsonのrevisionに実際のSHA文字列を書き、complete 1を実行してください。observation-1.jsonのローカルのGit・リモートのmain・Argo CDのrevisionが一致し、リソースのアイデンティティが保存されます。

mainという名前ではなく、動かないコミットSHAを比較してください。

緑のランプと業務の500を同時に観測する

observeで/healthzと業務の/の応答を読んでください。http.jsonに数値のreadiness=200、business=500を書き、complete 2を実行してください。observation-2.jsonに、実際のHTTPコードと本文のサンプル3組が残ります。Healthyを業務の成功と解釈しないでください。

HTTPの応答が返ってきたという事実と、業務が成功したという事実は異なります。

原因と修正すべき元のデータを区別する

git show HEAD:app/resources.jsonのnginx.confと実際の応答を突き合わせてください。diagnosis.jsonにcause=application-config、probe_scope=process、fix_source=gitを文字列として書き、complete 3を実行してください。外部APIやDNSを実際の原因として書いてはいけません。

今回のサーバーが実際に読むnginx設定のreturnの値を探してみてください。

設定だけをGitで修正する

config.jsonに数値のstatus=200と文字列のbody=checkout readyを作成し、complete 4を実行してください。ヘルパーが、ConfigMapだけを修正したGitコミットを作ってmainにpushします。observation-4.jsonで、新しいrevisionと新しいConfigMapが反映されたものの、以前のPodと500の応答が維持されているかを調べてください。git showで、Deploymentが変更されていないことも確認してください。

git showとPodのUIDで、設定の変更とロールアウトを切り分けてください。

subPathが残した古いファイルを証明する

observation-4.jsonのconfigmap.data.nginx.confとmounted_config、以前のPodのUIDを比較してください。consumption.jsonに文字列のmode=subPath、ブール値のpod_replaced=false、restart_required=trueを書き、complete 5を実行してください。このラボでの新しいPodへの交換方式で必要な動作を答えてください。ただ待つだけでsubPathの更新を期待しないでください。

APIに保存された設定と、コンテナの中のファイルが同じ値かどうかを比較してください。

設定のハッシュでPodテンプレートを更新する

observation-4.jsonのconfigmap.data.nginx.confのバイト列をUTF-8でエンコードして、SHA-256を計算してください。rollout.jsonのchecksumに、計算した64桁の文字列を書き、complete 6を実行してください。2つ目のGitコミットは、spec.template.metadata.annotationsのchecksum/configだけを変更します。新しいPodとマウントされたファイル、業務の200の応答を、observation-6.jsonに保存してください。

改行を含む実際のnginx.confの文字列で、ハッシュを計算してください。

新しいプロセスの応答で復旧を検証する

observation-6.jsonでgit_revisionとpod.metadata.uidを調べてください。verification.jsonに、revisionとpod_uidを該当の文字列で、business=200を数値で、deployment_replaced=falseをブール値で書き、complete 7を実行してください。実際の応答3組をもう一度観測し、ApplicationとDeploymentのUIDが維持されていることを確認してください。

新しいPodのUIDと、維持されたDeploymentのUIDを一緒に比較してください。

確認した範囲と残りの検証を報告する

前の観測とGitの系譜を根拠に、decision.jsonにrecovered=true、availability_guaranteed=falseをブール値で、config_strategy=versioned-rollout、next_check=external-pathを文字列で書いてください。complete 8で最終の観測を保存してください。内部のサンプルの成功と、外部のDNS・TLS・認証および長期的な可用性の保証を区別してください。

ClusterIPのサンプル3回で、外部経路と1か月の可用性を保証することはできません。