Administrér servicekonfiguration med dockup.yaml

dockup.yaml gør servicekonfiguration til et repository-artefakt, der kan gennemgås. I stedet for at være afhængig af en dashboard-tilstand, som nogen skal kunne huske, kan et team deklarere branch, port, build- og startkommandoer, health checks, almindelige environment-værdier og domæner i én fil.

Dockup adskiller inspektion fra ændringer. dockup plan viser forskellen mellem manifestet og den aktive service uden at ændre noget. dockup up anvender de deklarerede ændringer. Sletning kræver fortsat et eksplicit tilvalg med --prune.

Hvad kan dockup.yaml deklarere?

Et servicemanifest kan indeholde de produktionsindstillinger, der har gavn af 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 placeres som standard i repositoryets rodmappe. En anden sti kan vælges med --file.

Placér ikke secrets i env-mappingen. Manifestet commit’es, gennemgås, caches og kopieres ligesom andre source-filer. Brug dockup env set --secret eller en godkendt proces til injection af secrets til credentials.

CPU-, RAM- og diskforbrug er fortsat brugsbaseret og måles pr. minut i forhold til planens saldo; manifestet bør beskrive servicekonfiguration frem for antagelser om billing.

Hvordan viser dockup plan configuration drift?

Kør en skrivebeskyttet sammenligning før hver anvendelse:

dockup plan production/api --json

Resultatet indeholder ændringer med aspekter, felter, gamle værdier, nye værdier og handlinger. En plan kan vise, at branchen er ændret, at en health path er anderledes, at et domæne bliver tilføjet, eller at en almindelig environment-værdi er afveget.

En plan er værdifuld i fem situationer:

Situation	Det viser planen
En pull request ændrer manifestet	Den tilsigtede effekt i produktion før merge
Dashboardet er blevet redigeret manuelt	Afvigelser fra repositoryets source of truth
En agent foreslår en opdatering	De præcise felter, som agenten vil ændre
Gendannelse efter en incident	Om den aktive tilstand allerede afviger fra den kendte konfiguration
Opsætning med flere miljøer	Forskellene mellem production- og staging-manifester

Planning låser ikke servicen. Den aktive tilstand kan ændre sig mellem plan og apply, så workflows med høj risiko bør holde review og up tæt på hinanden og kontrollere resultatet af apply.

En coding agent bør returnere planens JSON eller en kort opsummering felt for felt. “Konfigurationen ser fin ud” er ikke et tilstrækkeligt review-artefakt.

Hvordan anvender dockup up config as code?

Anvend standardmanifestet:

dockup up production/api --json

Anvend manifestet, og start derefter en deployment:

dockup up production/api --deploy --json

Brug en anden fil til staging:

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

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

Resultatet af apply viser, hvilke ændringer der blev anvendt eller sprunget over, og kan indeholde deployment-ID’et, når --deploy bruges. Den efterfølgende deployment bør stadig verificeres ved at kontrollere terminal state, hvor det er relevant; en konfigurationsændring og en sund production release er to separate resultater.

Secret-værdier holdes uden for manifestet. Angiv dem via workflowet til secret environment, før konfigurationen anvendes, og deploy derefter og verificér den resulterende container uden at udskrive den gemte værdi.

Hvorfor er config as code additiv som standard?

Den sikreste fortolkning af et ufuldstændigt manifest er “administrér disse deklarerede værdier” og ikke “slet alt andet”. Dockup lader derfor environment variables og domæner, som ikke findes i filen, være uændrede.

Det er vigtigt ved gradvis adoption. En service kan allerede have secret variables, operationelle domæner eller midlertidig konfiguration, som endnu ikke er modelleret. Den første up bør ikke slette dem.

Sikkerhedsgarantierne er konkrete:

• dockup up sletter ikke services, databaser eller volumes.
• Eksisterende secret variables overskrives ikke af almindelige manifestværdier.
• Secret variables fjernes ikke ved pruning.
• Automatisk anvendelse af manifestet under deployment er additiv.
• Et ugyldigt manifest bliver ikke uden videre til en destruktiv oprydning.

Additiv adfærd gør dockup.yaml egnet til et gradvist GitOps-workflow. Det betyder også, at manifestet ikke automatisk er en komplet inventory, medmindre teamet bevidst tager pruning i brug for de understøttede felter.

Hvordan bør --prune gennemgås?

--prune fjerner understøttede almindelige environment-værdier og domæner, der ikke findes i manifestet:

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

Betragt flaget som en destruktiv anmodning. Gennemgå planen, angiv det præcise mål, og indhent menneskelig godkendelse, når en agent arbejder i production.

Handlingen omfatter ikke secrets, services, databaser eller volumes. Disse ressourcer har deres egen lifecycle og egne bekræftelsesflows. Denne adskillelse forhindrer, at en lille manifestændring udvikler sig til en bred sletning af infrastruktur.

En nyttig godkendelsesregistrering siger: “Anvend dockup.yaml på production/api, og fjern de to almindelige variables og ét domæne, der vises i plan X.” Den bør ikke være en genanvendelig blanketgodkendelse til fremtidige planer.

Den overordnede model for bekræftelser gennemgås i guardrails til AI-agenter i production.

Hvordan driver teams et GitOps-workflow med dockup.yaml?

Hold workflowet enkelt:

1. En udvikler eller agent redigerer dockup.yaml.
2. CI validerer YAML-syntaks og application tests.
3. En skrivebeskyttet dockup plan køres mod det tilsigtede mål.
4. Pull request’en viser både source-diff og en plan for den aktive tilstand.
5. En reviewer godkender ændringen.
6. dockup up --deploy anvender den.
7. Deploymenten venter på terminal success.
8. Status, logs og audit-dokumentation gemmes.

Manifestet bør ikke blive en losseplads. Behold application business configuration i applikationen, når det er relevant. Brug dockup.yaml til deployment- og runtime-indstillinger, som ejes af servicens boundary.

Filer, der er specifikke for hvert miljø, kan være tydeligere end én fil med et udokumenteret templating-lag. Brug for eksempel dockup.staging.yaml og dockup.production.yaml, og angiv den tilsigtede fil eksplicit.

En branch preview er en isoleret deployment, mens production-konfigurationen fortsat er et separat review-mål. I projekter med private networking kan previews tilsluttes project network og få read-only databaseadgang uden at ændre production-manifestet.

Brug guiden til environment variables og secrets til håndtering af credentials og zero-downtime deployments til readiness-gaten.

Playbook til håndtering af drift

Når dockup plan rapporterer uventede ændringer i den aktive tilstand, skal du ikke automatisk overskrive dem. Find ud af, om dashboardændringen var en akut rettelse, en uautoriseret ændring eller en tilsigtet indstilling, som aldrig blev commit’et.

Vælg derefter én source of truth:

• Opdatér manifestet for at bevare den tilsigtede aktive værdi.
• Anvend manifestet for at gendanne den gennemgåede værdi.
• Dokumentér en midlertidig undtagelse med en ejer og en udløbsdato.
• Undersøg audit-loggen, når oprindelsen er ukendt.

dockup audit --writes --json

Denne proces holder dockup.yaml autoritativ uden at slette konteksten fra en incident.

Dockup CLI reference er kilden til aktuelle manifestfelter og indstillingerne til plan/up.

Design manifestændringer, der er nemme at gennemgå

Hold hver ændring så lille, at planen har ét tydeligt formål. Hvis en ændring af branch, en ressourceforøgelse, et nyt domæne, en omskrivning af en health check og oprydning i environment samles i én pull request, bliver både review og rollback sværere.

Brug kommentarer til at forklare usædvanlige værdier, men kopiér ikke den operationelle dokumentation ind i filen. Link repositoryets runbook til servicens target, health-semantik og godkendelsespolitik. Manifestet bør fortsat være gyldig YAML, som kan parses uden en custom preprocessor.

En nyttig pull-request-skabelon beder om outputtet fra dockup plan --json, den forventede deployment-effekt, om --prune ønskes, og ID’et på den forrige deployment. Det giver en AI-agent eller menneskelig reviewer det samme grundlag.

Introducér manifestet uden at forstyrre den aktive tilstand

Begynd med de felter, du kan verificere, for en eksisterende service. Kør dockup info production/api --json, skriv et minimalt dockup.yaml, og sammenlign det med dockup plan. Tilføj indstillinger trinvis i stedet for at forsøge at genskabe alle historiske dashboardvalg på én gang.

Fordi apply er additiv, bevares ikke-administrerede almindelige værdier og domæner, mens adoptionen fortsætter. Når manifestet præcist repræsenterer den tilsigtede konfiguration, der ikke indeholder secrets, skal du beslutte, om teamet nogensinde vil bruge pruning. Nogle teams holder oprydning manuel; andre tillader kun --prune i en beskyttet pipeline efter godkendelse af planen.

Målet med config as code er ikke at maksimere antallet af linjer i Git. Målet er at gøre intentionen for production forståelig, nem at gennemgå og mulig at gendanne.

Hold planer fri for secret-materiale

En plan bør være sikker at vedhæfte til en pull request eller en incident-registrering. Da dockup.yaml kun indeholder almindelige værdier, og eksisterende secret-værdier fortsat er beskyttede, kan reviewers inspicere den tilsigtede konfiguration uden at få adgang til production-credentials. Gennemgå dog almindelige værdier for interne hostnames, kundeidentifikatorer eller andre data, der ikke bør være offentlige.

Hold source og target samlet

Angiv det tilsigtede project/service i pull request’en og deployment-jobbet. Et gyldigt dockup.yaml, der anvendes på det forkerte target, er stadig en operationel fejl. Target discovery og manifest-review er to separate, nødvendige checks.

Validér YAML før plan

Pars manifestet i CI, før du kalder Dockup, så fejl i indrykning eller typer fejler tæt på source-ændringen. Syntaksvalidering erstatter ikke dockup plan; den forhindrer unødvendige requests med en fil, der ikke kan læses.

Foretræk én source

Et gennemgået dockup.yaml bør forklare intentionen for production.

Begynd med en deployment, der kan verificeres

Tilføj et minimalt manifest til én service, kør en skrivebeskyttet plan, og gennemgå hvert rapporteret felt før den første apply.

Kom gratis i gang på app.dockup.ai. Free-planen koster $0 pr. måned, inkluderer $10 i startkredit og understøtter ét workspace, tre databaser og tre deployments.

FAQ

Hvad er dockup.yaml?

Det er Dockups config-as-code-manifest til deklaration af service-branch, port, build- og startindstillinger, health checks, almindelige environment-værdier og domæner.

Ændrer dockup plan production?

Nej. dockup plan er skrivebeskyttet og viser forskellen mellem manifestet og den aktive service.

Sletter dockup up konfiguration, der ikke findes i filen?

Ikke som standard. Apply er additiv. Understøttede almindelige environment-værdier og domæner fjernes kun, når --prune bruges eksplicit.

Kan secrets gemmes i dockup.yaml?

Det bør de ikke. Commit kun almindelige værdier; angiv secrets via kommandoen til secret environment eller runtime secret injection. Eksisterende secrets er beskyttet mod pruning.

Kan dockup up deploye efter anvendelse af konfigurationen?

Ja. Den dokumenterede --deploy-indstilling anvender manifestet og starter en deployment, hvis terminalresultat derefter bør verificeres.