VPS migrációs ellenőrzőlista: biztonsági mentések, DNS, TLS és visszaállítás
Gyakorlati migrációs sorrend egy saját üzemeltetésű alkalmazáshoz: leltár, konzisztens biztonsági mentések, tesztelt célhely, ellenőrzött írások, DNS átállás és egy helyreállítási útvonal.
Egy pillantásra
Egy ellenőrzött VPS migráció leltárba veszi a szolgáltatásokat és adatokat, konzisztens biztonsági mentést készít, ellenőrzi a visszaállított célhelyet, teszteli a gazdagépnév- és TLS útvonalválasztást, összehangolja a végső írásokat és a DNS-t, és adattudatos visszaállítást tart fenn. Egyetlen ellenőrzőlista sem garantál nulla leállást önmagában.
Készíts leltárt az alkalmazásról, mielőtt áthelyezed
Sorol fel minden szolgáltatást, verziót, portot, ütemezett feladatot, adatbázist, feltöltött fájlt és konfigurációt, amelyre az alkalmazásnak a működéshez szüksége van. Azonosítsd, hol történnek írások, és mely külső szolgáltatásoktól függ. Egy másolt webkönyvtár nem teljes migráció, ha az adatok máshol élnek.
Jegyezd fel a jelenlegi DNS neveket, az aktív IPv4 és IPv6 rekordokat, a tanúsítvány-megújítási módszereket és egy helyreállítási hozzáférési útvonalat. A titkokat a privát telepítési eszközeidben tartsd. Ne tedd jelszavakat, privát kulcsokat vagy adatbázis-mentéseket nyilvános dokumentumgyökérbe vagy megosztott migrációs ellenőrzőlistába.
Készíts konzisztens biztonsági mentést, és bizonyítsd, hogy visszaállítható
Az adatbázis által támogatott biztonsági mentési mechanizmust használd, ahelyett hogy tetszőleges fájlokat másolnál, miközben az írások folytatódnak. A SQLite esetén az Online Backup API konzisztens adatbázis-pillanatképet készít. WAL módban a WAL fájl részt vesz az állandó adatbázis-állapotban, így csak a fő adatbázisfájl másolása kihagyhatja a jóváhagyott változtatásokat.
Egy konzisztens adatbázis-biztonsági mentés nem automatikusan konzisztens a külön tárolt feltöltésekkel, sorokkal vagy fájlokkal. Hangold össze azok rögzítését az alkalmazásoddal. Állítsd vissza egy külön teszt-helyre, és ellenőrizd a rekordokat, fájlhivatkozásokat és az alkalmazás viselkedését, mielőtt a biztonsági mentést használhatónak tekintenéd.
Készítsd elő a célhelyet a DNS megváltoztatása előtt
Hozd létre a szándékolt felhasználókat, jogosultságokat, futtatókörnyezet-verziókat, szolgáltatásokat és alkalmazáskönyvtárakat az új szerveren. Állítsd vissza a teszt biztonsági mentést a cél adathelyére, adott esetben a nyilvános webgyökéren kívül. Ellenőrizd a tulajdonjogot és a hozzáférést azzal a szolgáltatásfiókkal, amely ténylegesen futtatni fogja az alkalmazást.
Őrizd meg a nem kapcsolódó webhelyeket egy megosztott szerveren. Használj dedikált dokumentumgyökeret, virtuális gazdagépet és futtatókörnyezetet, érvényesítsd a webszerver-konfigurációt, és készíts elő egy visszaállítást, amely csak az ehhez a változtatáshoz tartozó fájlokat és konfigurációt állítja vissza.
Teszteld a valódi gazdagépnevet és tanúsítványt az új szerveren
Egy böngészőkérés egy csupasz IP-címre nem reprodukálja a gazdagépnév-alapú útvonalválasztást vagy a tanúsítvány-érvényesítést. A curl --resolve lehetővé teszi, hogy egy teszt a szándékolt gazdagépnevet és egy kiválasztott cél-IP-t használjon, miközben megtartja a normál gazdagépnév- és TLS ellenőrzéseket. Ellenőrizd a HTTP-állapotot és a várt alkalmazástartalmat is. A példa csak dokumentációs értékeket használ; cseréld ki őket a saját ellenőrzött domainnevedre és célhelyedre.
A teszt sikerességéhez már léteznie kell egy érvényes tanúsítványnak és egy engedélyezett hálózati útvonalnak. Soha ne tiltsd le a tanúsítvány-ellenőrzést, hogy a migrációt késznek nyilvánítsd. A DNS-alapú ACME érvényesítés érvényesíthet egy domaint a webszerver címe nélkül; a HTTP-alapú érvényesítésnek más elérhetőségi követelményei vannak. A megújítást a kezdeti kiadástól külön teszteld.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Válassz írás-ellenőrzési és végső szinkronizálási tervet
Ütemezz be egy rövid karbantartási időszakot vagy egy másik, az alkalmazáshoz illő konzisztencia-mechanizmust. Állítsd le vagy irányítsd át az általad azonosított írókat, készítsd el a végső konzisztens adatbázis-biztonsági mentést, szinkronizáld a megfelelő változó fájlokat, és ellenőrizd az eredményt. A sorfeldolgozók, webhookok és cron-feladatok akkor is írhatnak, amikor a nyilvános felület csendesnek tűnik.
Fájlszinkronizálás előtt végezz próbafuttatást. Ne adj hozzá törlési jelzőket, és ne másolj teljes rendszerkönyvtárakat gyors megoldásként. Tartsd a régi szolgáltatást helyreállíthatóan, amíg ellenőrizted az új alkalmazást, és megállapítottad, melyik hely az írások hiteles forrása.
Változtasd meg a DNS, majd figyeld mindkét címcsaládot
Frissítsd a szolgáltatáshoz szükséges rekordokat, és számolj a meglévő feloldó-gyorsítótárakkal. Ellenőrizd a hiteles válaszokat és több normál kliensútvonalat. Ha egy elavult AAAA rekord aktív marad, a IPv6 kliensek továbbra is elérhetik a régi szervert, míg a IPv4 kliensek az újat érik el.
Teszteld a bejelentkezést, az olvasásokat, az írásokat, a feltöltéseket, a háttérfeladatokat és a külső visszahívásokat az új szolgáltatáson. Az átmenet során ne futtass két független, írható példányt ugyanabból az alkalmazásból. Tarts egyértelmű szabályt a régi célhelyre még eljutó forgalom kezelésére.
A visszaállítás legyen adatdöntés is, ne csak DNS döntés
Határozd meg azokat a hibafeltételeket, amelyek visszaállítást váltanak ki, és hogy ki irányítja az átállást. A DNS önmagában való visszaállítása nem elég, miután új írások érkeztek a célhelyre: meg kell őrizned vagy össze kell egyeztetned azokat az adatokat, mielőtt visszatérsz egy régebbi példányhoz.
Tartsd meg a forrást és a biztonsági mentéseket egy megfelelő helyreállítási időszakra. A régi hozzáférést csak akkor távolítsd el, és az erőforrásokat csak akkor vond ki, miután a célhelyet, a biztonsági mentéseket, a megújítást és a megfigyelést ellenőrizted. A megőrzésnek és törlésnek a tényleges szolgáltatási irányelvet kell követnie, nem egy általános, rögzített óraszámot.