ClickOps ile Nereye Kadar? Infrastructure as Code (IaC) Dünyasına Giriş
Bulut konsolunda elle butonlara tıklayarak altyapı yönetmek (ClickOps), sistemler büyüdükçe hata payını ve yapılandırma sapmalarını artırır. Infrastructure as Code (IaC); sunucuları, ağları ve veri tabanlarını yazılım geliştirme standartlarıyla kod olarak tanımlamamızı, sürümlememizi ve dakikalar içinde güvenle ayağa kaldırmamızı sağlar.
Bulut bilişim platformlarıyla (AWS, Azure, Google Cloud, Huawei Cloud vb.) ilk tanıştığımız anı hatırlayalım: Tarayıcıdan konsola girilir, görsel arayüzde birkaç butona tıklanarak bir VPC oluşturulur, subnet'ler ayrılır, bir sanal sunucu başlatılır ve güvenlik gruplarından portlar açılır. Dakikalar içinde her şey hazır ve çalışır durumdadır. İlk bakışta harika bir kolaylık gibi görünür.
Ancak proje büyüdüğünde ve test ortamında tıkır tıkır çalışan sistemi prod (canlı) ortama taşımak gerektiğinde senaryo değişir:
- "Test ortamındaki sunucuya hangi disk tipini bağlamıştık?"
- "Güvenlik grubunda hangi IP bloğuna izin vermiştik?"
- "Veri tabanı parametre grubundaki o kritik ayarı kim, ne zaman değiştirmişti?"
Konsol ekranlarında buton arayarak altyapı inşa etme pratiği sektörde ClickOps olarak adlandırılır. Prototip aşamasında hızlı olsa da, ClickOps uzun vadede unutkanlığa, güvenlik açıklarına ve ortamlar arası uyumsuzluklara kapı aralar.
Tam bu tıkanma noktasında modern yazılım dünyasının kurtarıcı yaklaşımı devreye girer: Infrastructure as Code (IaC).
Infrastructure as Code (IaC) Nedir?
IaC, en yalın tanımıyla; sunucuları, ağ topolojilerini, veri tabanlarını, depolama alanlarını ve güvenlik kurallarını arayüzden elle kurmak yerine makine tarafından okunabilir kod dosyaları aracılığıyla tanımlama ve yönetme pratiğidir.
Buradaki temel zihniyet devrimi şudur: Altyapı artık güncelliğini yitiren bir Word dokümanı veya bir mühendisin hafızası değil; bizzat versiyon kontrol sisteminde (Git) yaşayan çalışan kodun ta kendisidir.
Bir web uygulaması yazarken kodumuzu nasıl GitHub/GitLab üzerinde sürümlüyor, Pull Request açıp kod incelemesi (Code Review) yapıyor ve pipeline'lar üzerinden test ediyorsak; altyapımız için de birebir aynı adımları işletiriz.
IaC Hangi Kronik Sorunları Çözer?
1. Configuration Drift (Yapılandırma Sapması)
Geliştirme ortamında çalışan bir uygulamanın canlıya alındığında çökmesinin bir numaralı sebebi ortamlar arasındaki küçük yapılandırma farklarıdır. Biri test sunucusunda portu açmış ama canlı sunucuda unutmuştur. IaC ile ortamlar tek bir şablondan üretilir; böylece test, staging ve prod ortamlarının birebir aynı olması garanti edilir.
2. Şeffaflık ve Denetlenebilirlik (Auditability)
"Bu portu kim, neden açtı?" sorusunun cevabı konsol loglarında kaybolmaz. Git commit geçmişine veya ilgili Pull Request'e baktığınızda; hangi mühendisin, hangi iş görevi (task/issue) için, hangi tarihte o değişikliği yaptığını ve kimlerin bu değişikliği onayladığını saniyeler içinde görebilirsiniz.
3. Hızlı Felaket Kurtarma (Disaster Recovery)
Hizmet aldığınız veri merkezinde büyük bir kesinti yaşandığında veya bir bölge (region) tamamen çöktüğünde, ClickOps ile altyapıyı başka bir bölgede sıfırdan ayağa kaldırmak saatler hatta günler sürebilir. IaC ile sadece hedef bölge parametresini (region = "eu-central-1") değiştirip tek bir komut çalıştırarak dakikalar içinde tüm sistemi klonlayabilirsiniz. Ayrıca kendi geliştirmiş olduğum Disaster Recovery aracıma da bu linkten ulaşabilirsiniz.
4. Idempotency (Eşgüçlülük)
Modern IaC araçlarının en büyük gücü idempotent olmalarıdır. Yazdığınız altyapı kodunu bir kez de çalıştırsanız, arka arkaya on kez de çalıştırsanız hedef durum aynı kalır. Kod, mevcut durum ile istenen durumu karşılaştırır; zaten var olan bir sunucuyu tekrar açmaz, yalnızca değişen veya eksik kalan kısımları günceller.
İki Farklı Felsefe: Declarative vs. Imperative
IaC araçları altyapıyı kodlarken temelde iki farklı yaklaşım benimser:
| Kriter | Declarative (Bildirimsel) | Imperative (Emredici) |
|---|---|---|
| Mantık | Ne istediğinizi tarif edersiniz. | Nasıl yapılacağını adım adım tarif edersiniz. |
| Örnek | "Bana 2 sunucu ve 1 VPC ver." | "Önce VPC yarat, sonra subnet bağla, sonra sunucu başlat." |
| Durum Takibi | Hedef duruma ulaşmak için gereken adımları araç kendisi çözer. | Hata yönetimini ve mevcut kaynak kontrolünü sizin yazmanız gerekir. |
| Öncü Araçlar | Terraform, OpenTofu, CloudFormation | Bash/Python Scriptleri, AWS CLI |
Endüstri standardı altyapı yönetiminde ezici çoğunlukla Declarative (Bildirimsel) yaklaşım tercih edilir; çünkü öngörülebilirliği artırır ve karmaşık bağımlılık yönetimini insan zihninden alıp aracın motoruna devreder.
Örnek Bir Bakış: Terraform ile Kod Nasıl Görünür?
Görsel arayüzde onlarca menü gezmek yerine declarative bir dille (örneğin HCL) bir bulut sunucusunu tanımlamak bu kadar sadedir:
hcl# AWS üzerinde basit bir web sunucusu tanımı resource "aws_instance" "web_server" { ami = "ami-0c55b159cbfafe1f0" instance_type = "t3.micro" tags = { Name = "Production-WebServer" Environment = "Prod" ManagedBy = "Terraform" } }
Bu kodu çalıştırmadan önce terraform plan komutu vererek sistemin ne ekleyeceğini, neyi değiştireceğini veya neyi sileceğini önceden bir simülasyon olarak görebilirsiniz.
Popüler IaC Araçları ve İş Bölümü
Sektörde altyapı yönetimi genelde iki ana aşamaya ayrılır:
1. Altyapı Sağlama (Provisioning) Araçları
Sunucuyu, ağı, diski, DNS kayıtlarını sıfırdan meydana getiren araçlardır.
- Terraform / OpenTofu: Sektörün fiili standardı. Bulut bağımsızdır (AWS, Azure, GCP, on-premise vb. destekler).
- Pulumi: Altyapıyı HCL gibi özel diller yerine TypeScript, Python, Go veya C# gibi genel amaçlı programlama dilleriyle yazmak isteyenlerin tercihi.
- Buluta Özgü Çözümler: AWS CloudFormation / AWS CDK, Azure Bicep.
2. Yapılandırma Yönetimi (Configuration Management) Araçları
Ayağa kalkan sunucuların içine girip yazılımları kuran, servisleri başlatan ve ayar dosyalarını güncelleyen araçlardır.
- Ansible: Ajan gerektirmeyen (agentless), SSH üzerinden çalışan ve YAML dosyalarıyla yönetilen en popüler araçtır.
Modern Pratik: Genellikle omurga (VPC, sunucular, yük dengeleyiciler) Terraform ile ayağa kaldırılır; sunucuların iç konfigürasyonu ise Ansible veya hafif işlerde Cloud-init ile tamamlanır.
IaC'ye Başlarken Hayat Kurtaran Kurallar
- State Dosyasını Asla Git'e Göndermeyin: Terraform gibi araçlar altyapının anlık haritasını bir state dosyasında saklar. Bu dosya hassas şifreler içerebilir. State dosyasını daima AWS S3 + DynamoDB gibi uzaktan erişilen, şifreli ve kilitleme (state locking) özelliği olan depolarda saklayın.
- Secret Değerleri Kodun İçine Yazmayın: API token'ları, veri tabanı şifreleri veya SSH anahtarları asla
.tfveya.ymldosyalarına doğrudan yazılmamalıdır. HashiCorp Vault, AWS Secrets Manager veya CI/CD ortam değişkenleri kullanılmalıdır. - CI/CD Entegrasyonu Yapın: Altyapı değişikliklerini yerel bilgisayarınızdan uygulamak yerine; Pull Request açıldığında otomatik plan çıkaran, kod incelenip onaylandığında otomatik apply eden bir GitHub Actions veya GitLab CI boru hattı kurun.
Sonuç
Altyapıyı kod olarak yönetmek, başlangıçta öğrenme eğrisi ve ekstra disiplin gerektirse de; ekipleri insan hatasından, acil durum paniklerinden ve saatler süren manuel kurulumlardan kurtarır.
ClickOps ile günü kurtarabilirsiniz; ancak ölçeklenebilir, güvenli ve sürdürülebilir bir bulut mimarisi inşa etmek istiyorsanız Infrastructure as Code bir tercih değil, modern mühendisliğin bir gerekliliğidir.