Kontrolní seznam migrace VPS: zálohy, DNS, TLS a návrat
Praktický postup migrace pro vlastní aplikaci: inventář, konzistentní zálohy, otestovaný cíl, řízené zápisy, přepnutí DNS a cesta obnovy.
Na první pohled
Řízená migrace VPS provádí inventář služeb a dat, vytváří konzistentní zálohu, ověřuje obnovený cíl, testuje hostname a směrování TLS, koordinuje závěrečné zápisy a DNS a zachovává návrat s ohledem na data. Žádný kontrolní seznam sám o sobě nezaručuje nulové výpadky.
Před přesunem proveďte inventář aplikace
Uveďte služby, verze, porty, plánované úlohy, databáze, nahrávané soubory a konfiguraci potřebnou k fungování aplikace. Určete, kde dochází k zápisům a na kterých externích službách závisí. Zkopírovaný webový adresář není úplná migrace, když data žijí jinde.
Zaznamenejte aktuální názvy DNS, aktivní záznamy IPv4 a IPv6, způsoby obnovy certifikátů a cestu přístupu pro obnovu. Tajné klíče uchovávejte ve svých soukromých nástrojích pro nasazení. Nevkládejte hesla, soukromé klíče ani výpisy databáze do veřejného kořene dokumentů nebo do sdíleného kontrolního seznamu migrace.
Vytvořte konzistentní zálohu a prokažte, že se obnoví
Použijte mechanismus zálohování podporovaný databází, místo abyste kopírovali libovolné soubory, dokud zápisy pokračují. U SQLite vytváří Online Backup API konzistentní snímek databáze. V režimu WAL se soubor WAL podílí na trvalém stavu databáze, takže kopírování pouze hlavního souboru databáze může vynechat potvrzené změny.
Konzistentní záloha databáze není automaticky konzistentní se samostatně uloženými nahrávanými soubory, frontami nebo soubory. Jejich zachycení slaďte se svou aplikací. Obnovte do samostatného testovacího umístění a před tím, než zálohu budete považovat za použitelnou, ověřte záznamy, odkazy na soubory a chování aplikace.
Připravte cíl před změnou DNS
Na novém serveru vytvořte zamýšlené uživatele, oprávnění, verze runtime, služby a adresáře aplikace. Obnovte testovací zálohu do cílového umístění dat, kde je to vhodné mimo veřejný webový kořen. Zkontrolujte vlastnictví a přístup pomocí servisního účtu, který bude aplikaci skutečně spouštět.
Na sdíleném serveru zachovejte nesouvisející weby. Použijte vyhrazený kořen dokumentů, virtuální hostitel a runtime, ověřte konfiguraci webového serveru a připravte návrat, který obnoví pouze soubory a konfiguraci patřící této změně.
Otestujte skutečné hostname a certifikát na novém serveru
Požadavek prohlížeče na holou IP adresu nereprodukuje směrování podle hostname ani ověření certifikátu. curl --resolve umožňuje testu použít zamýšlený hostname a zvolenou cílovou IP adresu při zachování běžných kontrol hostname a TLS. Zkontrolujte také stav HTTP a očekávaný obsah aplikace. Příklad používá hodnoty pouze pro dokumentaci; nahraďte je vlastní ověřenou doménou a cílem.
Aby tento test prošel, musí již existovat platný certifikát a povolená síťová cesta. Nikdy nevypínejte ověřování certifikátu, abyste migraci prohlásili za připravenou. Ověření ACME založené na DNS může ověřit doménu bez změny adresy jejího webového serveru; ověření založené na HTTP má jiné požadavky na dosažitelnost. Testujte obnovu odděleně od počátečního vydání.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Zvolte plán řízení zápisů a závěrečné synchronizace
Naplánujte krátké období údržby nebo jiný mechanismus konzistence vhodný pro aplikaci. Zastavte nebo přesměrujte zapisující procesy, které jste identifikovali, pořiďte závěrečnou konzistentní zálohu databáze, synchronizujte odpovídající měnitelné soubory a výsledek ověřte. Pracovníci front, webhooky a úlohy cron mohou zapisovat, i když veřejné rozhraní vypadá klidně.
Před synchronizací souborů použijte zkušební běh. Nepřidávejte příznaky mazání ani nekopírujte celé systémové adresáře jako zkratku. Udržujte starou službu obnovitelnou, dokud nezkontrolujete novou aplikaci a nestanovíte, které umístění je autoritativní pro zápisy.
Změňte DNS, poté sledujte obě rodiny adres
Aktualizujte záznamy potřebné pro službu a počítejte s existujícími mezipamětmi resolverů. Zkontrolujte autoritativní odpovědi a několik běžných klientských cest. Pokud zůstane aktivní zastaralý záznam AAAA, klienti IPv6 mohou dál dosáhnout starého serveru, zatímco klienti IPv4 dosáhnou nového.
Na nové službě otestujte přihlášení, čtení, zápisy, nahrávání, úlohy na pozadí a externí zpětná volání. Během přechodu se vyhněte provozu dvou nezávislých zapisovatelných kopií stejné aplikace. Mějte jasné pravidlo pro zpracování provozu, který stále dorazí na starý cíl.
Udělejte z návratu rozhodnutí o datech i rozhodnutí o DNS
Definujte podmínky selhání, které spustí návrat, a kdo řídí přepnutí. Pouhé vrácení DNS nestačí poté, co na cíl dorazily nové zápisy: tato data musíte zachovat nebo sladit před návratem ke starší kopii.
Zdroj a zálohy uchovávejte po přiměřenou dobu obnovy. Starý přístup odeberte a prostředky vyřaďte až poté, co byly zkontrolovány cíl, zálohy, obnova a monitorování. Uchovávání a mazání by se měly řídit skutečnými zásadami služby, ne obecným pevným počtem hodin.