Nasazení uvízlé ve frontě: co zkontrolovat jako první

Nasazení uvízlé ve frontě patří mezi nejméně informativní chyby, které vám platforma může zobrazit. Nic nespadlo. Neobjevily se žádné logy, protože se nic nespustilo. Vydání tam jednoduše zůstává a při každém obnovení se zobrazí stejné slovo.

Frustrující je, že „ve frontě“ může označovat nejméně čtyři různé situace, které spolu vůbec nesouvisejí. Zjistit, ve které z nich jste, zabere asi třicet sekund — a podle toho poznáte, jestli máte čekat, zkusit to znovu, nebo hledat problém úplně jinde.

Co „ve frontě“ skutečně znamená

Nasazení ve frontě bylo přijato a zaznamenáno, ale zatím mu nebyl přidělen worker. Mezi těmito dvěma okamžiky musí platit několik věcí:

• Platforma musí načíst váš zdrojový kód, což obvykle znamená API call na vašeho Git providera.
• Musí být k dispozici volný build slot.
• Musí být dokončena každá podmínka, na které vydání závisí — migrační krok, operace s volume nebo předchozí nasazení stejné služby.

Pokud je některá z těchto věcí zablokovaná, záznam existuje, ale práce se nespustí. To je celý mechanismus. Není na něm nic záhadného, ale většina dashboardů vykresluje všechny čtyři případy stejným slovem.

Čtyři případy v pořadí, v jakém se je vyplatí kontrolovat

1. Váš Git provider má špatný den

Tohle je nejčastější příčina a zároveň ta, se kterou nemůžete nic dělat. Platforma si vyžádala váš repozitář a dostala pomalou odpověď nebo chybu. Pokud se ve stejnou dobu zařadí do fronty několik nesouvisejících služeb a žádná z nich nesdílí kód, je společnou závislostí právě provider.

Nejdřív zkontrolujte jeho status page. Nasazení, které čeká na upstream API, se samo uvolní a opakované spuštění pouze přidá další záznam na hromadu — proto se uvízlá fronta tak často promění v pět uvízlých front.

2. Něco před ním ještě neskončilo

Většina platforem serializuje nasazení pro jednotlivé služby, a dává to smysl: dva buildy zapisující stejný image tag nejsou závod, který chcete vyhrát. Pokud stále běží dřívější nasazení dané služby — nebo ještě hůř, systém se pouze domnívá, že běží, protože worker zemřel bez ohlášení — další nasazení čeká.

Na Dockupu vypíše dockup deployments historii od nejnovějšího záznamu a u každé položky její stav. Pokud nasazení nad vaším vydáním ve frontě není v koncovém stavu, máte odpověď. Zrušení nebo vypršení jeho časového limitu uvolní frontu.

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

Výstup --json obsahuje stav a délku každého nasazení, takže je z něj „předchozí nasazení nikdy neskončilo“ zřejmé způsobem, kterého se se spinnerem nedočkáte.

3. Není kapacita

Každá platforma má omezený počet build workerů. Na sdíleném tarifu vás může příval aktivity napříč platformou zařadit za buildy ostatních uživatelů. Je to skutečný stav, obvykle krátkodobý, a právě v tomto případě je čekání opravdu správným řešením.

Důležité je, jestli to můžete vidět. Pozice ve frontě nebo odhad čekání promění zážitek připomínající výpadek v běžnou situaci. Samotné „ve frontě“ ale nestačí.

4. Nasazení se nikdy nemělo spustit

Nepříjemný případ: záznam byl vytvořen, ale proces, který ho měl převzít, se nikdy nespustil. Worker spadl, webhook se ztratil nebo token mezi spuštěním a načtením vypršel.

Rozhodující je čas. Čekání ve frontě se počítá na sekundy až několik minut. Nasazení, které je deset minut ve frontě a před ním není žádné jiné vydání, nečeká — je uvízlé a také uvízlé zůstane.

Jak odlišit čekání od zamrznutí

Než to zkusíte znovu, zjistěte tři skutečnosti:

1. Probíhá nějaké jiné nasazení? Pokud běží jiné vydání stejné služby, jste v případě 2 a měli byste ho nechat být.
2. Jak dlouho je nasazení ve frontě? Méně než dvě minuty je normální. Více než deset minut ne.
3. Zařadily se ve stejnou dobu do fronty i jiné služby? Pokud se všechny nesouvisející služby zastavily naráz, hledejte problém upstream, ne ve svém kódu.

Tyto tři odpovědi téměř pokaždé rozliší, jestli máte čekat, nebo jednat.

Proč opakované spuštění situaci obvykle zhorší

Při uvízlém vydání je přirozené znovu stisknout tlačítko deploy. U serializované pipeline je to kontraproduktivní: přidáte druhý záznam za první, a pokud je první skutečně uvízlý, druhý zdědí stejnou blokaci. Vývojáři, kteří na tento problém narazí, často skončí se sloupcem položek ve frontě, z nichž se žádná nespustí, dokud se neuvolní první v pořadí.

Pokud to chcete zkusit znovu, nejdřív uvízlé nasazení zrušte. Jedno nasazení ve frontě, které viditelně selže, je mnohem užitečnější než pět nasazení, která tam jen čekají.

Jak to řešíme na Dockupu

Důležité konstrukční rozhodnutí je, že nasazení nikdy není pouze považováno za běžící. Každé má koncový stav a právě jeho dosažení uvolní frontu. Build, který skončí bez ohlášení, po vypršení časového limitu také uvolní službu.

Pomáhají i dvě další věci, které mají větší význam, než se může zdát:

Stages mají názvy. Nasazení v Dockupu prochází načtením zdroje, buildem a health gate; každá stage si zaznamenává vlastní délku. Když je něco pomalé, vidíte, co je pomalé, místo abyste sledovali jedno slovo. stageTimings je v každém záznamu nasazení, včetně výstupu --json.

Za vydáním, které už selhalo, se nic nezařadí do fronty. Pokud health check nikdy neprojde, nasazení skončí — nezůstane zabírat službu, zatímco přemýšlíte, co se děje. Předchozí verze po celou dobu dál obsluhuje traffic, což je druhá část důvodu, proč uvízlé vydání na Dockupu neznamená výpadek.

# 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

Obecné pravidlo

Zařazení do fronty není samo o sobě chybový stav. Chybovým stavem je zařazení do fronty bez vysvětlení. Každá platforma vás občas nechá čekat na Git providera nebo volný build slot; rozdíl mezi pětiminutovým zdržením a promarněným odpolednem spočívá v tom, jestli vám rozhraní řekne, ve kterém ze čtyř případů se nacházíte.

Když zvažujete, kde něco provozovat, stojí za to si to záměrně ověřit: spusťte deploy a sledujte, co vám platforma zobrazí mezi jeho přijetím a spuštěním. Pokud je odpovědí jediné slovo bez časového údaje, dříve nebo později nad tím strávíte celé odpoledne.

Často kladené otázky

Jak dlouho by mělo nasazení zůstat ve frontě? Na zdravé platformě několik sekund až pár minut. Cokoli delšího než deset minut bez další položky před ním považujte spíš za uvízlé než pomalé.

Mám nasazení ve frontě spustit znovu? Nejdřív ho zrušte. V serializované pipeline se opakované spuštění zařadí za uvízlé nasazení a zdědí stejnou blokaci.

Způsobí uvízlé nasazení výpadek mého webu? Nemělo by. Na platformě, která přepíná traffic až poté, co nové vydání projde health checkem, běžící verze po celou dobu dál obsluhuje požadavky — nasazení ve frontě nebo neúspěšné nasazení je vydání, ke kterému nikdy nedošlo, nikoli výpadek.

Proč se několik služeb zařadí do fronty najednou? Protože sdílejí závislost. Téměř vždy jde o Git providera nebo build fleet, nikoli o něco ve vašem kódu.