Tek hamlede Kubernetes’e geçmek

ClickFortify, docker-compose çalıştıran tek bir VM üzerinde hayata başladı. Bugün GCP üzerinde Kubernetes’te çalışıyor ve ArgoCD ile dağıtılıyor. Bu yazı ikisi arasındaki geçişi ve bunu neden kademeli bir migration yerine tek hamlede yapmaya karar verdiğimi anlatıyor.

Ürün duramaz

ClickFortify canlı trafikteki reklam tıklamalarını toplar, puanlar ve hariç tutmaları Google Ads ve Meta’ya geri yazar. Tıklamalar günün her saati gelir. Bakım penceresi gerektiren ya da tracker’ı yarısı bir stack’te, yarısı diğerinde bırakan bir geçiş planı, gerçek reklamverenlere gerçek bütçe kaybettirir.

Dolayısıyla soru "her şeyi nasıl taşırız?" değildi. Soru "geçişi tek, küçük ve geri alınabilir bir adım haline nasıl getiririz?" idi.

Önce dağıtım yolunu doğru kurmak

Herhangi bir trafik taşınmadan önce kümenin güvendiğim bir dağıtım yoluna ihtiyacı vardı. GitOps kurulumu üç depo kullanıyor: uygulama, ArgoCD’nin dağıttığı manifest’ler ve platform altyapısı. Orijinal plan manifest’leri uygulama monorepo’su içinde tutuyordu. Onları ayırdım; çünkü ArgoCD her yenilemede depoyu yeniden klonluyor ve monorepo büyük, çünkü platformun kendi yaşam döngüsü ve kendi gözden geçirenleri var ve çünkü bu sayede uygulamanın CI’ının platform deposuna hiçbir erişimi kalmıyor.

Bu, bir geçiş için önemli. Yeni taraf, bundan sonra hep dağıtılacağı şekilde dağıtılırsa, onu ilk gün doğrulamak sürüm sürecini de doğrulamış olur.

Paralel bir stage hostname seti

Karar verdiğim plan üç adımdan oluşuyordu:

1. Yeni stack’in tamamını kümede, stage.example.com gibi paralel bir stage hostname setinin arkasında dağıtmak.
2. Orada doğrulamak.
3. Üretim hostname’lerini tek hamlede kümeye yönlendirmek.

Yeni taraf test edilirken üretimde hiçbir şey değişmedi. Eski VM tüm gerçek istekleri karşılamaya devam etti ve stage hostname’leri bana yeni stack’i uçtan uca deneyebileceğim bir yer sağladı.

Veri taşıma yok ve beraberinde gelen tuzak

İki taraf da aynı veritabanlarını kullanıyordu. Tek hamlelik geçişi mümkün kılan da buydu: çalıştırılacak bir kopya, tutarlı tutulacak bir senkronizasyon ya da iki stack’in veri konusunda anlaşamadığı bir an yoktu. DNS taşındığında yeni stack zaten eskisinin okuyup yazdığı satırları okuyup yazıyordu.

Tuzak şu ki stage tarafı hiçbir zaman gerçek bir sandbox değildi. Yazdığı her şey üretim verisine düşüyordu. Testler bunun için ayrılmış özel bir alanı kullandı ve hiçbir gerçek müşterinin script’i stage tracker’ına yönlendirilmedi.

Worker neden sıfırda kaldı

Worker, zamanlanmış işleri çalıştıran servis. Paylaşılan bir veritabanında iki worker, her zamanlanmış işin iki kez çalışması demek: e-postalar iki kez gider, temizlikler iki kez siler. Bu yüzden yeni taraftaki worker tüm stage dönemi boyunca sıfır replikada kaldı.

# Illustrative: keep the new side's worker off until the flip
kubectl scale deployment worker --replicas=0

Geçiş ve kalıcı olduğunu doğrulamak

Geçişin kendisi bir DNS değişikliğiydi: üretim hostname’leri kümeye yönlendirildi. Bundan önce, kümede çalışan imaj digest’lerinin yayına almayı beklediğim şeyle eşleştiğini kontrol ettim.

Sonrasında en önemli kontrol tracker üzerindeydi. Tracker bir CDN’in ve bir reverse proxy’nin arkasında duruyor ve bunun arkasında ziyaretçinin gerçek IP’sini bulmak, topoloji değiştiğinde tam da bozulan türden bir şey. Geçişten sonraki canlı tracker trafiği gerçek ziyaretçi IP’lerini gösteriyordu ve hiçbir CDN edge adresi yoktu. Bu doğrulandıktan sonra stage hostname’leri kaldırıldı.

Geçişin hemen ardından geri dönüş, aynı hamlenin tersiydi: hostname’leri silmek yerine durdurduğum eski VM’e geri yönlendirmek.

Aynı geçişi yapacak birine ne söylerdim

1. İki taraf veritabanlarını paylaşabiliyorsa bunu yapın. Veri taşımayı ortadan kaldırır ve geçişi tek bir DNS değişikliğine indirir.
2. Her zamanlanmış işi listeleyin ve stage süresince tam olarak tek bir yerde çalıştığından emin olun; bu, bir servisin prova edilemeyeceği anlamına gelse bile.
3. Kuyruktaki ve ertelenmiş işleri geçişten önce boşaltın ya da dışa aktarın. Bunlar veritabanının dışında yaşar.
4. Doğrulama kontrolünü geçişten önce belirleyin ve health endpoint’lerine değil, gerçek trafiğe dayandırın.