Kahvenin Yanında Bir Fırtına: Sıfır Kesinti Hayali Nereden Çıktı?
Bir sabah, kahvemi alıp masaya oturduğumda bir uyarı düştü: “Canlı ortamda kısa bir kesinti yaşandı, kullanıcılar çıkış yaptı.” O an hissettiğim şeyi tahmin edersiniz. Kısa bile sürse o dalga yayılıyor; bildirim, destek mesajı, herkesin nefesi hızlanıyor. O gün şunu düşündüm: Madem her şeyi betikleştiriyoruz, neden dağıtımı da güvenli ve sıfır kesintiye yakın hale getirmiyoruz? Bu yazıda, tam da o günün sonunda şekillenen akışı anlatacağım. Terraform ile VPS’i otomatik kuracağız, DNS tarafında Cloudflare’i devreye alacağız, ortamı Proxmox ya da OpenStack üzerinde şekillendireceğiz ve dağıtım geldiğinde mavi-yeşil geçişle trafiği sakince yönlendireceğiz.
Hiç başınıza geldi mi? Ufak bir güncelleme yüzünden ana sayfaya bile giremeyen kullanıcılar… Mesela şöyle düşünün: Yeni sürüm hazır, testlerden geçmiş, ama geçiş unutkan bir anınıza denk geliyor ve bir DNS kaydını 10 dakika geç güncelliyorsunuz. Ya da Proxmox’ta düğümde bir ayar eksik kalıyor, ağ arayüzü beklendiği gibi açılmıyor. Bütün bu küçük hatalar zincirini, betiklenmiş bir akış ve temkinli bir mavi-yeşil strateji ile yumuşatmak mümkün. Benim aklımda kalan tarif şu: Terraform, Cloudflare ve Proxmox/OpenStack üçlüsü; arada cloud-init, sonda Cloudflare tarafında dengeli bir trafik devri.
Haritayı Çizelim: Terraform Akışı ve Düşünme Biçimi
Benim için Terraform, “önce hayali kur, sonra yeniden üret” demek. Dosyada yazdığım her kaynak, yarın tekrar kurabileceğim bir dünyaya dönüşüyor. Sihir buradan geliyor. Akışı üç katmanda düşünebilirsiniz: Altyapı, ağ ve trafik. Altyapıda VPS yaşam döngüsünü yönetiyoruz; Proxmox veya OpenStack fark etmez, amaç sanal makineyi aynı tarifle ayağa kaldırmak. Ağ tarafında cloud-init gibi ufak sihirler devreye giriyor; makine ilk nefesini alır almaz kullanıcı, SSH anahtarı, servis birimleri tanımlı hale geliyor. Trafikte ise Cloudflare DNS kayıtları, mümkünse Load Balancer, en azından planlı bir yönlendirme akışı ile mavi-yeşil geçişi yürütüyor.
Mesela şöyle düşünün: “green” ve “blue” diye iki havuzunuz var. Green canlı; blue bir adım geride. Yeni sürümü blue’da kurup doğruluyorsunuz. Sonra trafiği yavaşça blue’ya devrediyorsunuz. Eğer bir şey ters giderse eskisini geri almak, “yamalı bohça” içindeki iş akışlarını düzeltmekten daha kolay. Bu yüzden Terraform tarafında kaynakları adlarla ve etiketlerle belli eden bir düzen kurmak çok iş görüyor. Kendi deneyimimde, dosyaları modüllere bölmek ve state’i kilitlemek, ileride karşınıza çıkacak sürprizleri ciddi şekilde azaltıyor.
Proxmox’ta VPS’i Terraform ile Ayağa Kaldırmak: Küçük Dokunuşlar Büyük Rahatlık
Proxmox tarafında Terraform ile çalışmak, özellikle yerel ya da özel bulut ortamında çok hoş bir konfor sağlıyor. İlk kez kurduğumda, bir şablon VM hazırlayıp onu bulut imgesi gibi kullandım; içindeki cloud-init ayarları sayesinde her yeni makine, kendini “tanıyıp” ayağa kalktı. Provider ayarıyla başlayan bu akış, isimlendirme ve ağ kartı tanımlarıyla tatlı tatlı ilerliyor. Ayar dosyalarını küçük, anlaşılır parçalara bölmek önemli; aksi halde uzadıkça insanın morali bozuluyor.
İskeleti şöyle bir şey olabilir:
terraform {
required_providers {
proxmox = {
source = "Telmate/proxmox"
version = ">= 2.9.0"
}
}
}
provider "proxmox" {
pm_api_url = var.pm_api_url
pm_user = var.pm_user
pm_password = var.pm_password
pm_tls_insecure = false
}
resource "proxmox_vm_qemu" "app_blue" {
name = "app-blue-01"
target_node = var.pm_node
clone = var.template_name
cores = 2
memory = 4096
network {
model = "virtio"
bridge = "vmbr0"
}
ipconfig0 = "ip=${var.blue_ip}/24,gw=${var.gateway}"
ssh_user = "ubuntu"
sshkeys = file(var.ssh_public_key)
cloudinit_cdrom_storage = var.ci_storage
}
Burada şunun altını çizeyim: SSH anahtarını dosyadan çekmek, kullanıcıyı cloud-init üzerinden tanımlamak ve ağ yapılandırmasını ipconfig satırında netleştirmek, ilk boot deneyimini sağlam yapıyor. Proxmox tarafında provider ve kaynakların nasıl kullanıldığı için resmi dokümana göz atmak iyi olur; ben ilk kez denerken Terraform Proxmox provider dokümantasyonunu epey karıştırmıştım.
Bu arada güvenlik duvarı tarafını da ihmal etmeyin. Makine ayağa kalkar kalkmaz temel kuralların hazır olması iç rahatlatıyor. Bir süre önce buna özel bir rehber yazmıştım; isterseniz nftables ile VPS güvenlik duvarını tatlı tatlı kurma adımlarına göz atın, oradaki ipuçları bu akışla güzel birleşiyor.
OpenStack Alternatifi: Flavor, İmaj, cloud-init ile Aynı Akışın Bulut Sürümü
OpenStack üzerinde de benzer bir ritim var: Flavor seçersiniz, imajı belirtirsiniz, ağınızı bağlarsınız, cloud-init ile ilk açılışta işler yerine oturur. Terraform OpenStack provider bu noktada çok yardımcı. İlk kurulumda en çok, ağ isimleri ve güvenlik gruplarını doğru referanslamakta takılıyoruz; bir de metadata ve user_data kısmını düzenli tutmak gerekir. Az ama öz bir user_data, işler büyüdükçe eliniz ayağınız oluyor.
terraform {
required_providers {
openstack = {
source = "terraform-provider-openstack/openstack"
version = ">= 1.54.0"
}
}
}
provider "openstack" {
auth_url = var.auth_url
region = var.region
tenant_name = var.project
user_name = var.username
password = var.password
}
resource "openstack_compute_instance_v2" "app_green" {
name = "app-green-01"
image_name = var.image
flavor_name = var.flavor
key_pair = var.keypair
security_groups = ["default", "web"]
network {
name = var.network
}
user_data = file("cloud-init/app.yaml")
}
OpenStack tarafında ben genelde user_data’yı ayrı bir dosyada tutup Terraform’un içine dosya olarak çağırıyorum. Küçük bir not: cloud-init ile yaptığınız işleri bir kez daha gözden geçirmek, ilk açılışta servislerin sıraya girip girmediğini kontrol etmek hayat kurtarıyor. Bu yaklaşımı daha önce detaylı anlattığım bir yazı da var; cloud-init ve Ansible ile tekrar üretilebilir VPS akışına göz atarsanız, burada anlattıklarımız anlam kazanır.
Cloudflare ile DNS ve Trafik: İnce Ayar, Sağlık Kontrolleri ve Load Balancer
Gelelim anahtara: Trafiği doğru anda, doğru yere yönlendirmek. Cloudflare, DNS kayıtlarıyla başlayıp Load Balancer ile taşları yerine oturtmanızı sağlıyor. Sıfır kesintiye yaklaşmak istiyorsak, tek bir A kaydını çevirmek yerine, iki havuz arasında kontrollü geçiş daha huzurlu. Bu yüzden mümkünse Load Balancer kullanmayı seviyorum; pool mantığı, sağlık kontrolleri ve ağırlık verme özelliği ile sürümleri yumuşakçe devredebilirsiniz. Resmi dokümana bir göz atmak isterseniz Cloudflare Load Balancer sayfası toparlayıcı.
Terraform tarafında Cloudflare provider ile işler okunaklı hale geliyor:
terraform {
required_providers {
cloudflare = {
source = "cloudflare/cloudflare"
version = ">= 4.0"
}
}
}
provider "cloudflare" {
api_token = var.cf_api_token
}
# DNS: kök alan adı yerine uygulama alt alanına odaklanalım
resource "cloudflare_record" "app_blue" {
zone_id = var.cf_zone_id
name = "app"
type = "A"
value = var.blue_ip
proxied = true
ttl = 1
}
Tek başına bu kayıt mavi-yeşil geçişte sınırlı kalır. Asıl rahatlık Load Balancer ile geliyor. Havuzları oluşturup health check tanımladığınızda, yükü kademe kademe aktarabilirsiniz. Sağlık kontrollerinin sıkı olması da şart değil; uygulamanın “gerçekten canlı” olduğuna işaret eden basit bir endpoint yeterli. Provider belgeleri için Cloudflare Terraform provider dokümantasyonu elinizin altında dursun; kaynak isimleri ve alanlar versiyona göre küçük farklar gösterebiliyor.
Canlı trafikte WebSocket veya gRPC kullanıyorsanız, bağlantı ömrü ve zaman aşımı ayarları işin “görünmeyen” kısmı. Bu konuda deneyimlerden damıttığım notlarımı burada toplamıştım; Cloudflare ile WebSocket ve gRPC yayınının hep canlı kalması üzerine yazdığım öneriler, mavi-yeşil geçişte bağlantıların kopmamasına ciddi katkı sağlıyor.
Mavi-Yeşil Dağıtım: Bir Sürümü Sessizce Yerine Kaydırmak
Yapboz parçaları hazır. Şimdi adımları hikaye gibi düşünelim. Önce blue havuzunu Terraform ile ayağa kaldırırsınız; uygulama servisleri, veritabanı bağlantıları ve log yönlendirmesi kontrol edilir. Ardından Cloudflare Load Balancer’da blue’ya küçük bir ağırlık verirsiniz; yüzde demeyelim, “az biraz” trafik gitsin. Birkaç dakika izleyip hata görmüyorsanız, ağırlığı artırırsınız. Bu sırada green çalışmaya devam eder, kimse panik yapmaz. Takıldığınız yerde tek hamleyle geri dönmek mümkün olur.
Bu geçişin iki hassas noktası var. Birincisi, durum (state). Terraform state dosyasını güvenle saklamak ve aynı anda birden fazla kişinin değişiklik yapmasını kilitlemek önemli. İkincisi, veri katmanı. Uygulamanız yazma yükü taşıyorsa, şemayı önce geriye uyumlu şekilde güncellemek, sonra uygulamayı yeni sürüme geçirmek daha sağlıklı. Veritabanı tarafındaki küçük gecikmeler ve replikasyon farkları bile fark yaratabilir; canlı ortamın akışını küçümsememek gerek. Bu noktada dağıtımların prova edilmesi, staging ortamında kısa stres testleri, izleme panellerinin “gerçekten bakılan” paneller olması işinizi kolaylaştırır.
Bir de geri dönüş planı. Geri dönüş, geçiş kadar net ve hızlı olmalı. Loglar bir yerde, metrikler başka yerde, uyarılar e-postada kalırsa karar almak zorlaşıyor. O yüzden tek bakışta anlaşılır bir gösterge seti hayat kurtarıyor. İlgili konularda daha derine inmek isterseniz, felaket senaryosuna göz kırpan pratik bir yazı bırakayım: RTO/RPO’yu netleştirip yedek testleri ve runbook’ları çalışır hale getirmek burada anlattıklarımızın arka planını güçlendiriyor.
Durum Yönetimi, Gizli Bilgiler ve Küçük Tuzaklar
İşler büyüdükçe Terraform dosyaları da büyüyor. İlk tavsiyem, modüllere bölmek. “compute”, “network”, “dns” gibi modüller, düşünceyi sade tutuyor. State dosyasını uzakta saklamak ve kilitlemek ise olmazsa olmaz; bir bulut depolama veya sürüm kontrolüne entegre bir remote backend, aynı anda değişiklik yapma riskini azaltıyor. Aynı zamanda değişiklik planlarını (plan/apply ayrımı) ciddiye almak, gözden kaçan bir kaynağın yanlışlıkla silinmesini engelliyor.
Gizli bilgiler… API token’ı, parola, SSH anahtarı gibi değerleri değişken dosyalarında çıplak bırakmayın. Ortak bir gizli yönetimi belirlemek, hatta mümkünse bir kasaya koyup Terraform’un oradan okumasını sağlamak iç rahatlatıyor. Küçük ama etkili bir not: Plan çıktısının loglarda sızmaması için duyarlı değişkenleri “sensitive” olarak işaretleyin. Ayrıca hata anında ne yapacağınızı önceden yazmak, gece geç saatlerde verilen refleks kararları daha kaliteli hale getiriyor.
Son olarak, dağıtımın hemen ardından ufak bir sağlık turu yapmayı adet edindim. Birkaç temel endpoint’i, hataya eğilimli işlemleri ve oturum yönetimini gözden geçirmek, “eee bitti mi?” sorusuna konforlu bir “evet” demeyi sağlıyor. Eğer uygulamanız önbellek kullanıyorsa, dağıtımdan sonra kısa bir ısınma aşaması planlamak iyi hissettiriyor. Ön yüz tarafında mikro önbellekleme gibi tekniklerin canlı akışa etkisini merak ediyorsanız, zamanında paylaştığım Nginx mikro önbellekleme notları geçiş sonrası stabiliteye güzel katkılar yapıyor.
İzleme, Gözlem ve Küçük Bir Geri Dönüş Hikayesi
İtiraf edeyim, ilk mavi-yeşil denememde çok heyecanlanmıştım. İzleme panellerini açtım, trafiği az az blue’ya verdik, loglarda minik bir uyarı belirdi. Aklıma ilk gelen şey geri sarma oldu. Ağırlığı tekrar green’e çektik, olay kapandı. Sorunu bulduk; cloud-init dosyasında, servis bağımlılıklarını iki satırla netleştirince ikinci denemede her şey yağ gibi aktı. Bu küçük geri dönüş, aslında mavi-yeşilin güzelliğini özetliyor: Kırmadan öğrenmek.
İzleme tarafında ben metrik ve logu yan yana görmeyi seviyorum. Trafik geçiş anında gecikme artıyor mu, hata oranı zıplıyor mu, oturum sayısı düşüyor mu? Bu üçüne bakınca “gitti mi, gidiyor mu, gidecek mi” sorularına net cevap alabiliyorum. Eğer uygulamanız stateful ise, veritabanı ve dosya depolama tarafındaki davranışları da aynı ekranda görmek çok işe yarıyor. Bu konuları dağıtım sonrası yaşamın bir parçası haline getirirseniz, “sıfır kesinti” hedefi bir slogandan çıkıp günlük rutine dönüşüyor.
Bu arada ağ ayarları ve zaman aşımı değerleri, özellikle gerçek zamanlı bağlantılarda kritik. Ayrıntı sevenler için tekrar not düşeyim; Cloudflare ile uzun ömürlü bağlantıları canlı tutma ipuçları dağıtımın “hissini” iyileştiriyor.
Kapanış: Bir Sonraki Geçiş Daha Huzurlu Olsun
Toparlayalım. Terraform ile altyapıyı yazdıkça, kurulum tekrar üretilebilir hale geliyor. Proxmox veya OpenStack üzerinde VPS’i ayağa kaldırmak, cloud-init ile ilk nefesini verdirmek ve Cloudflare ile trafiği yönetmek bir araya gelince, mavi-yeşil dağıtım doğal bir ritim kazanıyor. Küçük hatalar büyük paniğe dönüşmeden önce fark ediliyor; geri dönüş adımı her zaman hazır. Bence en değerlisi bu huzur.
Pratik bir tavsiye listesi bırakayım, ama cümlelerin arasında saklı dursun: Modülleri küçük tutun, state’i kilitleyin, gizli bilgileri açıkta gezdirmeyin, sağlık kontrollerini gerçekçi kılın, log ve metrikleri yan yana izleyin, rollback’i prova edin. Ve elbette, ilk kurulumu sahneye çıkmadan önce bir sahne provasından geçirin. Daha fazla altyapı otomasyonu fikrine açsanız, cloud-init ve Ansible ile VPS’i tekrar üretilebilir kılma yazısına göz atın; oradaki düşünceyle bu yazı çok iyi anlaşır.
Yolun sonunda, dağıtım vakti geldiğinde kahvenizi sakin sakin yudumlayabildiğinizi fark edeceksiniz. Umarım bu rehber, aklınızdaki parçaları yerine oturtur. Sorularınız olursa her zaman yazın; bir sonraki yazıda başka bir küçük sırrı paylaşırız.
Küçük not: Terraform kaynakları ve örnekleri kurcalarken resmi dokümanları elinizin altında tutun; versiyonlar arasında küçük farklar olabiliyor. Başlangıç için Cloudflare provider dökümanı iyi bir referans.
