Communitygithub.com

lguidolin/cloud-delivery-aks

Verwenden Sie diese Fertigkeit bei der Bereitstellung auf Kubernetes oder Azure Kubernetes Service (AKS), der Konfiguration von Cloud-Geheimnissen, dem Einrichten von progressiven Rollouts/Canary-Deployments, kurzlebigen PR-Umgebungen oder k8s-Health-Probes. Stichwörter: Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, Canary, Blue-Green, Liveness, Readiness, PodDisruptionBudget, HPA, Rollback, GHCR.

Was ist cloud-delivery-aks?

Diese Fertigkeit bietet ein umfassendes Bereitstellungs-Framework für Kubernetes und Azure Kubernetes Service (AKS). Sie implementiert kritische Sicherheitsmechanismen wie Health-Gates, progressive Rollouts (Canary/Blue-Green) und einen überprüfbaren Verifizierungs-Gate auf AKS. Die Fertigkeit ist stack-spezifisch und lädt nur, wenn eine Aufgabe Kubernetes/AKS betrifft, sodass Projekte ohne Cloud-Bereitstellung (z. B. lokales Docker Compose) nicht betroffen sind. Die Kernprinzipien umfassen: unveränderliche, digeste-basierte Images, die in CI gebaut, in GHCR gespeichert und ohne Neubau durch die Umgebungen (Preview → Staging → Production) befördert werden. Kurzlebige Preview-Umgebungen pro PR ermöglichen isolierte Tests. Kubernetes-Health-Probes (Liveness, Readiness, Startup), Rolling-Update-Strategien, PodDisruptionBudgets und horizontale Pod-Autoscaling (HPA) sind obligatorisch. Progressive Bereitstellung in Produktion erfolgt über Argo Rollouts/Flagger mit automatisierter Metrikanalyse. Die Fertigkeit behandelt auch Rollbacks, Migrationen und Sicherheit. Rollbacks sind erstklassig und werden vor riskanten Änderungen geübt – ein einfaches `kubectl rollout undo` reicht aus, da Images unveränderlich sind. Migrationen sind separate Pipeline-Schritte mit Expand-Safety. Geheimnisse werden über Azure Key Vault bezogen, nie in Images eingebettet. CI dient als Gate mit Linting, Typprüfungen, Tests und Sicherheitsscans. Die Pipeline hat drei Stufen: Preview (pro PR), Staging (bei Merge in Main) und Production (nach Freigabe und Genehmigung). Die Digests werden basierend auf Git-Referenzen befördert, um Reproduzierbarkeit zu gewährleisten. Die Fertigkeit bietet auch eine detaillierte Übersichtstabelle mit Mechanismen für Geheimnisse, Health, Rollouts, Rollbacks, Preview-Umgebungen und Genehmigungen (erzwungen oder beratend).

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/cloud-delivery-aks
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

Cloud Delivery auf AKS

Überblick

Der Bereitstellungsmechanismus für Kubernetes/Azure. Implementiert Bereitstellungssicherheit und den Verifizierungs-Gate auf AKS. Stack-spezifisch konzipiert – diese Fertigkeit wird nur geladen, wenn eine Aufgabe k8s/AKS betrifft, sodass Projekte ohne Cloud-Bereitstellung (z. B. lokales Docker Compose) diesen Inhalt nie sehen.

Bereitstellungsregeln

  • Lokale Entwicklung nutzt den gesamten Stack via Docker Compose, ein Befehl, umfassend – eine Anforderung erster Güte.
  • Images werden in CI erstellt → GHCR, identifiziert durch Content-Digest, dann unverändert befördert Preview → Staging → Production. Nie pro Umgebung neugebaut.
  • Kurzlebige Preview-Umgebungen pro PR. Jeder PR wird in seinem eigenen isolierten Namespace auf AKS bereitgestellt, bei Merge/Schließen abgebaut. Das Integrationstest-Bett; günstig zu erstellen und zu zerstören.
  • Kubernetes-Health-Gating. Jede Workload definiert Liveness-, Readiness- und Startup-Probes (verbunden mit den Endpunkten in observability-and-slos), eine Rolling-Update-Strategie mit begrenztem maxUnavailable/maxSurge und einem PodDisruptionBudget. Verwenden Sie ein HPA für Last.
  • Progressive Bereitstellung in Produktion. Canary oder Blue-Green via Argo Rollouts / Flagger mit automatischer Metrikanalyse, die an SLOs gebunden ist; ein fehlgeschlagenes Canary wird automatisch abgebrochen.
  • Rollback ist erstklassig und wird geübt. Unveränderliche, digest-addressed Images machen Rollback zu einer erneuten Bereitstellung des zuvor guten Digests (kubectl rollout undo / Abbruch des Rollouts). Vor dem Ausliefern riskanter Änderungen verifiziert.
  • Migrationen sind ein separater, geordneter Pipeline-Schritt, expand-sicher (siehe zero-downtime-migrations), werden vor dem Code ausgeführt, der von ihnen abhängt – nie in den Pod gebündelt, der das neue Schema benötigt.
  • CI ist das Gate: Lint, Typprüfung, Vertragsprüfungen, Tests, Security-Scans werden bei jeder Änderung ausgeführt und blockieren den Merge im Modus enforced. CI baut auch das Image und veröffentlicht seinen Provenance-Attestation und befördert dann diesen Digest unverändert.
  • Dev/Prod-Parität & Konfiguration aus der Umgebung. Geheimnisse aus Azure Key Vault (via Secrets Store CSI-Treiber oder versiegelte Secrets) – niemals in Images oder festgeschriebenen .env. Ports/Konfiguration aus der Umgebung. Nur für Dev bestimmte Werkzeuge (pgTAP, Test-Runner) werden nie in Produktions-Images ausgeliefert.

Die Pipeline

StufeAuslöserUmgebungDigest
previewPR geöffnet / synchronisiertkurzlebiger ns preview-<app>-pr-<N>hier gebaut, getaggt sha-<pr-head>
stagingMerge in mainpersistenter ns stagingNeutag des Preview-Digests als sha-<merge>
productionRelease veröffentlicht + Genehmigungns productionDigest des Eltern-Commits des Release-Commits

Warum der Eltern-Commit. Der Release-Commit von release-please ändert nur CHANGELOG.md und das Manifest, daher ist sein Baum nie einer, den Staging durchlaufen hat – was immer Preview für den Release-PR selbst gebaut hat, wurde nie über Preview hinaus befördert. Sein Eltern-Commit ist der letzte Feature-Merge, was genau das ist, was Staging validiert hat, vorausgesetzt, release-please hält seinen Release-Branch an der Spitze von main (sein Standardverhalten). Den Digest aus Git abzuleiten, anstatt aus dem Live-Cluster-Zustand, hält die Beförderung reproduzierbar.

Sicherheit beim Neutag. Squash-Merge erzeugt einen anderen Commit-SHA und, wenn sich main während des PRs verschoben hat, einen anderen Baum. Zwei Absicherungen:

  • Erfordern „Branches aktuell halten vor Merge“ – eine Untermenge der Regel für erforderliche Status-Checks – sodass der Squash-Baum per Konstruktion dem PR-Kopf-Baum entspricht. Diese Absicherung benötigt Branch-Protection, existiert also nur im Modus enforced; ein Projekt im Modus advisory hat den untenstehenden Baumvergleich als einzige Absicherung und sollte den Neubaupfad als Routine statt als Ausnahme erwarten.
  • Verifizieren statt annehmen: Vergleiche git rev-parse <merge>^{tree} mit dem PR-Kopf-Baum. Gleich → Neutag. Ungleich → Neubau beim Merge-SHA. Das ist nicht der Neubau pro Umgebung, den die Bereitstellungsregeln verbieten: Ein ungleicher Baum bedeutet, dass der Inhalt selbst sich von dem unterscheidet, was Preview validiert hat, also gibt es kein beförderbares Artefakt – und das neugebaute Image tritt in Staging als neuer Kandidat ein, nicht als Beförderung. Beachten Sie, was verloren geht, wenn dieser Pfad genommen wird: Dieses Image wurde nie in einer Preview-Umgebung überprüft, daher gilt „das ausgelieferte Image ist das überprüfte Image“ nicht dafür. Staging ist dann seine erste Validierung, nicht seine zweite.

Der Neutag ist eine Pointer-Operation – kein Neubau, kein Pull:

docker buildx imagetools create -t "$REPO:sha-$MERGE_SHA" "$REPO@sha256:$DIGEST"

Der Attestation bleibt an den PR-Kopf-SHA gebunden, also erfassen Sie die Kopf→Merge-Zuordnung im Bereitstellungsdatensatz; die Image-Konfiguration kann ohne Neubau nicht bearbeitet werden.

Das Genehmigungs-Gate – eine Eigenschaft, zwei Mechanismen:

ModusMechanismus
enforcedGitHub-Umgebung production mit erforderlichen Reviewern
advisoryEin workflow_dispatch-Promote-Job; das Ausführen ist die Entscheidung

Kurzreferenz

AspektMechanismus
GeheimnisseKey Vault → CSI-Treiber; rotiert; nie im Image
HealthLiveness + Readiness + Startup-Probes; Readiness prüft echte Abhängigkeiten
Sicheres RolloutCanary/Blue-Green, SLO-gesteuert, automatischer Abbruch bei Fehlschlag
RollbackErneute Bereitstellung des zuvor guten Digests; vor riskanten Auslieferungen geübt
PR-UmgebungIsolierter Namespace, bei Merge abgebaut
SchemaSeparater geordneter Schritt, expand-sicher, vor Code
BeförderungNeutag des Digests; nie Neubau pro Umgebung
GenehmigungUmwelt-Reviewer (enforced) oder manuelle Dispatch (advisory)

Warum dies isoliert ist: Alle Azure/k8s-Spezifika leben hier hinter einem stack-spezifischen Auslöser. Ein lokales oder Cloud-fremdes Projekt ersetzt seine eigene Bereitstellungsfertigkeit; die Prinzipien (unveränderliches Artefakt, reversibles + progressives Bereitstellen, entkoppelte Migrationen) stammen aus resilience-and-deploy-safety.

Vollständige Begründung: Artikel XIX der Verfassung, gebündelt in engineering-constitution/references/engineering-constitution.md.

Individual skills in this repo

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

lguidolin/change-hygiene-and-code-craft

Use when writing or refactoring code, structuring a commit or PR, or deciding whether to abstract duplication. Symptoms — mixing reorg with logic changes, a PR doing several things at once, a file growing large, the second copy of similar code, or unsure whether to DRY something up.

lguidolin/commit-history-rewrite

Use when an existing repository has messy commit history that needs to conform to conventional commits before adopting release-please, or when intermediate WIP/fixup/merge commits need to be cleaned up.

lguidolin/conventional-commits-and-releases

Use when committing, writing a commit message, opening a PR that will be squash-merged, or configuring automated versioning/changelogs. Keywords — conventional commits, release-please, semver, feat/fix/chore, breaking change, changelog.

lguidolin/defense-in-depth-security

Use when handling untrusted input, secrets, authentication/authorization, or dependencies — or threat-modeling a new surface. Keywords — STRIDE, threat model, least privilege, secrets management, supply chain, dependency scanning, input validation, audit log, defense in depth.

lguidolin/designing-before-building

Use when starting a feature, fixing a non-trivial bug, or about to write implementation code — before any code exists. Symptoms you need this: "this is simple, I'll just code it", reaching for the editor before a design is approved, or an idea that hasn't been turned into a spec and plan.

lguidolin/engineering-constitution

Use when starting work in a project that follows the engineering constitution, orienting to its rules, or deciding which engineering practice applies to a task — spec writing, commits, testing, security, deploys, database, or UI work.

lguidolin/graphql-contract-testing

Use when writing a GraphQL query/mutation that the UI and a test will share, or building route/schema contract or smoke tests. Symptoms — copying a query into a test, a test asserting on query text, schema change that didn't break the UI build, or RLS/permission drift. Keywords — graphql-codegen, typed document, contract test, route smoke test.

lguidolin/init-repo-CI

Use when setting up a new repository with conventional commits, release-please, and CI automation, or when retrofitting an existing repository that lacks automated versioning and PR validation workflows.

lguidolin/interface-craft-and-accessibility

Use when building or styling UI — components, layouts, forms, design tokens — or making accessibility decisions. Keywords — a11y, WCAG, keyboard navigation, focus state, contrast, design system, minimalist UI, component reuse, ARIA, semantic HTML.

lguidolin/merge-gates-and-automation

Use when setting up or changing CI, pre-push hooks, or a task runner, or deciding what must pass before merge. Symptoms — tempted to put authoritative checks only in a local hook, skip CI, bypass with --no-verify, or unsure what gates a merge vs. runs locally.

lguidolin/observability-and-slos

Use when adding logging, metrics, tracing, health checks, SLOs, or alerting — or when building a service surface that needs to be operable and debuggable. Keywords — structured logs, OpenTelemetry, correlation id, RED metrics, liveness, readiness, SLI, SLO, error budget, alerting.

lguidolin/performance-and-scale

Use when working on hot paths, list endpoints, pagination, data-access in loops, or public interfaces/schemas. Symptoms — unbounded queries, N+1 access, no latency budget, optimizing without measuring, or changing an interface many consumers depend on. Keywords — pagination, N+1, Hyrum's Law, performance budget, bundle size.

lguidolin/postgres-postgraphile-rls-and-sql

Use when writing PostgreSQL, PostGraphile config, Row-Level Security policies, SQL schema files, or working on the Browser→App→PostGraphile→Postgres data path. Keywords — RLS, SECURITY DEFINER, search_path, pgSettings, grants, roles, GraphQL depth limit, query cost, statement_timeout, SQL file organization.

lguidolin/recording-decisions

Use when a design or architecture decision has been made and needs to be captured — writing a decision record or ADR, updating a decision index, noting a deferred idea, or superseding a past decision. Keywords — ADR, decision record, rationale, rejected alternatives, dependency index.

lguidolin/resilience-and-deploy-safety

Use when planning a deploy, designing a rollback, or responding to an incident or writing a postmortem. Keywords — deploy safety, rollback, immutable artifact, progressive delivery, canary, blast radius, incident response, blameless postmortem, error budget.

lguidolin/ship-it

Use when the user wants to ship work — push, PR, archive decision records, merge, and clean up. Handles the full lifecycle from committing final changes through post-merge cleanup including converting specs/plans to compact decision records.

lguidolin/tests-as-a-control

Use when writing or modifying tests, when a test breaks during a refactor, or when testing permission/role rules. Symptoms — tempted to edit a test to make it pass, testing only the happy path, a deny-test that started passing, flaky tests, or unsure what to assert.

lguidolin/zero-downtime-migrations

Use when changing a database schema where data must survive the change — adding/removing/renaming columns, constraints, indexes, or backfilling. Symptoms — a destructive migration bundled with a code deploy, a NOT NULL column with a backfill, a table-locking UPDATE, or a rename. Keywords — expand/contract, parallel change, backfill, NOT VALID, CREATE INDEX CONCURRENTLY, graphile-migrate.

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community