VPS-migraation tarkistuslista: varmuuskopiot, DNS, TLS ja peruutus
Käytännöllinen migraatiosekvenssi itse isännöidylle sovellukselle: inventaario, johdonmukaiset varmuuskopiot, testattu kohde, hallitut kirjoitukset, DNS siirto ja palautuspolku.
Yhdellä silmäyksellä
Hallittu VPS-migraatio inventoi palvelut ja datan, luo johdonmukaisen varmuuskopion, varmistaa palautetun kohteen, testaa isäntänimen ja TLS reitityksen, koordinoi lopulliset kirjoitukset ja DNS sekä säilyttää datatietoisen peruutuksen. Mikään tarkistuslista yksinään ei takaa nollakatkoa.
Inventoi sovellus ennen sen siirtämistä
Listaa palvelut, versiot, portit, ajoitetut tehtävät, tietokannat, ladatut tiedostot ja sovelluksen toimintaan tarvittava kokoonpano. Tunnista, missä kirjoitukset tapahtuvat ja mistä ulkoisista palveluista se on riippuvainen. Kopioitu verkkohakemisto ei ole täydellinen migraatio, kun data sijaitsee muualla.
Kirjaa nykyiset DNS nimet, aktiiviset IPv4 ja IPv6 tietueet, varmenteen uusimismenetelmät ja palautuskäyttöoikeuspolku. Pidä salaisuudet yksityisessä käyttöönottotyökaluissasi. Älä laita salasanoja, yksityisiä avaimia tai tietokantavedoksia julkiseen dokumenttijuurihakemistoon tai jaettuun migraation tarkistuslistaan.
Luo johdonmukainen varmuuskopio ja todista, että se palautuu
Käytä tietokannan tukemaa varmuuskopiomekanismia sen sijaan, että kopioisit mielivaltaisia tiedostoja kirjoitusten jatkuessa. SQLite osalta Online Backup API luo johdonmukaisen tietokantapikakuvan. WAL tilassa WAL tiedosto osallistuu pysyvään tietokannan tilaan, joten vain päätietokantatiedoston kopioiminen voi jättää pois vahvistetut muutokset.
Johdonmukainen tietokantavarmuuskopio ei ole automaattisesti johdonmukainen erikseen tallennettujen latausten, jonojen tai tiedostojen kanssa. Koordinoi niiden tallennus sovelluksesi kanssa. Palauta erilliseen testisijaintiin ja varmista tietueet, tiedostoviitteet ja sovelluksen käyttäytyminen ennen kuin pidät varmuuskopiota käyttökelpoisena.
Valmistele kohde ennen DNS muuttamista
Luo aiottu käyttäjät, käyttöoikeudet, ajonaikaiset versiot, palvelut ja sovellushakemistot uudelle palvelimelle. Palauta testivarmuuskopio kohteen tietosijaintiin, tarvittaessa julkisen verkkohakemiston ulkopuolelle. Tarkista omistajuus ja käyttöoikeus palvelutilillä, joka todella ajaa sovellusta.
Säilytä muut sivustot jaetulla palvelimella. Käytä erillistä dokumenttijuurta, virtuaali-isäntää ja ajonaikaista ympäristöä, validoi web-palvelimen kokoonpano ja valmistele peruutus, joka palauttaa vain tämän muutoksen omistamat tiedostot ja kokoonpanon.
Testaa todellinen isäntänimi ja varmenne uudella palvelimella
Selaimen pyyntö pelkkään IP-osoitteeseen ei toista isäntänimeen perustuvaa reititystä tai varmenteen validointia. curl --resolve antaa testin käyttää aiottua isäntänimeä ja valittua kohde-IP-osoitetta säilyttäen samalla normaalin isäntänimen ja TLS tarkistukset. Tarkista myös HTTP-tila ja odotettu sovellussisältö. Esimerkki käyttää vain dokumentaatioarvoja; korvaa ne omalla vahvistetulla verkkotunnuksellasi ja kohteellasi.
Voimassa olevan varmenteen ja sallitun verkkopolun on jo oltava olemassa, jotta testi onnistuu. Älä koskaan poista varmenteen vahvistusta käytöstä kutsuaksesi migraatiota valmiiksi. DNS-pohjainen ACME validointi voi validoida verkkotunnuksen muuttamatta sen web-palvelimen osoitetta; HTTP-pohjaisella validoinnilla on erilaiset tavoitettavuusvaatimukset. Testaa uusiminen erikseen alkuperäisestä myöntämisestä.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Valitse kirjoituksen hallinta- ja loppusynkronointisuunnitelma
Ajoita lyhyt huoltokatko tai muu sovellukselle sopiva johdonmukaisuusmekanismi. Pysäytä tai uudelleenohjaa tunnistamasi kirjoittajat, ota lopullinen johdonmukainen tietokantavarmuuskopio, synkronoi vastaavat muuttuvat tiedostot ja varmista tulos. Jonotyöntekijät, webhookit ja cron-tehtävät voivat kirjoittaa, vaikka julkinen käyttöliittymä näyttäisi hiljaiselta.
Käytä kuivaharjoittelua ennen tiedostojen synkronointia. Älä lisää poistolippuja tai kopioi kokonaisia järjestelmähakemistoja oikotienä. Pidä vanha palvelu palautettavana, kunnes olet tarkistanut uuden sovelluksen ja selvittänyt, mikä sijainti on kirjoitusten kannalta authoritative.
Muuta DNS, tarkkaile sitten molempia osoiteperheitä
Päivitä palvelun edellyttämät tietueet ja ota huomioon olemassa olevat resolver-välimuistit. Tarkista authoritative-vastaukset ja useat normaalit asiakaspolut. Jos vanhentunut AAAA tietue jää aktiiviseksi, IPv6 asiakkaat voivat edelleen tavoittaa vanhan palvelimen, kun taas IPv4 asiakkaat tavoittavat uuden.
Testaa kirjautuminen, lukeminen, kirjoittaminen, lataukset, taustatyöt ja ulkoiset takaisinkutsut uudessa palvelussa. Vältä kahden itsenäisen kirjoitettavan kopion ajamista samasta sovelluksesta siirtymän aikana. Pidä selkeä sääntö liikenteen käsittelylle, joka tavoittaa edelleen vanhan kohteen.
Tee peruutuksesta sekä datapäätös että DNS päätös
Määrittele vikatilanteet, jotka laukaisevat peruutuksen, ja kuka valvoo siirtoa. Pelkkä DNS palauttaminen ei riitä, kun uudet kirjoitukset ovat saavuttaneet kohteen: sinun on säilytettävä tai sovitettava kyseinen data ennen paluuta vanhempaan kopioon.
Pidä lähde ja varmuuskopiot asianmukaisen palautumisjakson ajan. Poista vanhat käyttöoikeudet ja poista resurssit käytöstä vasta, kun kohde, varmuuskopiot, uusiminen ja valvonta on tarkistettu. Säilytyksen ja poistamisen tulee noudattaa todellista palvelukäytäntöä, ei yleistä kiinteää tuntimäärää.