Kod olarak altyapı (IaC): başlangıç

Sunucuların Manuel Yapılandırılması Neden Hâlâ Ciddi Bir Sorun?

Daha önce bir sunucuyu elle ve adım adım kurduysanız, muhtemelen şu senaryoya aşinasınızdır: Önce bir VPS alırsınız, SSH ile bağlanırsınız, Nginx kurarsınız, PHP'yi ayarlarsınız, veritabanını oluşturursunuz ve birkaç saatlik çalışmanın ardından sunucu ayağa kalkar. Her şey yolunda gider, ta ki sunucu çökene ve tüm bu süreci tekrar tekrarlamak zorunda kalana kadar — bu sefer "En son tam olarak hangi ayarları yapmıştım?" sorusuyla birlikte.

Manuel yapılandırmanın birkaç temel sorunu vardır: Tekrarlanabilirlik eksikliği (hiçbir iki sunucu birbirinin aynısı olacak şekilde yapılandırılmaz), insan hatası (yanlış bir komut tüm güvenliği tehlikeye atabilir) ve hiçbir dokümantasyonun olmaması (tek doğruluk kaynağı sizin hafızanızdır). İşte tam bu noktada Altyapı Olarak Kod (Infrastructure as Code veya IaC) devreye girer ve tam olarak bu sorunları çözer.

Altyapı Olarak Kod, sunucu ve ağdan kurulu yazılımlara kadar tüm altyapı bileşenlerini metin dosyaları ve sürüm kontrolüne tabi olacak şekilde tanımlamak anlamına gelir. Veri merkezi yönetim konsoluna gidip bir düğmeye tıklamak yerine, bir main.tf dosyası yazar ve çalıştırırsınız. Sonuç mu? Yazılım kodu gibi incelenebilir, test edilebilir ve yeniden üretilebilir bir altyapı.

Gerçek Sorun: "Benim Sunucumda Çalışıyor" Artık Yeterli Değil

Bir sanal sunucuda çalışan bir web uygulamanız olduğunu varsayalım. Bir gün sunucudaki PHP sürümünün 7.4 olduğunu, ancak geliştirme sisteminizde 8.2 olduğunu fark edersiniz. Veya ana sunucudaki güvenlik duvarının açık olduğunu, ancak yedek sunucuda kapalı olduğunu keşfedersiniz. Bu "Yapılandırma Sapması" (Configuration Drift), tam olarak gizemli hatalara ve güvenlik açıklarına neden olan şeydir.

Altyapı Olarak Kod ile altyapınız bir "durum makinesine" dönüşür. İstenen durumu kodda tanımlarsınız ve IaC aracı, sistemi bu duruma getirmekle görevlidir. Birisi manuel olarak bir şeyi değiştirirse, bir sonraki çalıştırmada ya tespit edilip düzeltilir ya da en azından bir sapma olarak raporlanır.

Bilmeniz Gereken Üç Nesil IaC Aracı

IaC araçları üç ana kategoriye ayrılabilir:

• Provisioning Araçları (Altyapı Oluşturma): Sunucuları, ağları ve bulut kaynaklarını oluşturan Terraform ve Pulumi gibi araçlar. Bu araçlar "fiziksel altyapıyı" yönetir.
• Yapılandırma Yönetimi Araçları (Yazılım Ayarlama): Mevcut sunucularda çalışan ve yazılımları kuran/yapılandıran Ansible, Puppet ve Chef gibi araçlar.
• Değişmez Altyapı Araçları: Hazır sunucu imajları (AMI gibi) oluşturan Packer gibi araçlar. Bu yaklaşımda sunucu asla güncellenmez; yeni bir sürümle değiştirilir.

Pratikte çoğu ekip, Terraform (oluşturma için) ve Ansible (ayarlama için) kombinasyonunu kullanır. Bundan sonra odak noktamız Terraform olacak çünkü Altyapı Olarak Kod için en popüler ve aynı zamanda en basit başlangıç noktası olarak kabul edilir.

Terraform ile Başlarken: Gerçek Bir Örnek

Veri merkezinde bir sanal sunucu (VPS) başlatmak istediğinizi varsayalım. Geleneksel yöntemle panele girer, bir sunucu oluşturur, SSH anahtarını ayarlar ve ardından yazılımı elle kurarsınız. Terraform ile tüm bu süreç bir metin dosyasına dönüşür.

Terraform Kurulumu ve Temel Yapı

Önce Terraform'u kurun. Ubuntu/Debian'da:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

Ardından bir proje dizini oluşturun ve ilk dosyayı oluşturun:

mkdir my-infra && cd my-infra
nano main.tf

Bu dosyada önce provider'ı tanımlarız. İranlı bir servis sağlayıcıyla çalışıyorsanız, muhtemelen OpenStack uyumlu bir API veya özel bir provider kullanıyorsunuzdur. Basit bir örnek için standart AWS provider'ını kullandığımızı varsayalım:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "me-south-1"
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "MyFirstIaCServer"
  }
}

Şimdi üç ana komutu çalıştırın:

1. terraform init — provider eklentilerini indirmek için
2. terraform plan — uygulanacak değişiklikleri görmek için (uygulamadan)
3. terraform apply — sunucuyu gerçekten oluşturmak için

terraform plan çıktısı size tam olarak neyin oluşturulacağını gösterir. Bu "önizleme", IaC'nin en büyük avantajlarından biridir: herhangi bir değişiklikten önce ne olacağını bilirsiniz.

State Yönetimi: IaC'nin Kalbi

Terraform, altyapınızın mevcut durumunu kaydeden terraform.tfstate adlı bir dosya tutar. Bu dosya hayati öneme sahiptir; kaybolursa Terraform neyin oluşturulduğunu ve neyin oluşturulmadığını bilemez. Ekip projelerinde bu dosya güvenli ve ortak bir yerde (S3 veya GitLab gibi) saklanmalıdır. Şifrelenmiş bir backend kullanmıyorsanız, asla Git'e commit etmeyin.

Yaygın bir hata: apply'den önce terraform plan çalıştırmayı unutmak. Özellikle production ortamında her zaman plan'ı çalıştırın. Kodda yapılacak yanlış bir değişiklik tüm altyapıyı yok edebilir.

Yaygın Hatalardan Kaçınmak İçin Pratik İpuçları

Altyapı Olarak Kod, doğru kullanılmazsa sorun yaratabilir. İşte birkaç yaygın hata ve çözümleri:

Hata 1: Kodda Kimlik Bilgileri Kullanmak

API anahtarlarını veya şifreleri asla doğrudan .tf dosyalarına yazmayın. Bu dosyalar genellikle Git'te saklanır ve depoya erişimi olan herkes bunları görebilir. Bunun yerine ortam değişkenleri veya Vault gibi araçlar kullanın:

provider "aws" {
  region     = "me-south-1"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

Değerleri terraform.tfvars dosyasında (.gitignore içinde yer alır) veya ortam değişkeni olarak tanımlayın.

Hata 2: Ekip Çalışmasında State Kilidini Göz Ardı Etmek

İki kişi aynı anda terraform apply çalıştırırsa, state bozulabilir. Terraform Cloud veya S3 tabanlı backend'ler gibi araçlar kilitleme (Locking) ile bu sorunu çözer. Küçük ekiplerde en azından bir kural koyun: her seferinde yalnızca bir kişi apply işlemi yapsın.

Hata 3: Altyapı Kodunu Test Etmemek

IaC kodu da yazılım kodu gibi test edilmelidir. terraform validate ve terraform fmt gibi araçları CI/CD sürecinize ekleyin. Daha gelişmiş testler için terraform-compliance veya kitchen-terraform kullanın.

Gerçek Dünyada Altyapı Olarak Kod: Tam Yaşam Döngüsü

Artık temelleri bildiğinize göre, tam bir senaryoyu inceleyelim. Bir sunucuda çalışması gereken bir Node.js uygulamanız olduğunu varsayalım. Altyapı Olarak Kod ile çalışma döngüsü şu şekildedir:

1. Altyapıyı Tanımlama: main.tf içinde bir sunucu, bir security group (güvenlik duvarı) ve bir Elastic IP tanımlarsınız.
2. Yazılımı Ayarlama: Ansible veya bir user_data betiği ile Node.js ve PM2'yi kurarsınız.
3. Değişiklikleri Uygulama: terraform apply komutunu çalıştırırsınız. Sunucu oluşturulur, yazılım kurulur ve uygulama ayağa kalkar.
4. Güncelleme: Uygulamanın yeni bir sürümü varsa, kodu değiştirir ve tekrar apply edersiniz. Terraform yalnızca gerekli değişiklikleri uygular.
5. Silme: Sunucuya artık ihtiyacınız yoksa, terraform destroy komutunu çalıştırırsınız ve her şey silinir — hiçbir şey atlanmadan.

Bu döngü, büyük şirketlerde "GitOps" olarak adlandırılan şeyin ta kendisidir: Altyapınız Git'te yaşar, her değişiklik Pull Request ile uygulanır ve kimse doğrudan sunucuya erişemez.

IaC'ye Ne Zaman Geçmelisiniz?

Yalnızca bir sunucunuz varsa ve onu kişisel bir proje için yönetiyorsanız, Altyapı Olarak Kod "fazla" gibi görünebilir. Ancak şu durumlarda:

• İkiden fazla sunucunuz varsa,
• Staging ve production ortamlarını yeniden oluşturmanız gerekiyorsa,
• Ekibiniz birden fazla kişiyse,
• Veya altyapının otomatik dokümantasyonuna ihtiyacınız varsa,

…Altyapı Olarak Kod artık bir seçenek değil; bir zorunluluktur. İlk öğrenme maliyeti (Terraform ile yaklaşık bir hafta), her dağıtımda kazandığınız saatlerin yanında önemsizdir.

API ve IaC araçlarıyla uyumlu bir altyapı arıyorsanız, ServerNet bulut hizmetleri, kaynakların programlama arayüzleri aracılığıyla yönetilmesine olanak tanır ve bu yaklaşımı uygulamak için iyi bir başlangıç noktası olabilir.

Özet: Sıradaki Adımınız

Altyapı Olarak Kod yalnızca bir araç değil; bir zihniyet değişikliğidir. Sunuculara elle oluşturulan "tek kullanımlık nesneler" olarak bakmak yerine, onları incelenebilir, test edilebilir ve yeniden üretilebilir "kod" olarak görün. Küçük bir projeyle başlayın: Terraform ile bir test sunucusu oluşturun, birkaç gün onunla çalışın ve önceki yöntemden ne kadar kolay olduğunu görün.

Başlamak için şu üç şeyi yapın:

1. Terraform'u kurun ve bir test sunucusu oluşturun.
2. .tf dosyalarınızı bir Git deposuna koyun.
3. Aynı sunucuya Nginx kuran basit bir Ansible betiği yazın.

Bu alıştırmadan sonra, Altyapı Olarak Kod'un neden en önemli DevOps becerilerinden biri haline geldiğini anlayacaksınız. Manuel yapılandırma için artık hiçbir bahane yok — tekrarlayan işleri yapmayı sevmiyorsanız tabii.