Dnevnici izgradnje i izvođenja: otklanjanje pogrešaka pri implementaciji na Dockupu

Dnevnici izgradnje i izvođenja odgovaraju na različita pitanja. Dnevnici izgradnje objašnjavaju kako je izvorni kod pretvoren u image i zašto taj proces nije uspio. Dnevnici izvođenja objašnjavaju što je izgrađena aplikacija radila nakon pokretanja containera ili Kubernetes workload-a.

Čitanje pogrešnog streama gubitak je vremena. Nedostajuća ovisnost tijekom izgradnje imagea nikad se neće pojaviti u dnevnicima izvođenja, dok image koji se uspješno izgradi, ali se ruši pri pokretanju, može imati potpuno uredan izlaz izgradnje.

Koja je razlika između dnevnika izgradnje i dnevnika izvođenja?

Za odabir streama koristite fazu implementacije:

Faza	Uobičajeni status	Ispravan dnevnik	Uobičajeni neuspjesi
Kloniranje	cloning	Izgradnja	Pristup repozitoriju, grana
Instalacija ovisnosti	building	Izgradnja	Lockfile, registry, paket
Kompilacija/bundling	building	Izgradnja	Pogreške tipova, memorija, datoteke koje nedostaju
Pokretanje imagea	deploying	Izvođenje i health	Startna naredba, port, dozvole
Pokrenuti servis	running	Izvođenje	Iznimke, nedostupnost ovisnosti
Provjera spremnosti	deploying	Izvođenje i health konfiguracija	Pogrešna putanja, sporo pokretanje

Pročitajte najnoviji izlaz izgradnje:

dockup logs production/api --build --json

Pročitajte izlaz izvođenja iz pokrenutog servisa:

dockup logs production/api --json

Zatražite više redaka izvođenja kada je relevantni događaj stariji:

dockup logs production/api -n 500 --json

JSON odgovor identificira cilj i vrstu dnevnika, što agentu pomaže izbjeći spajanje nepovezanih streamova.

Kako funkcionira dockup logs --build --follow?

Način praćenja streama šalje nove retke anketiranjem trenutačne snimke:

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

U JSON načinu izlaz je NDJSON: jedan objekt po retku i po batchu. Potrošač može obrađivati svaki redak inkrementalno.

Završni batch označava konačni rezultat izgradnje. Naredba se sama zaustavlja kada implementacija uspije ili ne uspije te vraća izlazni kod različit od nule u slučaju neuspjeha. Zbog toga je prikladna za agenta ili CI job bez ručno napisane statusne petlje.

Praćenje izvođenja funkcionira na sličan način:

dockup logs production/api -f --json

Svaki batch uključuje restarted. Kada je restarted:true, container se ponovno pokrenuo ili se zadržani buffer rotirao, pa Dockup ponovno šalje cijelu trenutačnu snimku umjesto da tiho izgubi retke.

Zadani interval anketiranja iznosi 2 sekunde. Opciju --interval koristite samo kada postoji konkretna potreba za promjenom učestalosti.

Kako dijagnosticirati neuspjelu izgradnju?

Započnite konačnim rezultatom implementacije:

dockup deploy production/api --wait --json

Kada naredba završi s deploy_failed, dohvatite dnevnik izgradnje i pronađite prvi uzročni error, a ne posljednju poruku kaskadnog neuspjeha.

Korisni slijed je:

1. Potvrdite cilj i ID implementacije.
2. Odredite fazu kloniranja, instalacije, kompilacije ili imagea.
3. Pronađite prvu pogrešku koja se ne može riješiti ponovnim pokušajem.
4. Usporedite način izgradnje s namjenom repozitorija.
5. Ako je moguće, ponovite postupak iz čistog klona.
6. Napravite jednu ciljanu promjenu.
7. Ponovno implementirajte s opcijom --wait.

Uobičajeni Nixpacks problemi uključuju neprepoznati root projekta, nedostajući lockfile, izostanak uobičajene startne skripte ili potrebu za nativnim paketom. Uobičajeni problemi s Dockerfileom uključuju neispravan build context, artefakt koji nije kopiran, nedostupan base image ili neuspješnu instrukciju RUN.

Vodič Nixpacks vs Dockerfile daje pregled odluka pri odabiru build sustava.

Nemojte popravljati determinističku pogrešku izgradnje povećanjem timeouta od 900 sekundi. Promjena timeouta pomaže legitimno dugoj izgradnji; ne popravlja naredbu koja je završila s pogreškom.

Kako dijagnosticirati rušenje pri izvođenju ili neuspjelu provjeru zdravlja?

Uspješno izgrađen image i dalje može ne uspjeti prije preusmjeravanja prometa. Pregledajte stanje servisa i izlaz izvođenja:

dockup status production/api --json
dockup logs production/api --json
dockup health production/api --json

Obratite pažnju na sljedeće:

• Proces se odmah nakon pokretanja prekida.
• Aplikacija se veže na pogrešan port.
• Aplikacija osluškuje na 127.0.0.1 umjesto na svim sučeljima.
• Nedostaje obavezni environment key.
• Veza s bazom podataka ili Redisom ne uspijeva.
• Dozvole datoteka onemogućuju pokretanje.
• Health putanja vraća status koji označava neuspjeh.
• Pokretanje traje dulje nego što dopušta konfigurirani broj pokušaja.
• Migracija ne uspijeva ili se izvršava istodobno s drugom migracijom.

Health konfiguraciju možete pregledati ili ažurirati:

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

Nemojte oslabiti health gate samo kako bi neispravno izdanje prošlo. Ako pokretanju legitimno treba više vremena, promijenite pravila na temelju dokaza i zadržite endpoint koji i dalje potvrđuje spremnost.

Promjene environmenta zahtijevaju novu implementaciju. Ako popravite tajnu koja je nedostajala, ponovno implementirajte i pričekajte; ponovnim pokretanjem starog containera ne primjenjuje se novi željeni environment.

Kako agenti trebaju parsirati NDJSON bez gubitka izlaznog koda?

Agent ili skripta trebaju čitati svaki JSON redak uz očuvanje statusa procesa. Izbjegavajte prosljeđivanje u naredbu koja skriva izvorni izlazni kod bez pipefail.

set -o pipefail
dockup logs production/api --build -f --json \
  | tee build-stream.ndjson

Uz pipefail, neuspješna Dockup naredba zadržava status koji nije nula za cijeli pipeline, iako je tee uspješno završio.

Potrošač može zasebno pregledati svaki objekt:

while IFS= read -r line; do
  printf '%s\n' "$line" | jq -r '.lines[]?'
done < build-stream.ndjson

Sačuvajte izvorni NDJSON artefakt. Čitljiv izvadak koristan je za pull request ili incident, ali izvorna polja čuvaju oznake ponovnog pokretanja, status i signale završetka.

Opća načela strojnih sučelja objašnjena su u članku Dizajn CLI-ja za AI agente.

Koji je ponovljiv runbook za otklanjanje pogrešaka pri implementaciji?

Koristite ovaj put odlučivanja:

dockup status production/api --json
dockup deployments production/api -n 5 --json
dockup logs production/api --build --json
dockup logs production/api --json

Zatim klasificirajte incident:

Klasifikacija	Dokaz	Sljedeća radnja
Izvorni kod/izgradnja	Pogreška u dnevniku izgradnje	Ispravite repozitorij ili definiciju izgradnje
Konfiguracija	Nedostajući/pogrešni environment ili port	Ispravite konfiguraciju i ponovno implementirajte
Spremnost	Aplikacija radi, health ne uspijeva	Ispravite endpoint ili opravdajte vremenske postavke
Ovisnost pri izvođenju	Iznimka pri povezivanju	Provjerite bazu podataka, mrežu i vjerodajnice
Regresija	Prethodna verzija radila je	Razmotrite rollback na poznati ID
Nesigurnost platforme	Timeout, nema konačnog stanja	Pregledajte status prije novog pokušaja

Vratite prethodnu verziju tek nakon što identificirate poznatu prethodnu implementaciju:

dockup rollback <deploymentId> production/api --json

Najprije sačuvajte ID neuspjele implementacije i dnevnike. Rollback vraća dostupnost servisa; ne objašnjava uzrok problema.

Članak implementacije bez prekida rada objašnjava zašto neuspjela provjera spremnosti može zaštititi produkcijski promet.

Kako produkcijske dnevnike učiniti korisnima?

Dockup može dohvatiti izlaz, ali aplikacija određuje kvalitetu dnevnika. Dajte prednost strukturiranim zapisima s jednim događajem, vremenskim oznakama, razinom ozbiljnosti, ID-ovima zahtjeva ili traceova, nazivom komponente i sigurnim opisom pogreške.

Nikada ne zapisujte access tokene, URL-ove baza podataka, lozinke, pune authorization headere ni osobne podatke koji nisu nužni za rad. Maskiranje tajni u Dockup konfiguraciji ne uklanja proizvoljan izlaz aplikacije.

Zabilježite sigurne činjenice o pokretanju koje se mogu dijagnosticirati:

• Verzija aplikacije ili commit.
• Naziv okruženja.
• Port na kojem aplikacija osluškuje.
• Nazivi uključenih značajki bez vrijednosti tajni.
• Klasa hosta baze podataka, ali ne i lozinka.
• Verzija migracije.
• Spremnost health endpointa.

Predložak vremenske crte incidenta

Zabilježite:

1. ID implementacije i izvorni commit.
2. Vremenske oznake početka implementacije i konačnog rezultata.
3. Prvu uzročnu pogrešku izgradnje ili izvođenja.
4. Rezultat health gatea.
5. Naredbu za oporavak i ID implementacije.
6. Razdoblje utjecaja na korisnike.
7. Osobu zaduženu za daljnje korake.

Podaci o uptimeu daju dostupnost i vrijeme odziva na razini minuta:

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

Rezultat uključuje prosječno vrijeme odziva i p95 vrijeme odziva. Kombinirajte ga s dnevnicima izgradnje i izvođenja kako biste razlikovali incident pri implementaciji od dugotrajnije regresije performansi.

Za trenutačne opcije dnevnika koristite Dockup CLI referencu, a za sigurno zapisivanje dnevnika aplikacije najbolje sigurnosne prakse.

Povežite dnevnike s poviješću implementacija

Redak je koristan samo kada ga je moguće povezati s ispravnim izdanjem. ID implementacije, hash commita i vrijeme pokretanja pohranite uz artefakt dnevnika. Kada se dva izdanja dogode u kratkom razmaku, same vremenske oznake mogu zavarati.

dockup deployments production/api -n 20 --json

Povijest implementacija pokazuje koji je izvorni kod bio aktivan i koje je izdanje doseglo konačno stanje. Agent ne bi trebao pripisati iznimku pri izvođenju najnovijem commitu dok stanje servisa ne potvrdi da je taj commit stvarno implementiran.

Izbjegnite izlaganje tajni kroz dnevnike

Neuspjela veza često navodi developere da ispišu cijeli URL. Umjesto toga zabilježite protokol, maskirani host, naziv baze podataka i kategoriju pogreške. Za tokene zabilježite samo sigurni fingerprint generiran prije pohrane, ako organizacija za to ima pravila.

Pregledajte artefakte neuspjele izgradnje prije dijeljenja izvan tima. Izlaz package managera i Dockera može sadržavati URL-ove privatnih repozitorija, korisnička imena registryja ili argumente naredbi, čak i kada Dockup ispravno maskira pohranjene environment tajne.

Time dnevnici izgradnje i izvođenja postaju dovoljno sigurni za zajedničku dijagnostiku.

Sačuvajte minimalni paket dokaza

Za svako neuspjelo izdanje sačuvajte JSON rezultata implementacije, dnevnik izgradnje, relevantni izvadak dnevnika izvođenja, status servisa i odabrani ID implementacije za oporavak. Taj je paket dovoljno malen za rutinsku upotrebu, a dovoljno potpun da drugi operater može nastaviti bez ponavljanja nesigurnih mutacija.

Potvrdite popravak, a ne samo novu izgradnju

Nakon što ispravljena implementacija uspije, ponovite neuspjeli zahtjev ili uvjet pokretanja i pratite izlaz izvođenja kako biste provjerili pojavljuje li se problem ponovno. Incident zatvorite tek kada izvorni simptom izostane, health gate prođe i očekivano ponašanje u produkciji bude potvrđeno.

Zaokružite postupak

Dokumentirajte potvrđeni popravak.

Započnite implementacijom koju je moguće provjeriti

Namjerno izazovite neuspjeh jedne testne izgradnje, zabilježite njezin NDJSON stream i izlazni kod, a zatim provjerite odabire li vaš runbook dnevnik izgradnje umjesto dnevnika izvođenja.

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

Česta pitanja

Koja je razlika između Dockup dnevnika izgradnje i dnevnika izvođenja?

Dnevnici izgradnje obuhvaćaju kloniranje, instalaciju ovisnosti, kompilaciju i izradu imagea. Dnevnici izvođenja obuhvaćaju pokrenuti aplikacijski container ili podove.

Kako mogu pratiti Dockup dnevnike izgradnje uživo?

Koristite dockup logs s opcijama --build i --follow ili -f. Uz --json naredba emitira NDJSON batcheve i završava kada implementacija dosegne konačno stanje.

Zašto praćenje izgradnje završava s izlaznim kodom različitim od nule?

Ono čuva rezultat implementacije. Neuspjela izgradnja mora uzrokovati neuspjeh pozivajuće shell sesije, CI joba ili zadatka agenta, umjesto da izgleda kao uspješan stream dnevnika.

Što znači restarted:true u izlazu praćenja izvođenja?

Označava da se container ponovno pokrenuo ili da se zadržani buffer rotirao, pa je Dockup ponovno emitirao trenutačnu snimku umjesto da tiho izgubi retke.

Trebaju li dnevnici aplikacije sadržavati environment tajne?

Ne. Dockup maskira čitanja pohranjene konfiguracije, ali proizvoljne tajne koje aplikacija ispiše ne može učiniti sigurnima. Vjerodajnice maskirajte na razini zapisivanja dnevnika aplikacije.