Queued állapotban elakadt deployment: mit ellenőrizz először?

A queued állapotban elakadt deployment az egyik legkevésbé informatív hiba, amit egy platform jelezhet. Semmi sem omlott össze. Logok sem jelentek meg, mert semmi sem futott le. A release egyszerűen ott marad, és minden frissítés ugyanazt az egy szót mutatja.

A frusztráló része, hogy a „queued” legalább négy különböző helyzetet takarhat, amelyeknek semmi közük egymáshoz. Annak megállapítása, hogy melyikről van szó, körülbelül harminc másodpercet vesz igénybe — és eldönti, hogy várnod kell, újra kell próbálkoznod, vagy valami egészen mást kell ellenőrizned.

Mit jelent valójában a „queued”?

Egy queued deploymentet a rendszer elfogadott és rögzített, de még nem kapott workert. A két pillanat között több feltételnek is teljesülnie kell:

• A platformnak le kell kérnie a forráskódot, ami általában egy API-hívást jelent a Git-szolgáltatód felé.
• Szabad build slotnak kell rendelkezésre állnia.
• A release minden előfeltételének teljesülnie kell — például egy migration lépésnek, egy volume-műveletnek vagy ugyanazon service egy korábbi deploymentjének.

Ha ezek közül bármi blokkolva van, a rekord létrejön, de a munka nem indul el. Ennyi az egész folyamat. Nem rejtély, a legtöbb dashboard mégis mind a négy esetet ugyanazzal az egy szóval jeleníti meg.

A négy eset, az ellenőrzés ajánlott sorrendjében

1. A Git-szolgáltatódnak éppen rossz napja van

Ez a leggyakoribb ok, és az, amivel nem tudsz mit kezdeni. A platform lekérte a repositorydat, de lassú választ vagy hibát kapott. Ha több, egymástól független service kerül egyszerre queue-ba, és nincs közös kódjuk, akkor a közös dependency a szolgáltató.

Mielőtt bármi mást tennél, ellenőrizd a szolgáltatód status page-ét. Egy upstream API-ra váró deploy magától rendeződik, az újrapróbálás pedig csak újabb rekordot tesz a sorba — ezért lesz egy elakadt queue-ból olyan gyakran öt elakadt queue.

2. Valami előtte még nem fejeződött be

A legtöbb platform service-enként sorba rendezi a deploymenteket, és ez helyes is: két build, amely ugyanabba az image tagbe ír, nem olyan race condition, amit meg akarsz nyerni. Ha az adott service egy korábbi deploymentje még fut — vagy ami még rosszabb, csak a rendszer úgy hiszi, hogy fut, mert egy worker jelentés nélkül leállt —, akkor a következő várakozik.

A Dockupon a dockup deployments a legújabbal kezdve listázza az előzményeket, minden bejegyzésnél feltüntetve annak statusát. Ha a queued release-ed feletti bejegyzés még nincs terminális állapotban, akkor megvan a válasz: a sor feloldásához le kell állítanod, vagy meg kell várnod, amíg timeoutol.

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

A --json kimenet minden deployment statusát és időtartamát tartalmazza, így a „az előző sosem fejeződött be” helyzet sokkal egyértelműbb, mint egy spinnerből.

3. Nincs kapacitás

Minden platformon véges számú build worker áll rendelkezésre. Egy shared tieren a platform egészét érintő aktivitási hullám miatt mások buildjei mögé kerülhetsz. Ez valós probléma, általában rövid ideig tart, és ez az az eset, amikor valóban a várakozás a helyes lépés.

Itt az számít, hogy látod-e, mi történik. A queue pozíciója vagy a várható várakozási idő egy kieséshez hasonló élményt normális működéssé változtat. Egy önmagában megjelenő „queued” viszont nem.

4. A deployment valójában sosem indult volna el

A kellemetlen eset: a rekord létrejött, de az a folyamat, amelynek fel kellett volna vennie, sosem tette meg. Egy worker összeomlott, egy webhook elveszett, vagy egy token lejárt a trigger és a fetch között.

Az árulkodó jel az idő. A queue-ban töltött várakozási idő másodpercekben vagy legfeljebb néhány percben mérhető. Egy olyan deployment, amely tíz perce queued állapotban van, miközben nincs előtte másik release, nem várakozik — hanem elakadt, és úgy is marad.

Hogyan különböztesd meg a várakozást a lefagyástól?

Mielőtt újrapróbálnád, gyűjts össze három információt:

1. Fut éppen másik deployment? Ha ugyanazon service másik release-e fut, akkor a 2. esetről van szó, és érdemes békén hagynod.
2. Mióta van queued állapotban? Két perc alatt ez normális. Tíz perc felett már nem.
3. Más service-ek is ugyanakkor kerültek queue-ba? Ha egymástól független service-ek egyszerre álltak le, akkor upstream irányban keresd a problémát, ne a kódodban.

Ez a három válasz szinte minden esetben elválasztja egymástól a „várj” és a „cselekedj” helyzeteket.

Miért ront általában a helyzeten az újrapróbálás?

Elakadt release esetén ösztönösen újra megnyomod a deploy gombot. Serializált pipeline-ban ez kontraproduktív: egy második rekordot teszel az első mögé, és ha az első valóban elakadt, a második is örökli a blokkolást. Az ezt megtapasztaló fejlesztők gyakran egy egész oszlopnyi queued bejegyzésnél kötnek ki, amelyek közül egyik sem fut le, amíg a sor eleje fel nem oldódik.

Ha újra szeretnéd próbálni, előbb állítsd le az elakadt példányt. Egy queued deployment, amely láthatóan hibával leáll, sokkal hasznosabb, mint öt olyan, amely csak várakozik.

Hogyan kezeljük ezt a Dockupon?

Itt az a fontos tervezési döntés, hogy egy deploymentről soha nem csak feltételezzük, hogy fut. Mindegyiknek van terminális állapota, és a sor felszabadítását ez biztosítja. Egy jelentés nélkül leálló build is timeoutol, és felszabadítja a service-t.

Két másik megoldás is többet segít, mint elsőre gondolnád:

A stage-ek el vannak nevezve. Egy Dockup deployment a source fetch, a build és a health gate szakaszain halad végig, és minden stage rögzíti a saját időtartamát. Ha valami lassú, láthatod, melyik lépés lassú, ahelyett hogy egyetlen szót figyelnél. A stageTimings minden deployment rekordon szerepel, a --json kimenetben is.

Egy már hibával leállt release mögé semmi sem kerül queue-ba. Ha a health check nem teljesül, a deployment véget ér — nem foglalja tovább a service-t, miközben te csak találgatsz. Az előző verzió ezalatt végig kiszolgálja a forgalmat, és részben ez az oka annak is, hogy egy elakadt release nem jelent kiesést a Dockupon.

# 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

Az általános szabály

A queueing önmagában nem hibamód. Az az, ha a queueinghez nem tartozik magyarázat. Bármelyik platformon előfordulhat, hogy várnod kell egy Git-szolgáltatóra vagy egy build slotra; az ötperces bosszúság és az egész délutánt felemésztő probléma közötti különbség az, hogy az interfész megmutatja-e, a négy eset közül melyikről van szó.

Amikor azt mérlegeled, hol futtass valamit, ezt érdemes tudatosan ellenőrizni: indíts egy deployt, és nézd meg, mit mutat a platform az elfogadás és az indítás közötti időben. Ha a válasz egyetlen szó, timestamp nélkül, előbb-utóbb egy egész délutánt fogsz erre áldozni.

Gyakran ismételt kérdések

Mennyi ideig maradhat egy deployment queued állapotban? Egészséges platformon néhány másodpercig vagy legfeljebb néhány percig. Ha tíz percnél tovább tart, és nincs előtte másik deployment, akkor lassú helyett inkább elakadtként kezeld.

Újrapróbáljam a queued deploymentet? Csak azután, hogy leállítottad. Serializált pipeline-ban az újrapróbált deployment az elakadt mögé kerül queue-ba, és ugyanazt a blokkolást örökli.

Leállhat az oldalam egy elakadt deployment miatt? Nem kellene. Egy olyan platformon, amely csak azután vált forgalmat, hogy az új release átment a health checken, a futó verzió végig kiszolgálja a forgalmat — egy queued vagy hibás deploy olyan release, amely sosem történt meg, nem pedig kiesés.

Miért kerül egyszerre több service is queue-ba? Mert közös dependencyn osztoznak, és ez szinte mindig a Git-szolgáltató vagy a build fleet, nem pedig a kódod.