dockup.yaml Config as Code: Planlegg og bruk trygt

dockup.yaml gjør tjenestekonfigurasjon til et repository-artefakt som kan gjennomgås. I stedet for å være avhengig av husket tilstand i dashboardet kan et team deklarere branch, port, build- og start-kommandoer, helsesjekker, vanlige environment-verdier og domener i én fil.

Dockup skiller inspeksjon fra endringer. dockup plan viser forskjellen mellom manifestet og den aktive tjenesten uten å endre noe. dockup up tar i bruk de deklarerte endringene. Sletting er fortsatt et eksplisitt valg gjennom --prune.

Hva kan dockup.yaml deklarere?

Et tjenestemanifest kan inneholde produksjonsinnstillingene som har nytte av 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 }

Filen plasseres som standard i roten av repositoryet. En annen sti kan velges med --file.

Ikke legg secrets i env-mappingen. Manifestet committes, gjennomgås, caches og kopieres på samme måte som andre kildefiler. Bruk dockup env set --secret eller en godkjent prosess for secret injection for credentials.

CPU-, RAM- og diskforbruk er fortsatt bruksbasert og måles per minutt opp mot saldoen i planen; manifestet bør beskrive tjenestekonfigurasjon, ikke antakelser om fakturering.

Hvordan viser dockup plan configuration drift?

Kjør en skrivebeskyttet sammenligning før hver apply:

dockup plan production/api --json

Resultatet inneholder endringer med aspekter, felter, gamle verdier, nye verdier og handlinger. En plan kan vise at branchen er endret, at en health path er annerledes, at et domene vil bli lagt til, eller at en vanlig environment-verdi har fått drift.

En plan er nyttig i fem situasjoner:

Situasjon	Det planen avdekker
En pull request endrer manifestet	Forventet effekt i produksjon før merge
Dashboardet er endret manuelt	Drift fra kilden i repositoryet
En agent foreslår en oppdatering	De nøyaktige feltene agenten vil endre
Gjenoppretting etter en hendelse	Om aktiv tilstand allerede avviker fra kjent konfigurasjon
Oppsett med flere miljøer	Forskjeller mellom production- og staging-manifester

Planning låser ikke tjenesten. Aktiv tilstand kan endres mellom plan og apply, så arbeidsflyter med høy risiko bør holde gjennomgangen og up tett sammen og kontrollere resultatet fra apply.

En coding agent bør returnere planens JSON eller en kort oppsummering felt for felt. «Konfigurasjonen ser bra ut» er ikke et tilstrekkelig review-artefakt.

Hvordan bruker dockup up config as code?

Bruk standardmanifestet:

dockup up production/api --json

Bruk manifestet og start deretter en deployment:

dockup up production/api --deploy --json

Bruk en annen fil for staging:

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

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

Resultatet fra apply viser hvilke endringer som ble tatt i bruk eller hoppet over, og kan inkludere deployment-ID-en når --deploy brukes. Den påfølgende deploymenten bør fortsatt verifiseres ved å kontrollere terminaltilstanden der det er relevant; en konfigurasjonsendring og en frisk release i produksjon er to separate resultater.

Secret-verdier holdes utenfor manifestet. Angi dem gjennom arbeidsflyten for secret environment før du tar i bruk konfigurasjonen, og deploy og verifiser deretter den resulterende containeren uten å skrive ut den lagrede verdien.

Hvorfor er config as code additiv som standard?

Den tryggeste tolkningen av et ufullstendig manifest er «administrer disse deklarerte verdiene», ikke «slett alt annet». Dockup lar derfor environment-variabler og domener som mangler i filen, være uendret.

Dette er viktig ved gradvis innføring. En tjeneste kan allerede ha secret-variabler, operative domener eller midlertidig konfigurasjon som ennå ikke er modellert. Den første up bør ikke slette dem.

Sikkerhetsgarantiene er konkrete:

• dockup up sletter ikke tjenester, databaser eller volumes.
• Eksisterende secret-variabler overskrives ikke av vanlige manifestverdier.
• Secret-variabler blir ikke prunet.
• Automatisk bruk av manifestet under deploy er additiv.
• Et ugyldig manifest blir ikke stille omgjort til en destruktiv opprydding.

Additiv oppførsel gjør dockup.yaml egnet for en inkrementell GitOps-workflow. Det betyr også at manifestet ikke automatisk er en komplett oversikt, med mindre teamet bevisst tar i bruk pruning for feltene som støttes.

Hvordan bør --prune gjennomgås?

--prune fjerner støttede vanlige environment-verdier og domener som mangler i manifestet:

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

Behandle flagget som en destruktiv forespørsel. Gå gjennom planen, oppgi det nøyaktige målet, og innhent menneskelig godkjenning når en agent opererer i produksjon.

Operasjonen omfatter ikke secrets, tjenester, databaser eller volumes. Disse ressursene har egne livssykluser og bekreftelsesprosesser. Dette skillet hindrer at en liten manifestendring fører til omfattende sletting av infrastruktur.

En nyttig godkjenningslogg sier: «Bruk dockup.yaml på production/api og prune de to vanlige variablene og ett domene som vises i plan X.» Den bør ikke være en generell tillatelse som kan gjenbrukes for fremtidige planer.

Den overordnede modellen for bekreftelser er beskrevet i produksjonsrekkverk for AI-agenter.

Hvordan bruker team en GitOps-workflow med dockup.yaml?

Hold workflowen enkel:

1. En utvikler eller agent redigerer dockup.yaml.
2. CI validerer YAML-syntaks og applikasjonstester.
3. En skrivebeskyttet dockup plan kjøres mot det tiltenkte målet.
4. Pull request-en viser både kildekodeendringen og planen for aktiv tilstand.
5. En reviewer godkjenner endringen.
6. dockup up --deploy tar den i bruk.
7. Deploy venter på et endelig vellykket resultat.
8. Status, logger og revisjonsspor beholdes.

Manifestet bør ikke bli en oppsamlingsplass. Behold applikasjonens forretningskonfigurasjon i applikasjonen når det er riktig. Bruk dockup.yaml for deployment- og runtime-innstillinger som eies av tjenestegrensen.

Miljøspesifikke filer kan være tydeligere enn én fil med et udokumentert templating-lag. Bruk for eksempel dockup.staging.yaml og dockup.production.yaml, og oppgi den tiltenkte filen eksplisitt.

En branch preview er en isolert deployment, mens produksjonskonfigurasjonen fortsatt er et separat review-mål. I prosjekter med private nettverk kan previews kobles til prosjektnettverket og få skrivebeskyttet databasetilgang uten å endre produksjonsmanifestet.

Bruk veiledningen for environment-variabler og secrets for håndtering av credentials og deployments uten nedetid for readiness-gaten.

Spillbok for håndtering av drift

Når dockup plan rapporterer uventede endringer i aktiv tilstand, må du ikke automatisk overskrive dem. Finn ut om endringen i dashboardet var en nødretting, en uautorisert endring eller en ønsket innstilling som aldri ble committet.

Velg deretter én kilde til sannhet:

• Oppdater manifestet for å beholde den ønskede aktive verdien.
• Bruk manifestet for å gjenopprette den gjennomgåtte verdien.
• Dokumenter et midlertidig unntak med en eier og en utløpsdato.
• Undersøk audit-loggen når opphavet er ukjent.

dockup audit --writes --json

Denne prosessen holder dockup.yaml autoritativ uten å slette konteksten rundt hendelsen.

Dockup CLI-referansen er kilden til gjeldende manifestfelter og plan-/up-alternativer.

Utform manifestendringer som er enkle å gjennomgå

Hold hver endring liten nok til at planen har ett tydelig formål. Hvis du kombinerer en branch-endring, økte ressurser, et nytt domene, en omskriving av health check og opprydding i environment i én pull request, blir både gjennomgang og rollback vanskeligere.

Bruk kommentarer til å forklare uvanlige verdier, men ikke dupliser operativ dokumentasjon i filen. Koble repositoryets runbook til tjenestemålet, health-semantikken og godkjenningspolicyen. Manifestet bør fortsatt være gyldig YAML som kan parses uten en egendefinert preprocessor.

En nyttig mal for pull requests ber om resultatet fra dockup plan --json, forventet effekt på deploymenten, om --prune er forespurt, og ID-en til forrige deployment. Dette gir en AI-agent eller menneskelig reviewer det samme grunnlaget.

Innfør manifestet uten å forstyrre aktiv tilstand

For en eksisterende tjeneste bør du begynne med feltene du kan verifisere. Kjør dockup info production/api --json, skriv et minimalt dockup.yaml, og sammenlign det med dockup plan. Legg til innstillinger trinnvis i stedet for å forsøke å gjenskape alle historiske valg i dashboardet på én gang.

Siden apply er additiv, blir uadministrerte vanlige verdier og domener værende mens innføringen pågår. Når manifestet representerer den ønskede ikke-hemmelige konfigurasjonen nøyaktig, må du avgjøre om teamet noen gang skal bruke pruning. Noen team holder oppryddingen manuell; andre tillater --prune bare i en beskyttet pipeline etter godkjenning av planen.

Målet med config as code er ikke å maksimere antall linjer i Git. Målet er å gjøre hensikten med produksjonen forståelig, gjennomgåbar og mulig å gjenopprette.

Hold planene frie for secret-materiale

En plan bør være trygg å legge ved en pull request eller en hendelseslogg. Siden dockup.yaml bare inneholder vanlige verdier, og eksisterende secret-verdier fortsatt er beskyttet, kan reviewere kontrollere den ønskede konfigurasjonen uten å få produksjonscredentials. Gå likevel gjennom vanlige verdier for interne hostnames, kundeidentifikatorer eller andre data som ikke bør være offentlige.

Hold kilde og mål samlet

Oppgi det tiltenkte project/service-målet i pull request-en og deployment-jobben. Et gyldig dockup.yaml som brukes på feil mål, er fortsatt en operativ feil. Målgjenfinning og gjennomgang av manifestet er to separate kontroller som begge kreves.

Valider YAML før plan

Parse manifestet i CI før du kaller Dockup, slik at feil i innrykk eller typer stopper prosessen nær kildeendringen. Syntaksvalidering erstatter ikke dockup plan; den forhindrer unødvendige requests med en fil som ikke kan leses.

Foretrekk én kilde

Et gjennomgått dockup.yaml bør forklare hensikten med produksjonen.

Start med en deployment som kan verifiseres

Legg et minimalt manifest til én tjeneste, kjør en skrivebeskyttet plan, og gå gjennom hvert rapporterte felt før den første apply.

Start gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett workspace, tre databaser og tre deployments.

Vanlige spørsmål

Hva er dockup.yaml?

Det er Dockups manifest for config as code, som deklarerer tjenestens branch-, port-, build- og start-innstillinger, helsesjekker, vanlige environment-verdier og domener.

Endrer dockup plan produksjonen?

Nei. dockup plan er skrivebeskyttet og viser forskjellen mellom manifestet og den aktive tjenesten.

Sletter dockup up konfigurasjon som ikke finnes i filen?

Ikke som standard. Apply er additiv. Støttede vanlige environment-verdier og domener fjernes bare når --prune brukes eksplisitt.

Kan secrets lagres i dockup.yaml?

Det bør de ikke. Commit bare vanlige verdier; angi secrets gjennom kommandoen for secret environment eller runtime secret injection. Eksisterende secrets er beskyttet mot pruning.

Kan dockup up deploye etter at konfigurasjonen er tatt i bruk?

Ja. Det dokumenterte --deploy-alternativet tar i bruk manifestet og starter en deployment. Det endelige resultatet bør deretter verifiseres.