Konfiguracija kao kod uz dockup.yaml: siguran plan i primjena

dockup.yaml pretvara konfiguraciju servisa u artefakt repozitorija koji je moguće pregledati. Umjesto oslanjanja na zapamćeno stanje dashboarda, tim u jednoj datoteci može deklarirati branch, port, naredbe za build i pokretanje, health checkove, uobičajene vrijednosti okruženja i domene.

Dockup razdvaja pregled od izmjena. dockup plan prikazuje razliku između manifesta i aktivnog servisa bez ikakvih promjena. dockup up primjenjuje deklarirane promjene. Brisanje je i dalje moguće samo uz eksplicitnu opciju --prune.

Što se može deklarirati u dockup.yaml?

Manifest servisa može sadržavati produkcijske postavke koje imaju koristi od code reviewa:

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 }

Datoteka se prema zadanim postavkama nalazi u korijenu repozitorija. Drugi put može se odabrati opcijom --file.

Ne stavljajte tajne u mapiranje env. Manifest se commit-a, pregledava, sprema u cache i kopira kao i ostale izvorne datoteke. Za credentials koristite dockup env set --secret ili odobreni postupak za ubacivanje tajni.

Potrošnja CPU-a, RAM-a i diska i dalje se obračunava prema korištenju i mjeri po minuti u odnosu na stanje plana; manifest treba opisivati konfiguraciju servisa, a ne pretpostavke o naplati.

Kako dockup plan prikazuje drift konfiguracije?

Prije svake primjene pokrenite usporedbu koja ne mijenja stanje:

dockup plan production/api --json

Rezultat sadrži promjene s aspektima, poljima, starim i novim vrijednostima te radnjama. Plan može pokazati da se branch promijenio, da se path health checka razlikuje, da će se dodati domena ili da je obična vrijednost okruženja promijenjena.

Plan je vrijedan u pet situacija:

Situacija	Što plan otkriva
Pull request mijenja manifest	Predviđeni učinak na produkciju prije mergea
Dashboard je ručno uređen	Drift u odnosu na izvor u repozitoriju
Agent predlaže ažuriranje	Točna polja koja agent namjerava izmijeniti
Oporavak od incidenta	Razlikuje li se aktivno stanje od poznate konfiguracije
Postavka s više okruženja	Razlike između produkcijskog i staging manifesta

Planiranje ne zaključava servis. Aktivno se stanje može promijeniti između plana i primjene, zato rizični workflowi trebaju pregled i up držati vremenski blizu te provjeriti rezultat primjene.

Coding agent treba vratiti JSON plana ili sažetak po pojedinačnim poljima. „Konfiguracija izgleda dobro” nije dovoljan artefakt za pregled.

Kako dockup up primjenjuje konfiguraciju kao kod?

Primijenite zadani manifest:

dockup up production/api --json

Primijenite promjene i zatim pokrenite deployment:

dockup up production/api --deploy --json

Za staging upotrijebite drugu datoteku:

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

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

Rezultat primjene navodi koje su promjene primijenjene ili preskočene, a može sadržavati i ID deploymenta kada se koristi --deploy. Povezani deployment i dalje treba, gdje je to primjereno, provjeriti do završnog stanja; izmjena konfiguracije i zdravi produkcijski release zasebni su ishodi.

Vrijednosti tajni ostaju izvan manifesta. Postavite ih putem workflowa za tajne varijable okruženja prije primjene konfiguracije, zatim izvršite deployment i provjerite rezultirajući container bez ispisivanja spremljene vrijednosti.

Zašto je konfiguracija kao kod prema zadanim postavkama aditivna?

Najsigurnije je nepotpun manifest tumačiti kao „upravljaj ovim deklariranim vrijednostima”, a ne kao „izbriši sve ostalo”. Zato Dockup ostavlja nepromijenjenima environment varijable i domene koje nisu navedene u datoteci.

To je važno tijekom postupnog uvođenja. Servis možda već ima tajne varijable, operativne domene ili privremenu konfiguraciju koja još nije modelirana. Prvi up ne bi ih trebao izbrisati.

Sigurnosna jamstva su konkretna:

• dockup up ne briše servise, baze podataka ni volumene.
• Postojeće tajne varijable ne prepisuju se običnim vrijednostima iz manifesta.
• Tajne varijable ne uklanjaju se postupkom prune.
• Automatska primjena manifesta tijekom deploymenta je aditivna.
• Neispravan manifest ne pretvara se neprimjetno u destruktivno čišćenje.

Aditivno ponašanje čini dockup.yaml prikladnim za inkrementalni GitOps workflow. To također znači da manifest nije automatski potpun inventar, osim ako tim namjerno ne uvede prune za podržana polja.

Kako treba pregledati opciju --prune?

--prune uklanja podržane obične vrijednosti okruženja i domene koje nisu navedene u manifestu:

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

Tu opciju tretirajte kao destruktivan zahtjev. Pregledajte plan, navedite točan cilj i pribavite ljudsko odobrenje kada agent radi u produkciji.

Operacija ne obuhvaća tajne, servise, baze podataka ni volumene. Ti resursi imaju vlastiti lifecycle i postupke potvrde. To razdvajanje sprječava da se mala izmjena manifesta pretvori u široko brisanje infrastrukture.

Korisna evidencija odobrenja glasi: „Primijeni dockup.yaml na production/api i ukloni dvije obične varijable i jednu domenu prikazane u planu X.” Ne bi trebala biti opća dozvola koja se može ponovno koristiti za buduće planove.

Širi model potvrde objašnjen je u članku zaštitne mjere za AI agente u produkciji.

Kako timovi koriste GitOps workflow uz dockup.yaml?

Neka workflow bude jednostavan:

1. Developer ili agent uređuje dockup.yaml.
2. CI provjerava YAML sintaksu i testove aplikacije.
3. Read-only dockup plan pokreće se nad predviđenim ciljem.
4. Pull request prikazuje i source diff i plan aktivnog stanja.
5. Reviewer odobrava promjenu.
6. dockup up --deploy primjenjuje je.
7. Deployment čeka završni uspjeh.
8. Status, logovi i revizijski dokazi se čuvaju.

Manifest ne bi trebao postati odlagalište svega. Poslovnu konfiguraciju aplikacije držite u aplikaciji kada je to primjereno. dockup.yaml koristite za deployment i runtime postavke za koje je odgovorna granica servisa.

Datoteke specifične za pojedina okruženja mogu biti jasnije od jedne datoteke s nedokumentiranim templating slojem. Na primjer, koristite dockup.staging.yaml i dockup.production.yaml te eksplicitno proslijedite željenu datoteku.

Preview za branch izolirani je deployment, dok produkcijska konfiguracija ostaje zaseban cilj pregleda. U projektima s privatnim networkingom previewi se mogu priključiti na projektnu mrežu i dobiti read-only pristup bazi podataka bez promjene produkcijskog manifesta.

Za rukovanje credentialima pogledajte vodič za environment varijable i tajne, a za gate spremnosti deployment bez downtimea.

Playbook za odgovor na drift

Kada dockup plan prijavi neočekivane promjene aktivnog stanja, nemojte ih automatski prepisati. Utvrdite je li izmjena na dashboardu bila hitni popravak, neovlaštena promjena ili namjerna postavka koja nikada nije commit-ana.

Zatim odaberite jedan izvor istine:

• Ažurirajte manifest kako biste sačuvali željenu aktivnu vrijednost.
• Primijenite manifest kako biste vratili pregledanu vrijednost.
• Dokumentirajte privremenu iznimku s vlasnikom i rokom isteka.
• Istražite audit log kada je izvor nepoznat.

dockup audit --writes --json

Taj postupak održava dockup.yaml autoritativnim bez brisanja konteksta incidenta.

Referenca za Dockup CLI izvor je aktualnih polja manifesta te opcija plan/up.

Dizajnirajte promjene manifesta koje je lako pregledati

Svaku promjenu zadržite dovoljno malom da plan ima jednu jasnu svrhu. Kombiniranje promjene brancha, povećanja resursa, nove domene, izmjene health checka i čišćenja okruženja u jednom pull requestu otežava i pregled i rollback.

Komentarima objasnite neuobičajene vrijednosti, ali nemojte u datoteci duplicirati operativnu dokumentaciju. U runbooku repozitorija povežite ciljni servis, semantiku health checka i pravila odobravanja. Manifest treba ostati valjan YAML koji je moguće parsirati bez prilagođenog preprocesora.

Korisni predložak pull requesta traži izlaz naredbe dockup plan --json, očekivani učinak deploymenta, informaciju traži li se --prune i ID prethodnog deploymenta. Tako AI agent ili ljudski reviewer dobivaju iste dokaze.

Uvedite manifest bez narušavanja aktivnog stanja

Za postojeći servis počnite s poljima koja možete provjeriti. Pokrenite dockup info production/api --json, napišite minimalni dockup.yaml i usporedite ga s naredbom dockup plan. Dodajte postavke u fazama umjesto da pokušate odjednom rekonstruirati svaku povijesnu postavku dashboarda.

Budući da je primjena aditivna, neupravljane obične vrijednosti i domene ostaju tijekom uvođenja. Kada manifest točno predstavlja željenu konfiguraciju koja nije tajna, odlučite hoće li tim ikada koristiti prune. Neki timovi čišćenje uvijek rade ručno; drugi dopuštaju --prune samo u zaštićenom pipelineu nakon odobrenja plana.

Cilj konfiguracije kao koda nije maksimalan broj redaka u Gitu. Cilj je učiniti produkcijsku namjeru razumljivom, preglednom i obnovljivom.

Planove držite bez materijala koji sadrži tajne

Plan treba biti siguran za dodavanje u pull request ili zapis incidenta. Budući da dockup.yaml sadrži samo obične vrijednosti, a postojeće tajne ostaju zaštićene, revieweri mogu pregledati željenu konfiguraciju bez dobivanja produkcijskih credentiala. Ipak, obične vrijednosti treba provjeriti zbog internih hostnameova, identifikatora korisnika ili drugih podataka koji ne bi trebali biti javni.

Izvor i cilj držite zajedno

U pull requestu i deployment jobu navedite željeni project/service. Valjan dockup.yaml primijenjen na pogrešan cilj i dalje je operativni kvar. Otkrivanje cilja i pregled manifesta dva su zasebna obavezna koraka provjere.

Provjerite YAML prije plana

Parsajte manifest u CI-ju prije pozivanja Dockupa kako bi pogreške u uvlačenju ili tipovima pale odmah uz izvornu promjenu. Provjera sintakse ne zamjenjuje dockup plan; ona sprječava nepotrebne zahtjeve s datotekom koju nije moguće učitati.

Preferirajte jedan izvor

Pregledani dockup.yaml treba objašnjavati produkcijsku namjeru.

Započnite deploymentom koji je moguće provjeriti

Dodajte minimalni manifest jednom servisu, pokrenite read-only plan i pregledajte svako prijavljeno polje prije prve primjene.

Započnite besplatno na app.dockup.ai. Plan Free iznosi 0 USD mjesečno, uključuje početni kredit od 10 USD te podržava jedan workspace, tri baze podataka i tri deploymenta.

Česta pitanja

Što je dockup.yaml?

To je Dockupov manifest za konfiguraciju kao kod kojim se deklariraju branch servisa, port, postavke builda i pokretanja, health checkovi, obične vrijednosti okruženja i domene.

Mijenja li dockup plan produkciju?

Ne. dockup plan je read-only i prikazuje razliku između manifesta i aktivnog servisa.

Briše li dockup up konfiguraciju koja nije u datoteci?

Ne prema zadanim postavkama. Primjena je aditivna. Podržane obične vrijednosti okruženja i domene uklanjaju se samo kada se eksplicitno upotrijebi --prune.

Mogu li se tajne pohraniti u dockup.yaml?

Ne bi trebale. Commit-ajte samo obične vrijednosti, a tajne postavite putem naredbe za tajne environment varijable ili runtime ubacivanja tajni. Postojeće tajne zaštićene su od prunea.

Može li dockup up pokrenuti deployment nakon primjene konfiguracije?

Da. Dokumentirana opcija --deploy primjenjuje manifest i pokreće deployment, čiji završni rezultat potom treba provjeriti.