Käyttöönotto juuttui queued-tilaan: tarkista nämä ensin

Queued-tilaan juuttunut käyttöönotto on yksi vähiten tietoa antavista virhetilanteista, joita alusta voi näyttää. Mikään ei ole kaatunut. Lokeja ei ole ilmestynyt, koska mitään ei ole suoritettu. Julkaisu vain pysyy paikallaan, ja jokainen päivitys näyttää saman sanan.

Turhauttavaa on se, että ”queued” kattaa vähintään neljä eri tilannetta, joilla ei ole mitään tekemistä toistensa kanssa. Sen selvittäminen, missä tilanteessa olet, vie noin kolmekymmentä sekuntia. Samalla selviää, pitäisikö odottaa, yrittää uudelleen vai etsiä syytä kokonaan muualta.

Mitä ”queued” oikeasti tarkoittaa

Jonoon asetettu käyttöönotto on hyväksytty ja tallennettu, mutta sille ei ole vielä annettu workeria. Näiden kahden hetken välillä muutaman asian täytyy toteutua:

• Alustan on haettava lähdekoodisi, mikä tarkoittaa yleensä API-kutsua Git-palveluntarjoajallesi.
• Build-paikan on oltava vapaana.
• Kaikkien julkaisun edellytysten on oltava valmiina — esimerkiksi migration-vaiheen, volume-operaation tai saman servicen aiemman käyttöönoton.

Jos jokin näistä on estynyt, tietue on olemassa, mutta työ ei ala. Siinä koko mekanismi. Kyse ei ole mysteeristä, mutta useimmat dashboardit näyttävät kaikki neljä tapausta samalla sanalla.

Neljä tapausta siinä järjestyksessä, jossa ne kannattaa tarkistaa

1. Git-palveluntarjoajallasi on huono päivä

Tämä on yleisin syy, etkä voi itse tehdä sille mitään. Alusta pyysi repositoryasi ja sai hitaasti vastaavan tai virheen palauttavan vastauksen. Jos useat toisistaan riippumattomat servicet joutuvat jonoon samaan aikaan eivätkä jaa koodia, yhteinen riippuvuus on palveluntarjoaja.

Tarkista palveluntarjoajasi status-sivu ennen mitään muuta. Ylemmän tason APIa odottava deploy menee ohi itsestään, ja uudelleen yrittäminen lisää vain uuden tietueen kasaan — minkä vuoksi juuttunut jono muuttuu niin usein viideksi juuttuneeksi jonoksi.

2. Jokin sen edellä ei ole valmis

Useimmat alustat suorittavat deployt sarjassa servicen sisällä, ja hyvästä syystä: kahden buildin kirjoittaminen samaan image tagiin ei ole kilpailutilanne, jonka haluat voittaa. Jos servicen aiempi deployment on edelleen käynnissä — tai pahempaa, sen uskotaan yhä olevan käynnissä, koska worker kaatui ilmoittamatta — seuraava odottaa.

Dockupissa dockup deployments listaa historian uusimmat ensin ja näyttää jokaisen merkinnän statuksen. Jos queued-julkaisusi yläpuolella oleva merkintä ei ole päättävässä tilassa, siinä on vastauksesi. Jonon vapauttaa kyseisen ajon peruuttaminen tai sen aikakatkaisun odottaminen.

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

--json-tuloste sisältää kunkin deploymentin statuksen ja keston, joten ”edellinen ei koskaan valmistunut” käy ilmi tavalla, jota spinner ei pysty osoittamaan.

3. Kapasiteettia ei ole

Jokaisella alustalla on rajallinen määrä build-workereita. Jaetulla tasolla koko alustan vilkas toiminta voi asettaa sinut muiden buildien taakse. Tämä on todellinen tilanne, joka kestää yleensä vain hetken, ja tässä tapauksessa odottaminen on aidosti oikea ratkaisu.

Oleellista on, näetkö tämän tilanteen. Jonon sijainti tai arvio odotusajasta muuttaa katkosta muistuttavan kokemuksen normaaliksi toiminnaksi. Pelkkä ”queued” ei tee niin.

4. Deployment ei olisi koskaan alkanutkaan

Ikävä tapaus: tietue luotiin, mutta sitä käsitteleväksi tarkoitettu komponentti ei koskaan käsitellyt sitä. Worker kaatui, webhook katosi tai token vanheni triggerin ja haun välillä.

Ratkaiseva vihje on aika. Jonossa odottaminen kestää sekunneista pariin minuuttiin. Deployment, joka on ollut jonossa kymmenen minuuttia ilman yhtäkään edellä olevaa julkaisua, ei odota — se on jumissa ja pysyy jumissa.

Miten erotat odottamisen jumittumisesta

Ennen kuin yrität uudelleen, selvitä kolme asiaa:

1. Onko jokin muu deployment käynnissä? Jos saman servicen toinen julkaisu on käynnissä, kyseessä on tapaus 2, ja siihen kannattaa olla puuttumatta.
2. Kuinka kauan se on ollut jonossa? Alle kaksi minuuttia on normaalia. Yli kymmenen ei ole.
3. Joutuivatko muut servicet jonoon samaan aikaan? Jos toisistaan riippumattomat servicet pysähtyivät kaikki yhtä aikaa, etsi syytä upstreamista, älä koodistasi.

Näiden kolmen vastauksen avulla ”odota” ja ”toimi” erottuvat lähes aina toisistaan.

Miksi uudelleen yrittäminen yleensä pahentaa tilannetta

Juuttuneen julkaisun kohdalla vaistonvarainen ratkaisu on painaa deploy uudelleen. Sarjoitetussa pipelinessä tämä toimii päinvastoin: lisäät toisen tietueen ensimmäisen taakse, ja jos ensimmäinen on todella jumissa, toinen perii saman eston. Tätä kokeilleet kehittäjät päätyvät usein jonoon, jossa on peräkkäin useita queued-merkintöjä. Mikään niistä ei käynnisty, ennen kuin jonon ensimmäinen pääsee etenemään.

Jos aiot yrittää uudelleen, peruuta juuttunut ajo ensin. Yksi näkyvästi epäonnistuva jonossa oleva deployment on paljon hyödyllisempi kuin viisi paikalleen jäävää.

Miten hoidamme tämän Dockupissa

Tärkeä suunnitteluratkaisu on, ettei deploymentia koskaan vain uskota käynnissä olevaksi. Jokaisella on päättävä tila, ja juuri sen saavuttaminen vapauttaa jonon. Myös ilman ilmoitusta kuoleva build päätyy aikakatkaisuun ja vapauttaa servicen.

Kaksi muutakin asiaa auttavat enemmän kuin ehkä kuulostaa:

Vaiheet on nimetty. Dockup-deployment etenee lähdekoodin hausta buildiin ja health gateen, ja jokainen vaihe tallentaa oman kestonsa. Kun jokin on hidasta, näet mikä on hidasta sen sijaan, että seuraisit yhtä sanaa. stageTimings on jokaisessa deployment-tietueessa, myös --json-tulosteessa.

Epäonnistuneen julkaisun taakse ei jonoteta mitään. Jos health check ei koskaan mene läpi, deployment päättyy — se ei jää varaamaan serviceä siksi aikaa, kun ihmettelet tilannetta. Edellinen versio jatkaa liikenteen palvelemista koko ajan. Tämä on toinen syy siihen, miksi juuttunut julkaisu ei Dockupissa tarkoita katkosta.

# 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

Yleissääntö

Jonottaminen ei ole vikatila. Jonottaminen ilman siihen liittyvää syytä on. Jokainen alusta saa sinut toisinaan odottamaan Git-palveluntarjoajaa tai build-paikkaa. Viiden minuutin harmituksen ja kokonaisen hukkaan menneen iltapäivän erottaa se, kertooko käyttöliittymä, missä neljästä tapauksesta olet.

Kun arvioit, missä haluat ajaa jotain, tämä kannattaa tarkistaa tarkoituksella: käynnistä deploy ja katso, mitä alusta näyttää sen hyväksymisen ja käynnistymisen välillä. Jos vastaus on yksi sana ilman aikaleimaa, tulet ennemmin tai myöhemmin käyttämään tähän kokonaisen iltapäivän.

Usein kysyttyä

Kuinka kauan deploymentin pitäisi pysyä jonossa? Terveellä alustalla sekunneista pariin minuuttiin. Jos jono on kestänyt yli kymmenen minuuttia eikä sen edellä ole mitään, sitä kannattaa pitää jumissa olevana eikä vain hitaana.

Pitäisikö jonossa oleva deployment yrittää uudelleen? Ei ennen kuin olet peruuttanut sen. Sarjoitetussa pipelinessä uusi yritys jonoutuu juuttuneen ajon taakse ja perii saman eston.

Aiheuttaako juuttunut deployment sivustoni kaatumisen? Ei pitäisi. Alustalla, joka vaihtaa liikenteen uuteen julkaisuun vasta health checkin läpäisemisen jälkeen, käynnissä oleva versio jatkaa liikenteen palvelemista koko ajan — jonoon jäänyt tai epäonnistunut deploy on julkaisu, jota ei koskaan tapahtunut, ei käyttökatko.

Miksi useat servicet joutuvat jonoon samaan aikaan? Koska ne jakavat riippuvuuden, joka on lähes aina Git-palveluntarjoaja tai build-fleet eikä mikään koodissasi.