Z Git repozitára do produkcie: Sprievodca nasadením v Dockup

Presun Git repozitára do produkcie si vyžaduje viac než pripojenie remote repozitára a stlačenie tlačidla deploy. Platforma musí poznať cieľový service, branch, spôsob buildu, start command, listening port, environment, health gate a postup obnovy. Dockup tieto rozhodnutia explicitne sprístupňuje a zároveň podporuje automatické buildy pomocou Nixpacks aj Dockerfiles spravované priamo v repozitári.

Táto príručka začína repozitárom, ktorý ešte nikdy nebol nasadený, a končí overenou URL, históriou nasadení, logmi a otestovaným príkazom na rollback.

Čo treba skontrolovať pred prvým produkčným nasadením?

Overte, že repozitár možno nasadiť bez nedokumentovaného lokálneho stavu. Čistý clone by mal obsahovať všetko potrebné na inštaláciu dependencies a spustenie aplikácie, s výnimkou secrets.

Použite tento checklist:

Kontrola	Očakávaný výsledok
Default branch	Existuje zamýšľaný produkčný branch
Dependency lockfile	Je commitnutý pre reprodukovateľné inštalácie
Start process	Počúva na nakonfigurovanom porte a adrese 0.0.0.0
Health route	Vráti úspešný výsledok bez externých side effectov
Database migrations	Majú explicitný a bezpečný plán spúšťania
Secrets	Sú uložené mimo Gitu
Persistent files	Používajú volume, nie filesystem kontajnera
Rollback	Predchádzajúce nasadenie možno znova spustiť

Nainštalujte CLI a autentifikujte sa:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Pred vytvorením čohokoľvek si zobrazte existujúce services:

dockup services --json

Predídete tak vytvoreniu duplicitných resources a overíte presný workspace aj konvenciu cieľov.

Ako Dockup create podporuje Git deployment?

Bežný príkaz na prvé nasadenie vytvorí service, nasadí ho, počká na výsledok a prepojí aktuálny priečinok:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Výsledný target je production/api. Link .dockup umožní neskorším príkazom rozpoznať tento service pri spustení v repozitári, no produkčná dokumentácia by mala naďalej uvádzať úplný target.

Po prerušenom pokuse o provisioning si zobrazte services a skontrolujte presný target ešte pred opätovným spustením vytvárania:

dockup services --json

Ak production/api už existuje, pokračujte načítaním jeho statusu a histórie nasadení. Predídete tak tomu, aby sa neistý výsledok sieťovej operácie zmenil na duplicitný service. Prístupové údaje k repozitáru uchovávajte mimo source controlu a výstupu príkazov.

Ako Dockup vyberá Nixpacks alebo Dockerfile?

Ak repozitár obsahuje Dockerfile, Dockup ho použije. V opačnom prípade Nixpacks automaticky rozpozná aplikáciu a vytvorí build. Vďaka tomuto poradiu je explicitná definícia kontajnera v repozitári nadradená.

Nixpacks je vhodnou prvou voľbou, ak aplikácia dodržiava bežné konvencie svojho ekosystému a nevyžaduje úpravy na úrovni operačného systému. Dockerfile sa hodí, keď potrebujete konkrétny base image, system packages, multi-stage build, vlastného runtime používateľa alebo presne určené hranice kopírovania.

Nemusíte pridávať prázdny Dockerfile len preto, aby projekt pôsobil „production ready“. Nesprávny Dockerfile môže byť menej reprodukovateľný než konvenčný automatický build. Pri rozhodovaní použite postup v článku Nixpacks vs Dockerfile.

Po vytvorení si zobrazte service:

dockup info production/api --json

Odpoveď obsahuje URL repozitára, branch, typ nasadenia, port, nastavenia buildu a spustenia, kľúče environment premenných, custom domains a údaje o poslednom nasadení.

Ak je potrebné prepísať automaticky rozpoznané príkazy, použite zdokumentované nastavenia:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Nastavenia sa uplatnia pri nasledujúcom nasadení.

Ako nakonfigurovať produkčné environment a health?

Bežné hodnoty a secrets pridávajte samostatne:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Hodnoty secrets sú pri výpise environmentu zamaskované. Možno ich nastaviť alebo nahradiť, no uložená hodnota sa nevracia.

Zmeny environmentu vyžadujú redeploy, pretože bežiaci proces nemôže spätne prijať nové environment premenné. Celý životný cyklus vysvetľuje článok environment variables and secrets.

Nakonfigurujte health gate, ktorý reprezentuje pripravenosť aplikácie:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup používa blue-green flow bez downtime a traffic na nové nasadenie odošle až po úspešnom overení readiness. Ak nie je nakonfigurovaná žiadna HTTP path, gate sa môže opierať o readiness TCP portu.

Health route by mala overovať, či je aplikačný proces pripravený obsluhovať requests. Nemala by vykonávať deštruktívne kontroly ani nákladné testy celého systému. Hlboké kontroly dependencies môžu vytvárať falošné výpadky, keď je voliteľná služba v zhoršenom stave.

Ako nasadiť, sledovať a overiť produkciu?

Spustite release a počkajte na terminálny stav:

dockup deploy production/api --wait --json

Predvolený timeout je 900 sekúnd. Exit code 0 znamená úspech. Výsledky deploy_failed a deploy_timeout sú nenulové, takže shell scripts a CI systémy sa správne zastavia.

Ak chcete sledovať build vo formáte NDJSON:

dockup logs production/api --build -f --json

Stream sa ukončí pri úspechu alebo zlyhaní. Ak build prejde, ale kontajner spadne, skontrolujte runtime logs:

dockup logs production/api --json

Po úspešnom release overte stav platformy a verejne dostupné správanie:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Uptime probes sa spúšťajú každú minútu a reportujú priemerný čas odpovede aj p95. Security scanning kontroluje CVEs v image a konfiguráciu. Pridajte smoke test špecifický pre aplikáciu a skutočný business endpoint; readiness platformy je nevyhnutná, ale sama osebe nestačí.

Podrobný postup práce s logmi nájdete v článku build and runtime log debugging.

Ako zaviesť automatické nasadenia a previews?

Prvé produkčné nasadenie vykonajte manuálne a dostatočne pomaly na to, aby ste mohli pozorovať každú hranicu procesu. Keď poznáte build, health gate a postup rollbacku, povoľte nasadenie po pushi:

dockup auto-deploy production/api --on --json

Automatické nasadenie by malo byť naviazané na chránený branch a pravidlá code review. Push je produkčný trigger, takže oprávnenia v repozitári sa stávajú oprávneniami k infraštruktúre.

Pull request a branch previews poskytujú izolované URL a environmenty:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

V projekte s private networking sa previews pripájajú do projektovej siete. Môžu pristupovať k rovnakej produkčnej databáze na adrese <slug>.internal, no Dockup pre preview automaticky vytvorí databázového používateľa iba na čítanie. Preview tak môže kontrolovať dáta v tvare podobnom produkcii bez možnosti ich meniť.

Tým však nezanikajú povinnosti súvisiace s ochranou súkromia. Prístup k preview by mal byť naďalej obmedzený, auditovaný a používaný iba tam, kde je čítanie produkčných dát povolené.

Ako vykonať rollback chybného nasadenia?

Pred obnovou zachovajte dôkazy. Pri zlyhaní buildu si prečítajte build logs, pri páde aplikácie runtime logs. Potom si zobrazte históriu nasadení:

dockup deployments production/api -n 20 --json

Vyberte deployment ID so známym statusom a timestampom a znova ho spustite:

dockup rollback <deploymentId> production/api --json

Rollback by mal byť explicitnou súčasťou riešenia incidentu. Zaznamenajte ID neúspešného nasadenia, vybrané ID obnovy, dôvod a následnú opravu. Ak databázová migrácia nie je spätne kompatibilná, samotný rollback aplikácie nemusí obnoviť kompatibilitu; návrh migrácií musí byť súčasťou release plánu.

Príručka o deploymentoch bez downtime vysvetľuje prepnutie trafficu, zatiaľ čo Dockup CLI reference dokumentuje všetky flags príkazov.

Záznam o dokončení prvého nasadenia

Na konci procesu od Git repozitára po produkciu zaznamenajte:

• Presný target project/service.
• Repozitár a produkčný branch.
• Spôsob buildu: Nixpacks alebo Dockerfile.
• Build a start commands, ak boli prepísané.
• Listening port a health path.
• Deployment ID a terminálny status.
• Produkčnú URL a plán custom domain.
• Overenie uptime a security.
• Deployment ID rollbacku alebo pravidlo výberu.

Tento záznam zmení druhé nasadenie na rutinnú operáciu namiesto ďalšieho objavovania neznámeho.

Oddeľte stav aplikácie od container image

Zapisovateľný filesystem v service kontajneri považujte za nahraditeľný. Nové nasadenie vytvorí novú verziu a rollback znova spustí starší image; súbory zapísané iba v starom kontajneri preto nie sú trvalou stratégiou pre dáta.

Pre relačný stav, stav dokumentov alebo cache používajte managed databases a pre súbory, ktoré musia prežiť nasadenia, pripojte volume. Pred prvým produkčným release overte mount paths. Kontajnerový priečinok na uploady, ktorý nikdy nebol pripojený ako volume, môže pôsobiť zdravo, kým ďalšie nasadenie dáta neodstráni.

Pred presunom súborov generovaných používateľmi si prečítajte persistent volumes and snapshots. Pri databázovom stave používajte backup systém konkrétnej databázy a nepovažujte hot volume snapshot za backup konzistentný z hľadiska transakcií.

Odhadnite prvý mesiac bez vymýšľania fixného účtu za inštanciu

Dockup meria spotrebu CPU, RAM a disku po minútach a odpočítava ju zo zostatku plánu. Free plan zahŕňa počiatočný kredit $10 a až tri nasadenia; odporúčaný Pro plan stojí $20 mesačne a zahŕňa kredit na využitie vo výške $20.

Keď bude mať service skutočný traffic, skontrolujte jeho spotrebu CPU, RAM a disku v app.dockup.ai. Pri rozhodovaní, či treba upraviť service, databázu alebo persistent disk, vychádzajte zo skutočnej spotreby za minútu, nie z odhadnutého maxima.

Overte čisté druhé nasadenie

Po prvom release urobte neškodnú zmenu schválenú code review a znova ju nasaďte. Overíte tým, že link repozitára, predpoklady build cache, health gate, environment a história fungujú ako trvalý proces, nie iba ako jednorazovo úspešný provisioning.

Udržujte target explicitný

Zaznamenajte finálny reťazec project/service.

Zachovajte URL release

Vedľa deployment ID zaznamenajte produkčnú URL.

Potvrďte ďalší trigger

Zaznamenajte, či budúce releases prebehnú manuálne alebo použijú voliteľný deploy-on-push. Po prvom nasadení tak zostanú oprávnenia repozitára, ochrana branchu a produkčné očakávania zosúladené.

Začnite overiteľným nasadením

Vyberte malý repozitár s jasným start command a health route. Po prvom úspešnom release zdokumentujte presný target a rollback ID.

Začnite bezplatne na app.dockup.ai. Free plan stojí $0 mesačne, zahŕňa počiatočný kredit $10 a podporuje jeden workspace, tri databázy a tri nasadenia.

FAQ

Môže Dockup nasadiť repozitár bez Dockerfile?

Áno. Ak Dockerfile nie je prítomný, Dockup použije Nixpacks na automatické rozpoznanie a build aplikácie.

Čo robí dockup create --link?

Zapíše link .dockup do aktuálneho priečinka, aby neskoršie príkazy mohli rozpoznať priradený target projektu/service.

Prečo by prvé nasadenie malo používať --wait?

Príkaz zostane pripojený, kým nasadenie nedosiahne stav úspechu, zlyhania alebo timeoutu, a vráti exit code, ktorý presne reprezentuje terminálny výsledok.

Uplatnia sa zmeny environment premenných okamžite?

Nie. Uplatnia sa v novom kontajneri pri nasledujúcom nasadení, preto po zmene konfigurácie environmentu service znova nasaďte.

Ako Dockup vykoná rollback aplikácie?

Zobrazte históriu nasadení, identifikujte známe predchádzajúce deployment ID a použite dockup rollback s týmto ID a presným targetom service.