Så separerar du databasmigreringar från appstarten under utrullning av containrar
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.
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.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
