Distribusjon står fast i kø: Dette bør du sjekke først

En distribusjon som står fast i kø er en av de minst informative feilene en plattform kan vise deg. Ingenting har krasjet. Ingen logger har dukket opp, fordi ingenting har kjørt. Releasen blir bare stående der, og hver oppdatering viser det samme ordet.

Det frustrerende er at «i kø» dekker minst fire ulike situasjoner, og de har ikke nødvendigvis noe med hverandre å gjøre. Det tar omtrent tretti sekunder å finne ut hvilken situasjon du er i, og det avgjør om du bør vente, prøve på nytt eller undersøke noe helt annet.

Hva betyr «i kø» egentlig?

En distribusjon i kø er godtatt og registrert, men har ennå ikke fått tildelt en worker. Mellom disse to tidspunktene må flere ting være på plass:

• Plattformen må hente kildekoden din, som vanligvis betyr et API-kall til Git-leverandøren din.
• En ledig build-plass må være tilgjengelig.
• Eventuelle forutsetninger i releasen må være ferdige — et migreringstrinn, en volumoperasjon eller en tidligere distribusjon av samme tjeneste.

Hvis noe av dette er blokkert, finnes registreringen, men arbeidet starter ikke. Det er hele mekanismen. Det er ikke noe mysterium, men de fleste kontrollpaneler viser alle de fire tilfellene med det samme ordet.

De fire tilfellene, i den rekkefølgen det er lurt å sjekke dem

1. Git-leverandøren din har en dårlig dag

Dette er den vanligste årsaken, og den du ikke kan gjøre noe med. Plattformen ba om repositoryet ditt og fikk et tregt svar eller en feil. Hvis flere urelaterte tjenester havner i kø samtidig, og ingen av dem deler kode, er den delte avhengigheten leverandøren.

Sjekk status siden til leverandøren før du gjør noe annet. En deploy som venter på et upstream-API, vil løse seg av seg selv, og nye forsøk legger bare enda en registrering i køen — og derfor blir én fastlåst kø så ofte til fem fastlåste køer.

2. Noe foran den er ikke ferdig

De fleste plattformer serialiserer distribusjoner per tjeneste, og med god grunn: To builds som skriver samme image-tag, er ikke en race du ønsker å vinne. Hvis en tidligere distribusjon av tjenesten fortsatt kjører — eller, enda verre, fortsatt anses å kjøre fordi en worker døde uten å rapportere det — må den neste vente.

På Dockup viser dockup deployments historikken med det nyeste først, sammen med statusen for hver oppføring. Hvis distribusjonen over den fastlåste releasen ikke er i en sluttstatus, har du svaret ditt. Da må du avbryte den eller la den få tidsavbrudd for å åpne køen.

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

Resultatet fra --json inneholder status og varighet for hver distribusjon. Da blir det tydelig at «den forrige ble aldri ferdig» på en måte en spinner ikke kan vise.

3. Ingen kapasitet

Alle plattformer har et begrenset antall build-workere. På en delt tjenestenivå kan mye aktivitet på tvers av plattformen plassere deg bak andre brukeres builds. Dette er reelt, varer vanligvis kort, og er det eneste tilfellet der det faktisk er riktig å vente.

Det viktige her er om du kan se det. En køposisjon eller et estimat på ventetiden gjør en opplevelse som ligner et driftsavbrudd, til en normal situasjon. Et nakent «i kø» gjør ikke det.

4. Distribusjonen kom aldri til å starte

Dette er det ubehagelige tilfellet: Registreringen ble opprettet, men det som skulle hente den, gjorde det aldri. En worker krasjet, en webhook gikk tapt, eller et token utløp mellom utløsningen og hentingen.

Tegnet er tiden. Ventetid i kø måles i sekunder til et par minutter. En distribusjon som har stått i kø i ti minutter uten andre releaser foran seg, venter ikke — den sitter fast, og den kommer til å fortsette å sitte fast.

Slik skiller du venting fra en hengende prosess

Før du prøver på nytt, bør du finne tre fakta:

1. Er noe annet under distribusjon? Hvis en annen release av samme tjeneste kjører, er du i tilfelle 2, og du bør la den være i fred.
2. Hvor lenge har den stått i kø? Under to minutter er normalt. Over ti minutter er det ikke.
3. Havnet andre tjenester i kø samtidig? Hvis urelaterte tjenester stoppet samtidig, bør du se oppstrøms, ikke på koden din.

Disse tre svarene skiller mellom «vent» og «gjør noe» nesten hver gang.

Hvorfor nye forsøk vanligvis gjør det verre

Når en release sitter fast, er det naturlig å trykke på deploy igjen. I en serialisert pipeline virker dette mot sin hensikt: Du legger en ny registrering bak den første, og hvis den første faktisk sitter fast, arver den andre den samme blokkeringen. Utviklere som støter på dette, ender ofte opp med en kolonne av oppføringer i kø, hvor ingen av dem kjører før den første i køen blir ferdig.

Hvis du skal prøve på nytt, må du avbryte den fastlåste først. Én distribusjon i kø som feiler synlig, er langt mer nyttig enn fem som bare blir stående.

Slik håndterer vi dette i Dockup

Den viktige designbeslutningen her er at en distribusjon aldri bare antas å kjøre. Hver distribusjon har en sluttstatus, og det er når den nås, at køen frigjøres. En build som dør uten å rapportere, får likevel tidsavbrudd og frigjør fortsatt tjenesten.

To andre ting hjelper mer enn man kanskje skulle tro:

Trinnene har navn. En Dockup-distribusjon går gjennom henting av kildekode, build og en helsesjekk, og hvert trinn registrerer sin egen varighet. Når noe går tregt, kan du se hva som er tregt, i stedet for å se på ett enkelt ord. stageTimings finnes i alle distribusjonsregistreringer, også via --json.

Ingenting legges i kø bak en release som allerede har feilet. Hvis helsesjekken aldri består, avsluttes distribusjonen — den blir ikke stående og oppta tjenesten mens du lurer på hva som skjer. Den forrige versjonen fortsetter å betjene trafikk hele tiden. Det er den andre grunnen til at en fastlåst release ikke er et driftsavbrudd på Dockup.

# 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

Den generelle regelen

Å stå i kø er ikke en feiltilstand. Å stå i kø uten en tilknyttet årsak er det. Alle plattformer vil av og til få deg til å vente på en Git-leverandør eller en build-plass. Forskjellen mellom fem minutters irritasjon og en hel tapt ettermiddag er om grensesnittet forteller deg hvilket av de fire tilfellene du er i.

Når du vurderer hvor du skal kjøre noe, er dette verdt å undersøke med vilje: Utløs en deploy, og se hva plattformen viser mellom det tidspunktet den godtar den, og tidspunktet den starter. Hvis svaret er ett enkelt ord uten tidsstempel, kommer du før eller siden til å bruke en hel ettermiddag på dette.

Vanlige spørsmål

Hvor lenge bør en distribusjon stå i kø? Sekunder til et par minutter på en velfungerende plattform. Alt over ti minutter uten noe foran seg bør behandles som fastlåst, ikke bare tregt.

Bør jeg prøve en distribusjon i kø på nytt? Ikke før du har avbrutt den. I en serialisert pipeline havner et nytt forsøk bak den fastlåste distribusjonen og arver den samme blokkeringen.

Tar en fastlåst distribusjon nettstedet mitt ned? Det bør den ikke gjøre. På en plattform som først bytter trafikk når en ny release har bestått helsesjekken, fortsetter den kjørende versjonen å betjene trafikk hele tiden — en deploy som står i kø eller har feilet, er en release som aldri skjedde, ikke et driftsavbrudd.

Hvorfor havner flere tjenester i kø samtidig? Fordi de deler en avhengighet, og det er nesten alltid Git-leverandøren eller build-infrastrukturen, ikke noe i koden din.