Git-repositoriosta tuotantoon: Dockup-käyttöönotto-opas

Git-repositorion vieminen tuotantoon edellyttää muutakin kuin remoten yhdistämistä ja deploy-painikkeen painamista. Platformin on tunnettava palvelun kohde, branch, build-menetelmä, start-komento, kuunteluportti, ympäristö, health gate ja palautuspolku. Dockup tekee nämä valinnat näkyviksi ja tukee sekä automaattisia Nixpacks-buildauksia että repositorion omia Dockerfile-tiedostoja.

Tässä oppaassa aloitetaan repositoriosta, jota ei ole koskaan deployattu, ja päädytään varmennettuun URL-osoitteeseen, deployment-historiaan, lokeihin ja testattuun rollback-komentoon.

Mitä ennen ensimmäistä tuotantoonvientiä pitää tarkistaa?

Varmista, että repositorion voi deployata ilman dokumentoimatonta paikallista tilaa. Puhtaan clonen tulee sisältää kaikki riippuvuuksien asentamiseen ja sovelluksen käynnistämiseen tarvittava, salaisuuksia lukuun ottamatta.

Käytä tätä tarkistuslistaa:

Tarkistus	Odotettu tulos
Oletus-branch	Tarkoitettu tuotanto-branch on olemassa
Riippuvuuksien lockfile	Committattu toistettavia asennuksia varten
Käynnistysprosessi	Kuuntelee määritettyä porttia ja osoitetta 0.0.0.0
Health-reitti	Palauttaa onnistumisen ilman ulkoisia sivuvaikutuksia
Tietokantamigraatiot	Niille on määritetty turvallinen suoritusmenettely
Salaisuudet	Tallennettu Gitin ulkopuolelle
Pysyvät tiedostot	Käyttävät volumea, eivät containerin tiedostojärjestelmää
Rollback	Aiempi deployment voidaan ajaa uudelleen

Asenna CLI ja autentikoi:

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

Listaa olemassa olevat servicet ennen uuden luomista:

dockup services --json

Näin vältät päällekkäiset resurssit ja varmistat tarkan workspacen ja target-käytännön.

Miten Dockup create tukee Git-käyttöönottoa?

Tavallinen ensimmäisen deploymentin komento luo servicen, deployaa sen, odottaa tulosta ja linkittää nykyisen hakemiston:

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

Tuloksena syntyvä target on production/api. .dockup-linkin avulla myöhemmät komennot voivat ratkaista kyseisen servicen, kun ne suoritetaan repositorion sisällä, mutta tuotantodokumentaatiossa tulee silti kirjata koko target.

Jos provisiointiyritys keskeytyy, listaa servicet ja tarkista tarkka target ennen kuin yrität luomista uudelleen:

dockup services --json

Jos production/api on jo olemassa, jatka lukemalla sen tila ja deployment-historia. Näin epävarmaa verkkotulosta ei muuteta päällekkäiseksi serviceksi. Säilytä repositorion käyttöoikeustunnukset lähdekoodin ja komentotulosteen ulkopuolella.

Miten Dockup valitsee Nixpacksin tai Dockerfilen?

Jos repositoriossa on Dockerfile, Dockup käyttää sitä. Muussa tapauksessa Nixpacks tunnistaa sovelluksen ja buildaa sen automaattisesti. Näin repositorion eksplisiittinen container-määritys on ensisijainen.

Nixpacks on hyvä ensimmäinen valinta, kun sovellus noudattaa yleisiä ekosysteemin käytäntöjä eikä tarvitse käyttöjärjestelmätason mukautuksia. Dockerfile on hyödyllinen, kun tarvitset tietyn base imagen, järjestelmäpaketteja, multi-stage-buildin, mukautetun runtime-käyttäjän tai tarkat copy-rajat.

Tyhjää Dockerfilea ei tarvitse lisätä vain siksi, että projekti näyttäisi “valmiilta tuotantoon”. Virheellinen Dockerfile voi olla vähemmän toistettava kuin tavanomainen automaattinen build. Käytä Nixpacks vs Dockerfile-oppaan päätösprosessia.

Tarkista service luomisen jälkeen:

dockup info production/api --json

Vastaus sisältää repositorion URL-osoitteen, branchin, deployment-tyypin, portin, build- ja start-asetukset, ympäristöavaimet, custom domainit sekä viimeisimmän deploymentin tiedot.

Jos tunnistetut komennot tarvitsevat yliajon, käytä dokumentoituja asetuksia:

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

Asetukset tulevat voimaan seuraavassa deploymentissa.

Miten tuotantoympäristö ja health määritetään?

Lisää tavalliset arvot ja salaisuudet erikseen:

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

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

Salaiset arvot peitetään, kun ympäristö listataan. Ne voidaan asettaa tai korvata, mutta tallennettua arvoa ei palauteta.

Ympäristömuutokset edellyttävät redeployta, koska käynnissä oleva prosessi ei voi vastaanottaa uutta ympäristöä jälkikäteen. Koko elinkaari kuvataan oppaassa ympäristömuuttujat ja salaisuudet.

Määritä readinessia edustava health gate:

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

Dockup käyttää zero-downtime blue-green -prosessia ja ohjaa liikenteen uuteen deploymentiin vasta, kun readiness on onnistunut. Jos HTTP-polkuja ei ole määritetty, gate voi käyttää TCP-portin readinessia.

Health-reitin tulee varmistaa, että sovellusprosessi on valmis palvelemaan pyyntöjä. Älä tee siitä tuhoavia tarkistuksia tai kalliita koko järjestelmän testejä. Syvät riippuvuustarkistukset voivat aiheuttaa vääriä käyttökatkoja, jos valinnainen service on häiriintynyt.

Miten tuotanto deployataan, sitä seurataan ja toiminta varmennetaan?

Käynnistä release ja odota päätetilaa:

dockup deploy production/api --wait --json

Oletusaikakatkaisu on 900 sekuntia. Exit 0 tarkoittaa onnistumista. deploy_failed ja deploy_timeout ovat nollasta poikkeavia tuloksia, joten shell-skriptit ja CI-järjestelmät pysähtyvät oikein.

Voit seurata buildia NDJSON-muodossa:

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

Stream päättyy onnistumiseen tai virheeseen. Jos build onnistuu mutta container kaatuu, tarkista runtime-lokit:

dockup logs production/api --json

Onnistuneen releasen jälkeen varmista platformin tila ja julkinen toiminta:

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

Uptime-probet suoritetaan minuutin välein, ja ne raportoivat vasteajan keskiarvon ja p95-arvon. Security scanning tarkistaa imagen CVE-haavoittuvuudet ja konfiguraation. Lisää sovelluskohtainen smoke test varsinaista liiketoimintaendpointia varten; platformin readiness on välttämätön, mutta ei riittävä.

Yksityiskohtainen lokimenetelmä on kuvattu oppaassa build- ja runtime-lokien vianmääritys.

Miten automaattiset deployt ja previewt kannattaa ottaa käyttöön?

Tee ensimmäinen tuotantorelease riittävän manuaalisesti, jotta voit tarkkailla jokaista rajapintaa. Kun build, health gate ja rollback-polku ovat tuttuja, ota pushiin perustuva deployment käyttöön:

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

Automaattisen deploymentin tulee seurata suojattua branchia ja code review -käytäntöä. Push on tuotantotriggeri, joten repositorion käyttöoikeuksista tulee infrastruktuurin käyttöoikeuksia.

Pull request- ja branch-previewt tarjoavat eristetyt URL-osoitteet ja ympäristöt:

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

Private networking -projektissa previewt liittyvät projektin verkkoon. Ne voivat saavuttaa saman tuotantotietokannan osoitteessa <slug>.internal, mutta Dockup luo previewlle automaattisesti read-only-tietokantakäyttäjän. Preview voi tarkastella tuotantoa muistuttavaa dataa kirjoittamatta siihen.

Tämä ei poista tietosuojaa koskevia velvoitteita. Preview-käyttö tulee silti rajata, auditoida ja sallia vain silloin, kun tuotantodatan lukeminen on sallittua.

Miten virheellinen deployment palautetaan?

Säilytä todisteet ennen palautusta. Lue build-lokit build-virheessä ja runtime-lokit kaatumistilanteessa. Listaa sitten deployment-historia:

dockup deployments production/api -n 20 --json

Valitse deployment ID, jonka tila ja aikaleima tunnetaan, ja aja se uudelleen:

dockup rollback <deploymentId> production/api --json

Rollbackin tulee olla eksplisiittinen incident-toimenpide. Kirjaa epäonnistuneen deploymentin ID, valittu palautus-ID, syy ja jatkokorjaus. Jos tietokantamigraatio ei ole backward compatible, pelkkä sovelluksen rollback ei välttämättä palauta yhteensopivuutta; migraatioiden suunnittelun tulee olla osa release-suunnitelmaa.

Zero-downtime-deployment-opas selittää liikenteen siirron, ja Dockup CLI -referenssi dokumentoi kaikki komentoliput.

Ensimmäisen deploymentin valmistumisraportti

Kun Git-repositoriosta tuotantoon -työnkulku on valmis, tallenna:

• Tarkka project/service-target.
• Repositorio ja tuotanto-branch.
• Build-menetelmä: Nixpacks tai Dockerfile.
• Build- ja start-komennot, jos niitä on yliajettu.
• Kuunteluportti ja health-polku.
• Deployment ID ja päätetila.
• Tuotanto-URL ja custom domain -suunnitelma.
• Uptime- ja security-varmennus.
• Rollback-deployment ID tai valintasääntö.

Tämä raportti muuttaa toisesta deploymentista rutiinitoimenpiteen uuden selvitystyön sijaan.

Erota sovelluksen tila container-imagesta

Service-containerin kirjoitettavaa tiedostojärjestelmää tulee käsitellä korvattavana. Uusi deployment luo uuden version ja rollback ajaa vanhemman imagen uudelleen; ainoastaan vanhan containerin sisään kirjoitetut tiedostot eivät ole kestävä dataratkaisu.

Käytä hallittuja tietokantoja relaatio-, dokumentti- tai cache-tilalle ja liitä volume tiedostoille, joiden on säilyttävä deploymentien välillä. Varmista mount-polut ennen ensimmäistä tuotantoreleasea. Containerisoitu upload-hakemisto, jota ei ole koskaan mountattu, voi vaikuttaa terveeltä, kunnes seuraava deploy poistaa datan.

Tutustu oppaaseen pysyvistä volumeista ja snapshoteista ennen käyttäjien tuottamien tiedostojen siirtämistä. Tietokantadatan osalta käytä tietokantakohtaista backup-järjestelmää sen sijaan, että käsittelisit hot volume snapshotia transaktionaalisesti eheänä varmuuskopiona.

Arvioi ensimmäinen kuukausi keksimättä kiinteää instanssilaskua

Dockup mittaa CPU:n, RAM-muistin ja levyn kulutusta minuutti kerrallaan ja vähentää käytön planin saldosta. Free-plan sisältää 10 dollarin aloitussaldon ja enintään kolme deploymentia; suositeltu Pro-plan maksaa 20 dollaria kuukaudessa ja sisältää 20 dollarin käyttösaldon.

Kun servicellä on todellista liikennettä, tarkista sen CPU-, RAM- ja levynkulutus osoitteessa app.dockup.ai. Käytä päätöksessä havaittua minuuttikohtaista kulutusta — älä arvattua enimmäiskulutusta — ja arvioi sen perusteella, tarvitsevatko service, tietokanta tai pysyvä levy säätöä.

Varmista toinen deployment puhtaassa tilassa

Tee ensimmäisen releasen jälkeen harmiton, tarkistettu muutos ja deployaa uudelleen. Näin varmistat, että repositorion linkki, build-cachen oletukset, health gate, ympäristö ja historia toimivat jatkuvana prosessina eivätkä vain kertaluonteisen provisioinnin onnistumisena.

Pidä target eksplisiittisenä

Kirjaa lopullinen project/service-merkkijono.

Säilytä release-URL

Kirjaa tuotanto-URL deployment ID:n viereen.

Vahvista seuraava triggeri

Kirjaa, ovatko tulevat releaset manuaalisia vai käyttävätkö ne valinnaista deploy-on-push-toimintoa. Näin repositorion käyttöoikeudet, branch protection ja tuotantoa koskevat odotukset pysyvät linjassa ensimmäisen deploymentin jälkeen.

Aloita varmennettavasta deploymentista

Valitse pieni repositorio, jolla on selkeä start-komento ja health-reitti, ja dokumentoi tarkka target sekä rollback ID ensimmäisen onnistuneen releasen jälkeen.

Aloita ilmaiseksi osoitteessa app.dockup.ai. Free-plan maksaa 0 dollaria kuukaudessa, sisältää 10 dollarin aloitussaldon ja tukee yhtä workspacea, kolmea tietokantaa ja kolmea deploymentia.

FAQ

Voiko Dockup deployata repositorion ilman Dockerfilea?

Kyllä. Kun Dockerfilea ei ole, Dockup käyttää Nixpacksia sovelluksen automaattiseen tunnistamiseen ja buildaamiseen.

Mitä dockup create --link tekee?

Se kirjoittaa nykyiseen hakemistoon .dockup-linkin, jonka avulla myöhemmät komennot voivat ratkaista siihen liittyvän project/service-targetin.

Miksi ensimmäisessä deployssa pitäisi käyttää --wait-valitsinta?

Se pitää komennon liitettynä, kunnes deployment saavuttaa onnistumisen, virheen tai aikakatkaisun, ja palauttaa exit coden, joka kuvaa päätetulosta oikein.

Tulevatko ympäristömuuttujien muutokset voimaan heti?

Eivät. Ne tulevat voimaan seuraavassa deploymentissa uuteen containeriin, joten redeployaa service ympäristökonfiguraation muuttamisen jälkeen.

Miten Dockup palauttaa sovelluksen aiempaan versioon?

Listaa deployment-historia, tunnista tunnettu aiempi deployment ID ja käytä dockup rollbackia kyseisen ID:n ja tarkan service-targetin kanssa.