Community程式設計與開發github.com

carnufex/gitops-app-onboarding

在 GitOps 管理的 Kubernetes 叢集(搭配 ArgoCD ApplicationSet、每個應用程式一個目錄、External Secrets、Gateway API 路由、可選 LoadBalancer IP)中新增應用程式。用於建置或導入新應用程式或服務時,該應用程式會成為自己的 ArgoCD 應用程式與命名空間;或用於新增的應用程式無法同步或密碼永不顯示時。涵蓋安全導入順序、新命名空間所需的每個白名單、映像檔、密碼與儲存慣例、通知值班人員應用程式故障的警報,以及何時可以安全公開。

gitops-app-onboarding 是什麼?

此技能(carnufex/gitops-app-onboarding)提供了一個結構化流程,用於將新的應用程式導入由 GitOps 管理的 Kubernetes 叢集,特別是使用 ArgoCD ApplicationSet(每個應用程式一個目錄)、External Secrets、Gateway API 路由和可選的 LoadBalancer IP。它能確保導入過程安全且可重複,減少因缺少白名單設定或配置順序錯誤而導致的同步失敗。 此技能支援 ArgoCD 平台,並要求先讀取 GitOps 儲存庫中的 `.claude/profiles/gitops.md` 設定檔,該檔案定義了叢集特定的路徑、白名單、儲存類別、閘道器和參考應用程式。在導入過程中,它會逐步引導使用者:建立命名空間與 Kustomization 檔案、在後端新增密碼、部署工作負載、設定路由,並加入監控告警(「凌晨三點警報」),確保應用程式故障時值班人員能即時得知。 此技能會強制執行多項關鍵慣例:映像檔必須使用 `tag@sha256:<digest>` 格式以確保不可變性;所有密碼必須透過 ExternalSecret 從遠端密碼儲存庫取得,絕不能直接寫入 Git;儲存使用量必須符合設定檔中定義的硬性限制;路由則通過內部或外部閘道器進行管理。導入完成後,它會引導使用者進行驗證,確認 ArgoCD 應用程式狀態、ExternalSecret 同步、Pod 就緒度、路由回應以及監控規則是否已載入。

相容平台✓Claude Code~Codex CLI~Cursor
Part ofMobile
npx skills add https://github.com/carnufex/claude-skills/tree/HEAD/plugins/gitops/skills/gitops-app-onboarding

Installed? Explore more 程式設計與開發 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

GitOps 應用程式導入

此方法為通用方法;叢集的實際資訊(路徑、白名單、註冊表、儲存類別、閘道器、參考應用程式、警報存放位置)位於 GitOps 儲存庫中的 .claude/profiles/gitops.md。請先閱讀設定檔。 如果設定檔遺失,請透過讀取儲存庫(ApplicationSet、AppProject、密碼儲存庫、一兩個現有應用程式、監控資料夾)從 templates/profile.md 建立它,並在一行內告知使用者您已建立該檔案。切勿猜測路徑。

應用程式如何上線

  • 使用目錄產出器的 ApplicationSet 會將設定檔應用程式目錄下的每個資料夾轉換為其自己的 ArgoCD 應用程式與命名空間。一旦資料夾包含有效的 kustomization.yaml,它就會開始部署。
  • 在推送到 ArgoCD 追蹤的分支之前,任何內容都不會到達叢集。僅使用 kubectl 套用的變更將在下一次同步時被還原。
  • 平台元件(CNI、儲存、控制器)不應放在應用程式目錄中;設定檔會說明它們的位置。

新命名空間必須在相同提交中於各處加入白名單

設定檔的白名單章節列出了每個參考命名空間的檔案(通常包括:AppProject 的 destinations、ClusterSecretStore 的 conditions,以及如果應用程式需要 LB IP 時的 LoadBalancer IP 池與 L2/BGP 宣告選擇器)。遺漏任何一個都會導致應用程式無法同步、其 ExternalSecret 停留在 SecretSyncError 狀態,或其 LB IP 永遠無法被宣告。在新增資料夾的提交中,將命名空間新增至所有適用的檔案。

導入順序(從最小安全形狀開始)

  1. ns.yaml:使用設定檔中的 Pod 安全標籤來建立命名空間。
  2. kustomization.yaml:按依賴順序排列資源(命名空間和設定,然後是工作負載,最後是路由)。
  3. 密碼:先在密碼後端(設定檔:密碼)建立條目,然後為每個密碼建立一個 ExternalSecret。絕對不要提交密碼值;引導密碼和應急密碼應保留在 Git 之外。
  4. 執行時期清單(Deployment、Service、PVCs、ConfigMap),僅在映像檔名稱和密碼名稱確認之後。提供真實健康端點的 Readiness 與 Liveness 探針、資源請求,以及命名空間 Pod 安全層級所需的 Security Context。
  5. 凌晨三點警報(如下),與工作負載在同一變更中新增。
  6. 路由,最後,在映像檔運行、密碼解析成功且探針通過之後(請參閱公開)。
  7. 在應用程式資料夾中新增 README.md:說明其用途、執行時期依賴項、密碼名稱、儲存方式以及如何存取。

慣例(設定檔中已有值)

  • 映像檔:固定使用 tag@sha256:<digest>,除非設定檔指出應用程式追蹤移動標籤;自有的映像檔來自設定檔的註冊表,並使用不可變標籤。私有映像檔需要設定檔中的拉取密照模式。
  • 密碼:使用針對設定檔 ClusterSecretStore 的 ExternalSecret 資源,絕不內聯使用 Secret 資料。
  • 儲存:使用設定檔中的儲存類別及其用途(小型複製區塊磁碟區 vs NFS 上的大量資料)。設定檔中的容量限制為硬性限制。
  • 路由:公有和內部閘道器及其主機模式;透過 LoadBalancer Service 進行原始 TCP/UDP 路由。
  • 參考設定檔中參考應用程式的形狀,而非自行發明新的形狀。

凌晨三點警報

在推送之前詢問:如果這個應用程式在凌晨三點故障,要如何才能有人知道,他們會先查看什麼?

  • 該應用程式必須由能夠通知到人的警報所涵蓋:將其命名空間和工作負載新增至設定檔的監控警示規則(不可用副本、崩潰迴圈、待處理 Pod 或 PVC),或者如果應用程式有這些規則無法察覺的故障模式(例如停止排空的佇列、停止運行的作業、即將過期的憑證或權杖),則新增應用程式專屬的規則。
  • 應用程式的日誌必須說明失敗原因,並提供可用於定位問題的 ID;如果映像是我們的且日誌沒有這麼做,則這是一項任務。
  • 在提交訊息中寫下信號:凌晨 3 點:<警示名稱> via <接收者>。

公開

在應用程式運行、其密碼解析成功且其健康檢查通過之前,請勿新增公開路由。僅供內部使用的工具應僅附加到內部閘道器,且不應有公開路由。當您確實要公開時,請遵循設定檔的相關技能來處理公開 Ingress 路徑(DNS、通道、憑證)。

導入後(驗證,不要假設)

  1. 推送;觀察新應用程式出現並收斂(kubectl get applications.argoproj.io -n argocd,或使用設定檔的驗證指令)。如果設定檔有說明,可以要求重新整理以跳過輪詢延遲。
  2. 檢查:應用程式 Synced 且 Healthy,每個 ExternalSecret 為 SecretSynced,Pod 就緒,路由有回應,且警報規則已載入(出現在監控堆疊的規則清單中)。
  3. 如果未收斂,請從上到下逐步檢查鏈結:白名單 → 密碼 → ArgoCD 同步錯誤 → Pod → 路由。白名單通常是罪魁禍首。設定檔的相關技能會列出叢集的診斷技能。

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

相關技能