Så separerar du databasmigreringar från appstarten under utrullning av containrar

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How to Separate Database Migrations From App Startup During Container Rollouts - Zima Store Online

Det är lättare att förhindra dubbla databasmigreringar när schemaändringar körs som ett uttryckligt distributionssteg i stället för vid starten av varje appcontainer.

Den förebyggande lösningen är att ge migreringarna en enda ansvarig, en uppsättning autentiseringsuppgifter och en klar signal om slutförande innan nya repliker börjar hantera trafik. Låt webb- och workercontainrar kunna starta om utan behörighet att ändra schemat, låt utrullningen vänta på ett lyckat migreringsjobb och utforma schemaändringarna så att gamla och nya appversioner kan samexistera en kort stund. Då elimineras kapplöpningen i stället för att man bara hoppas att varje replik upptäcker samma migreringshistorik först.

Ta bort migreringskommandon från den normala appstarten

Granska image-entrypointen, Compose-kommandot, workerkommandot, health-wrappern och distributionsskriptet efter automatiska migreringsanrop. Applikationen ska kunna starta om utan att ändra schemat, såvida omstarten inte är det avsiktligt valda migreringssteget.

En distributionsartikel från Octopus hävdar att migreringar behöver en separat livscykel i stället för att kopplas till starten av varje mikrotjänstprocess.

Ha migreringsbinären tillgänglig där den behövs, men anropa den inte både från webbinträdet och från ett separat jobb. En enda tydlig ansvarig är enklare att granska än flera startvägar som alla är beroende av låsning i ramverket.

Kör ett migreringsjobb före distributionen

Skapa ett engångsjobb som använder samma migreringsfiler som releasen och avslutas lyckat först när måldatabasen har nått det förväntade schematillståndet. Låt apputrullningen vara beroende av detta resultat.

En aktuell utrullningsguide visar hur ett jobb körs före utrullningen i stället för att varje replik ska tävla vid starten.

Skala inte migreringsuppgiften på samma sätt som appservicen. Jobbet bör ha en enda exekveringsansvarig per måldatabas, en begränsad tidsgräns, loggar och ett tydligt feltillstånd som blockerar den nya appversionen.

Villkora appstarten med lyckad migrering

Låt nya webb- och workercontainrar vänta tills migreringssteget rapporterar lyckat resultat, men låt inte varje väntande container köra migreringen igen. Beroendet gäller resultatet, inte att schemaändringen ska utföras på nytt.

Andrew Locks distributionsmönster använder appkapslar som väntar på migreringen, medan migreringslogiken förblir centraliserad.

För en mindre hemservermiljö kan samma princip implementeras med en dedikerad Compose-tjänst och ett kontrollerat distributionsskript. Håll mekanismen tillräckligt enkel för att en misslyckad migrering tydligt stoppar utrullningen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Använd bakåtkompatibla schemaändringar under överlappningen

Rullande distributioner kan tillfälligt köra gamla och nya appversioner mot samma databas. Undvik migreringar som tar bort eller byter namn på ett fält innan den gamla versionen har slutat använda det.

En aktuell guide om migreringar utan driftstopp rekommenderar att bygga ut innan du drar ihop, så att tillägg i schemat införs före destruktiv städning.

Dela vid behov upp stora ändringar i faserna utbyggnad, återfyllnad, växling och sammandragning. Migreringsjobbet bör inte skapa ett schema som bara den nya containern förstår medan gamla repliker fortfarande hanterar förfrågningar.

Håll migreringsuppgifterna utanför appreplikerna

Använd när det är praktiskt möjligt ett konto med behörighet att ändra schemat endast för det tillfälliga migreringssteget. Normala appcontainrar bör ha de mer begränsade läs- och skrivbehörigheter som krävs för applikationsdata.

En Liquibase-artikel om distribution beskriver att databasändringar hör hemma i automatisering med kontrollerad och repeterbar tillämpning av ändringar.

Denna separation minskar risken för att migreringen körs av misstag även om en approcess startas om eller dupliceras. Lagra den upphöjda autentiseringsuppgiften i distributionshemligheternas sökväg i stället för i den vanliga miljön för långvariga tjänster.

Verifiera att utrullningen inte kan tillämpa batchen två gånger

Testa distributionen mot en tillfällig databas eller en återställd ögonblicksbild genom att starta flera apprepliker, starta om dem och köra distributionskommandot igen. Migreringssteget ska rapportera det befintliga schematillståndet utan att ändra det en andra gång.

JetBrains sammanfattar driftregeln som att köra migreringar som ett distributionssteg före den normala appstarten.

Den förebyggande policyn är komplett när omstarter av appen inte kan ändra schemat, när en misslyckad migrering blockerar releasen och när upprepad körning av utrullningen lämnar databasen oförändrad. Den relaterade ZimaSpace-artikeln om felsökning av dubbla migreringar är återställningsvägen om dubbel körning redan har inträffat.