Uygulamalarınızın dinamik trafik dalgalanmalarına ayak uydurmakta veya altyapınızın yönetimini basitleştirmekte zorlanıyor musunuz? Günümüzün hızlı tempolu dijital dünyasında, bulut kaynaklarını etkili bir şekilde yönetmek ve ölçeklendirmek kritik öneme sahiptir. Bu makale, Azure Sanal Makine Ölçek Kümelerini (VMSS) Terraform ile otomatize etme ve altyapı kodunuzu GitHub’a güvenle taşıma sürecini adım adım açıklayarak, bu zorlukların üstesinden gelmenize yardımcı olacaktır.
Uygulamalarınızın kullanıcı taleplerine göre anında ölçeklenebilmesini, yüksek erişilebilirlik sunmasını ve yönetim yükünü azaltmasını mı istiyorsunuz? Azure Sanal Makine Ölçek Kümeleri (VMSS), işte tam da bu ihtiyaçları karşılamak üzere tasarlanmış güçlü bir bulut hizmetidir. Tek bir yapılandırma ile binlerce aynı sanal makineyi dağıtmanıza ve yönetmenize olanak tanır. Özellikle değişken iş yüklerine sahip uygulamalar için vazgeçilmez bir çözüm sunar.
Öncelikle, VMSS’nin sunduğu en büyük avantajlardan biri otomatik ölçeklendirmedir. Uygulamanızın trafik yükü arttığında, VMSS otomatik olarak yeni sanal makineler ekleyerek performansı sabit tutar. Trafik azaldığında ise gereksiz makineleri kapatarak maliyetleri optimize eder. Bu esneklik, özellikle Black Friday gibi yoğun alışveriş dönemlerinde anlık trafik patlamaları yaşayan bir e-ticaret platformu için hayat kurtarıcı olabilir. Manuel olarak sunucu ekleyip çıkarmak yerine, sistem bu süreci sizin için şeffaf bir şekilde yönetir. Bu, insan hatası riskini azaltırken operasyonel verimliliği önemli ölçüde artırır.
Bununla birlikte, VMSS aynı zamanda yüksek erişilebilirlik ve dayanıklılık sağlar. Ölçek kümesindeki bir sanal makine arızalandığında, VMSS otomatik olarak arızalı makineyi algılar ve yerine yenisini başlatır. Bu sayede uygulamanızın kesintisiz çalışmaya devam etmesi sağlanır. Ayrıca, Azure Load Balancer veya Application Gateway gibi yük dengeleyici hizmetlerle entegre olarak çalışır. Gelen trafiği ölçek kümesindeki tüm sanal makinelere eşit şekilde dağıtarak tek bir hata noktasını ortadan kaldırır ve uygulamanızın performansını maksimum seviyede tutar. Bu, iş sürekliliği açısından kritik bir rol oynar ve kullanıcı deneyimini doğrudan etkiler.
Son olarak, VMSS’nin kolay yönetim ve dağıtım özelliği, DevOps ekipleri için büyük bir kolaylık sunar. Tüm sanal makineler tek bir birim olarak yönetildiği için, işletim sistemi güncellemeleri, güvenlik yamaları veya uygulama dağıtımları gibi işlemler tek seferde tüm küme için uygulanabilir. Bu, manuel müdahale gerektiren süreçleri minimize eder ve zamandan tasarruf sağlar. Sanal makinelerin yapılandırmaları ve imajları tek bir merkezden kontrol edildiği için, tutarlılık sağlanır ve “konfigürasyon kayması” gibi sorunların önüne geçilir. Geliştiriciler ve operasyon ekipleri, altyapıyı kod olarak yönetme (Infrastructure as Code – IaC) prensiplerini benimseyerek, VMSS’nin kurulumunu ve yönetimini otomatikleştirebilirler. Bu, özellikle büyük ve karmaşık altyapılar için vazgeçilmez bir yetenektir.
Özetle, Azure VMSS; esneklik, dayanıklılık, ölçeklenebilirlik ve yönetim kolaylığı gibi bir dizi önemli avantaj sunarak modern bulut uygulamalarının temelini oluşturur. Uygulamanızın yoğunluğunu düşünmeden, sadece iş mantığınıza odaklanmanızı sağlayan bu güçlü hizmet, bulut altyapınızı daha verimli ve güvenilir hale getirir.
Altyapıyı Kod Olarak Yönetmek: Terraform ve Azure Entegrasyonu
Geleneksel olarak, sunucu ve ağ gibi altyapı bileşenlerinin elle yapılandırılması hem zaman alıcı hem de hataya açık bir süreçti. Peki ya altyapınızı, uygulamanızın kodu gibi yönetebilseydiniz? İşte bu noktada Altyapıyı Kod Olarak (Infrastructure as Code – IaC) kavramı ve onun en popüler araçlarından biri olan Terraform devreye giriyor. IaC, altyapının betikler veya tanım dosyaları aracılığıyla yönetilmesi, sağlanması ve yapılandırılması felsefesidir. Bu, altyapı dağıtımlarını tekrarlanabilir, tutarlı ve otomatize edilebilir hale getirir.
Terraform Nedir ve Neden Tercih Etmeliyiz?
Terraform, HashiCorp tarafından geliştirilen açık kaynaklı bir IaC aracıdır. Deklaratif bir dil (HashiCorp Configuration Language – HCL) kullanarak, istediğiniz altyapı durumunu tanımlamanıza olanak tanır. Siz Terraform’a “Şu kaynakları bu ayarlarla istiyorum” dersiniz, Terraform ise mevcut durumu analiz eder ve bu istediğiniz duruma ulaşmak için gereken adımları otomatik olarak atar. Bu, idempotent (aynı işlemi birden fazla kez uyguladığınızda hep aynı sonucu veren) bir yaklaşımdır, yani altyapınızın her zaman beklediğiniz gibi olmasını sağlar.
Terraform’u tercih etmemizin başlıca nedenleri şunlardır:
- Sağlayıcı Agnostik: Sadece Azure ile değil, AWS, Google Cloud, Oracle Cloud gibi birçok bulut sağlayıcısı ve VMware, Kubernetes gibi platformlarla entegre olabilir. Bu, hibrit bulut stratejileri uygulayan veya farklı sağlayıcılarda kaynakları olan şirketler için büyük bir avantajdır.
- Durum Yönetimi: Terraform, dağıtılan altyapının durumunu bir “state” dosyasında tutar. Bu dosya, gerçek altyapı ile kodunuz arasında bir eşleme görevi görür ve Terraform’un değişiklikleri doğru bir şekilde yönetmesini sağlar. Bu, manuel konfigürasyon kaymalarını önler ve her dağıtımın öngörülebilir olmasını sağlar.
- Modüler Yapı: Karmaşık altyapıları daha küçük, yeniden kullanılabilir modüllere ayırabilirsiniz. Bu modüller, farklı projelerde veya farklı ekipler arasında paylaşılabilir, bu da geliştirme hızını artırır ve tutarlılığı sağlar.
- Planlama Yeteneği:
terraform plankomutu, altyapınızda yapılacak değişiklikleri uygulamadan önce size gösterir. Bu sayede, beklenmedik sürprizlerle karşılaşma riskiniz azalır ve dağıtıma tam kontrol sağlarsınız.
Azure Üzerinde Terraform Kurulumu ve Yapılandırması
Terraform’u Azure ile kullanmaya başlamak için birkaç ön koşulun yerine getirilmesi gerekir:
- Terraform Kurulumu: İlk olarak, işletim sisteminize Terraform’u kurmanız gerekir. HashiCorp’un resmi web sitesinden veya paket yöneticiniz aracılığıyla kolayca kurabilirsiniz.
- Azure CLI Kurulumu: Terraform’un Azure kaynaklarını yönetebilmesi için Azure Komut Satırı Arayüzü (CLI) yüklü ve yapılandırılmış olmalıdır. Bu, Terraform’un Azure API’leriyle etkileşime geçmesini sağlar.
- Azure Kimlik Doğrulaması: Terraform’un Azure ortamında kaynak oluşturma, güncelleme veya silme yetkisine sahip olması için kimlik doğrulaması yapması gerekir. Bunun en güvenli ve önerilen yolu, bir Service Principal (Hizmet Sorumlusu) kullanmaktır.
Bir Service Principal oluşturmak için Azure CLI’da aşağıdaki komutları kullanabilirsiniz. Bu, Terraform’un Azure’a erişimini güvenli bir şekilde sağlar.
az ad sp create-for-rbac --name "terraform-sp" --role "Contributor" --scopes "/subscriptions/YOUR_SUBSCRIPTION_ID"
Bu komut size appId, password (client secret), tenant ve subscriptionId gibi bilgileri döndürecektir. Bu bilgiler, Terraform'un Azure sağlayıcısını yapılandırmak için kullanılacaktır. Bu bilgiler hassas olduğu için güvenli bir şekilde saklanmalıdır.
Terraform, altyapınızı kod olarak yöneterek DevOps süreçlerinizi hızlandırır ve tekrarlanabilirlik sağlar. Azure ile entegrasyonu sayesinde, bulut kaynaklarınızı deklaratif bir yaklaşımla kolayca dağıtabilir ve yönetebilirsiniz. Bu, hata oranını azaltırken verimliliği maksimize eder.
Terraform ile Azure VMSS Oluşturma Adım Adım Rehberi
Şimdi pratik kısma geçelim ve Terraform kullanarak Azure'da bir Sanal Makine Ölçek Kümesi oluşturalım. Bu süreç, basit bir web uygulaması için gerekli olan temel ağ bileşenlerinden, yük dengeleyiciye ve ölçek kümesinin kendisine kadar tüm altyapıyı kapsayacak. Amacımız, uygulamanızın ölçeklenebilir ve yüksek erişilebilir olmasını sağlamaktır.
Adım 1: Temel Ön Hazırlıklar ve Dosya Yapısı
Herhangi bir Terraform projesine başlamadan önce, projemiz için uygun bir dizin oluşturmalıyız. Bu dizin içinde, Terraform yapılandırma dosyalarımızı barındıracağız.
mkdir azure-vmss-terraform
cd azure-vmss-terraform
Bu dizin içerisinde, genellikle aşağıdaki gibi bir dosya yapısı kullanırız:
main.tf: Ana kaynak tanımlarımızı ve modül çağrılarını içerir.variables.tf: Değişken tanımlarını barındırır, böylece yapılandırmayı daha esnek hale getirebiliriz.outputs.tf: Dağıtım sonrası elde etmek istediğimiz çıktı değerlerini (örneğin, Public IP adresi) tanımlar.versions.tf: Terraform ve sağlayıcı versiyon kısıtlamalarını belirtir.
Adım 2: Terraform Yapılandırma Dosyaları
Şimdi bu dosyalara adım adım içerik ekleyelim:
versions.tf (Terraform ve Sağlayıcı Versiyonları)
Bu dosya, Terraform'un hangi sürümle ve Azure sağlayıcısının hangi sürümüyle çalışacağını belirtir. Bu, tutarlılık ve uyumluluk açısından önemlidir.
terraform {
required_version = ">= 1.0.0" # Terraform'un minimum sürümü
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0" # Azure sağlayıcısının sürümü
}
}
}
provider "azurerm" {
features {} # Azure provider'ın özellik setini etkinleştirir
}
variables.tf (Değişken Tanımları)
Bu dosya, dağıtımımızda kullanılacak dinamik değerleri tanımlar. Bu sayede kodu farklı ortamlar veya ayarlar için kolayca özelleştirebiliriz.
variable "resource_group_name" {
description = "Azure kaynak grubunun adı."
type = string
default = "rg-vmss-terraform-prod"
}
variable "location" {
description = "Kaynakların dağıtılacağı Azure bölgesi."
type = string
default = "West Europe"
}
variable "vmss_name" {
description = "Sanal Makine Ölçek Kümesinin adı."
type = string
default = "vmss-web-app"
}
variable "vm_size" {
description = "Sanal makinelerin boyutu (SKU)."
type = string
default = "Standard_B2s"
}
variable "admin_username" {
description = "Sanal makine için yönetici kullanıcı adı."
type = string
default = "azureuser"
}
variable "admin_password" {
description = "Sanal makine için yönetici şifresi."
type = string
sensitive = true # Hassas bilgi olduğunu belirtir
}
main.tf (Ana Kaynak Tanımları)
Bu en kapsamlı dosyamızdır. Burada kaynak grubundan, ağ bileşenlerine ve nihayet Sanal Makine Ölçek Kümesine kadar her şeyi tanımlayacağız.
# Azure Kaynak Grubu Oluşturma
resource "azurerm_resource_group" "rg" {
name = var.resource_group_name
location = var.location
}
# Sanal Ağ (VNet) Oluşturma
resource "azurerm_virtual_network" "vnet" {
name = "vnet-vmss"
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
}
# Alt Ağ (Subnet) Oluşturma
resource "azurerm_subnet" "subnet" {
name = "subnet-vmss"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
address_prefixes = ["10.0.2.0/24"]
}
# Genel IP Adresi Oluşturma (Yük Dengeleyici için)
resource "azurerm_public_ip" "pip" {
name = "pip-vmss-lb"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
allocation_method = "Static"
sku = "Standard"
}
# Yük Dengeleyici (Load Balancer) Oluşturma
resource "azurerm_lb" "lb" {
name = "lb-vmss"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
sku = "Standard"
frontend_ip_configuration {
name = "FrontEndIpConfiguration"
public_ip_address_id = azurerm_public_ip.pip.id
}
}
# Yük Dengeleyici Backend Havuzu Oluşturma
resource "azurerm_lb_backend_address_pool" "backend_pool" {
loadbalancer_id = azurerm_lb.lb.id
name = "BackendPool"
}
# Yük Dengeleyici Sağlık Kontrolü (Health Probe) Oluşturma
resource "azurerm_lb_probe" "http_probe" {
loadbalancer_id = azurerm_lb.lb.id
name = "http-probe"
port = 80 # Web sunucusunun çalıştığı port
protocol = "Tcp"
request_path = "/" # Sağlık kontrolü için HTTP yolu (isteğe bağlı)
}
# Yük Dengeleyici Kuralı Oluşturma (HTTP için)
resource "azurerm_lb_rule" "http_rule" {
loadbalancer_id = azurerm_lb.lb.id
name = "http-rule"
protocol = "Tcp"
frontend_port = 80
backend_port = 80
frontend_ip_configuration_name = azurerm_lb.lb.frontend_ip_configuration[0].name
backend_address_pool_ids = [azurerm_lb_backend_address_pool.backend_pool.id]
probe_id = azurerm_lb_probe.http_probe.id
disable_outbound_snat = true # VMSS için SNAT devre dışı bırakılır
}
# Ağ Güvenlik Grubu (NSG) Oluşturma (Opsiyonel, daha fazla güvenlik için)
resource "azurerm_network_security_group" "nsg" {
name = "nsg-vmss"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
security_rule {
name = "Allow_HTTP_Inbound"
priority = 100
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "80"
source_address_prefix = "Internet"
destination_address_prefix = "*"
}
security_rule {
name = "Allow_SSH_Inbound"
priority = 101
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "22"
source_address_prefix = "Internet"
destination_address_prefix = "*"
}
}
# Sanal Makine Ölçek Kümesi (VMSS) Oluşturma
resource "azurerm_linux_virtual_machine_scale_set" "vmss" {
name = var.vmss_name
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
sku = var.vm_size
instances = 2 # Başlangıç örnek sayısı
admin_username = var.admin_username
admin_password = var.admin_password
disable_password_authentication = false # SSH anahtarı yerine şifre kullanılır (test için)
os_disk {
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
source_image_reference {
publisher = "Canonical"
offer = "0001-com-ubuntu-server-focal"
sku = "20_04-lts-gen2"
version = "latest"
}
network_interface {
name = "vmss-nic"
primary = true
ip_configuration {
name = "vmss-ipconfig"
primary = true
subnet_id = azurerm_subnet.subnet.id
load_balancer_backend_address_pool_ids = [azurerm_lb_backend_address_pool.backend_pool.id]
}
}
# Özel komut dosyası ile web sunucusu (Nginx) yükleme
custom_data = base64encode(<Hello from Azure VMSS! Hostname: $(hostname)" > /var/www/html/index.nginx-debian.html
EOF
)
# Otomatik ölçeklendirme ayarları
# Bu örnekte minimum 2, maksimum 5 örnek arasında ölçeklenecek
# Daha gelişmiş kurallar için azurerm_monitor_autoscale_setting kaynağına bakınız.
# Bu basic örnekte sadece instance sayısı tanımlanmıştır.
}
Adım 3: Terraform Komutları
Yapılandırma dosyalarımızı tamamladıktan sonra, Terraform komutlarını kullanarak altyapımızı dağıtabiliriz:
terraform init: Terraform projesini başlatır, gerekli sağlayıcı eklentilerini indirir ve arka ucu yapılandırır.terraform plan: Yapılandırma dosyalarınızdaki değişiklikleri gerçek Azure ortamıyla karşılaştırır ve hangi kaynakların oluşturulacağını, güncelleneceğini veya silineceğini gösterir. Bu, bir dağıtımın ne yapacağını önceden görmek için kritik bir adımdır.terraform apply: Planlanan değişiklikleri Azure ortamına uygular ve kaynakları oluşturur. Sizden onay isteyecektir.
terraform init
terraform plan -var 'admin_password=YourStrongPasswordHere' # Şifreyi doğrudan komut satırında geçmek yerine değişkene atayın
terraform apply -var 'admin_password=YourStrongPasswordHere' # Otomatik onay için -auto-approve kullanabilirsiniz (dikkatli olun)
admin_password için bir değer sağlamayı unutmayın. Güvenlik nedeniyle, bu tür hassas bilgileri doğrudan komut satırında vermek yerine, çevre değişkenleri veya Terraform'un değişken dosyaları (.tfvars) aracılığıyla sağlamak daha güvenlidir.
variables.tf dosyasında sensitive = true olarak işaretlemek ve terraform.tfvars gibi bir dosyada tutmak, ancak bu dosyayı versiyon kontrolüne (GitHub'a) yüklememek en iyi uygulamadır. Bunun yerine, bu değişkenleri CI/CD ortamında secret olarak veya elle girerek sağlamalısınız.
Bu adımlarla, temel bir Azure Sanal Makine Ölçek Kümesini başarıyla dağıtmış olacaksınız. Yük dengeleyici genel IP adresini kullanarak web tarayıcınızdan "Hello from Azure VMSS!" mesajını görmelisiniz.
Altyapı Kodunuzu Versiyonlamak: GitHub Entegrasyonu
Altyapımızı kod olarak tanımlamak harika, ancak bu kodu nasıl yöneteceğiz, ekip içinde nasıl paylaşacağız ve zaman içindeki değişiklikleri nasıl takip edeceğiz? İşte bu noktada versiyon kontrol sistemleri ve özellikle GitHub devreye giriyor. Altyapı kodunuzu GitHub'da depolamak, sadece bir depolama çözümü değil, aynı zamanda işbirliği, güvenlik ve otomasyon için güçlü bir temel oluşturur.
Neden Altyapı Kodunu GitHub'a Yüklemeliyiz?
GitHub, dünyanın en büyük kod barındırma platformlarından biridir ve Git versiyon kontrol sistemini temel alır. Altyapı kodunuzu (Terraform dosyalarınızı) GitHub'a yüklemenin birçok avantajı vardır:
- Versiyon Kontrolü: Her değişiklik bir taahhüt (commit) olarak kaydedilir. Bu, geçmişe dönük tüm değişiklikleri görmenizi, belirli bir sürüme geri dönmenizi ve kimin hangi değişikliği yaptığını izlemenizi sağlar. Bu, hata ayıklama ve denetim süreçleri için paha biçilmezdir.
- İşbirliği ve Ekip Çalışması: Birden fazla geliştirici veya DevOps mühendisi aynı altyapı kodu üzerinde eş zamanlı olarak çalışabilir. Çekme istekleri (Pull Requests) ve kod incelemeleri (Code Reviews), değişikliklerin kaliteli ve güvenli olmasını sağlar. Bu, takımın birlikte daha verimli çalışmasını teşvik eder.
- CI/CD Tetikleyicisi: GitHub'a yapılan her kod değişikliği (push), otomatik olarak Sürekli Entegrasyon/Sürekli Dağıtım (CI/CD) iş akışlarını tetikleyebilir. Bu, altyapı değişikliklerinin otomatik olarak test edilmesini ve dağıtılmasını sağlar.
- Belgelendirme ve Şeffaflık: Kodun kendisi en iyi belgedir. GitHub, kodunuzu ve değişiklik geçmişini merkezi bir konumda tutarak, herkesin altyapınızın nasıl çalıştığını anlamasını kolaylaştırır.
- Güvenlik: Hassas bilgileri (şifreler, API anahtarları) doğrudan koda gömmek yerine, GitHub Secrets gibi özelliklerle güvenli bir şekilde yönetebilirsiniz. Ayrıca, GitHub'ın erişim kontrol mekanizmaları, deponuza kimlerin erişebileceğini ve hangi işlemleri yapabileceğini belirlemenizi sağlar.
Yerel Terraform Projesini GitHub Deposuna İtme
Terraform projenizi GitHub'a yüklemek oldukça basit bir süreçtir. Adımlar genellikle şu şekildedir:
- Yeni Bir GitHub Deposu Oluşturma: GitHub'a gidin ve projeniz için yeni bir boş depo (repository) oluşturun.
- Yerel Git Deposunu Başlatma: Terraform dosyalarınızın bulunduğu dizinde bir Git deposu başlatın.
.gitignoreDosyası Oluşturma: Terraform'un durum dosyası (terraform.tfstate) ve hassas değişkenler içeren.tfvarsdosyaları gibi bazı dosyalar kesinlikle versiyon kontrolüne dahil edilmemelidir. Bu dosyaları.gitignore'a ekleyerek Git'in bunları izlemesini engellersiniz.- Dosyaları Aşamaya Ekleme ve Taahhüt Etme: Değişikliklerinizi aşamaya (staging area) ekleyin ve bir taahhüt mesajıyla kaydedin.
- Uzak Depoyu Ekleme ve Yükleme: Yerel deponuzu GitHub'daki uzaktan depoyla ilişkilendirin ve kodunuzu yükleyin.
İşte komutlar:
# 1. Proje dizinine gidin
cd azure-vmss-terraform
# 2. Git deposunu başlatın
git init
# 3. .gitignore dosyası oluşturun ve hassas dosyaları ekleyin
echo "*.tfstate" > .gitignore
echo "*.tfstate.backup" >> .gitignore
echo "*.tfvars" >> .gitignore
echo ".terraform/" >> .gitignore
echo ".terraform.lock.hcl" >> .gitignore
echo "*.json" >> .gitignore # Eğer çıktıları JSON olarak alıyorsanız
# 4. Tüm Terraform dosyalarını (ve .gitignore'ı) aşamaya ekleyin
git add .
# 5. Değişiklikleri taahhüt edin (commit)
git commit -m "Initial commit: Azure VMSS Terraform configuration"
# 6. GitHub'da oluşturduğunuz deponun URL'sini buraya ekleyin
# Örneğin: https://github.com/kullaniciadi/azure-vmss-terraform.git
git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPOSITORY.git
# 7. Kodu GitHub'a yükleyin
git push -u origin main
Bu adımlar sayesinde altyapı kodunuz artık GitHub üzerinde merkezi olarak yönetilecek. Herhangi bir değişiklik yaptığınızda, git add ., git commit -m "mesaj" ve git push komutlarıyla bu değişiklikleri GitHub'a yansıtabilirsiniz.
Terraform Durum Dosyasının Güvenliği ve Uzak Durum Yönetimi
Yukarıdaki .gitignore örneğinde belirttiğimiz gibi, terraform.tfstate dosyası asla doğrudan Git deposuna yüklenmemelidir. Bu dosya, dağıttığınız altyapının tüm ayrıntılarını ve hassas verileri (örneğin, sanal makinelerin özel IP adresleri, SSH anahtarlarının bazı kısımları) içerebilir. Bunun yerine, Terraform'un uzak durum yönetimi (remote state) özelliğini kullanmalısınız.
Azure Blob Storage, Terraform durum dosyasını güvenli ve erişilebilir bir şekilde saklamak için mükemmel bir çözümdür. Uzak durum kullanarak, Terraform durumu merkezileştirilir ve ekip üyeleri arasında paylaşılabilir hale gelir, aynı zamanda kilit mekanizmaları sayesinde eş zamanlı dağıtımların çakışması önlenir. main.tf dosyanızın başına aşağıdaki bloğu ekleyerek uzak durumu yapılandırabilirsiniz (veya versions.tf içinde de tanımlanabilir):
terraform {
backend "azurerm" {
resource_group_name = "tfstate-rg" # Durum dosyasının tutulacağı kaynak grubu
storage_account_name = "tfstatesa12345" # Durum dosyasının tutulacağı depolama hesabı
container_name = "tfstate" # Depolama hesabı içindeki kapsayıcı adı
key = "vmss-production.tfstate" # Durum dosyasının adı
}
# ... diğer terraform ayarları ...
}
Bu yapılandırma ile terraform init komutunu çalıştırdığınızda, Terraform durum dosyanızı belirtilen Azure Blob Storage hesabına kaydedecektir. Bu, hem güvenlik hem de işbirliği için en iyi uygulamadır.
GitHub Actions ile Sürekli Dağıtım (CI/CD) Entegrasyonu
Altyapı kodumuzu GitHub'a yükledik, peki şimdi bu koddaki değişiklikleri nasıl otomatik olarak Azure'a dağıtabiliriz? Manuel terraform apply komutları yerine, GitHub Actions gibi bir Sürekli Entegrasyon/Sürekli Dağıtım (CI/CD) aracı kullanarak bu süreci tamamen otomatikleştirebiliriz. GitHub Actions, deponuzdaki olaylara (örneğin, bir push veya pull request) yanıt olarak iş akışları çalıştırmanıza olanak tanıyan esnek bir otomasyon platformudur.
GitHub Actions Nedir ve Neden Kullanmalıyız?
GitHub Actions, doğrudan GitHub deponuzda CI/CD iş akışları oluşturmanızı sağlar. Bu iş akışları, genellikle YAML dosyaları aracılığıyla tanımlanır ve bir veya daha fazla adım (adım), iş (job) ve eylem (action) içerir. GitHub Actions'ı kullanmanın başlıca faydaları şunlardır:
- Depo Entegrasyonu: İş akışlarınız doğrudan kodunuzla aynı deponun içinde yaşar. Bu, "yapılandırma kayması" riskini azaltır ve kod ile dağıtım arasındaki senkronizasyonu artırır.
- Geniş Ekosistem: Terraform dağıtımı, Docker imajı oluşturma, testleri çalıştırma gibi çeşitli görevler için binlerce hazır eylem (action) mevcuttur.
- Otomasyon: Her kod değişikliğinde otomatik testler ve dağıtımlar çalıştırarak manuel hataları azaltır ve dağıtım hızını artırır.
- Ücretsiz Katman: GitHub, açık kaynak projeleri ve küçük ekipler için cömert bir ücretsiz kullanım katmanı sunar.
Azure ile Kimlik Doğrulama ve GitHub Actions İş Akışı
GitHub Actions'ın Azure'da kaynakları yönetebilmesi için Azure'a kimlik doğrulaması yapması gerekir. Daha önce oluşturduğumuz Service Principal'ı bu amaçla kullanabiliriz. Service Principal'ın kimlik bilgilerini GitHub Actions'a güvenli bir şekilde aktarmak için GitHub Secrets'ı kullanmak en iyi yöntemdir.
GitHub deponuzda Settings > Secrets > Actions yolunu izleyerek yeni bir repo secret oluşturmalısınız. Aşağıdaki sırları ekleyin:
AZURE_CLIENT_ID: Service Principal'ınızınappIddeğeri.AZURE_CLIENT_SECRET: Service Principal'ınızınpassworddeğeri.AZURE_TENANT_ID: Azure kiracınızın (tenant) ID'si.AZURE_SUBSCRIPTION_ID: Azure aboneliğinizin ID'si.
Bu sırları kullanarak, GitHub Actions iş akışınız, Azure'a güvenli bir şekilde kimlik doğrulaması yapabilir.
Basit Bir GitHub Actions İş Akışı Örneği
Şimdi Terraform kodumuzu otomatik olarak dağıtacak basit bir iş akışı oluşturalım. Deponuzda .github/workflows/main.yml adında bir dosya oluşturun ve içine aşağıdaki içeriği yapıştırın:
name: Terraform Azure VMSS CI/CD
on:
push:
branches:
- main # main branch'ine yapılan her push'ta tetikle
pull_request:
branches:
- main # main branch'ine yapılan her pull request'te tetikle
env:
TF_VAR_admin_password: ${{ secrets.VM_ADMIN_PASSWORD }} # VM için yönetici şifresi (GitHub Secret'tan)
jobs:
terraform:
name: 'Terraform Apply'
runs-on: ubuntu-latest
environment: production # Ortam tanımlaması (isteğe bağlı, daha gelişmiş senaryolar için)
steps:
- name: Checkout Code
uses: actions/checkout@v3
- name: Setup Terraform
uses: hashicorp/setup-terraform@v2
with:
terraform_version: 1.5.0 # Kullanılacak Terraform sürümü
- name: Azure Login
uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Terraform Init
id: init
run: terraform init -backend-config="resource_group_name=tfstate-rg" -backend-config="storage_account_name=tfstatesa12345" -backend-config="container_name=tfstate" -backend-config="key=vmss-production.tfstate"
- name: Terraform Format
id: fmt
run: terraform fmt -check
- name: Terraform Validate
id: validate
run: terraform validate -no-color
- name: Terraform Plan
id: plan
run: terraform plan -no-color
# Eğer pull request ise, plan çıktısını yorum olarak ekle
# if: github.event_name == 'pull_request'
# env:
# GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Terraform Apply
id: apply
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
run: terraform apply -auto-approve -input=false -no-color
Bu iş akışı:
maindalına yapılan herpushveyapull_requestolayında tetiklenir.- Kodu depolar.
- Terraform'u ayarlar.
- Azure'a Service Principal kullanarak giriş yapar.
terraform initkomutunu çalıştırarak uzak durumu (Azure Blob Storage) yapılandırır.terraform fmt -checkile kod biçimlendirme kontrolü yapar.terraform validateile yapılandırma dosyasının geçerliliğini kontrol eder.terraform planile yapılacak değişiklikleri gösterir.- Sadece
maindalına yapılanpushişlemlerindeterraform apply -auto-approvekomutunu çalıştırarak değişiklikleri otomatik olarak dağıtır. Bu, üretim ortamına otomatik dağıtım için güçlü bir yaklaşımdır.
-auto-approve parametresini doğrudan main dalına yapılan her push işlemi için kullanmak riskli olabilir. Genellikle, terraform plan çıktısını bir insan incelemesinden geçirmek ve onaylamak için Pull Request yorumlarına eklemek veya ayrı bir manuel onay adımı eklemek daha güvenli bir yaklaşımdır.
Bu iş akışı, altyapı kodunuzun versiyonlanmasını ve dağıtımını tamamen otomatik hale getirerek DevOps süreçlerinizi büyük ölçüde hızlandırır ve insan hatası riskini minimize eder. Böylece, geliştirme ekipleri altyapı dağıtımını beklemek yerine daha hızlı bir şekilde yeni özellikler üzerinde çalışabilirler.
Gelişmiş Konfigürasyonlar ve En İyi Uygulamalar
Terraform ve Azure VMSS ile temel bir dağıtım yapmayı öğrendik. Şimdi ise daha karmaşık senaryolar ve üretim ortamları için gerekli olabilecek bazı ileri düzey konfigürasyonlara ve en iyi uygulamalara göz atalım. Bu teknikler, altyapınızın daha esnek, güvenli ve yönetilebilir olmasını sağlayacaktır.
Özel Sanal Makine İmajları Kullanımı
Yukarıdaki örnekte Azure'un standart Ubuntu imajını kullandık. Ancak genellikle uygulamalarınızın belirli bağımlılıkları veya özel yapılandırmaları olur. Bu durumlarda, önceden yapılandırılmış özel bir sanal makine imajı (Custom Image) kullanmak mantıklıdır. Azure Compute Gallery (önceden Shared Image Gallery), özel imajlarınızı yönetmek ve VMSS tarafından kullanılabilir hale getirmek için ideal bir çözümdür.
Özel bir imaj kullanmak için, azurerm_linux_virtual_machine_scale_set kaynağının source_image_reference bloğunu aşağıdaki gibi değiştirebilirsiniz:
resource "azurerm_linux_virtual_machine_scale_set" "vmss" {
# ... diğer ayarlar ...
source_image_id = "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RG/providers/Microsoft.Compute/galleries/YOUR_GALLERY_NAME/images/YOUR_IMAGE_DEFINITION_NAME/versions/YOUR_IMAGE_VERSION"
# Veya Managed Image kullanmak için:
# source_image_id = azurerm_image.my_custom_image.id
# ... diğer ayarlar ...
}
Bu yaklaşım, VMSS örneklerinizin her zaman aynı temel yapılandırma ile başlatılmasını garanti eder ve başlangıç sürelerini kısaltır, çünkü custom_data içindeki betiklerin çalıştırılmasına gerek kalmaz.
Gelişmiş Ölçeklendirme Politikaları ve Metrikler
Örneğimizde VMSS'yi sabit bir örnek sayısıyla başlattık. Ancak VMSS'nin gücü, otomatik ölçeklendirme yeteneklerinden gelir. azurerm_monitor_autoscale_setting kaynağını kullanarak, CPU kullanımı, bellek tüketimi, ağ trafiği veya Azure Kuyruk depolama uzunluğu gibi metrikleri temel alan karmaşık ölçeklendirme kuralları tanımlayabilirsiniz.
resource "azurerm_monitor_autoscale_setting" "vmss_autoscale" {
name = "vmss-autoscale-profile"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
target_resource_id = azurerm_linux_virtual_machine_scale_set.vmss.id
profile {
name = "default"
capacity {
default = 2
minimum = 2
maximum = 5
}
rule {
metric_trigger {
metric_name = "Percentage CPU"
metric_resource_id = azurerm_linux_virtual_machine_scale_set.vmss.id
time_grain = "PT1M"
statistic = "Average"
time_window = "PT5M"
aggregation = "Average"
operator = "GreaterThan"
threshold = 75
}
scale_action {
direction = "Increase"
type = "ChangeCount"
value = 1
cooldown = "PT5M"
}
}
rule {
metric_trigger {
metric_name = "Percentage CPU"
metric_resource_id = azurerm_linux_virtual_machine_scale_set.vmss.id
time_grain = "PT1M"
statistic = "Average"
time_window = "PT5M"
aggregation = "Average"
operator = "LessThan"
threshold = 25
}
scale_action {
direction = "Decrease"
type = "ChangeCount"
value = 1
cooldown = "PT5M"
}
}
}
}
Bu yapılandırma, CPU kullanımı %75'in üzerine çıktığında VMSS'ye bir örnek ekler, %25'in altına düştüğünde ise bir örnek kaldırır. Bu, uygulamanızın performansını korurken maliyetleri optimize etmenin etkili bir yoludur.
Modüler Yapılandırma (Terraform Modülleri)
Daha karmaşık altyapılar veya farklı projelerde yeniden kullanılabilir bileşenler oluşturmak istediğinizde, Terraform modülleri devreye girer. Modüller, bir veya daha fazla kaynak tanımını bir araya getirerek soyutlama sağlar. Örneğin, bir "ağ" modülü bir VNet, alt ağlar ve güvenlik gruplarını paketleyebilir, veya bir "vmss" modülü ölçek kümesi, yük dengeleyici ve otomatik ölçeklendirme ayarlarını içerebilir.
# Örnek bir modül çağrısı
module "web_vmss" {
source = "./modules/web-vmss" # Yerel bir modül yolu
# source = "Azure/vmss/azurerm" # Terraform Registry'den bir modül
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
vmss_name = var.vmss_name
# ... diğer modül değişkenleri ...
}
Modüller, kodunuzu daha okunabilir, yönetilebilir ve yeniden kullanılabilir hale getirerek büyük projelerde karmaşıklığı azaltır.
Güvenlik İpuçları ve En İyi Uygulamalar
Bulut altyapısı güvenliği her zaman öncelikli olmalıdır:
- En Az Yetki Prensibi: Terraform'un Azure'a erişimi için kullandığı Service Principal'a yalnızca ihtiyaç duyduğu minimum izinleri verin. Örneğin, sadece kaynak oluşturma ve yönetme yetkisi, abonelik düzeyinde "Katkıda Bulunan" rolünden daha güvenlidir.
- Hassas Veri Yönetimi: Şifreler ve anahtarlar gibi hassas verileri doğrudan kodda veya Git deposunda tutmaktan kaçının. GitHub Secrets, Azure Key Vault veya HashiCorp Vault gibi araçları kullanarak bu verileri güvenli bir şekilde yönetin. Terraform'un
sensitive = truedeğişken özelliğini kullanın. - Ağ Güvenliği: Ağ Güvenlik Grupları (NSG'ler) ve Azure Güvenlik Duvarı (Firewall) kullanarak sanal ağ trafiğini sıkı bir şekilde kontrol edin. Yalnızca gerekli portları ve IP adreslerini açın.
- Denetim ve İzleme: Dağıtılan kaynakları Azure Monitor ve Azure Log Analytics ile izleyerek performans ve güvenlik anormalliklerini takip edin.
- DevOps ve Mobil Uyumlu HTML: Oluşturduğunuz web uygulamaları için mobil uyumlu tasarımlar kullanın. VMSS üzerinde çalışan web uygulamalarınızın kullanıcı arayüzü, farklı cihazlarda (mobil, tablet, masaüstü) sorunsuz çalışmalıdır. Bu, CSS medya sorguları (media queries) ile sağlanır:
/* Örnek Mobil Uyumlu CSS */ @media only screen and (max-width: 600px) { body { font-size: 14px; } .container { width: 100%; padding: 10px; } }
Bu gelişmiş konfigürasyonlar ve en iyi uygulamalar, Azure Sanal Makine Ölçek Kümeleri dağıtımlarınızı daha sağlam, güvenli ve verimli hale getirecek, böylece uygulamanızın performansı ve kullanıcı deneyimi üzerinde olumlu bir etki yaratacaktır.
Sonuç ve Sıkça Sorulan Sorular
Bu makale boyunca, Azure Sanal Makine Ölçek Kümeleri'nin (VMSS) ne olduğunu, dinamik iş yüklerini nasıl karşıladığını ve yüksek erişilebilirlik sağladığını detaylıca inceledik. Ardından, altyapıyı kod olarak yönetme prensiplerini ve Terraform'un bu süreçteki merkezi rolünü ele aldık. Adım adım bir VMSS'nin Terraform ile nasıl oluşturulacağını gösterdik, gerekli ağ bileşenlerinden yük dengeleyiciye kadar tüm adımları kod örnekleriyle destekledik. Altyapı kodumuzu GitHub'a taşımanın faydalarını ve versiyon kontrolünün önemini vurguladık, ayrıca GitHub Actions ile otomatik CI/CD iş akışlarının nasıl kurulacağını gösterdik. Son olarak, özel imajlar, gelişmiş ölçeklendirme politikaları ve güvenlik ipuçları gibi ileri düzey konulara değindik.
Terraform ile Azure VMSS'i dağıtmak ve bunu GitHub üzerinde yönetmek, modern bulut altyapısı yönetiminin temel taşlarındandır. Bu yaklaşım, sadece altyapı dağıtımını otomatikleştirmekle kalmaz, aynı zamanda operasyonel maliyetleri düşürür, dağıtım hızını artırır ve insan hatası riskini minimize eder. Ekiplerin işbirliği yapmasını kolaylaştırır ve altyapının tutarlılığını garanti altına alır. Gelecekte, daha karmaşık mimarileri yönetmek, çoklu bulut senaryolarını ele almak ve gelişmiş izleme entegrasyonları kurmak için bu temel bilgilerden yola çıkabilirsiniz. DevOps pratiklerinizi bir üst seviyeye taşımak ve bulut ortamınızın tam potansiyelini kullanmak için bu araçları ve yöntemleri benimsemek kritik öneme sahiptir.
Sıkça Sorulan Sorular (SSS)
1. VMSS'te disk şifrelemesi nasıl yapılır?
Cevap: Azure VMSS'te disk şifrelemesi için Azure Disk Encryption'ı (ADE) kullanabilirsiniz. Terraform'da, azurerm_virtual_machine_scale_set kaynağının içinde diskleri şifrelemek için özel uzantıları veya yönetilen diskler için Key Vault ile entegrasyonu yapılandırabilirsiniz. Ancak bu işlem, kimlik doğrulama ve anahtar yönetimi nedeniyle ek yapılandırmalar gerektirir. En kolay yolu, VMSS örnekleriniz için disk şifrelemesi yapabilen önceden şifrelenmiş bir özel imaj kullanmaktır.
2. Terraform durumu (state) güvenli bir şekilde nasıl yönetilir?
Cevap: Terraform durum dosyası (.tfstate) hassas bilgiler içerebileceği için yerel olarak saklanmamalı veya versiyon kontrolüne (GitHub'a) yüklenmemelidir. En iyi uygulama, Azure Blob Storage gibi uzak bir depolama hizmetini kullanmaktır. Bu, durumu merkezileştirir, ekipler arasında paylaşılabilir hale getirir ve eşzamanlı değişiklikleri önlemek için kilitleme mekanizmaları sağlar. terraform init komutunu çalıştırırken uzak depolama ayarlarını belirtmeniz gerekir.
3. Özel bir Linux dağıtımı veya Windows Server kullanabilir miyim?
Cevap: Evet, kesinlikle kullanabilirsiniz. Terraform'daki azurerm_linux_virtual_machine_scale_set yerine azurerm_windows_virtual_machine_scale_set kaynağını kullanarak Windows Server tabanlı bir VMSS oluşturabilirsiniz. Ayrıca, source_image_reference bloğunda istediğiniz Linux dağıtımının (örneğin, Debian, CentOS) yayımlayıcı, teklif, SKU ve sürüm bilgilerini belirterek veya özel bir Azure Compute Gallery (Shared Image Gallery) imajı kullanarak istediğiniz işletim sistemini dağıtabilirsiniz.
4. GitHub Actions ile birden fazla ortamı (dev, staging, prod) nasıl yönetirim?
Cevap: Birden fazla ortamı yönetmek için genellikle iki ana yaklaşım kullanılır:
- Ayrı Dizeler/Dallar: Her ortam için ayrı Terraform yapılandırma dizinleri veya GitHub dalları oluşturabilirsiniz (örn.
environments/dev,environments/prod). GitHub Actions iş akışlarınız, hangi dalda veya dizinde değişiklik yapıldığına göre ilgili ortamı hedefleyebilir. - Terraform Çalışma Alanları (Workspaces): Terraform'un kendi içinde çalışma alanları oluşturarak aynı Terraform kodunu farklı durum dosyalarıyla birden fazla ortam için kullanabilirsiniz (
terraform workspace new dev,terraform workspace new prod). Ancak, karmaşık ortamlar için ayrı dizeler genellikle daha şeffaf ve yönetilebilir kabul edilir.
Her ortam için farklı GitHub Secrets ve Azure Service Principal'lar kullanarak kimlik doğrulamasını ayırmak da önemlidir.
5. Azure VMSS maliyetlerini nasıl optimize edebilirim?
Cevap: Maliyet optimizasyonu için birkaç yöntem bulunmaktadır:
- Otomatik Ölçeklendirme Kuralları: Etkili otomatik ölçeklendirme kuralları tanımlayarak, yalnızca ihtiyaç duyulduğunda örneklerin çalışmasını sağlayın. Gerekmediğinde örnekleri azaltın.
- Sanal Makine Boyutu (SKU): İş yükünüz için uygun en küçük ve maliyet etkin sanal makine boyutunu seçin.
- Azure Reserved Instances: Uzun süreli (1 veya 3 yıl) kullanım taahhüdü vererek sanal makine maliyetlerinde önemli indirimler elde edebilirsiniz.
- Spot Sanal Makineler: Kesintiye toleranslı iş yükleri için (örn. batch processing), Azure Spot Sanal Makineleri kullanarak çok daha düşük maliyetlerle örnekler çalıştırabilirsiniz.
- Kaynakları Temizleme: Kullanmadığınız test veya geliştirme ortamlarını silmeyi unutmayın. Terraform'un
terraform destroykomutu bu konuda size yardımcı olabilir.