Git-tárolótól az éles környezetig: Dockup telepítési útmutató

Egy Git-tároló éles környezetbe telepítése többet jelent annál, mint hogy csatlakoztatunk egy remote tárolót, majd megnyomjuk a deploy gombot. A platformnak ismernie kell a szolgáltatás célját, az ágat, a buildelési módot, az indítási parancsot, a figyelt portot, a környezetet, a health gate feltételeit és a helyreállítási lehetőséget. A Dockup egyértelművé teszi ezeket a döntéseket, miközben támogatja az automatikus Nixpacks buildet és a tárolóban definiált Dockerfile használatát is.

Ez az útmutató egy még nem telepített tárolóból indul, és egy ellenőrzött URL-lel, telepítési előzményekkel, logokkal, valamint tesztelt rollback paranccsal zárul.

Mit kell ellenőrizni az első éles telepítés előtt?

Ellenőrizd, hogy a tároló dokumentálatlan lokális állapot nélkül is telepíthető. Egy tiszta clone-nak mindent tartalmaznia kell, ami a függőségek telepítéséhez és az alkalmazás indításához szükséges, a titkok kivételével.

Használd ezt az ellenőrzőlistát:

Ellenőrzés	Várt eredmény
Alapértelmezett ág	Létezik a kívánt éles ág
Függőség-lockfile	A reprodukálható telepítésekhez commitolva van
Indítási folyamat	A beállított porthoz és a 0.0.0.0 címhez kötődik
Health route	Külső mellékhatások nélkül sikeres választ ad
Adatbázis-migrációk	Van hozzájuk egyértelmű, biztonságos végrehajtási terv
Titkok	A Git-en kívül vannak tárolva
Tartós fájlok	Volume-ot használnak a container fájlrendszere helyett
Rollback	Az előző deployment újra futtatható

Telepítsd a CLI-t, majd hitelesítsd magad:

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

A létrehozás előtt listázd a meglévő szolgáltatásokat:

dockup services --json

Ezzel elkerülheted a duplikált erőforrásokat, és ellenőrizheted a pontos workspace- és targetkonvenciót.

Hogyan támogatja a Dockup create a Git-telepítést?

Az első telepítéshez használt szokásos parancs létrehozza a szolgáltatást, elindítja a deploymentet, megvárja az eredményt, majd összekapcsolja az aktuális könyvtárral:

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

A létrejövő target production/api lesz. A .dockup link lehetővé teszi, hogy a későbbi parancsok a tárolón belül futtatva feloldják ezt a szolgáltatást, az éles környezet dokumentációjában azonban továbbra is rögzíteni kell a teljes targetet.

Megszakadt provisioningkísérlet után listázd a szolgáltatásokat, és a létrehozás újbóli futtatása előtt vizsgáld meg a pontos targetet:

dockup services --json

Ha a production/api már létezik, folytasd az állapotának és a deploymentelőzményeinek lekérdezésével. Így nem lesz egy bizonytalan hálózati eredményből duplikált szolgáltatás. A repository-hozzáférési hitelesítő adatokat tartsd a source code-on és a parancskimeneten kívül.

Hogyan választja ki a Dockup a Nixpacks vagy a Dockerfile használatát?

Ha a tároló tartalmaz Dockerfile-t, a Dockup azt használja. Ellenkező esetben a Nixpacks felismeri az alkalmazást, és automatikusan buildeli. Ennek a sorrendnek köszönhetően a tároló explicit containerdefiníciója lesz az elsődleges.

A Nixpacks jó első választás, ha az alkalmazás a gyakori ökoszisztéma-konvenciókat követi, és nincs szüksége operációsrendszer-szintű testreszabásra. Dockerfile-ra akkor lehet szükség, ha meghatározott base image-et, rendszercsomagokat, multi-stage buildet, egyedi runtime-felhasználót vagy pontos copy-határokat szeretnél.

Nem kell üres Dockerfile-t hozzáadnod csak azért, hogy a projekt „éles környezetre késznek” tűnjön. Egy hibás Dockerfile kevésbé lehet reprodukálható, mint egy konvencionális automatikus build. Használd a Nixpacks vs Dockerfile útmutatóban ismertetett döntési folyamatot.

A létrehozás után vizsgáld meg a szolgáltatást:

dockup info production/api --json

A válasz tartalmazza a repository URL-jét, az ágat, a deployment típusát, a portot, a build- és startbeállításokat, a környezeti kulcsokat, az egyéni domaineket és a legutóbbi deployment adatait.

Ha az automatikusan felismert parancsokat felül kell írni, használd a dokumentált beállításokat:

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

A beállítások a következő deployment során lépnek életbe.

Hogyan állítható be az éles környezet és a health gate?

A hagyományos értékeket és a titkokat külön add hozzá:

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

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

A titkos értékek maszkolva jelennek meg a környezet listázásakor. Beállíthatók vagy lecserélhetők, a tárolt érték azonban nem kérhető le.

A környezeti változásokhoz újra kell futtatni a deploymentet, mert a futó processz utólag nem kaphat új környezetet. A teljes életciklust a környezeti változókról és titkokról szóló útmutató ismerteti.

Állíts be olyan health gate-et, amely a readiness állapotot jelzi:

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

A Dockup zero-downtime blue-green folyamatot használ, és csak akkor irányít forgalmat az új deploymentre, ha a readiness sikeres. Ha nincs HTTP-útvonal beállítva, a gate visszaeshet a TCP-port readiness ellenőrzésére.

A health route-nak azt kell ellenőriznie, hogy az alkalmazás processze készen áll-e a kérések kiszolgálására. Ne végeztess vele romboló műveleteket vagy költséges, teljes rendszerre kiterjedő teszteket. A mély dependency checkek téves kiesést jelezhetnek, ha egy opcionális szolgáltatás állapota romlik.

Hogyan telepítheted, figyelheted és ellenőrizheted az éles környezetet?

Indítsd el a release-t, majd várd meg a végállapotot:

dockup deploy production/api --wait --json

Az alapértelmezett timeout 900 másodperc. A 0-s kilépési kód sikert jelent. A deploy_failed és a deploy_timeout nem nulla eredményt ad, így a shell scriptek és a CI-rendszerek megfelelően leállnak.

A build NDJSON formátumú követéséhez:

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

A stream sikeres vagy sikertelen állapotnál ér véget. Ha a build sikeres, de a container összeomlik, vizsgáld meg a runtime logokat:

dockup logs production/api --json

Sikeres release után ellenőrizd a platform állapotát és a publikus működést:

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

Az uptime probe-ok percenként futnak, és az átlagos, valamint a p95 válaszidőt jelentik. A security scanning az image-ek CVE-it és a konfigurációt ellenőrzi. Adj hozzá alkalmazásspecifikus smoke tesztet a tényleges üzleti endpointhez; a platform readiness szükséges, de önmagában nem elégséges.

A részletes logolási módszert a build- és runtime-logok hibakereséséről szóló útmutató ismerteti.

Hogyan érdemes bevezetni az automatikus deploymenteket és a preview-környezeteket?

Az első éles release-t kezdetben elég manuálisan végezd ahhoz, hogy minden határfelületet megfigyelhess. Ha már ismert a build, a health gate és a rollback folyamata, engedélyezd a push-alapú deploymentet:

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

Az automatikus deploymentnek védett ágat és code review folyamatot kell követnie. Egy push éles környezetet érintő trigger, ezért a repository-jogosultságok infrastruktúra-jogosultságokká válnak.

A pull request- és branch preview-k izolált URL-eket és környezeteket biztosítanak:

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

Privát hálózatkezelést használó projektben a preview-k csatlakoznak a projekt hálózatához. Ugyanazt az éles adatbázist a <slug>.internal címen érhetik el, a Dockup azonban automatikusan csak olvasási jogosultságú adatbázis-felhasználót hoz létre a preview számára. A preview így megvizsgálhatja az éleshez hasonló adatokat anélkül, hogy módosítaná őket.

Ez nem szünteti meg az adatvédelmi kötelezettségeket. A preview-hozzáférést továbbra is korlátozni és auditálni kell, és csak olyan esetben szabad használni, amikor az éles adatok olvasása engedélyezett.

Hogyan állíthatsz vissza egy hibás deploymentet?

A helyreállítás előtt őrizd meg a bizonyítékokat. Buildhiba esetén olvasd el a build logokat, összeomlás esetén pedig a runtime logokat. Ezután listázd a deploymentelőzményeket:

dockup deployments production/api -n 20 --json

Válassz ki egy olyan deployment ID-t, amelynek státusza és időpontja ismert, majd futtasd újra:

dockup rollback <deploymentId> production/api --json

A rollback explicit incidenskezelési művelet legyen. Rögzítsd a hibás deployment ID-ját, a választott helyreállítási ID-t, az okot és a további javítást. Ha egy adatbázis-migráció nem visszafelé kompatibilis, önmagában az alkalmazás rollbackje nem feltétlenül állítja helyre a kompatibilitást; a migráció megtervezésének a release tervének részét kell képeznie.

A zero-downtime deployment útmutatója ismerteti a forgalom átirányítását, a Dockup CLI-referencia pedig az összes parancsopciót dokumentálja.

Az első deployment rögzítése

A Git-tárolótól az éles környezetig tartó munkafolyamat végén rögzítsd a következőket:

• A pontos project/service targetet.
• A repositoryt és az éles ágat.
• A buildelési módot: Nixpacks vagy Dockerfile.
• A felülírt build- és startparancsokat.
• A figyelt portot és a health path értékét.
• A deployment ID-ját és végállapotát.
• Az éles URL-t és az egyéni domain tervét.
• Az uptime- és security-ellenőrzés eredményét.
• A rollback deployment ID-ját vagy a kiválasztás szabályát.

Ez a nyilvántartás a második deploymentet rutinszerű műveletté teszi egy újabb feltárási feladat helyett.

Válaszd külön az alkalmazás állapotát és a container image-et

A szolgáltatás containerében lévő írható fájlrendszert cserélhetőként kell kezelni. Egy új deployment új verziót hoz létre, a rollback pedig egy korábbi image-et futtat újra; ezért a kizárólag a régi containerben tárolt fájlok nem jelentenek tartós adattárolási stratégiát.

Relációs, dokumentum- vagy cache-állapothoz használj menedzselt adatbázisokat, a deploymentek között megőrzendő fájlokhoz pedig csatolj volume-ot. Az első éles release előtt ellenőrizd a mount path-eket. Egy nem csatolt, containerizált feltöltési könyvtár egészségesnek tűnhet, amíg a következő deploy nem törli az adatokat.

A felhasználók által létrehozott fájlok áthelyezése előtt olvasd el a tartós volume-okról és snapshotokról szóló útmutatót. Adatbázis-állapot esetén az adatbázis saját biztonsági mentési rendszerét használd, és ne kezeld a futó volume snapshotját tranzakciókonzisztens mentésként.

Becsüld meg az első hónapot fix instance-számla kitalálása nélkül

A Dockup percenként méri a CPU-, RAM- és lemezhasználatot, majd a felhasználást levonja a csomag egyenlegéből. A Free csomag 10 USD kezdő jóváírást és legfeljebb három deploymentet tartalmaz; az ajánlott Pro csomag havi 20 USD-ba kerül, és 20 USD felhasználási jóváírást tartalmaz.

Miután a szolgáltatás valódi forgalmat kap, az app.dockup.ai oldalon tekintsd át a CPU-, RAM- és lemezhasználatát. A szolgáltatás, az adatbázis vagy a tartós lemez méretének módosításáról a megfigyelt percenkénti fogyasztás alapján dönts, ne egy feltételezett maximális érték alapján.

Ellenőrizd a tiszta második deploymentet

Az első release után készíts egy ártalmatlan, review-zott módosítást, majd telepítsd újra. Ezzel meggyőződhetsz arról, hogy a repository-link, a build cache-re vonatkozó feltételezések, a health gate, a környezet és az előzmények nem egyszeri provisioning sikerként, hanem folyamatos folyamatként működnek.

Tartsd explicit módon a targetet

Rögzítsd a végleges project/service karakterláncot.

Őrizd meg a release URL-jét

A production URL-t a deployment ID mellett rögzítsd.

Erősítsd meg a következő triggert

Rögzítsd, hogy a jövőbeli release-ek manuálisan készülnek-e, vagy az opcionális push-alapú deploymentet használják. Így az első deployment után is összhangban maradnak a repository-jogosultságok, az ágvédelem és az éles környezettel kapcsolatos elvárások.

Kezdj ellenőrizhető deploymenttel

Válassz egy kis, egyértelmű startparanccsal és health route-tal rendelkező repositoryt, majd az első sikeres release után dokumentáld a pontos targetet és a rollback ID-t.

Kezdd ingyenesen az app.dockup.ai oldalon. A Free csomag havi 0 USD-ba kerül, 10 USD kezdő jóváírást tartalmaz, és egy workspace-et, három adatbázist, valamint három deploymentet támogat.

GYIK

Telepíthet a Dockup Dockerfile nélküli repositoryt?

Igen. Ha nincs Dockerfile, a Dockup Nixpacks segítségével automatikusan felismeri és buildeli az alkalmazást.

Mit csinál a dockup create --link?

A jelenlegi könyvtárban létrehoz egy .dockup linket, hogy a későbbi parancsok feloldhassák a hozzá tartozó project/service targetet.

Miért érdemes az első deploy során a --wait opciót használni?

A parancsot a deployment sikeres, sikertelen vagy timeouttal végződő állapotáig futva tartja, és olyan exit code-ot ad vissza, amely pontosan jelzi a végső eredményt.

Azonnal érvénybe lépnek a környezeti változók módosításai?

Nem. Az új értékek a következő deployment során létrehozott új containerben lépnek életbe, ezért a környezeti konfiguráció módosítása után telepítsd újra a szolgáltatást.

Hogyan állít vissza egy alkalmazást a Dockup?

Listázd a deploymentelőzményeket, azonosíts egy ismert korábbi deployment ID-t, majd használd a dockup rollback parancsot ezzel az ID-val és a pontos szolgáltatási targettel.