dockup.yaml Config as Code: Planera och tillämpa säkert

dockup.yaml gör servicekonfigurationen till en granskningsbar artefakt i repot. I stället för att förlita sig på ett dashboard-tillstånd som någon minns kan teamet deklarera branch, port, build- och startkommandon, health checks, vanliga environment-värden och domäner i en och samma fil.

Dockup skiljer inspektion från förändringar. dockup plan visar skillnaden mellan manifestet och den aktiva servicen utan att ändra något. dockup up tillämpar de deklarerade ändringarna. Borttagning kräver ett uttryckligt val genom --prune.

Vad kan dockup.yaml deklarera?

Ett servicemanifest kan innehålla produktionsinställningar som bör granskas som kod:

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 }

Filen placeras som standard i repots rot. En annan sökväg kan väljas med --file.

Lägg inte secrets i env-mappningen. Manifestet checkas in, granskas, cachas och kopieras precis som andra källfiler. Använd dockup env set --secret eller en godkänd process för secret injection när credentials ska hanteras.

Förbrukning av CPU, RAM och disk är fortsatt användningsbaserad och mäts per minut mot planens saldo. Manifestet bör därför beskriva servicekonfiguration snarare än antaganden om debitering.

Hur visar dockup plan konfigurationsdrift?

Kör en skrivskyddad jämförelse före varje tillämpning:

dockup plan production/api --json

Resultatet innehåller ändringar med aspekter, fält, gamla värden, nya värden och åtgärder. En plan kan visa att branchen har ändrats, att en health path skiljer sig, att en domän kommer att läggas till eller att ett vanligt environment-värde har avvikit.

En plan är värdefull i fem situationer:

Situation	Vad planen visar
En pull request ändrar manifestet	Den avsedda effekten på produktionen före merge
Dashboarden har redigerats manuellt	Drift från repots källa
En agent föreslår en uppdatering	Exakta fält som agenten tänker ändra
Återställning efter en incident	Om det aktiva tillståndet redan skiljer sig från den kända konfigurationen
Konfiguration med flera miljöer	Skillnader mellan produktions- och stagingmanifest

Planering låser inte servicen. Det aktiva tillståndet kan ändras mellan plan och tillämpning, så workflows med hög risk bör hålla granskningen och up nära varandra och kontrollera resultatet från tillämpningen.

En coding agent bör returnera planens JSON eller en kort sammanfattning fält för fält. ”Konfigurationen ser bra ut” är inte ett tillräckligt granskningsunderlag.

Hur tillämpar dockup up config as code?

Tillämpa standardmanifestet:

dockup up production/api --json

Tillämpa manifestet och starta sedan en deployment:

dockup up production/api --deploy --json

Använd en annan fil för staging:

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

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

Resultatet visar vilka ändringar som tillämpades eller hoppades över och kan innehålla deployment-ID:t när --deploy används. Den omgivande deployment-processen bör fortfarande använda verifiering av slutstatus där det är lämpligt. En konfigurationsändring och en frisk produktionsrelease är separata resultat.

Secret-värden förblir utanför manifestet. Ange dem via workflowet för secret environment innan konfigurationen tillämpas, deploya sedan och verifiera den resulterande containern utan att skriva ut det lagrade värdet.

Varför är config as code additivt som standard?

Den säkraste tolkningen av ett ofullständigt manifest är ”hantera dessa deklarerade värden”, inte ”ta bort allt annat”. Därför lämnar Dockup environment-variabler och domäner som saknas i filen oförändrade.

Detta är viktigt vid gradvis införande. En service kan redan ha secret-variabler, operativa domäner eller tillfällig konfiguration som ännu inte har modellerats. Den första up ska inte radera dem.

Säkerhetsgarantierna är specifika:

• dockup up tar inte bort services, databaser eller volymer.
• Befintliga secret-variabler skrivs inte över av vanliga manifestvärden.
• Secret-variabler tas inte bort genom prune.
• Automatisk tillämpning av manifestet vid deploy är additiv.
• Ett ogiltigt manifest blir inte i tysthet till en destruktiv rensning.

Det additiva beteendet gör dockup.yaml lämpligt för ett inkrementellt GitOps-workflow. Det innebär också att manifestet inte automatiskt är en fullständig inventering, såvida teamet inte medvetet börjar använda pruning för fält som stöds.

Hur bör --prune granskas?

--prune tar bort vanliga environment-värden och domäner som stöds men saknas i manifestet:

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

Betrakta flaggan som en destruktiv begäran. Granska planen, ange det exakta målet och inhämta mänskligt godkännande när en agent arbetar mot produktion.

Åtgärden omfattar inte secrets, services, databaser eller volymer. Dessa resurser har egna livscykler och bekräftelseflöden. Separationen förhindrar att en liten manifeständring leder till en omfattande infrastruktur-borttagning.

Ett användbart godkännande kan lyda: ”Tillämpa dockup.yaml på production/api och ta bort de två vanliga variablerna och den domän som visas i plan X.” Det bör inte vara ett återanvändbart generellt tillstånd för framtida planer.

Den bredare modellen för bekräftelser beskrivs i produktionsskyddsräcken för AI-agenter.

Hur arbetar team med ett GitOps-workflow med dockup.yaml?

Håll workflowet enkelt:

1. En utvecklare eller agent redigerar dockup.yaml.
2. CI validerar YAML-syntax och applikationstester.
3. En skrivskyddad dockup plan körs mot det avsedda målet.
4. Pull requesten visar både källkodsdiffen och planen för det aktiva tillståndet.
5. En granskare godkänner ändringen.
6. dockup up --deploy tillämpar den.
7. Deployen väntar på slutgiltig framgång.
8. Status, loggar och audit-underlag sparas.

Manifestet bör inte bli en plats där allt möjligt samlas. Behåll applikationens verksamhetskonfiguration i applikationen när det är lämpligt. Använd dockup.yaml för deployment- och runtime-inställningar som ägs av servicens gräns.

Miljöspecifika filer kan vara tydligare än en enda fil med ett odokumenterat templating-lager. Använd till exempel dockup.staging.yaml och dockup.production.yaml, och ange avsedd fil uttryckligen.

En branch preview är en isolerad deployment, medan produktionskonfigurationen förblir ett separat granskningsmål. I projekt med private networking kan previews ansluta till projektnätverket och få skrivskyddad databasåtkomst utan att produktionsmanifestet ändras.

Använd guiden för environment-variabler och secrets för credential-hantering och zero-downtime deployments för readiness-gaten.

Playbook för att hantera drift

När dockup plan rapporterar oväntade ändringar i det aktiva tillståndet ska du inte automatiskt skriva över dem. Ta reda på om ändringen i dashboarden var en akut korrigering, en obehörig ändring eller en avsiktlig inställning som aldrig checkades in.

Välj sedan en källa som gäller:

• Uppdatera manifestet för att bevara det avsedda aktiva värdet.
• Tillämpa manifestet för att återställa det granskade värdet.
• Dokumentera ett tillfälligt undantag med ansvarig person och slutdatum.
• Undersök audit-loggen när ursprunget är okänt.

dockup audit --writes --json

På så sätt förblir dockup.yaml auktoritativt utan att incidentens sammanhang raderas.

Dockup CLI-referensen är källan för aktuella manifestfält och alternativen för plan/up.

Utforma manifeständringar som är lätta att granska

Håll varje ändring tillräckligt liten för att planen ska ha ett tydligt syfte. Om en branchändring, en resursökning, en ny domän, en omskrivning av health check och en rensning av environment kombineras i samma pull request blir både granskning och rollback svårare.

Använd kommentarer för att förklara ovanliga värden, men duplicera inte operativ dokumentation i filen. Länka repots runbook till servicemålet, health-semantiken och godkännandepolicyn. Manifestet ska förbli giltig YAML som kan parsas utan en anpassad preprocessor.

En användbar mall för pull requests efterfrågar resultatet från dockup plan --json, den förväntade deployment-effekten, om --prune begärs och föregående deployment-ID. Då får en AI-agent eller mänsklig granskare samma underlag.

Introducera manifestet utan att störa det aktiva tillståndet

Börja med de fält som du kan verifiera för en befintlig service. Kör dockup info production/api --json, skriv ett minimalt dockup.yaml och jämför det med dockup plan. Lägg till inställningar stegvis i stället för att försöka återskapa alla historiska val i dashboarden på en gång.

Eftersom tillämpningen är additiv finns ohanterade vanliga värden och domäner kvar under införandet. När manifestet korrekt beskriver den avsedda konfigurationen som inte består av secrets kan teamet besluta om pruning någonsin ska användas. Vissa team hanterar rensning manuellt, medan andra bara tillåter --prune i en skyddad pipeline efter godkännande av planen.

Målet med config as code är inte att maximera antalet rader i Git. Målet är att göra produktionsavsikten begriplig, granskningsbar och möjlig att återställa.

Håll planerna fria från secrets

En plan ska vara säker att bifoga till en pull request eller incidentpost. Eftersom dockup.yaml bara innehåller vanliga värden och befintliga secret-värden förblir skyddade kan granskare inspektera den avsedda konfigurationen utan att få tillgång till produktionscredentials. Granska ändå vanliga värden efter interna hostnames, kundidentifierare eller andra uppgifter som inte bör vara offentliga.

Håll källa och mål tillsammans

Ange avsett project/service i pull requesten och deployment-jobbet. Ett giltigt dockup.yaml som tillämpas på fel mål är fortfarande ett operativt fel. Målidentifiering och manifestgranskning är två separata kontroller som båda krävs.

Validera YAML före plan

Parsa manifestet i CI innan du anropar Dockup, så att indenterings- eller typfel upptäcks nära källändringen. Syntaxvalidering ersätter inte dockup plan; den förhindrar onödiga requests med en oläsbar fil.

Föredra en enda källa

Ett granskat dockup.yaml bör förklara produktionsavsikten.

Börja med en verifierbar deployment

Lägg till ett minimalt manifest för en service, kör en skrivskyddad plan och granska varje rapporterat fält före den första tillämpningen.

Kom igång gratis på app.dockup.ai. Free-planen kostar 0 USD per månad, inkluderar 10 USD i startkredit och stöder en workspace, tre databaser och tre deployments.

Vanliga frågor

Vad är dockup.yaml?

Det är Dockups manifest för config as code, där du deklarerar servicens branch, port, build- och startinställningar, health checks, vanliga environment-värden och domäner.

Ändrar dockup plan produktionen?

Nej. dockup plan är skrivskyddat och visar skillnaden mellan manifestet och den aktiva servicen.

Tar dockup up bort konfiguration som inte finns i filen?

Inte som standard. Tillämpningen är additiv. Vanliga environment-värden och domäner som stöds tas bara bort när --prune används uttryckligen.

Kan secrets lagras i dockup.yaml?

Det bör de inte. Checka bara in vanliga värden; ange secrets via kommandot för secret environment eller runtime secret injection. Befintliga secrets skyddas från pruning.

Kan dockup up deploya efter att konfigurationen har tillämpats?

Ja. Det dokumenterade alternativet --deploy tillämpar manifestet och startar en deployment, vars slutgiltiga resultat sedan bör verifieras.