A dockup.yaml Config as Code: biztonságos tervezés és alkalmazás

A dockup.yaml a szolgáltatáskonfigurációt review-olható repository-artifacttá alakítja. A dashboard korábbi állapotának felidézése helyett a csapat egyetlen fájlban deklarálhatja a branchet, a portot, a build- és start parancsokat, a health checkeket, a hagyományos környezeti változókat és a domaineket.

A Dockup különválasztja az ellenőrzést és a módosítást. A dockup plan módosítás nélkül megmutatja a manifest és az éles szolgáltatás közötti különbséget. A dockup up alkalmazza a deklarált módosításokat. A törlés továbbra is csak a --prune explicit megadásával engedélyezett.

Mit lehet deklarálni a dockup.yaml fájlban?

A service manifest tartalmazhatja azokat a production-beállításokat, amelyeknél előnyös a code review:

service:
  branch: main
  port: 3000
  dockerfile: Dockerfile
  build: npm run build
  start: npm start
  healthcheck:
    path: /health
    interval: 5
    timeout: 3
    retries: 5
  env:
    NODE_ENV: production
    API_URL: https://api.example.com
  domains:
    - api.example.com
    - { domain: admin.example.com, port: 4000 }

Alapértelmezés szerint a fájl a repository gyökerébe kerül. Másik elérési út a --file kapcsolóval választható ki.

Ne helyezz secret értékeket az env mappingbe. A manifestet a rendszer a többi source fájlhoz hasonlóan commitolja, review-olja, cache-eli és másolja. Credentialekhez használd a dockup env set --secret parancsot vagy egy jóváhagyott secret injection folyamatot.

A CPU-, RAM- és lemezhasználat továbbra is usage-based, és a plan egyenlegével szemben percenként kerül elszámolásra; a manifestnek a szolgáltatás konfigurációját kell leírnia, nem a billinggel kapcsolatos feltételezéseket.

Hogyan mutatja meg a dockup plan a konfigurációs driftet?

Minden apply előtt futtass csak olvasható összehasonlítást:

dockup plan production/api --json

Az eredmény a módosításokat aspectekkel, mezőkkel, régi és új értékekkel, valamint műveletekkel együtt tartalmazza. A plan jelezheti például, hogy megváltozott a branch, eltér a health path, új domain kerül hozzáadásra, vagy drift alakult ki egy egyszerű környezeti értékben.

A plan három helyzetben különösen hasznos:

Helyzet	Mit tár fel a plan?
A pull request módosítja a manifestet	A merge előtti várt production-hatás
Valaki manuálisan módosította a dashboardot	A repository forrásától való eltérés
Egy agent frissítést javasol	Az agent által módosítani kívánt pontos mezők
Incident utáni helyreállítás	Hogy az éles állapot eltér-e a korábbi ismert konfigurációtól
Többkörnyezetes beállítás	A production és a staging manifestjei közötti különbségek

A planning nem lockolja a szolgáltatást. Az éles állapot a plan és az apply között megváltozhat, ezért a magas kockázatú workflow-kban érdemes a review-t és az up futtatását időben közel tartani egymáshoz, majd ellenőrizni az apply eredményét.

Egy coding agentnek vissza kell adnia a plan JSON-kimenetét vagy egy tömör, mezőnkénti összefoglalót. A „Configuration looks good” nem elegendő review-artifact.

Hogyan alkalmazza a dockup up a config as code beállításokat?

Az alapértelmezett manifest alkalmazása:

dockup up production/api --json

Alkalmazás, majd deployment indítása:

dockup up production/api --deploy --json

Másik fájl használata staginghez:

dockup plan production/api \
  --file dockup.production.yaml \
  --json

dockup up production/api \
  --file dockup.production.yaml \
  --deploy \
  --json

Az apply eredménye jelzi, hogy mely módosításokat alkalmazta vagy hagyta ki, és a --deploy használatakor a deployment ID-ját is tartalmazhatja. A körülötte zajló deployment során továbbra is érdemes szükség esetén terminális állapotot ellenőrizni; a konfiguráció módosítása és egy egészséges production release két külön eredmény.

A secret értékek a manifesten kívül maradnak. A konfiguráció alkalmazása előtt állítsd be őket a secret environment workflow-n keresztül, majd deployolj, és ellenőrizd a létrejövő containert a tárolt érték kiíratása nélkül.

Miért additive alapértelmezés szerint a config as code működés?

A hiányos manifest legbiztonságosabb értelmezése az, hogy „ezeket a deklarált értékeket kezeld”, nem pedig az, hogy „minden mást törölj”. A Dockup ezért változatlanul hagyja azokat a manifestből hiányzó environment változókat és domaineket, amelyek már léteznek.

Ez a fokozatos bevezetés során fontos. Egy szolgáltatás már tartalmazhat secret változókat, operatív domaineket vagy ideiglenes konfigurációt, amelyet még nem modelleztek. Az első up futtatásnak nem szabad törölnie ezeket.

A biztonsági garanciák konkrétan a következők:

• A dockup up nem töröl service-eket, adatbázisokat vagy volume-okat.
• A meglévő secret változókat nem írják felül a manifest egyszerű értékei.
• A secret változók nem kerülnek prune-olásra.
• A deployment során automatikusan alkalmazott manifest additive módon működik.
• Egy érvénytelen manifest nem alakul át csendben destruktív cleanup-műveletté.

Az additive működés alkalmassá teszi a dockup.yaml fájlt egy inkrementális GitOps workflow-ra. Ugyanakkor ez azt is jelenti, hogy a manifest csak akkor tekinthető teljes inventorynak, ha a csapat tudatosan bevezeti a támogatott mezők pruningját.

Hogyan érdemes review-zni a --prune használatát?

A --prune eltávolítja a manifestből hiányzó támogatott, egyszerű környezeti értékeket és domaineket:

dockup plan production/api --json
dockup up production/api --prune --json

Kezeld ezt a kapcsolót destruktív kérésként. Review-zd a plant, pontosan nevezd meg a célt, és production környezetben agent működése esetén kérj human approvalt.

A művelet nem vonatkozik a secret értékekre, service-ekre, adatbázisokra vagy volume-okra. Ezeknek a resource-oknak saját lifecycle- és megerősítési folyamataik vannak. Ez a szétválasztás megakadályozza, hogy egy kisebb manifestmódosítás széles körű infrastructure deletion műveletté váljon.

Egy hasznos approval record például így szól: „A dockup.yaml alkalmazása a production/api célon, valamint a plan X-ben látható két egyszerű változó és egy domain prune-olása.” Ez nem jelenthet általános, jövőbeli planekre is érvényes blanket permissiont.

A tágabb confirmation modellt a production guardrails for AI agents ismerteti.

Hogyan működtetnek a csapatok GitOps workflow-t dockup.yaml használatával?

Tartsd egyszerűen a workflow-t:

1. Egy fejlesztő vagy agent módosítja a dockup.yaml fájlt.
2. A CI ellenőrzi a YAML szintaxisát és az alkalmazásteszteket.
3. Egy csak olvasható dockup plan fut le a kívánt célon.
4. A pull request tartalmazza a source diffet és az éles állapotról készült plant is.
5. Egy reviewer jóváhagyja a módosítást.
6. A dockup up --deploy alkalmazza azt.
7. A deploy megvárja a terminális sikert.
8. A status-, log- és audit-bizonyítékokat megőrzik.

A manifest nem válhat gyűjtőhellyé. Az alkalmazás üzleti konfigurációját megfelelő esetben tartsd az alkalmazásban. A dockup.yaml fájlt a szolgáltatás határáért felelős deployment- és runtime-beállításokhoz használd.

A környezetspecifikus fájlok egy dokumentálatlan templating layerrel ellátott közös fájlnál áttekinthetőbbek lehetnek. Például használj dockup.staging.yaml és dockup.production.yaml fájlokat, és add át explicit módon a kívánt fájlt.

A branch preview izolált deployment, miközben a production konfiguráció külön review-cél marad. Private networkinget használó projektekben a preview-k csatlakozhatnak a projekt hálózatához, és read-only adatbázis-hozzáférést kaphatnak anélkül, hogy módosítanák a production manifestet.

A credentialek kezeléséhez használd az environment variables and secrets guide útmutatót, a readiness gate-hez pedig a zero-downtime deployments leírást.

Drift response playbook

Amikor a dockup plan váratlan éles módosításokat jelez, ne írd felül automatikusan ezeket. Állapítsd meg, hogy a dashboardon végzett módosítás emergency fix, jogosulatlan változtatás vagy olyan szándékos beállítás volt-e, amelyet soha nem commitoltak.

Ezután válassz egyetlen source of truth-t:

• Módosítsd a manifestet a szándékosan megtartandó éles értéknek megfelelően.
• Alkalmazd a manifestet a review-zott érték helyreállításához.
• Dokumentálj egy ideiglenes kivételt felelőssel és lejárati idővel.
• Vizsgáld meg az audit logot, ha az eredet ismeretlen.

dockup audit --writes --json

Ez a folyamat megőrzi a dockup.yaml authoritative szerepét anélkül, hogy törölné az incident kontextusát.

A Dockup CLI reference tartalmazza a jelenlegi manifestmezők, valamint a plan és up opcióinak leírását.

Review-olható manifestmódosítások kialakítása

Tartsd az egyes módosításokat olyan kicsiben, hogy a plannak egyértelmű célja legyen. Ha egy pull requestben együtt szerepel branchmódosítás, erőforrás-bővítés, új domain, health check átírása és environment cleanup, az megnehezíti a review-t és a rollbacket is.

A szokatlan értékeket kommentekkel magyarázd, de ne másold az operatív dokumentációt a fájlba. A repository runbook hivatkozzon a szolgáltatás céljára, a health jelentésére és az approval policyra. A manifest maradjon érvényes YAML, amely custom preprocessor nélkül parse-olható.

Egy hasznos pull-request template bekéri a dockup plan --json kimenetét, a várt deployment-hatást, azt, hogy kértek-e --prune műveletet, valamint az előző deployment ID-ját. Így az AI agent és a human reviewer ugyanazokkal a bizonyítékokkal dolgozhat.

A manifest bevezetése az éles állapot megzavarása nélkül

Meglévő szolgáltatás esetén kezdd azokkal a mezőkkel, amelyeket ellenőrizni tudsz. Futtasd a dockup info production/api --json parancsot, írj egy minimális dockup.yaml fájlt, majd hasonlítsd össze a dockup plan eredményével. A beállításokat fokozatosan add hozzá, ne próbáld egyszerre rekonstruálni a dashboard összes korábbi beállítását.

Mivel az apply additive módon működik, az átvétel ideje alatt a nem kezelt egyszerű értékek és domainek megmaradnak. Miután a manifest pontosan tükrözi a kívánt, nem secret jellegű konfigurációt, döntsétek el, hogy a csapat használ-e valaha pruningot. Egyes csapatok manuálisan végzik a cleanupot, mások csak plan approval után, védett pipeline-ban engedélyezik a --prune használatát.

A config as code célja nem a Gitben lévő sorok számának maximalizálása. Hanem az, hogy a productionnel kapcsolatos szándék érthető, review-olható és helyreállítható legyen.

A plane-k maradjanak mentesek a secret anyagoktól

A plannek biztonságosan csatolhatónak kell lennie pull requesthez vagy incident recordhoz. Mivel a dockup.yaml csak egyszerű értékeket tartalmaz, a meglévő secret értékek pedig védettek maradnak, a reviewerek a kívánt konfigurációt production credentialek átadása nélkül is ellenőrizhetik. Ennek ellenére vizsgáld meg a hagyományos értékeket is belső hostnevek, ügyfélazonosítók és egyéb, nyilvánosságra nem hozandó adatok szempontjából.

A source és a target legyen együtt kezelve

A pull requestben és a deployment jobban is nevezd meg a kívánt project/service célt. Egy érvényes dockup.yaml rossz targetre alkalmazva ugyanúgy operatív hibát jelent. A target felderítése és a manifest review-ja két külön, kötelező ellenőrzés.

A YAML validálása a plan előtt

Parse-old a manifestet CI-ban, mielőtt meghívod a Dockupot, hogy az indentation- vagy type-hibák a source módosításához közel bukjanak el. A szintaxisvalidálás nem helyettesíti a dockup plan futtatását; csak elkerülhetővé teszi az olvashatatlan fájllal indított kéréseket.

Részesíts előnyben egyetlen source-ot

Egy review-zott dockup.yaml fájlnak érthetően kell leírnia a productionnel kapcsolatos szándékot.

Kezdd egy ellenőrizhető deploymenttel

Adj hozzá egy minimális manifestet egy szolgáltatáshoz, futtass egy csak olvasható plant, és az első apply előtt review-zd az összes jelentett mezőt.

Kezdd ingyen az app.dockup.ai oldalon. A Free plan havi 0 $, 10 $ induló kreditet tartalmaz, és egy workspace-t, három adatbázist, valamint három deploymentet támogat.

GYIK

Mi az a dockup.yaml?

A Dockup config-as-code manifestje, amellyel deklarálható a szolgáltatás branche, portja, build- és startbeállítása, health checkjei, egyszerű környezeti értékei és domainjei.

Módosítja a productiont a dockup plan?

Nem. A dockup plan csak olvasható, és megmutatja a manifest, valamint az éles szolgáltatás közötti különbséget.

Törli a dockup up a fájlban nem szereplő konfigurációt?

Alapértelmezés szerint nem. Az apply additive módon működik. A támogatott, egyszerű környezeti értékek és domainek csak explicit --prune használatakor kerülnek eltávolításra.

Tárolhatók secretek a dockup.yaml fájlban?

Nem ajánlott. Csak egyszerű értékeket commitolj; a secret értékeket a secret environment paranccsal vagy runtime secret injection használatával állítsd be. A meglévő secretek védettek a pruninggal szemben.

Tud a dockup up deployolni a konfiguráció alkalmazása után?

Igen. A dokumentált --deploy opció alkalmazza a manifestet és deploymentet indít, amelynek terminális eredményét ezt követően ellenőrizni kell.