Z repozitáře Git do produkce: průvodce nasazením v Dockup

Přesun repozitáře Git do produkce vyžaduje víc než připojit remote a stisknout tlačítko deploy. Platforma musí znát cílovou službu, branch, metodu buildu, start command, port, na kterém aplikace naslouchá, prostředí, podmínku health checku a postup obnovy. Dockup tato rozhodnutí zviditelňuje a zároveň podporuje automatické buildy pomocí Nixpacks i Dockerfile uložené přímo v repozitáři.

Tento průvodce začíná repozitářem, který ještě nikdy nebyl nasazen, a končí ověřenou URL, historií nasazení, logy a otestovaným příkazem pro rollback.

Co je třeba ověřit před prvním produkčním nasazením?

Ověřte, že lze repozitář nasadit bez nedokumentovaného lokálního stavu. Čistý clone by měl obsahovat vše potřebné k instalaci závislostí a spuštění aplikace, s výjimkou secrets.

Použijte tento checklist:

Kontrola	Očekávaný výsledek
Výchozí branch	Existuje zamýšlená produkční branch
Lockfile závislostí	Je commitnutý kvůli reprodukovatelným instalacím
Start process	Naslouchá na nakonfigurovaném portu a 0.0.0.0
Health route	Vrací úspěch bez vedlejších účinků
Migrace databáze	Mají explicitní a bezpečný plán provedení
Secrets	Jsou uložené mimo Git
Perzistentní soubory	Používají volume, nikoli filesystem kontejneru
Rollback	Předchozí nasazení lze znovu spustit

Nainstalujte CLI a přihlaste se:

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

Před vytvořením čehokoli si vypište existující služby:

dockup services --json

Předejdete tak vytvoření duplicitních resources a ověříte přesnou konvenci workspace a targetu.

Jak Dockup create podporuje nasazení z Gitu?

Obvyklý příkaz pro první nasazení vytvoří službu, nasadí ji, počká na výsledek a propojí aktuální adresář:

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

Výsledný target je production/api. Odkaz .dockup umožní pozdějším příkazům rozpoznat tuto službu při spuštění uvnitř repozitáře, ale produkční dokumentace by měla stále uvádět celý target.

Po přerušeném pokusu o provisioning si vypište služby a před opětovným spuštěním vytvoření zkontrolujte přesný target:

dockup services --json

Pokud production/api již existuje, pokračujte načtením jeho stavu a historie nasazení. Zabráníte tak tomu, aby se nejistý výsledek síťového požadavku změnil v duplicitní službu. Přístupové údaje k repozitáři uchovávejte mimo source control a výstup příkazů.

Jak Dockup volí Nixpacks nebo Dockerfile?

Pokud repozitář obsahuje Dockerfile, Dockup použije právě ten. V opačném případě Nixpacks aplikaci detekuje a automaticky sestaví. Díky tomuto pořadí má explicitní definice kontejneru v repozitáři přednost.

Nixpacks je dobrou první volbou, pokud aplikace odpovídá běžným konvencím svého ekosystému a nepotřebuje úpravy na úrovni operačního systému. Dockerfile se hodí, když potřebujete konkrétní base image, systémové balíčky, multi-stage build, vlastního runtime uživatele nebo přesně definované hranice kopírování.

Nemusíte přidávat prázdný Dockerfile jen proto, aby projekt „vypadal připravený pro produkci“. Nesprávný Dockerfile může být méně reprodukovatelný než konvenční automatický build. Použijte rozhodovací postup v článku Nixpacks vs Dockerfile.

Po vytvoření si službu zkontrolujte:

dockup info production/api --json

Odpověď obsahuje URL repozitáře, branch, typ nasazení, port, nastavení buildu a startu, klíče prostředí, custom domains a údaje o posledním nasazení.

Pokud detekované příkazy vyžadují override, použijte zdokumentované nastavení:

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

Nastavení se projeví při dalším nasazení.

Jak nakonfigurovat produkční prostředí a health check?

Běžné hodnoty a secrets přidávejte odděleně:

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

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

Hodnoty secrets jsou při výpisu prostředí skryté. Lze je nastavit nebo nahradit, ale uložená hodnota se nevrací.

Změny prostředí vyžadují nové nasazení, protože běžícímu procesu nelze zpětně předat nové prostředí. Celý lifecycle vysvětluje článek environment variables and secrets.

Nastavte health gate, který odpovídá připravenosti aplikace:

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

Dockup používá blue-green flow bez výpadku a provoz na nové nasazení přesměruje až po úspěšném ověření připravenosti. Pokud není nakonfigurována žádná HTTP cesta, může health gate použít připravenost TCP portu.

Health route by měla ověřovat, že je proces aplikace připraven přijímat požadavky. Neměla by provádět destruktivní kontroly ani nákladné testy celého systému. Hloubkové kontroly závislostí mohou vytvářet falešné výpadky, pokud je některá volitelná služba degradovaná.

Jak nasadit, sledovat a ověřit produkci?

Spusťte release a počkejte na konečný stav:

dockup deploy production/api --wait --json

Výchozí timeout je 900 sekund. Kód 0 znamená úspěch. Výsledky deploy_failed a deploy_timeout jsou nenulové, takže shell skripty a CI systémy se správně zastaví.

Pro sledování buildu ve formátu NDJSON:

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

Stream skončí při úspěchu nebo chybě. Pokud build proběhne úspěšně, ale kontejner spadne, prohlédněte si runtime logy:

dockup logs production/api --json

Po úspěšném release ověřte stav platformy a veřejné chování aplikace:

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

Uptime probes se spouštějí každou minutu a reportují průměrnou a p95 dobu odezvy. Security scanning kontroluje CVE v image a konfiguraci. Přidejte smoke test specifický pro aplikaci a skutečný business endpoint; připravenost platformy je nutná, ale sama o sobě nestačí.

Podrobný postup práce s logy najdete v článku build and runtime log debugging.

Jak zavést automatická nasazení a preview prostředí?

První produkční release proveďte ručně tak, abyste mohli sledovat každou hranici procesu. Jakmile znáte build, health gate a postup rollbacku, zapněte nasazení při pushi:

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

Automatické nasazení by mělo být navázané na chráněnou branch a pravidla code review. Push je produkční trigger, takže oprávnění k repozitáři se stávají oprávněními k infrastruktuře.

Preview prostředí pro pull requesty a branche poskytují izolované URL a prostředí:

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

V projektu s private networking se preview prostředí připojí k project network. Mohou přistupovat ke stejné produkční databázi na adrese <slug>.internal, ale Dockup pro preview automaticky vytvoří databázového uživatele pouze pro čtení. Preview tak může prohlížet data odpovídající produkčnímu prostředí, aniž by do nich zapisovalo.

Tím však nezanikají povinnosti v oblasti ochrany soukromí. Přístup k preview by měl být i nadále omezený, auditovaný a používaný pouze tam, kde je čtení produkčních dat povolené.

Jak provést rollback chybného nasazení?

Před obnovou zachovejte důkazy. Při chybě buildu si přečtěte build logy a při pádu aplikace runtime logy. Poté si vypište historii nasazení:

dockup deployments production/api -n 20 --json

Vyberte ID nasazení, u kterého znáte stav a časové razítko, a znovu ho spusťte:

dockup rollback <deploymentId> production/api --json

Rollback by měl být explicitním krokem při řešení incidentu. Zaznamenejte ID chybného nasazení, ID zvolené obnovy, důvod a následnou opravu. Pokud migrace databáze není zpětně kompatibilní, samotný rollback aplikace nemusí kompatibilitu obnovit; návrh migrací musí být součástí release plánu.

Průvodce nasazením bez výpadku vysvětluje přepnutí provozu, zatímco referenční dokumentace Dockup CLI popisuje všechny příznaky příkazů.

Záznam o dokončení prvního nasazení

Na konci workflow od repozitáře Git do produkce zaznamenejte:

• Přesný target project/service.
• Repozitář a produkční branch.
• Metodu buildu: Nixpacks nebo Dockerfile.
• Build a start commands, pokud byly přepsány.
• Port, na kterém aplikace naslouchá, a health path.
• ID nasazení a konečný stav.
• Produkční URL a plán custom domain.
• Ověření uptime a security.
• ID nasazení pro rollback nebo pravidlo jeho výběru.

Díky tomuto záznamu se druhé nasazení stane rutinní operací namísto dalšího průzkumu.

Oddělte stav aplikace od image kontejneru

Se zapisovatelným filesystemem uvnitř kontejneru služby zacházejte jako s nahraditelným. Nové nasazení vytvoří novou verzi a rollback znovu spustí starší image; soubory zapsané pouze ve starém kontejneru nejsou trvalou strategií pro uchovávání dat.

Pro relační, dokumentová nebo cache data používejte managed databases a pro soubory, které musí přetrvat mezi nasazeními, připojte volume. Před prvním produkčním release ověřte mount paths. Upload directory v kontejneru, který nikdy nebyl připojen jako volume, může vypadat funkčně, dokud další deploy data neodstraní.

Než přesunete soubory generované uživateli, projděte si článek persistent volumes and snapshots. Pro stav databáze použijte zálohovací systém určený pro konkrétní databázi; hot snapshot volume nepovažujte za zálohu konzistentní z hlediska transakcí.

Odhadněte první měsíc bez vymýšlení pevného účtu za instance

Dockup měří spotřebu CPU, RAM a disku po minutách a odečítá ji z kreditu plánu. Tarif Free zahrnuje počáteční kredit 10 $ a až tři nasazení; doporučený tarif Pro stojí 20 $ měsíčně a zahrnuje kredit na využití ve výši 20 $.

Jakmile bude mít služba skutečný provoz, zkontrolujte její spotřebu CPU, RAM a disku v app.dockup.ai. O tom, zda je třeba upravit službu, databázi nebo persistent disk, rozhodujte podle skutečné spotřeby za minutu, nikoli podle odhadovaného maxima.

Ověřte čisté druhé nasazení

Po prvním release proveďte další deploy s neškodnou změnou, která prošla review. Ověříte tím, že propojení s repozitářem, předpoklady build cache, health gate, prostředí i historie fungují jako průběžný proces, nikoli jen jako jednorázový úspěch při provisioningu.

Target ponechte explicitní

Zaznamenejte finální řetězec project/service.

Uchovejte URL release

Zapište produkční URL vedle ID nasazení.

Potvrďte další trigger

Zaznamenejte, zda budou budoucí release manuální, nebo zda budou používat volitelný deploy-on-push. Po prvním nasazení tak zůstanou oprávnění repozitáře, ochrana branchí a očekávání ohledně produkce vzájemně sladěné.

Začněte ověřitelným nasazením

Vyberte malý repozitář s jasným start commandem a health route a po prvním úspěšném release zdokumentujte přesný target a ID rollbacku.

Začněte zdarma na app.dockup.ai. Tarif Free stojí 0 $ měsíčně, zahrnuje počáteční kredit 10 $ a podporuje jeden workspace, tři databáze a tři nasazení.

FAQ

Může Dockup nasadit repozitář bez Dockerfile?

Ano. Pokud Dockerfile není přítomen, Dockup použije Nixpacks k automatické detekci a sestavení aplikace.

Co dělá dockup create --link?

Zapíše do aktuálního adresáře odkaz .dockup, takže pozdější příkazy mohou rozpoznat přidružený target projektu/služby.

Proč by první deploy měl používat --wait?

Příkaz zůstane připojený, dokud nasazení nedosáhne stavu úspěchu, chyby nebo timeoutu, a vrátí exit code, který přesně odpovídá konečnému výsledku.

Projeví se změny environment variables okamžitě?

Ne. Projeví se v novém kontejneru při dalším nasazení, takže po změně konfigurace prostředí službu znovu nasaďte.

Jak Dockup provede rollback aplikace?

Vypište historii nasazení, identifikujte známé předchozí ID nasazení a použijte dockup rollback s tímto ID a přesným targetem služby.