Deployment sidder fast i kø: Det skal du tjekke først

Et deployment, der sidder fast i kø, er en af de mindst informative fejl, en platform kan vise dig. Intet er crashet. Der er ikke kommet nogen logs, fordi intet er blevet kørt. Dit release står bare stille, og hver refresh viser det samme ord.

Det frustrerende er, at "i kø" dækker over mindst fire forskellige situationer, som ikke har noget med hinanden at gøre. Det tager omkring tredive sekunder at finde ud af, hvilken situation du står i, og det afgør, om du skal vente, prøve igen eller undersøge noget helt andet.

Hvad betyder "i kø" egentlig?

Et deployment i kø er blevet accepteret og registreret, men har endnu ikke fået tildelt en worker. Mellem de to tidspunkter skal en række ting være på plads:

• Platformen skal hente din source code, hvilket normalt betyder et API-kald til din Git-provider.
• Der skal være en ledig build-plads.
• Alle forudsætninger for releaset skal være afsluttet — et migrationstrin, en volume-operation eller et tidligere deployment af den samme service.

Hvis noget af dette er blokeret, findes registreringen, men arbejdet starter ikke. Det er hele mekanismen. Det er ikke et mysterium, men de fleste dashboards viser alle fire tilfælde med det samme ord.

De fire tilfælde i den rækkefølge, det giver mening at undersøge dem

1. Din Git-provider har en dårlig dag

Det er den mest almindelige årsag og den eneste, du ikke selv kan gøre noget ved. Platformen bad om dit repository og fik et langsomt svar eller en fejl. Hvis flere uafhængige services kommer i kø på samme tid, og ingen af dem deler kode, er den fælles afhængighed din provider.

Tjek din providers statusside som det første. Et deploy, der venter på et upstream-API, løser sig selv, og hvis du prøver igen, tilføjer du kun endnu en registrering til bunken — derfor bliver en fastlåst kø så ofte til fem fastlåste køer.

2. Noget foran det er ikke blevet færdigt

De fleste platforme serialiserer deployments pr. service, og det er med god grund: To builds, der skriver det samme image-tag, er et race, du ikke ønsker at vinde. Hvis et tidligere deployment af servicen stadig kører — eller endnu værre, stadig antages at køre, fordi en worker døde uden at rapportere det — venter det næste deployment.

På Dockup viser dockup deployments historikken med det seneste først og status for hver post. Hvis deploymentet lige over dit release i kø ikke er i en sluttilstand, har du svaret, og det er en annullering eller timeout, der får køen til at bevæge sig igen.

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

Outputtet fra --json indeholder status og varighed for hvert deployment, så det bliver tydeligt, at "det forrige blev aldrig færdigt" — på en måde, en spinner ikke kan vise.

3. Der er ingen kapacitet

Alle platforme har et begrænset antal build-workers. På et shared tier kan øget aktivitet på platformen placere dig bag andre brugeres builds. Det er reelt, normalt kortvarigt, og det er det ene tilfælde, hvor det faktisk er rigtigt at vente.

Det afgørende er, om du kan se det. En køposition eller et estimat for ventetiden gør en oplevelse, der ligner et nedbrud, til en normal situation. Et bart "i kø" gør ikke.

4. Deploymentet ville aldrig være startet

Det uheldige tilfælde: Registreringen blev oprettet, men det, der skulle hente den, gjorde det aldrig. En worker crashede, en webhook gik tabt, eller et token udløb mellem triggeren og hentningen.

Tegnet er tiden. Ventetid i kø måles i sekunder til et par minutter. Et deployment, der har stået i kø i ti minutter uden andre releases foran sig, venter ikke — det sidder fast, og det bliver ved med at sidde fast.

Sådan skelner du mellem ventetid og et hæng

Inden du prøver igen, skal du finde tre ting ud af:

1. Er noget andet ved at blive deployed? Hvis et andet release af den samme service kører, er du i tilfælde 2, og du bør lade det være.
2. Hvor længe har det stået i kø? Under to minutter er normalt. Over ti minutter er ikke.
3. Kom andre services i kø på samme tid? Hvis uafhængige services alle stoppede på én gang, skal du undersøge upstream — ikke din kode.

De tre svar skelner næsten altid mellem "vent" og "gør noget".

Hvorfor det som regel gør situationen værre at prøve igen

Når et release sidder fast, er den naturlige reaktion at trykke på deploy igen. På en serialiseret pipeline virker det mod hensigten: Du tilføjer en ny registrering bag den første, og hvis den første reelt sidder fast, arver den næste den samme blokering. Udviklere, der rammes af dette, ender ofte med en kolonne af poster i kø, hvor ingen af dem kører, før den forreste i køen bliver frigivet.

Hvis du vil prøve igen, skal du først annullere det fastlåste deployment. Ét deployment i kø, der fejler synligt, er langt mere nyttigt end fem, der bare står stille.

Sådan håndterer vi det på Dockup

Den designbeslutning, der betyder noget her, er, at et deployment aldrig blot antages at køre. Hvert deployment har en sluttilstand, og det er ankomsten til denne tilstand, der frigiver køen. Et build, der dør uden at rapportere det, får stadig timeout og frigiver stadig servicen.

To andre ting hjælper mere, end man skulle tro:

Trin har navne. Et Dockup-deployment bevæger sig gennem hentning af source code, build og health gate, og hvert trin registrerer sin egen varighed. Når noget er langsomt, kan du se hvad der er langsomt, i stedet for at se på ét enkelt ord. stageTimings findes i alle deployment-registreringer, også via --json.

Der sættes ikke noget i kø bag et release, der allerede er fejlet. Hvis health check aldrig går igennem, afsluttes deploymentet — det bliver ikke ved med at optage servicen, mens du undrer dig. Den tidligere version fortsætter med at håndtere trafik hele tiden, og det er den anden grund til, at et fastlåst release ikke er et nedbrud 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 regel

At være i kø er ikke en fejltilstand. At være i kø uden en tilknyttet årsag er. Alle platforme vil en gang imellem få dig til at vente på en Git-provider eller en build-plads; forskellen på fem minutters irritation og en hel eftermiddag, der går tabt, er, om interfacet fortæller dig, hvilket af de fire tilfælde du står i.

Når du vurderer, hvor noget skal køre, er det værd at undersøge med vilje: Udløs et deploy, og se, hvad platformen viser dig mellem accepten og starten. Hvis svaret er ét enkelt ord uden et tidsstempel, kommer du før eller siden til at bruge en eftermiddag på det.

Ofte stillede spørgsmål

Hvor længe bør et deployment stå i kø? Sekunder til et par minutter på en sund platform. Alt over ti minutter uden noget foran sig bør behandles som fastlåst snarere end langsomt.

Bør jeg prøve et deployment i kø igen? Ikke før du har annulleret det. På en serialiseret pipeline kommer et nyt forsøg i kø bag det fastlåste deployment og arver den samme blokering.

Går mit site ned på grund af et fastlåst deployment? Det bør det ikke. På en platform, der først skifter trafik over, når et nyt release består sit health check, fortsætter den kørende version med at håndtere trafik hele tiden — et deployment i kø eller et fejlet deploy er et release, der aldrig blev gennemført, ikke et nedbrud.

Hvorfor kommer flere services i kø på én gang? Fordi de deler en afhængighed, og det er næsten altid Git-provideren eller build-flåden snarere end noget i din kode.