Migratieworkflow voor Docker-benoemde volumes tussen twee thuisservers

De veilige aanpak is om een gearchiveerde of gesynchroniseerde kopie naar een expliciet geïdentificeerd doelvolume, gevolgd door controles met checksums en applicatievalidatie, te behandelen als een reeks waarneembare controlepunten en niet als één opdracht.

Op twee Linux-thuisservers met Docker Compose bestaat het praktische risico erin dat een stateful container naar een andere host moet worden verplaatst zonder een actief of verkeerd benoemd volume te kopiëren. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende controle, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop zodra de opslag instabiel wordt of de enige herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload succesvol draait of het bewijs een escalatiegrens bereikt.

Identificeer de bron- en doelvolumecontracten

Leg de image-digest van de broncontainer, de naam van het Compose-project, de service, de volumesleutel, de werkelijke Docker-volumenaam, de mountbestemming, de volumestuurprogramma en de applicatieversie vast. Gebruik docker inspect en docker volume inspect; leid het fysieke pad niet alleen af uit een YAML-label.

Compose voegt normaal gesproken de projectnaam toe aan benoemde volumes, tenzij een expliciete naam of een extern volume wordt gebruikt. Render op het doel de Compose-configuratie en maak het bedoelde lege volume expliciet aan, zodat de migratie niet in het ene volume terechtkomt terwijl de service een ander volume start.

Als het volume een database bevat, gebruik dan de systeemeigen dump of ondersteunde back-up als het primaire overdraagbare herstelpad en behandel de volumekopie als een herstelpunt voor dezelfde versie. Stop als het stuurprogramma op afstand werkt, de bronopslag instabiel is of de applicatiestatus zich uitstrekt over extra volumes die niet binnen de scope vallen.

Stop schrijfbewerkingen en maak een kopie die metadata behoudt

Zet de applicatie in onderhoudsmodus, stop achtergrondtaken en stop daarna de applicatie en database op een nette manier. Controleer of geen enkele container het volume met schrijfrechten heeft aangekoppeld. Maak een archief via een tijdelijke container of gebruik een gecontroleerde bestandssysteemkopie die numerieke eigenaars, machtigingen, symbolische koppelingen, waar nodig uitgebreide kenmerken en sparse bestanden behoudt.

Een onafhankelijke handleiding over Docker-volumemigratie met rsync laat zien hoe je Docker-volumegegevens met rsync verplaatst. De belangrijke grens is dat de bron in een rustige toestand moet zijn en dat de kopieeropdracht op de inhoud van het geïdentificeerde volume moet werken, en niet blind de interne map van Docker mag bewerken terwijl de daemon deze gebruikt.

Genereer een manifest met het aantal bestanden, het totale aantal bytes, representatieve hashes en de checksum van het archief. Laat het bronvolume en de systeemeigen back-up onaangeroerd; de kopieerstap is pas geslaagd wanneer het overdrachtsartefact op de doelhost leesbaar is.

Herstel naar het expliciete doelvolume

Controleer de capaciteit van het doelbestandssysteem, de beschikbaarheid van inodes, de verwachte UID's en GID's en dezelfde applicatie-imageversie. Herstel het archief naar het lege doelvolume zonder de structuur van de bovenste maplaag af te vlakken en vergelijk daarna eigenaarschap, aantallen, groottes en geselecteerde hashes.

Een communitydiscussie over een geval van een mislukte migratie van een benoemd volume laat zien waarom het rechtstreeks vervangen van bestanden in de interne volumes van Docker kan mislukken of tot verwarrende toestanden kan leiden. Gebruik de runtime om het volume in een helpercontainer te mounten en voer het herstel uit via die gecontroleerde interface.

Koppel eerst alleen een wegwerpbare kopie van de service aan, met alternatieve poorten en zonder toegang tot productiepeers. Als de applicatie schemaupgrades of beschadigde status meldt, stop dan en herstel het volume opnieuw vanuit het ongewijzigde artefact nadat je de compatibiliteit van de versies hebt opgelost.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Voer de omschakeling uit en behoud een rollback-host

Start afhankelijkheden vóór de applicatie, controleer logboeken, aanmelden, recente records, bijlagen, geplande taken en een wegwerpbare schrijfactie. Start de doelstack opnieuw en bevestig dat deze hetzelfde benoemde volume opnieuw aankoppelt. Werk de proxy of DNS pas bij nadat deze controles zijn geslaagd.

Het gerelateerde ZimaSpace-artikel over consistente back-ups van containergegevens helpt als het doel ondanks een geslaagde kopie leeg start. Vergelijk de mountbron van de runtime met het bedoelde volume voordat je gegevens opnieuw kopieert; herhaalde kopieën naar het verkeerde doel zorgen alleen voor meer onduidelijkheid.

Houd de bronapplicatie gestopt en het oude volume alleen-lezen totdat op het doel een nieuwe back-up en hersteltest zijn geslaagd. Voer een rollback uit door het verkeer terug te sturen naar de ongewijzigde bron, maar alleen als er op het doel geen nieuwe schrijfbewerkingen zijn geaccepteerd; stop anders en stem de gegevens opzettelijk op elkaar af.