Valmistele ja testaa uusi palvelin ensin, kopioi tiedot sovelluksen tukemalla johdonmukaisuusmenetelmällä, määritä käyttöönottoikkuna ja säilytä vanha ympäristö. Palautuksen on huomioitava uudella palvelimella hyväksytyt kirjoitukset, ei vain DNS-muutos.
Kartoita palvelu ennen koneen siirtämistä
Siirto sisältää muutakin kuin sovellustiedostot. Luettele tietokannat, lataukset, ajoitetut työt, jonotyöntekijät, varmenteet, verkkotunnukset, salaisuudet ja lähtevät integraatiot. Kirjaa ohjelmistoversiot ja olennaiset käyttöoletukset, kuten tiedostojen käyttöoikeudet ja tallennuspolut. Uusi dedikoitu palvelin voi paljastaa unohdetun riippuvuuden, joka asennettiin hiljaisesti vuosia aiemmin vanhaan ympäristöön.
Nimeä käyttöönottopäätökselle omistaja ja määritä, miltä onnistuminen näyttää. Sisällytä käyttäjälle näkyvät tarkistukset, tietojen johdonmukaisuus ja kyky palauttaa pääsy. Varmista, että uusi kokoonpano on toimitettu ja käyttökelpoinen, ennen kuin ilmoitat siirtopäivämäärän. Tilausvahvistus tai lueteltu laitteistomääritys ei ole sama asia kuin toimiva kohde, joka on valmis vastaanottamaan tuotantotietoja.
Rakenna kohde erillisenä ympäristönä
Asenna tarvittava ohjelmistopino, luo ylläpito ja määritä aiottu palomuuri. Pidä salaisuudet yksityisinä ja aseta palvelun käyttöoikeudet harkiten. Varmista sovelluksen odotettu isäntänimi ja varmenteen käyttäytyminen ennen julkisen liikenteen siirtämistä. Apache:n virtual host -dokumentaatio havainnollistaa, miksi isäntänimen reititys on erillinen kokoonpanopäätös palvelimen osoitteesta. Toimiva oletussivu ei todista, että oikea sovelluksen isäntä on määritetty.
Käytä harjoitteluun edustavaa palautettua tietojoukkoa, jossa lähtevä sähköposti, maksut ja ajoitetut työt on poistettu käytöstä tai ohjattu turvallisiin testijärjestelmiin. Tämä estää testiympäristöä toimimasta todellisten käyttäjien kanssa. Harjoittele kirjautumista, latauksia, taustatyötä ja palautusta. Kirjaa menettely ja sen kesto, jotta todellinen ikkuna perustuu havaittuun prosessiin eikä optimismiin.
Valitse johdonmukainen tietoraja
Käytä tietokannan ja sovelluksen tukemaa varmuuskopiointi- tai replikointimenetelmää. PostgreSQL erottaa SQL-dumpit, tiedostojärjestelmän varmuuskopiot ja jatkuvan arkistoinnin, joilla kullakin on omat oletuksensa. Sen dump-ohjeet huomauttavat, että tietokantadumpit voivat olla sisäisesti johdonmukaisia, kun taas klusterin laajuiset roolit ja muut yksityiskohdat vaativat erillisen käsittelyn. Lue tarkkoja vaatimuksia käyttämällesi järjestelmälle sen sijaan, että kopioisit avoimia datatiedostoja valikoimatta.
Suunnittele, miten tietokanta liittyy latauksiin ja jonon tilaan. Jos tietue viittaa tiedostoon, joka kopioitiin eri aikaan, palautettu sovellus voi olla puutteellinen, vaikka molemmat kopiot onnistuivat erikseen. Päätä, keskeytetäänkö kirjoitukset lyhyesti, käytetäänkö testattua replikointijärjestelyä vai suoritetaanko sovelluskohtainen vienti. Pidä tämä johdonmukaisuuspäätös selkeästi runbookissa.
| Vaihe | Vaadittu todiste | Päätös |
|---|---|---|
| Harjoittelu | Sovellus ja palautetut tiedot läpäisevät tarkistukset | Kohdetta voidaan harkita käyttöönottoon |
| Lopullinen synkronointi | Määritetty johdonmukainen palautuspiste | Jatka vain ymmärrettyjen jäljellä olevien muutosten kanssa |
| Liikenteen vaihto | Oikea reititys ja varmenteen käyttäytyminen | Valvo molempia kohteita |
| Palautus | Kaikkien uusien hyväksyttyjen kirjoitusten sijainti | Täsmäytä tiedot ennen liikenteen palauttamista |
Valmistele liikenteen reititys lupaamatta välittömiä muutoksia
DNS time-to-live -asetus määrittää, kuinka kauan tietueita voidaan välimuistittaa, kuten Cloudflaren DNS-dokumentaatiossa selitetään. Tarkista TTL varhain, jos DNS on osa siirtoa, ja anna olemassa olevien välimuistitietueiden vanhentua aiemman asetuksensa mukaisesti. Arvon muuttaminen käyttöönottohetkellä ei voi jälkikäteen lyhentää jokaista välimuistivastausta. Eri asiakkaat voivat saavuttaa eri kohteita siirtymän aikana.
Pidä vanha ympäristö saatavilla, kunnes reititysmuutokset vakiintuvat, ja määritä harkiten, voiko se edelleen hyväksyä kirjoituksia. Vältä päällekkäisten jonokuluttajien tai ajoitettujen töiden suorittamista, ellei sovellus ole suunniteltu siihen. Valvo pyyntöjä molemmilla puolilla ja vahvista aiottu isäntänimi, TLS-varmenne ja sovellusversio riippumattomilta asiakkailta.
Määritä palautus sen jälkeen, kun kirjoitukset alkavat
Ennen kuin uusi järjestelmä hyväksyy muutoksia, paluuliikenne voi olla suhteellisen yksinkertaista. Sen jälkeen pelkkä DNS-palautus voi hävittää työtä tai luoda kaksi ristiriitaista historiaa. Määrittele, miten äskettäin luodut tietueet ja lataukset säilytetään tai sovitetaan yhteen. Jos sovellus ei voi yhdistää niitä turvallisesti, hallittu huoltokatko voi olla parempi kuin improvisoitu paluu vanhaan kopioon.
Aseta ehdot, jotka edellyttävät siirron keskeyttämistä, ja pidä päätöksentekijä tavoitettavissa. Säilytä lokit ja hyödylliset todisteet projektin säilytyskäytäntöjen mukaisesti. Älä poista vanhaa konetta tai sen itsenäistä palautuskopiota pelkästään siksi, että etusivu latautui kerran. Säilytysajan tulee kattaa sovitut varmistus- ja palautustarpeet.
Päätä siirto operatiivisiin tarkistuksiin
Käyttöönoton jälkeen varmista varmuuskopiot, hälytykset, sertifikaatin uusiminen, ajoitetut työt ja käyttöoikeuksien palautus. Varmista, että valvottu isäntä on uusi kohde ja että tuotantoon ei jää testi-integraatioita. Tarkastele sovelluksen virheitä ja käyttäjälle näkyviä aikoja tavanomaisessa liikenteessä. Päivitä inventaario ja runbook, jotta seuraavan ylläpitäjän ei tarvitse päätellä, mikä muuttui.
SwissOctet:n erilliset tuoteperheet tarjoavat erilaisia fyysisiä kokoonpanoja, mutta siirtotyö ja hallittu tuki on vahvistettava valitulle palvelulle. Valitse luettelosta sopivat resurssit ja rakenna sitten testattu siirto sovelluksesi tietojen ympärille. Siirto on valmis, kun palvelu ja sen palautusprosessi toimivat kohteessa, ei pelkästään silloin, kun tiedostot on siirretty.
Käytännön tarkistuslistasi.
- Inventoi tiedot, työt, salaisuudet ja integraatiot.
- Varmista toimitettu kohde ennen ajoittamista.
- Harjoittele turvallisilla ulkoisilla integraatioilla.
- Määrittele tietokannan ja latausten yhdenmukaisuus.
- Suunnittele reitityksen siirtymä ja päällekkäisten töiden estäminen.
- Määrittele uusien kirjoitusten palautus.
- Varmista varmuuskopiot ja valvonta käyttöönoton jälkeen.
Olennaiset yksityiskohdat.
Voinko siirtää kopioimalla sovellushakemiston?+
Vain jos se tallentaa kaiken, mitä palvelu tarvitsee, ja säilyttää yhdenmukaisuuden. Tietokannat, lataukset, työt, salaisuudet ja kokoonpano vaativat yleensä erillistä huomiota.
Teksekö DNS-TTL:n lyhentäminen käyttöönotosta välittömän?+
Ei. Aiemmin välimuistiin tallennetut vastaukset voivat säilyä, kunnes niiden aiempi elinikä päättyy, ja asiakkaat voivat päivittyä eri aikoina.
Onko palautus vain DNS:n osoittamista vanhaan palvelimeen?+
Ei sen jälkeen, kun uusi palvelin hyväksyy kirjoituksia. Sinun on otettava huomioon ne tietueet ja tiedostot ennen liikenteen palauttamista.
Mene lähteelle.
Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista.
- PostgreSQL: Varmuuskopiointi ja palautus www.postgresql.org
- PostgreSQL: SQL-dumpin yhdenmukaisuus ja palautus www.postgresql.org
- Apache: Virtual Host -dokumentaatio httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen.