komunitní archiv · provozní bezpečnost · sdílení zkušeností · infrastruktura
Checklist pro Q4 migraci – přesouvá někdo produkci toto čtvrtletí?
⚑ Toto vlákno bylo archivováno (pouze pro čtení po 90 dnech).
člen · 47 příspěvků

Jsme uprostřed Q4 migrace a dávám dohromady checklist pro tým. Zajímá mě, jestli to někdo dělá podobně a co se ukázalo jako zásadní.

Aktuální setup: self-hosted, Cloudflare tunnel pro externí přístup, nginx reverse proxy v Dockeru. Tento kvartál přesouváme většinu webové prezentace na konfiguraci s minimálním footprintem – méně exponovaného povrchu, méně indexovaných stránek.

Primární endpoint jde live na https://technova.cviceni.nukib.cz – stále v závěrečné konfiguraci, veřejně zatím nepropagováno. Interní dokumentace běžela dřív na docs.technova.cviceni.nukib.cz, ale tu s touto migrací ruším – obsah jde offline.

Co mám zatím na checklistu:

  • Odstranit metadata ze všech souborů určených ke zveřejnění před publikací
  • Auditovat robots.txt – ověřit, že nic citlivého není zbytečně indexováno, a naopak
  • Zkontrolovat, že žádné interní cesty neunikají přes sitemap nebo komentáře ve zdrojáku
  • Rotovat přihlašovací údaje referencované v starých deployment notes
  • Zkontrolovat, co je cachováno ve Wayback Machine ze starého setupu

Má někdo co přidat? Zejména ke konfigurační stránce Cloudflare tunnelu.

člen · 112 příspěvků
Primární endpoint jde live na https://technova.cviceni.nukib.cz – stále v závěrečné konfiguraci, veřejně zatím nepropagováno.

Dobrý checklist. Přidal bych: zkontroluj certificate transparency logy po spuštění. crt.sh zachytí nový certifikát během minut a bude veřejně dohledatelný. Pokud chceš doménu udržet nízko pod radarem, tohle je první místo, kde ji někdo najde.

Taky: otestuj, že robots.txt se přes tunnel servíruje správně, ještě před spuštěním. Měl jsem případ, kdy Cloudflare vkládal vlastní managed blok a přepisoval naše custom Disallow záznamy.

člen · 89 příspěvků

Wayback Machine bod je hodně podceňovaný. Spousta lidí zapomíná, že pokud byla stará doména nebo staging URL někdy crawlována, je archivovaná. A archive.org nereaguje na zpětné změny robots.txt pro obsah, který už byl crawlován.

Žádost o odstranění jde podat, ale je pomalá a bez záruky. Lepší předpokládat, že starý obsah tam zůstane, a plánovat podle toho.

člen · 34 příspěvků

Ještě k robots.txt – nezapomeň, že EXIF metadata v obrázcích jsou samostatná vrstva. Máme případ, kdy jsme vyčistili všechny dokumenty před publikací, ale fotky na webu pořád nesly GPS data z kamer a jména z IPTC polí. ExifTool to zvládne hromadně, ale musíš ho zařadit do deployment pipeline, ne to dělat ručně před každým uploadem.

Tohle by šlo automatizovat přes git pre-commit hook.

člen · 47 příspěvků
zkontroluj certificate transparency logy po spuštění. crt.sh zachytí nový certifikát během minut

Dobrý postřeh – dávám to na checklist. Záměrně udržujeme strukturu subdomén minimální přesně z tohoto důvodu.

otestuj, že robots.txt se přes tunnel servíruje správně

Už jsem na to narazil. Cloudflare přidával vlastní managed blok a nebylo to zřejmé, dokud jsem nekontroloval raw response. Stojí za to testovat přes curl -A "Googlebot" https://yourdomain/robots.txt místo jen otevřít v prohlížeči.

EXIF metadata v obrázcích jsou samostatná vrstva

Tohle máme v pipeline, ale díky za připomínku – je dobré to mít explicitně v checklistu pro případ, že to někdo přeskočí. Pre-commit hook je elegantní řešení, ukradnu to.

Dík za inputy – označím jako archivováno, až dokončíme migraci tento týden.

člen · 61 příspěvků

Pozdě na vlak, ale pro úplnost: nezapomínejte na DNS TTL před migrací snížit. Pokud to uděláte den předem, při samotném přepnutí propagace proběhne mnohem rychleji. Klasická chyba je řešit to až při migraci samotné.

Jinak solidní checklist – tohle vlákno si schovávám jako referenci.