GitOps アプリケーションオンボーディング
この方法は汎用的です。クラスタの情報（パス、許可リスト、レジストリ、ストレージクラス、ゲートウェイ、参照アプリ、アラートの場所）は、GitOpsリポジトリ内の .claude/profiles/gitops.md にあります。プロファイルを最初に読んでください。 プロファイルがない場合は、リポジトリ（ApplicationSet、AppProject、シークレットストア、既存のアプリ1～2個、監視フォルダ）を読んで templates/profile.md から作成し、作成したことを1行でユーザーに伝えてください。パスを推測しないでください。
アプリが稼働するまで
- ディレクトリジェネレーターを持つApplicationSetは、プロファイルのアプリディレクトリ配下の各フォルダを、独自のArgoCDアプリケーションおよびネームスペースに変換します。フォルダに有効な
kustomization.yamlが存在すると、デプロイが開始されます。 - ArgoCDが追跡するブランチにプッシュされるまでは、何もクラスタに到達しません。
kubectlだけで適用した変更は、次の同期で元に戻ります。 - プラットフォームコンポーネント（CNI、ストレージ、コントローラー）はアプリディレクトリには配置しません。プロファイルにその場所が記載されています。
新しいネームスペースは、同じコミット内で、すべての場所で許可リストに追加する必要があります
プロファイルの許可リストセクションには、ネームスペースを指定するすべてのファイルがリストされています（通常：AppProjectの destinations、ClusterSecretStoreの conditions、アプリがLB IPを必要とする場合はLoadBalancer IPプールとL2/BGPアナウンスセレクター）。1つでも欠けると、アプリの同期が失敗したり、ExternalSecret が SecretSyncError のままになったり、LB IPがアナウンスされなくなります。フォルダを追加するコミットで、該当するすべてのファイルにネームスペースを追加してください。
オンボーディングの順序（最小限の安全な形状から）
ns.yaml：プロファイルのPodセキュリティラベルが付いたネームスペース。kustomization.yaml：依存関係の順序でリソースを指定（ネームスペースと設定、次にワークロード、最後にルート）。- シークレット：最初にシークレットバックエンドにエントリを作成し（プロファイルのシークレット参照）、次にシークレットごとに
ExternalSecretを作成します。シークレット値をコミットしないでください。ブートストラップ用や非常時のシークレットはGitの管理外に置きます。 - ランタイムマニフェスト（Deployment、Service、PVC、ConfigMap）：イメージ名とシークレット名が確定した後にのみ追加します。実際のヘルスエンドポイントに対するReadiness ProbeとLiveness Probe、リソースリクエスト、およびネームスペースのPodセキュリティレベルで要求されるセキュリティコンテキストを含めます。
- 3AMシグナル（下記参照）：ワークロードと同じ変更で追加します。
- ルート：最後に、イメージが実行され、シークレットが解決され、プローブが成功したら追加します（公開を参照）。
- アプリフォルダ内の
README.md：アプリの説明、ランタイム依存関係、シークレット名、ストレージ、アクセス方法を記載します。
規約（プロファイルに値があります）
- イメージ：プロファイルでアプリが可動タグを追跡すると指定されていない限り、
tag@sha256:<digest>で固定します。自社イメージは、プロファイルのレジストリからイミュータブルタグで取得します。プライベートイメージには、プロファイルのプルシークレットパターンが必要です。 - シークレット：
ExternalSecretリソースをプロファイルのClusterSecretStoreに対して使用し、インラインのSecretデータは使用しません。 - ストレージ：プロファイルのストレージクラスと、それぞれの用途（小規模なレプリケートブロックボリューム vs NFS上のバルクデータ）に従います。プロファイル内の容量制限はハードリミットです。
- ルーティング：パブリックおよび内部ゲートウェイとそのホストパターン、LoadBalancer Serviceによる生のTCP/UDPを指定します。
- 新しい形状を考案するのではなく、プロファイルの参照アプリの形状をコピーしてください。
3AMシグナル
プッシュする前に自問してください：もしこのアプリが午前3時に壊れたら、誰がどのように知り、最初に何を確認するだろうか？
- アプリは、担当者に届くアラートでカバーされている必要があります。プロファイルの監視アラートルール（利用不可レプリカ、クラッシュループ、保留中のPodまたはPVC）にネームスペースとワークロードを追加するか、アプリ固有の障害モード（ドレインを停止したキュー、実行を停止したジョブ、期限切れの証明書やトークンなど）がある場合は、アプリ固有のルールを追加します。
- アプリのログには、障害を特定するIDとともに何が失敗したかが記述されている必要があります。イメージが自社製でログにそれがない場合は、それはタスクです。
- コミットメッセージにシグナルを記述します：
午前3時: <アラート名> via <レシーバー>。
公開
アプリが実行され、シークレットが解決され、ヘルスチェックに合格するまで、パブリックルートを追加しないでください。内部ツールのみは内部ゲートウェイにのみ接続し、パブリックルートは持ちません。公開する場合は、プロファイルの関連スキルに従ってパブリックイングレスパス（DNS、トンネル、証明書）を設定します。
オンボーディング後（確認し、想定しない）
- プッシュします。新しいアプリケーションが表示され、収束するのを確認します（
kubectl get applications.argoproj.io -n argocd、またはプロファイルの確認コマンド）。プロファイルで方法が示されている場合は、ポーリング遅延をスキップするためにリフレッシュを要求します。 - 確認：アプリケーション
SyncedかつHealthy、すべてのExternalSecretがSecretSynced、Podが準備完了、ルートが応答し、アラートルールが読み込まれている（監視スタックのルールリストに表示される）ことを確認します。 - 収束しない場合は、チェーンをトップダウンで確認します：許可リスト → シークレット → ArgoCD同期エラー → Pod → ルーティング。許可リストが通常の原因です。プロファイルの関連スキルにクラスタの診断スキルが記載されています。