SOUKROMÁ OFFSHORE INFRASTRUKTURA
Web a onionAplikované · 4 min čtení

Runbook přepnutí domény, DNS a TLS na nový server

Připravte společně směrování hostname, certifikáty a rollback, aby migrace změnila server, aniž by narušila identitu webu nebo zabezpečená připojení.

Od SwissOctet Editorial
PŘÍMÁ ODPOVĚĎ

Připravte server a certifikát pro zamýšlený hostname, otestujte aplikaci před změnou veřejného DNS a během přechodu ponechte staré prostředí dostupné. Ověřte autoritativní záznamy, odpovědi v mezipaměti a TLS nezávisle. Samotná aktualizace DNS neprokazuje, že je obsluhována správná aplikace a certifikát.

01

Zinventarizujte názvy a závislosti

Vypište každý hostname, který web používá, včetně hlavní domény, aliasů, koncových bodů API a zpětných volání aplikace. Zaznamenejte, kdo kontroluje registraci a autoritativní DNS. Hostování aplikace automaticky neregistruje její doménu ani nedává operátorovi serveru kontrolu nad jejími záznamy. Uchovejte přístup ke stávajícímu prostředí, dokud není nové ověřeno.

Určete také e-mailové a ověřovací záznamy třetích stran, které má přesun zachovat. Migrace webu by neměla bez rozmyslu nahradit celou zónu DNS. Vytvořte plán změn na úrovni záznamů se zamýšlenými adresami a hodnotou pro rollback. Přihlašovací údaje ukládejte v soukromí; runbook potřebuje vlastníky a postupy, nikoli skutečná hesla nebo tokeny API.

02

Připravte směrování hostname na novém serveru

Stroj přijímající připojení musí pro svůj hostname obsluhovat zamýšlenou aplikaci. Nakonfigurujte webový server nebo hostingový panel odpovídajícím způsobem, s veřejným kořenovým adresářem dokumentů odděleným od soukromé konfigurace a přihlašovacích údajů. Otestujte všechny požadované názvy a přesměrování, nejen obecnou uvítací stránku dostupnou přes adresu serveru.

Použijte řízenou testovací metodu, která před veřejnou změnou odešle zamýšlený hostname na nový koncový bod. Podle potřeby zkontrolujte přihlášení, nahrávání a odkazy generované aplikací. Během testování zakažte úlohy, které by mohly duplikovat produkční akce. Test by měl prokázat chování aplikace, aniž by odesílal skutečnou poštu, přijímal platby nebo neúmyslně měnil starou živou databázi.

03

Zvolte metodu ověření certifikátu

Vydání certifikátu vyžaduje prokázání kontroly nad požadovanými názvy. Let's Encrypt dokumentuje mimo jiné metody ověření HTTP-01 a DNS-01. Ověření HTTP závisí na správném obsloužení požadované výzvy; ověření DNS používá určený záznam DNS a může podporovat vydání divokého certifikátu. Zvolte metodu, která odpovídá skutečnému nasazení a lze ji bezpečně udržovat.

Pokud je to možné, udržujte ověřovací přihlašovací údaje úzce vymezené. Automatizace DNS je obzvláště citlivá, protože široké přihlašovací údaje DNS mohou ovlivnit více než jeden web. Naplánujte obnovu certifikátu a způsob, jak se obnovené soubory dostanou do obslužného procesu. Úspěšné první vydání je užitečné, ale web také potřebuje funkční proces obnovy a monitorování certifikátu, který skutečně předkládá.

04

Naplánujte okno mezipaměti před změnou DNS

Záznamy DNS nesou time-to-live, který překladače používají při ukládání odpovědí do mezipaměti. Změna záznamu okamžitě nenahradí každý výsledek v mezipaměti. Pokud přechodu prospěje kratší TTL, naplánujte úpravu dostatečně včas, aby dříve uložené odpovědi mohly vypršet. Udržujte staré i nové prostředí schopné zvládnout přechod, který jste navrhli.

Tento ilustrativní sled odděluje přípravu od veřejného přepnutí. Jeho načasování je třeba přizpůsobit doméně, chování překladačů a aplikaci. Nejde o univerzální plán propagace. Migrace zahrnující živé zápisy také potřebuje datové přepnutí specifické pro aplikaci, protože dva funkční webové servery by jinak mohly přijímat změny do různých datových sad.

FázeAkcePodmínka před pokračováním
PřípravaZinventarizujte záznamy a nakonfigurujte nový koncový bodAplikace funguje pro zamýšlené názvy
CertifikátVydání a instalace certifikátuSprávný řetězec a hostname se ověří
PřechodAktualizujte pouze plánované záznamy DNSDatové přepnutí a rollback jsou definovány
PozorováníZkontrolujte autoritativní výsledky a výsledky klientůUživatelské cesty uspějí přes nový koncový bod
DokončeníPo ověření vyřaďte starou službuZbytkový provoz a potřeby obnovy jsou zkontrolovány
05

Ověřte DNS a TLS samostatně

Nejprve zkontrolujte autoritativní záznam a poté porovnejte odpovědi od klientů nebo překladačů zapojených do přechodu. Správná autoritativní hodnota a starší hodnota v mezipaměti mohou existovat současně. Zkontrolujte koncový bod, kterého dosáhl prohlížeč, místo abyste předpokládali, že každé připojení již používá novou adresu. Uchovávejte pozorování s časovými značkami, aby byl přechod srozumitelný.

U TLS ověřte zamýšlený hostname, platnost certifikátu a řetězec prostřednictvím skutečného klientského připojení. Zkontrolujte každý požadovaný alias a cestu přesměrování. Dokumentace Mozilla k TLS vysvětluje ověřování serveru a problémy se smíšeným obsahem: stránka a její dílčí zdroje by měly být doručovány bezpečně. Certifikát pro jeden hostname automaticky nepokrývá jiný koncový bod aplikace.

06

Udělejte z rollbacku také datové rozhodnutí

Rollback DNS může přesměrovat provoz, ale nevrátí zápisy provedené v nové aplikaci. Před přepnutím definujte, jak s těmito daty naložíte. U statické publikace může být rollback přímočarý; u služby přijímající nahrávané soubory nebo objednávky potřebuje stav aplikace jasného vlastníka a postup vyrovnání.

Představte si migraci malého publikačního webu s komentáři. Můžete připravit interval údržby nebo řízený přechod pouze pro čtení, zatímco se kopírují konečná data. Otestujte postup opětovného otevření a udržujte staré nasazení připravené. Zvolte přístup, který odpovídá aplikaci, místo abyste změnu DNS použili jako náhradu za plánování konzistence.

07

Po přepnutí web sledujte

Po zahájení provozu na novém koncovém bodu ověřte skutečné uživatelské cesty, míru chyb, předkládání certifikátu a úlohy na pozadí. Potvrďte, že zálohy nyní pokrývají zamýšlenou aplikaci a data. Před vyřazením zkontrolujte přístup ke starému serveru a po vyřešení potřeb obnovy a rollbacku odstraňte zastaralé přihlašovací údaje. Zaznamenejte konečnou konfiguraci DNS a certifikátu.

Při výběru webhostingu nebo výpočetních prostředků SwissOctet potvrďte skutečné odpovědnosti za doménu, certifikát a správu dané konfigurace. Katalog poskytuje hostingový cíl a prostředky; neprokazuje, že vaše doména již byla připojena nebo že byla nakonfigurována obnova certifikátu. Udržujte tyto kroky konkrétní a ověřitelné v plánu nasazení.

PŘEVEĎTE TO V AKCI

Váš praktický kontrolní seznam.

  • Zinventarizujte každý hostname a zachovejte nesouvisející záznamy DNS.
  • Před veřejným přepnutím otestujte směrování hostname.
  • Zvolte a automatizujte vhodnou výzvu certifikátu.
  • Naplánujte změny TTL a datový přechod.
  • Ověřte DNS a TLS samostatnými kontrolami.
  • Před vrácením zachovejte přístup pro rollback a vyřešte nové zápisy.
ČASTÉ OTÁZKY

Podrobnosti, na kterých záleží.

Aktivuje změna záznamu A HTTPS?+

Ne. DNS volí koncový bod; tento koncový bod stále potřebuje správné směrování hostname a platný nainstalovaný certifikát.

Mohu při problému vrátit pouze záznam DNS?+

Provoz lze přesměrovat, ale zápisy aplikace vyžadují samostatné řešení. Před migrací definujte plán datového rollbacku nebo vyrovnání.

Je divoký certifikát vždy nutný?+

Ne. Názvy certifikátů a ověření zvolte podle skutečných hostname. Divoký certifikát má specifické požadavky na pokrytí a ověření; není univerzální zkratkou pro migraci.

PRIMÁRNÍ ZDROJE

Jděte ke zdroji.

Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací.

  1. Let's Encrypt: Typy výzev letsencrypt.org
  2. IETF RFC 1034: Koncepty a možnosti DNS datatracker.ietf.org
  3. Mozilla MDN: Transport Layer Security developer.mozilla.org

Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně.

PROPOJTE ZNALOSTI

Související infrastruktura.

UDRŽTE NIT

Vaše další terénní poznámky.

Prozkoumat všechny průvodce