Deployment uviaznutý v stave queued: čo skontrolovať ako prvé

Deployment uviaznutý v stave queued patrí medzi najmenej informatívne zlyhania, aké vám platforma môže zobraziť. Nič nespadlo. Neobjavili sa žiadne logy, pretože sa nič nespustilo. Release tam jednoducho zostáva a pri každom obnovení stránky vidíte to isté slovo.

Frustrujúce je, že „queued“ môže označovať najmenej štyri rôzne situácie, ktoré spolu vôbec nesúvisia. Zistiť, v ktorej z nich sa nachádzate, trvá približne tridsať sekúnd — a podľa toho sa rozhodnete, či máte počkať, skúsiť to znova alebo hľadať problém úplne inde.

Čo „queued“ v skutočnosti znamená

Deployment v stave queued bol prijatý a zaznamenaný, ale zatiaľ mu nebol pridelený worker. Medzi týmito dvoma okamihmi musí platiť niekoľko vecí:

• Platforma musí načítať váš source, čo zvyčajne znamená API call na vášho Git providera.
• Musí byť voľný build slot.
• Musí byť dokončený každý prerequisite v release — migračný krok, operácia s volume alebo skorší deployment tej istej služby.

Ak je niektorá z týchto vecí zablokovaná, záznam existuje, ale práca sa nespustí. To je celý mechanizmus. Nie je na ňom nič záhadné, no väčšina dashboardov zobrazuje všetky štyri prípady rovnakým slovom.

Štyri prípady v poradí, v akom sa ich oplatí kontrolovať

1. Váš Git provider má zlý deň

Toto je najčastejšia príčina a zároveň tá, s ktorou nemôžete nič urobiť. Platforma si vyžiadala váš repository a dostala pomalú odpoveď alebo chybu. Ak sa v rovnakom čase zaradia do queue viaceré nesúvisiace služby a nezdieľajú žiadny kód, spoločnou závislosťou je provider.

Najprv skontrolujte status page svojho providera. Deploy, ktorý čaká na upstream API, sa dokončí sám a opakované spúšťanie iba pridá ďalší záznam do hromady — preto sa uviaznutý queue tak často zmení na päť uviaznutých queueov.

2. Niečo pred ním ešte nebolo dokončené

Väčšina platforiem serializuje deploymenty pre jednotlivé služby, a je to tak správne: dva buildy zapisujúce rovnaký image tag nie sú race, ktorú chcete vyhrať. Ak skorší deployment tejto služby stále beží — alebo si platforma ešte horšie myslí, že beží, pretože worker skončil bez odoslania informácie — ďalší deployment čaká.

V Dockup príkaz dockup deployments zobrazí históriu od najnovšieho záznamu a pri každom uvedie jeho status. Ak deployment nad vaším queued release nie je v terminálnom stave, máte odpoveď. Zrušenie alebo vypršanie jeho timeoutu uvoľní front.

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

Výstup --json obsahuje status a trvanie každého deploymentu, takže „predchádzajúci sa nikdy nedokončil“ je zrejmé spôsobom, akým to spinner nedokáže ukázať.

3. Nedostatok kapacity

Každá platforma má konečný počet build workerov. Na zdieľanom tieri vás môže nápor aktivity na celej platforme zaradiť za buildy iných používateľov. Je to reálny problém, zvyčajne krátkodobý, a práve v tomto prípade je čakanie skutočne správnym riešením.

Dôležité je, či to dokážete vidieť. Pozícia v queue alebo odhad času čakania zmení zážitok podobný výpadku na normálnu situáciu. Samotné „queued“ však nie.

4. Deployment sa nikdy nemal spustiť

Nepríjemný prípad: záznam bol vytvorený, ale proces, ktorý ho mal prevziať, sa nikdy nespustil. Worker spadol, webhook sa stratil alebo token vypršal medzi triggerom a načítaním zdroja.

Rozhodujúci je čas. Čakanie v queue sa meria v sekundách až niekoľkých minútach. Deployment, ktorý je v queue desať minút a pred ním nie je žiadny iný release, nečaká — je uviaznutý a uviaznutý aj zostane.

Ako rozlíšiť čakanie od zaseknutia

Pred opakovaným spustením si zistite tri skutočnosti:

1. Deployuje sa ešte niečo? Ak beží iný release tej istej služby, ide o prípad 2 a mali by ste ho nechať tak.
2. Ako dlho je v queue? Menej ako dve minúty je bežné. Viac ako desať nie.
3. Zaradili sa do queue v rovnakom čase aj iné služby? Ak sa všetky nesúvisiace služby zastavili naraz, hľadajte problém upstream, nie vo svojom kóde.

Tieto tri odpovede takmer vždy rozlíšia, či máte „čakať“, alebo „konať“.

Prečo opakované spúšťanie zvyčajne situáciu zhorší

Pri uviaznutom release je prirodzenou reakciou stlačiť deploy znova. Na serializovanom pipeline je to kontraproduktívne: pridáte druhý záznam za prvý, a ak je prvý skutočne uviaznutý, druhý zdedí rovnakú blokáciu. Developeri, ktorí na tento problém narazia, často skončia so stĺpcom queued záznamov, z ktorých sa nespustí ani jeden, kým sa neuvoľní začiatok frontu.

Ak chcete deploy spustiť znova, najprv zrušte uviaznutý záznam. Jeden queued deployment, ktorý viditeľne zlyhá, je oveľa užitočnejší než päť záznamov, ktoré iba čakajú.

Ako to riešime v Dockup

Dôležité je rozhodnutie v návrhu: deployment nikdy nie je iba považovaný za spustený. Každý má terminálny stav a jeho dosiahnutie uvoľní front. Build, ktorý skončí bez odoslania informácie, tiež vyprší a uvoľní službu.

Pomáhajú aj dve ďalšie veci, ktoré sú užitočnejšie, než sa na prvý pohľad zdá:

Stages majú názvy. Deployment v Dockup prechádza cez načítanie source, build a health gate, pričom každý stage zaznamenáva vlastné trvanie. Keď je niečo pomalé, vidíte, čo je pomalé, namiesto sledovania jediného slova. stageTimings je súčasťou každého záznamu deploymentu vrátane výstupu cez --json.

Za release, ktorý už zlyhal, sa nič nezaraďuje do queue. Ak health check nikdy neprejde, deployment sa ukončí — nezostane blokovať službu, kým premýšľate, čo sa deje. Predchádzajúca verzia počas celého času naďalej obsluhuje traffic, čo je druhá polovica dôvodu, prečo uviaznutý release v Dockup neznamená výpadok.

# 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

Všeobecné pravidlo

Queueing nie je failure mode. Queueing bez priradeného dôvodu ním však je. Každá platforma vás občas nechá čakať na Git providera alebo build slot; rozdiel medzi päťminútovým zdržiavaním a premárneným popoludním spočíva v tom, či vám rozhranie povie, v ktorom zo štyroch prípadov sa nachádzate.

Pri výbere platformy, na ktorej niečo spustíte, sa to oplatí cielene overiť: spustite deploy a sledujte, čo vám platforma zobrazí medzi jeho prijatím a spustením. Ak je odpoveďou jediné slovo bez timestampu, skôr či neskôr na tom strávite celé popoludnie.

Často kladené otázky

Ako dlho by mal deployment zostať v stave queued? Na zdravej platforme niekoľko sekúnd až pár minút. Čokoľvek dlhšie než desať minút bez záznamu pred ním považujte skôr za uviaznutie než za pomalé spracovanie.

Mám queued deployment spustiť znova? Nie skôr, než ho zrušíte. Na serializovanom pipeline sa retry zaradí za uviaznutý deployment a zdedí rovnakú blokáciu.

Vyradí uviaznutý deployment moju stránku? Nemal by. Na platforme, ktorá prepína traffic až po úspešnom health checku nového release, bežiaca verzia obsluhuje traffic po celý čas — queued alebo neúspešný deploy je release, ktorý sa nikdy neuskutočnil, nie výpadok.

Prečo sa viacero služieb zaradí do queue naraz? Pretože zdieľajú závislosť, ktorou je takmer vždy Git provider alebo build fleet, nie niečo vo vašom kóde.