Offshore Hosting'e Kesintisiz Geçiş

Hiç kimse canlı bir siteyi eğlence olsun diye taşımaz. Bunun nedeni, mevcut sağlayıcının aniden pasaportunuzun bir fotoğrafını istemesi, yirmi dört saatlik bir süre tanıyan bir şikayeti size iletmesi ya da veri merkezinin bulunduğu ülkenin artık verinizi tutmak için makul bir yer gibi görünmemesidir. Sizi iten sebep ne olursa olsun, taşınmanın kendisi tehlikeli olan kısımdır — sitenin karanlığa gömülebileceği tek an odur, ve dikkatsiz bir adımın yeni sunucuyu geride bırakmaya çalıştığınız kimliğe zımbalayabileceği tek andır.

İki riskin de tedavisi aynıdır ve bu bir araç değildir. Sıralamadır. Doğru sırayla yürütülen bir taşıma işleminde sitenin erişilemez olduğu bir pencere yoktur, çünkü iki sunucu da aynı anda çalışır durumdadır ve DNS taşınan en son şeydir. Yanlış sırayla yürütülen bir taşıma işlemi ise aynı anda hem bir kesinti hem de bir iz üretir. Aşağıdaki sıralama, iki ana akım sağlayıcı arasında geçiş yapmak yerine offshore, KYC'siz bir sağlayıcıya taşınan biri için yazılmıştır — mekanik aynıdır, ama sonrasındaki temizlik aynı değildir.

“Sıfır kesinti” gerçekte ne anlama gelir

Bu ifade gelişigüzel kullanılıyor ve insanların canı da tam bu gevşeklik yüzünden yanıyor. İki makineden aynı anda HTTP sunmak kolaydır. İki makine aynı anda hizmet verirken durumu tutarlı tutmak ise zor olan kısımdır ve veri kaybına yol açabilecek tek kısım da budur. Bu yüzden herhangi bir şey planlamadan önce, gerçekte hangisini işlettiğinize karar verin, çünkü cevap tüm gecenin şeklini belirler.

Yalnızca ilk satırın gerçekten bedava olduğuna dikkat edin. Diğer her yerde “sıfır kesinti”, “kimsenin bilet açmayacağı kadar kısa bir yazma dondurması” anlamına gelir. Saat 04:00'te iki dakikalık salt okunurluk bir yuvarlama hatasıdır; iki veritabanı arasında iki saatlik bölünmüş yazma ise bir hafta sonu süren uzlaştırma demektir. Dondurmayı seçin.

DNS TTL'yi taşımayı planladığınız günden günler önce düşürün

Bu, kendine özgü bir hazırlık süresi olan tek adımdır; bu yüzden hem ilk sırada gelir hem de insanların atladığı adımdır. TTL'niz — yaşam süresi — internetteki her resolver'a kaydınızı tekrar sormadan önce ne kadar süre önbellekte tutabileceğini söyler. A kaydınızın TTL'si 86400 ise, kaydı bir saat önce sorgulamış bir resolver, kayıt şirketinde ne değiştirirseniz değiştirin eski IP'yi bir yirmi üç saat daha vermeye devam eder.

Kritik ayrıntı şudur: TTL'yi düşürmenin kendisi de eski TTL'ye tabidir. Resolver'lar yeni, daha kısa değeri ancak önbellekteki eski kopyanın süresi dolduğunda öğrenir. Bu yüzden TTL'yi geçiş yapmadan en az bir tam eski-TTL süresi önce 300 saniyeye düşürün — bir günlük bir TTL için bu, işlemi 24 ila 48 saat önceden yapmak anlamına gelir. O zaman dünya, değişiklikten sonraki beş dakika içinde yeni kaydınızda birleşir ve geçiş, gerilimli bir olay olmaktan çıkar.

Taşımadan birkaç gün sonra TTL'yi yine makul bir değere geri çıkarın. 300 saniyelik bir TTL iyi bir araçtır ama zayıf bir kalıcı ayardır: sorgu hacminizi katlar ve DNS sağlayıcınızı çok daha keskin bir tek arıza noktasına dönüştürür.

Hafızanızdakini değil, gerçekte taşıdığınızı envanterleyin

Başarısız her taşıma işleminin ölüm-sonrası raporu aynıdır: kimsenin listelemediği bir şey kopyalanmamıştır. Web kök dizini ve veritabanı herkesin hatırladığı iki şeydir; aşağıdaki liste geri kalanıdır ve hafızadan değil, gerçekten madde madde gezmeye değer.

• Zamanlanmış işler. Her kullanıcı için crontab -l, ayrıca systemd timer'ları. Yenileme hook'ları ve gecelik işler burada saklanır.
• Servis tanımları. Özel systemd unit'leri, web sunucusu vhost'ları, PHP-FPM havuzları, herhangi bir supervisor yapılandırması.
• Sırlar ve ortam. .env dosyaları, API anahtarları, veritabanı parolaları, uygulama salt'ları — ve bunların yalnızca kopyalanması değil, döndürülmesi gerektiğini unutmayın.
• TLS materyali. Sertifikalar ve, daha da önemlisi, ACME hesabı ve yenileme yapılandırması.
• Mail kimliği. DKIM özel anahtarları, SPF ve DMARC kayıtları. Buradaki bir uyumsuzluk gürültülü şekilde bozulmaz; sessizce mailinizi spam'e gönderir.
• Yüklenmiş medya. Sık sık web kök dizininin dışındadır, sık sık sahip olduğunuz en büyük şeydir.
• IP'nize güvenen dışarıdaki her şey. Ödeme ağ geçidi izin listeleri, webhook hedefleri, veritabanı güvenlik duvarları, IP kısıtlaması olan üçüncü taraf API'ler. Saat 03:00'te “site çalışıyor ama ödeme sayfası bozuk” durumunun bir numaralı sebebi budur.
• Paket listesi. dpkg --get-selections ya da eşdeğeri, böylece yeni makinede neredeyse aynı değil, tam olarak aynı eklentiler ve kütüphaneler olur.

Kopyalamaya başlamadan önce listeyi yazın. Envanter aynı zamanda daha sonraki test planınızdır — üzerindeki her satır, DNS onun varlığını öğrenmeden önce yeni sunucuda doğrulanması gereken bir şeydir.

Önce yeni sunucuyu kurun, üzerinde bir şey barındırmadan önce sıkılaştırın

Hedef sunucuyu erkenden sipariş edin ve bir iki gün boş, çalışır halde bırakın. Bu örtüşmenin bir maliyeti yoktur — küçük bir offshore VPS ayda birkaç dolardır — ve kurulumu, dondurulmuş bir veritabanı beklerken zaman baskısı altında yapmamanın büyük bir değeri vardır.

Eski ortamı bilinçli olarak eşleştirin: aynı dağıtım ve ana sürüm, aynı PHP, Node veya Python ana sürümü, aynı veritabanı ana sürümü. İşin içindeyken modernleştirme isteği çok büyüktür ve buna tamamen direnilmelidir. Site geçişten sonra bozulursa, değişmiş olanın tam olarak tek bir değişken olmasını istersiniz. Yığını iki hafta sonra, sıradan bir öğleden sonra, geri dönme imkanınız varken yükseltin.

Sunucu hâlâ boşken sıkılaştırın. Yalnızca anahtarla SSH, varsayılan olarak reddeden bir güvenlik duvarı, otomatik güvenlik güncellemeleri — ilk saat sıkılaştırma kontrol listesi tam olarak bu listedir ve üzerinde hiçbir şey olmayan bir makineye uygulamak çok daha kolaydır. Veri, yargı alanı değiştirecek kadar hassassa, bekleme halinde şifrelemeye karar vermek için de doğru an tam olarak budur, çünkü bunu sonradan eklemek başka bir taşıma işlemi demektir.

Veriyi iki kez kopyalayın: önce yavaş bir geçiş, sonra hızlı bir geçiş

İçgüdü, her şeyi bakım penceresi sırasında kopyalamaktır. Tam tersini yapın. Eski site memnuniyetle trafik sunarken günler öncesinden tam bir kopya çalıştırın, sonra geçiş anında yalnızca değişeni taşıyan ikinci bir geçiş yapın. İlk geçiş altı saat sürebilir ve kimse fark etmez. İkincisi doksan saniye sürer ve tüm kesinti bütçeniz de budur.

Dosyalar için rsync -aHAX --numeric-ids izinleri, sahipliği, hard link'leri ve genişletilmiş öznitelikleri korur; --numeric-ids bayrağı önemlidir çünkü UID'ler yeni kurulmuş iki makine arasında nadiren örtüşür. Bunu bir kez erkenden, sonra geçişten hemen önce aynı argümanlarla tekrar çalıştırın — ikinci çalıştırma yalnızca farkı (delta) aktarır.

Veritabanları aynı iki aşamalı muameleyi ister ama farklı araçlarla. Bir mysqldump --single-transaction ya da pg_dump, üzerinde kurulum yapıp test edebileceğiniz tutarlı, erken bir anlık görüntü verir. Geçiş anında ya kısa yazma dondurmanız sırasında ikinci bir döküm alın, ya da — kısa bir dondurmanın bile canını yaktığı büyük bir veritabanı için — yeni sunucuyu günler öncesinden eskisinin bir replikası olarak kurun, yakalamasına izin verin, sonra terfi ettirin. Replikasyon, dondurmayı saniyelere indirir. Ama aynı zamanda iki saatlik bir taşıma işlemini iki günlük bir projeye dönüştürür, bu yüzden yalnızca boyut bunu gerçekten gerektirdiğinde kullanın.

DNS varlığını öğrenmeden önce yeni sunucuyu test edin

Gerçek ana bilgisayar adını tek bir genel kaydı bile değiştirmeden yeni IP'den sunabilirsiniz, ve bunu yapmalısınız da — geçişi olaysız kılan şey budur. Yerel /etc/hosts dosyanıza alan adını yeni IP'ye yönlendiren bir satır ekleyin, ya da bunu atlayıp curl'e tek bir istek için bunu yaptırın:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Şimdi envanteri gezin. Ana sayfayı ve üç derin sayfayı yükleyin. Giriş yapın. Bir form gönderin. Bir dosya yükleyin. Veritabanı bağlantısının yeni, yerel olan bağlantı olduğunu ve hâlâ internet üzerinden eski sunucuya işaret etmediğini kontrol edin — eski sunucuyu iptal edene kadar kusursuz çalışan bir hata türüdür bu. Cron işlerini elle çalıştırın ve çıktılarını okuyun. Yönlendirmeleri ve eksik bir URL'nin hâlâ 200 değil 404 döndürdüğünü doğrulayın.

TLS sertifikasını şimdi, geçişten önce çıkarın, sonra değil. Bir DNS-01 challenge kullanın; bu, alan adı kontrolünü bir TXT kaydı üzerinden kanıtlar ve bu yüzden A kaydı hâlâ eski sunucuya işaret ederken de çalışır. DNS değişikliğinden sonra HTTP-01 doğrulamasını beklerseniz, bu aradaki her erken ziyaretçi bir sertifika uyarısı alır — tam olarak korumaya çalıştığınız pencerede kendi kendine verilmiş bir kesinti.

Geçiş, sırasıyla

Bu noktada yeni sunucu kurulmuş, sıkılaştırılmış, doldurulmuş, gerçek ana bilgisayar adı altında test edilmiş ve geçerli bir sertifika tutuyor durumdadır. Geçişin kendisi artık kısa, sıkıcı bir listedir — hedeflenen de tam olarak budur.

1. Siteye başka birileri bağımlıysa pencereyi duyurun, sonra eski siteyi salt okunur ya da bakım moduna alın.
2. Eski sunucudaki cron'u ve arka plan worker'larını devre dışı bırakın. Bunu yenisinde başlatmadan önce yapın, asla sonra değil.
3. Son rsync fark geçişini ve son veritabanı dökümünü çalıştırın, sonra içe aktarın.
4. Uygulamayı yeni sunucuda başlatın ve smoke testlerinizi son veriye karşı --resolve üzerinden tekrar çalıştırın.
5. A ve AAAA kayıtlarını yeni IP'ye değiştirin. 300 saniyelik bir TTL ile dünya beş dakika içinde bunu takip eder.
6. Yeni sunucuda cron'u ve worker'ları etkinleştirin.
7. Her iki erişim logunu da yan yana izleyin. Trafik eski sunucudan boşalır ve yenisinde belirir; eskisi sessizleştiğinde geçiş tamamlanmış demektir.
8. Eski sunucuyu bir hafta boyunca çalışır, hizmet verir ve dokunulmamış halde bırakın. Bu sizin geri dönüş planınızdır.

Sekizinci adım insanların kestiği adımdır ve listedeki en ucuz sigortadır. Birkaç dolar karşılığında, emin olana kadar DNS'i geriye çevirme yeteneğini — beş dakikalık bir kurtarma — elinizde tutarsınız.

Taşımanın geride bıraktıkları

İşte genel taşıma rehberlerinin atladığı kısım, ve fiyat için değil de gizlilik için taşındıysanız en önemli olan kısım. Bir siteyi taşımak onun geçmişini silmez. Eski düzenlemenin birkaç kamusal ve yarı kamusal kaydı, taşınmadan sağ çıkıp kalıcı olarak yaşamaya devam eder ve hangilerinin sağ kaldığını bilmek, temiz bir kopuş ile onun sahte bir hissi arasındaki farktır.

Dürüst özet şudur: bir taşıma işlemi geçmişi yeniden yazamaz — yalnızca ona yenisini eklemeyi durdurabilir. Bu yine de büyük bir değer taşır, ama kararı değiştirir: tehdit modeliniz hiçbir gözlemcinin yeni siteyi eskisine bağlayamamasını gerektiriyorsa, aynı alan adını yeni bir sağlayıcıya taşımak bunu başaramaz, ve geçiş sırasında ne kadar özen gösterirseniz gösterin de başaramaz. O durum yeni bir isim ve temiz bir başlangıç gerektirir; bir sonraki bölümde ele alınıyor. Bunun yerine amacınız bugünden itibaren kimlik belirleyici kayıt üretmeyi durdurmak ve yasal ağırlık merkezini seçtiğiniz bir yargı alanına taşımaksa, taşıma işlemi tam olarak bunu yapar. Sunucu OpSec rehberimiz, sonrasında bunu temiz tutan alışkanlıkları ele alır.

Alan adı sorusu: birlikte mi taşınsın, yoksa sıfırdan mı başlansın?

Site ve alan adı birbirinden bağımsız kararlardır, ve bunları birbirine karıştırmak yaygındır. Hosting'i bugün taşıyabilir ve kayıt şirketine sonsuza dek dokunmayabilirsiniz; sunucu değişikliğinin hiçbir yanı alan adına dokunmayı gerektirmez. Bunu yapmanız gerekip gerekmediği ise tamamen alan adının sizin hakkınızda şimdiden ne bildiğine bağlıdır.

• Alan adını koruyun, kayıt şirketini değiştirin. Alan adının bir değeri olduğunda — bağlantılar, sıralamalar, insanların yazdığı bir isim — mantıklıdır. WHOIS kaydının geleceğini düzeltir, geçmişini değil, ve her sıralama sinyalini olduğu gibi korur. Çoğu ticari site için doğru cevap budur.
• Alan adını koruyun, yalnızca sunucuyu değiştirin. Anonimlik yerine yargı alanı, çalışma süresi ya da DMCA tutumu için taşındıysanız tamamen makuldür. Mümkün olan en basit taşıma, sıfır SEO riski.
• Yeni alan adı, eskisini yönlendir. Sıralamaları korur, ve iki ismi kamuya açık ve kalıcı olarak birbirine bağlar. Bunu süreklilik için seçin, gizlilik için asla — yönlendirmenin kendisi o bağlantıdır.
• Yeni alan adı, temiz kopuş. Bağlantıyı gerçek anlamda kesen tek seçenektir, ve sahip olduğunuz her sıralamaya ve gelen bağlantıya mal olur. Baştan itibaren gizli şekilde kaydedin, çünkü bir alan adı ancak ilk kaydı kadar anonimdir. Kripto ile anonim alan adı kaydı rehberimiz bunu doğru şekilde yapmayı ele alır.

Bilinçli seçin, ve geçiş sırasında değil öncesinde seçin. Alan adı hakkında DNS taşındıktan sonra fikir değiştirmek, hassas kısmı iki kez yapmak demektir.

Eski sunucuyu doğru şekilde devre dışı bırakın

Geçişten bir iki hafta sonra, yeni sunucunun logları sıkıcı ve eskisinin logları boşken, eski hesabı kapatma zamanı gelmiştir. Bunu bu sırayla yapın, çünkü cazip kısayol — doğrudan iptale basmak — verinizi başkasının diskinde bırakan kısayoldur.

1. Hiçbir şeyin hâlâ eski IP'ye işaret etmediğini doğrulayın: üçüncü taraf webhook'larda, izin listelerinde, izlemede sabit kodlanmış adresleri ve unuttuğunuz, örneğin başıboş bir mail ya da cpanel alt alan adı gibi herhangi bir DNS kaydını kontrol edin.
2. O makinede yaşamış her sırrı döndürün — veritabanı parolaları, API anahtarları, uygulama salt'ları, DKIM anahtarları, SSH anahtarları. Bunları ileri taşımayın.
3. SSH açık anahtarlarınızı ve destek erişimini eski sunucudan kaldırın.
4. Uygulamayı, dökümleri ve yedekleri silin, sonra boş alanın üzerine yazın; böylece geri dönüştürülen birimin gelişigüzel bir okuması hiçbir şey vermez.
5. Ancak o zaman servisi sonlandırın ve eski hesaptan kayıtlı ödeme yöntemini kaldırın.

Tüm sıralama tek sayfada

Gerekçeleri çıkarırsanız bir sunucu taşıma işlemi dokuz adımdır, ve bunlardan yalnızca ikisinin aciliyeti vardır:

1. İki gün önce: DNS TTL'yi 300 saniyeye düşürün.
2. İki gün önce: hedef sunucuyu sipariş edin ve sıkılaştırın, eski yığınla sürüm sürüme eşleştirerek.
3. Günler önce: envanteri yazın — cron, sırlar, TLS, mail anahtarları, medya, IP izin listeleri, paketler.
4. Günler önce: sunucudan sunucuya ilk tam veri kopyasını çalıştırın.
5. Pencereden önce: sertifikayı DNS-01 ile çıkarın ve her şeyi --resolve üzerinden test edin.
6. Pencere (dakikalar): yazmaları dondurun, eski cron'u devre dışı bırakın, fark kopyasını ve son dökümü çalıştırın, yeni uygulamayı başlatın.
7. Pencere (saniyeler): A kaydını değiştirin, sonra yeni sunucuda cron'u etkinleştirin.
8. Takip eden hafta: eski sunucuyu bir geri dönüş planı olarak canlı tutun, her iki log dosyasını da izleyin, sonra TTL'yi yeniden yükseltin.
9. Sonrasında: sırları döndürün, silin, iptal edin — ve taşımanın silemediği şeyi hatırlayın.

O listede zor olan hiçbir şey yok. Acı veren her adım, sırasından çıkarılmış bir adımdır — geceleyin düşürülen bir TTL, DNS değişikliğinden sonra çıkarılan bir sertifika, artık yetkili olmayan bir makinede etkin bırakılmış bir cron işi. Sıralamayı doğru yapın, ve bir taşıma işlemindeki ilginç kısım sunucuyu nereye koyacağınızı seçmek olur, taşınmanın kendisi değil. Bunu henüz karara bağlamadıysanız, başlanacak yer yargı alanı rehberidir.