Deployment zaglavljen u redu čekanja: što prvo provjeriti

Deployment zaglavljen u redu čekanja jedan je od najmanje informativnih kvarova koje vam platforma može prikazati. Ništa se nije srušilo. Nema logova jer se ništa nije pokrenulo. Release jednostavno stoji, a pri svakom osvježavanju prikazuje se ista riječ.

Frustrirajuće je to što "queued" obuhvaća najmanje četiri različite situacije koje međusobno nemaju nikakve veze. Utvrditi u kojoj se nalazite traje otprilike trideset sekundi, a o tome ovisi trebate li čekati, pokušati ponovno ili potražiti problem negdje sasvim drugdje.

Što "queued" zapravo znači

Queued deployment je prihvaćen i zabilježen, ali još nije dobio workera. Između ta dva trenutka mora biti ispunjeno nekoliko uvjeta:

• Platforma mora dohvatiti vaš source, što obično znači API poziv prema vašem Git provideru.
• Build slot mora biti slobodan.
• Svaki preduvjet u releaseu mora biti dovršen — migration korak, operacija nad volumeom ili raniji deployment istog servisa.

Ako je bilo što od toga blokirano, zapis postoji, ali se posao ne pokreće. To je cijeli mehanizam. Nije riječ o misteriju, ali većina dashboarda sva četiri slučaja prikazuje istom riječju.

Četiri slučaja, redoslijedom kojim ih vrijedi provjeriti

1. Vaš Git provider ima loš dan

To je najčešći uzrok i onaj na koji ne možete utjecati. Platforma je zatražila vaš repository, ali je dobila spor odgovor ili grešku. Ako se više nepovezanih servisa istodobno nađe u redu čekanja, a nijedan ne dijeli code, zajednička je dependency upravo provider.

Prije svega provjerite statusnu stranicu providera. Deploy koji čeka upstream API sam će se riješiti, a ponovni pokušaj samo dodaje još jedan zapis na hrpu — zato se zaglavljeni queue tako često pretvori u pet zaglavljenih queueova.

2. Nešto ispred njega još nije dovršeno

Većina platformi serijalizira deployment po servisu, i to s dobrim razlogom: dva builda koja zapisuju isti image tag nisu race koju želite dobiti. Ako se raniji deployment tog servisa još uvijek izvodi — ili, još gore, samo se smatra aktivnim jer je worker prestao raditi bez slanja statusa — sljedeći čeka.

Na Dockupu, dockup deployments prikazuje povijest, od najnovijih zapisa prema starijima, sa statusom svakog unosa. Ako deployment iznad vašeg queued releasea nije u završnom statusu, to je vaš odgovor, a otkazivanje ili čekanje da istekne timeout odblokirat će red.

dockup deployments my-project/my-api --json

Izlaz s opcijom --json sadrži status i trajanje svakog deploymenta, pa je "prethodni nikad nije završio" očito na način na koji spinner to ne može prikazati.

3. Nema kapaciteta

Svaka platforma ima konačan broj build workera. Na shared tieru nagli porast aktivnosti na platformi može vas staviti iza buildova drugih korisnika. To je stvaran problem, obično kratko traje i jedini je slučaj u kojem je čekanje doista pravi potez.

Ovdje je važno možete li to vidjeti. Pozicija u redu ili procjena vremena čekanja iskustvo koje nalikuje ispadu pretvara u normalnu situaciju. Samo "queued" ne daje tu informaciju.

4. Deployment se nikad nije trebao pokrenuti

Neugodniji slučaj: zapis je kreiran, ali stvar koja ga je trebala preuzeti to nikad nije učinila. Worker se srušio, webhook je izgubljen ili je token istekao između triggera i dohvata.

Ključan je pokazatelj vrijeme. Čekanje u redu traje od nekoliko sekundi do nekoliko minuta. Deployment koji je queued deset minuta, a ispred sebe nema nijedan drugi release, ne čeka — zaglavio je i tako će ostati.

Kako razlikovati čekanje od zaglavljivanja

Prije ponovnog pokušaja prikupite tri podatka:

1. Deploya li se još nešto? Ako se izvodi drugi release istog servisa, nalazite se u 2. slučaju i trebali biste ga ostaviti na miru.
2. Koliko je dugo u redu čekanja? Manje od dvije minute je normalno. Više od deset nije.
3. Jesu li se drugi servisi našli u redu čekanja u isto vrijeme? Ako su se nepovezani servisi odjednom zaustavili, tražite problem upstream, a ne u svom codeu.

Ta tri odgovora gotovo uvijek razdvajaju situaciju u kojoj treba čekati od one u kojoj treba djelovati.

Zašto ponovni pokušaj obično pogorša situaciju

Kod zaglavljenog releasea prirodno je ponovno pritisnuti deploy. Na serijaliziranom pipelineu to je kontraproduktivno: dodajete drugi zapis iza prvoga, a ako je prvi doista zaglavljen, drugi nasljeđuje istu blokadu. Developeri koji naiđu na ovaj problem često završe sa stupcem queued zapisa, od kojih se nijedan neće pokrenuti dok se prvi u redu ne riješi.

Ako ćete pokušati ponovno, najprije otkažite zaglavljeni deployment. Jedan queued deployment koji vidljivo ne uspije mnogo je korisniji od pet deploymenta koji samo stoje.

Kako to rješavamo na Dockupu

Ključna dizajnerska odluka ovdje jest da se za deployment nikad samo ne pretpostavlja da se izvodi. Svaki deployment ima završni status, a upravo njegovo postizanje oslobađa red. Build koji se ugasi bez slanja statusa i dalje će dosegnuti timeout te osloboditi servis.

Još dvije stvari pomažu više nego što se na prvi pogled čini:

Stageovi imaju nazive. Dockup deployment prolazi kroz dohvat sourcea, build i health gate, a svaki stage bilježi vlastito trajanje. Kad je nešto sporo, možete vidjeti što je sporo umjesto da gledate jednu riječ. stageTimings nalazi se u svakom deployment recordu, uključujući i izlaz opcije --json.

Iza releasea koji je već neuspješan ništa ne ostaje u redu. Ako health check nikad ne prođe, deployment završava — ne ostaje zauzimati servis dok se pitate što se događa. Prethodna verzija cijelo vrijeme nastavlja posluživati promet, što je drugi razlog zbog kojeg zaglavljeni release na Dockupu nije outage.

# What is the current state, and how long has each stage taken?
dockup status my-project/my-api --json

# Follow the build as it happens rather than waiting for a summary
dockup logs my-project/my-api --build --follow

Opće pravilo

Čekanje u redu nije način kvara. Čekanje u redu bez objašnjenja jest. Svaka će vas platforma povremeno natjerati da čekate Git provider ili build slot; razlika između petominutne gnjavaže i izgubljenog poslijepodneva jest u tome govori li vam sučelje u kojem se od četiri slučaja nalazite.

Kad procjenjujete gdje pokrenuti neku aplikaciju, to vrijedi namjerno provjeriti: pokrenite deploy i pogledajte što vam platforma prikazuje između prihvaćanja deploymenta i njegova pokretanja. Ako je odgovor jedna riječ bez timestampova, prije ili kasnije potrošit ćete cijelo poslijepodne na ovaj problem.

Često postavljana pitanja

Koliko dugo deployment treba ostati u redu čekanja? Nekoliko sekundi do nekoliko minuta na zdravoj platformi. Sve što traje dulje od deset minuta, a ispred nema ničega, treba smatrati zaglavljenim, a ne samo sporim.

Trebam li ponovno pokrenuti queued deployment? Ne prije nego što ga otkažete. Na serijaliziranom pipelineu ponovni pokušaj stavlja se iza zaglavljenog deploymenta i nasljeđuje istu blokadu.

Hoće li mi zaglavljeni deployment srušiti web-stranicu? Ne bi trebao. Na platformi koja prebacuje promet tek nakon što novi release prođe health check, pokrenuta verzija cijelo vrijeme nastavlja posluživati promet — queued ili neuspjeli deploy release je koji se nikad nije dogodio, a ne outage.

Zašto se više servisa istodobno nađe u redu čekanja? Zato što dijele dependency, a to je gotovo uvijek Git provider ili build fleet, a ne nešto u vašem codeu.