Uppgradera plattformen

För att planera en utrullning krävs lifecycle/plan och för att köra den lifecycle/execute, båda på plattformens rot; för att rulla tillbaka en krävs lifecycle/rollback. Platform Owner och Platform Contributor har alla tre. Allt nedan sker under Inställningar → Livscykelhantering.

Sök efter nya releaser

Plattformen läser releaseflödet ungefär en gång i timmen. För att läsa det nu öppnar du fliken Components och väljer Sök efter uppdateringar. Svaret är ett av:

• Hittade N ny(a) utgåva/utgåvor — kolumnen Version visar nu den nyare releasen bredvid versionen som körs, och raden ovanför tabellen räknar de komponenter som kan uppgraderas.
• Inga nya utgåvor — allt är uppdaterat — det vanliga svaret.
• Kunde inte nå utgåvekanalen — flödet kunde inte hämtas eller dess signatur kunde inte verifieras. Ingenting ändrades. Kontrollera att plattformen når flödet; om den gör det, se Hur plattformen läser flödet.
• Ingen utgåvekanal konfigurerad — plattformen läser inget flöde, så det finns inget att kontrollera.

Att söka registrerar bara vilka releaser som finns; det ändrar aldrig det som körs.

Planera en utrullning

Välj Ny utrullning, i sidhuvudet eller på fliken Rollouts. Planeringssidan listar de komponenter som har en nyare release (Inaktuella); Alla listar varje komponent, och Filtrera komponenter smalnar av listan efter namn.

1. Välj Välj inaktuella för att kryssa i varje inaktuell komponent med dess senaste release som mål — CRD-paketet också, eftersom planen bara kan lägga CRD:erna först om de finns med i den. Eller kryssa i komponenter en och en. Rensa kryssar ur allt.
2. Välj version under Mål för varje ikryssad rad. Listan visar varje releases kanal och, för ett CRD-paket, vilket installationsprogram den releasen kör. För att rulla tillbaka en komponent för hand letar du upp den under Alla och väljer en äldre release.
3. Välj Granska plan.

Kolumnerna är Komponent, Typ, Installerad (det som körs nu), Rullas efter (de komponenter den beror på) och Mål. En del avgörs åt dig:

• Komponenter du inte kryssade i förblir som de är. En komponent kan rullas ut ensam: det den beror på avgör bara ordningen när båda finns i planen.
• Ett tredjepartschart som en ikryssad modul låser visas indraget under modulen och rullas ut med den. Kryssa ur det för att lämna det kvar; planen säger det då.
• Ett chart märkt Manuell uppgradering uppgraderas för hand enligt leverantörens rutin och går inte att kryssa i.
• Plattformssteg (installer) finns inte i listan. Varje plan som flyttar CRD-paketet rullar ut en plattformsrelease, och plattformen lägger till den releasens installationsprogram som ett eget steg.

Granska planen

Granskningen ersätter listan, och sidans adress innehåller nu planen, så en omladdning eller en kollega med länken ser samma plan. Ändra urval går tillbaka till listan och släpper planen.

Läs den uppifrån:

• Batchar — varje batch blir klar innan nästa börjar, och komponenterna i en batch rullas ut tillsammans. Tredjepartscharts kommer först, ett per batch; sedan CRD-paketet; sedan plattformssteget; sedan Lifecycle-modulen för sig när den rullas ut med andra, eftersom dess nya version renderar de övrigas konfiguration; sist allt annat i beroendeordning. Varje rad visar versionen den rullas från och till.
• Beroenden — för varje tredjepartschart resultatet av en torrkörning av uppgraderingen när planen är validerad, om det skulle innebära en databasåterställning att ångra den, och om leverantören bara stöder en minorversion i taget.
• Lämnas utanför planen — det planen inte kunde ta med och varför, till exempel ett chart som en modul låser men som inte kan rullas ut än, eller en release vars plattformssteg inte kan köras. Resten av planen genomförs utan det.

Sidopanelen visar planens status. Validated betyder att den kan köras. Varje problem som listas i rött ovanför batcharna håller planen ovaliderad, och Kör utrullning visas inte. Vanliga problem: en målversion som ingen release har; en release som är märkt som schemabrytande; en release som bara får tillämpas från en nyare installerad version; ett chart som skulle hoppa över en minorversion som leverantören kräver; eller en release som också har ett CRD-paket som inte har tillämpats, medan paketet inte finns i planen. Ändra urvalet och granska igen.

Hantera kontrollerna före uppgradering

En validerad plan kör kontrollerna före uppgradering, och sidopanelen räknar dem som Godkända, Varningar, Misslyckade och Överhoppade. Hela rapporten finns under planen; varje kontroll beskrivs i Kontroller före uppgradering.

• En varning stoppar aldrig utrullningen.
• En misslyckad kontroll måste åsidosättas medvetet: kryssa i Rulla ut ändå och åsidosätt de misslyckade kontrollerna. Åsidosättandet, och id:na för kontrollerna det gällde, registreras på utrullningen.
• En misslyckad kontroll märkt Kan inte åsidosättas gör Kör utrullning otillgänglig, och kryssrutan omfattar den inte: utrullningen skulle bara nekas senare, i det steg som behöver det som saknas. Den vanligaste är plattformens administratörspaket, som en klusteradministratör tillämpar med kommandot som kontrollen visar — se Plattformens administratörspaket. När det är åtgärdat väljer du Kör kontrollerna igen.

Kör kontrollerna igen under rapporten kör den på nytt när du har åtgärdat något.

Kör utrullningen

Välj Kör utrullning. Innan något ändras gör plattformen följande:

1. den nekar om en annan utrullning inte har avslutats — bara en körs i taget, och en pausad utrullning räknas tills den avslutas;
2. den nekar om planen uppgraderar ett tredjepartschart eller kör ett plattformssteg och den operator som körs är för gammal för att genomföra det;
3. den kör kontrollerna före uppgradering igen och går efter den körningen, inte den du granskade, så en kontroll som har misslyckats sedan dess stoppar utrullningen om du inte åsidosatte den;
4. den skriver den konfiguration som releasen ger varje komponent, och nekar med orsaken om ett värde som konfigurationen behöver saknas på plattformen.

När utrullningen startar tar sidan dig till utrullningens egen sida.

Följ utrullningen

Utrullningens sida har en egen adress; skicka den till den som undrar hur uppgraderingen går. Varje utrullning listas också på fliken Rollouts, med Detaljer för att öppna den.

• Förlopp visar varje batch och, per komponent, om den står i kö, rullas ut eller är klar, versionen och avbildningens digest före och efter. Ett tredjepartschart visar i stället sina Helm-revisioner.
• Status, bredvid, visar utrullningens Tillstånd och Fas, när den startade och vem som startade den, och har åtgärderna.
• Pre-rollout snapshot visas för en utrullning som uppgraderar ett tredjepartschart: den säkerhetskopia som togs före batch 1.
• Checks after dependency batches visas när kontroller upprepas efter en chart-batch.
• Kontrollerna före uppgradering visas som de såg ut när utrullningen startade, med eventuella åsidosättanden.

Vad tillstånden betyder finns i Statusar.

När en utrullning pausar

En utrullning pausar i stället för att fortsätta när en komponent inte går att rulla ut — dess Deployment saknas eller slutar göra framsteg, eller dess chart-uppgradering, CRD-paket eller plattformssteg nekas —, när en komponent inte klarar sin hälsokontroll, när en kontroll som upprepas efter en chart-batch har blivit sämre, när klustret nekar operatorn något som utrullningen behöver, när ögonblicksbilden före utrullningen misslyckas eller när plattformssteget hittar plattformsinställningar som har ändrats för hand. Sidan säger det överst, med orsaken, och komponenten som fallerade visar detaljerna.

• Resume — när du har åtgärdat orsaken. Den pausade batchen kontrolleras igen och utrullningen fortsätter.
• Resume without snapshot — erbjuds bara när ögonblicksbilden misslyckades och får hoppas över. Utrullningen fortsätter utan säkerhetskopia av de uppgraderade chartens resurser, och åsidosättandet registreras. Ett chart som bara kan ångras genom en databasåterställning erbjuder det aldrig.
• En paus på grund av inställningar som ändrats för hand erbjuder dessutom Återställ — se Inställningar ändrade för hand.

En batch som inte blir klar inom sin tidsgräns — tio minuter, eller trettio för en batch som uppgraderar ett tredjepartschart — avslutar utrullningen som Failed i stället för att pausa den. En återupptagen batch får en ny tidsgräns.

Avbryt en utrullning

Cancel rollout avslutar en utrullning som inte är klar. Den avslutas som Cancelled; komponenter som redan har uppgraderats behåller sin nya version. Att avbryta hindrar utrullningen från att ta nästa steg, men stoppar inte en ändring som redan pågår: en komponent i den aktuella batchen vars nya version redan har tillämpats fortsätter att rullas ut, och en chart-uppgradering eller ett plattformssteg som har startat körs klart.

Rulla tillbaka

Roll back erbjuds på en utrullning som har avslutats — lyckad, misslyckad eller avbruten — och kräver lifecycle/rollback. Den startar en ny utrullning som tar tillbaka varje uppgraderad komponent till avbildningen den körde innan, i omvänd ordning, och tar dig till den utrullningen. Misslyckade kontroller före uppgradering stoppar den inte: en tillbakarullning är hur du återhämtar dig från en plattform som inte mår bra.

• CRD-paketet och plattformssteget rullas aldrig tillbaka. CRD-ändringar lägger bara till, och äldre komponenter bryr sig inte om det som lagts till.
• Ett tredjepartschart går tillbaka till den Helm-revision det hade före uppgraderingen. Ett chart som migrerar sin databas framåt lämnas utanför: att ångra det innebär att återställa plattformsdatabasen från säkerhetskopian före utrullningen och sedan rulla tillbaka chartet för hand.
• En modul som har migrerat sin egen databas framåt kanske inte kan köras på sin tidigare avbildning. Bekräftelsen säger det.

Efter utrullningen

Öppna fliken Efter uppgradering. En release kan lämna ett steg som bara en person kan ta, och en siffra på fliken och en påminnelse överst på varje sida säger när den har gjort det — se Efter uppgradering. När en utrullning har lyckats letar plattformen också efter inställningar som ändrats för hand och registrerar, för en releaseutrullning, releasen som plattformens version. Den gör båda när den märker att utrullningen lyckades: direkt medan utrullningens sida är öppen, annars nästa gång något kontrollerar om en utrullning pågår — senast vid nästa schemalagda kontroll, inom sex timmar.

Via API:t

Samma flöde finns i API:t, till exempel med stsh api:

stsh api GET /lifecycle/components
stsh api POST /lifecycle/rollouts/plans -d '{"targetVersions": {"apps": "<version>"}}'
stsh api POST /lifecycle/rollouts/plans/<plan-id>/validate
stsh api GET "/lifecycle/preflight?planId=<plan-id>"
stsh api POST /lifecycle/rollouts/executions -d '{"planId": "<plan-id>", "acknowledgedFailures": []}'
stsh api GET /lifecycle/rollouts/executions/<execution-id>

Ange en misslyckad kontrolls id i acknowledgedFailures för att åsidosätta den. Alla routes finns i modulens API-referens.