Terraform, S3 ve GitHub Actions ile Altyapı Otomasyonu

Modern yazılım dünyasında altyapı yönetimi zorlayıcı ve zaman alıcı bir süreç olabilir. Bu makale, Terraform, AWS S3 ve GitHub Actions’ı kullanarak altyapınızı nasıl otomatikleştireceğinizi adım adım açıklayacaktır.

Günümüzün hızla değişen teknoloji dünyasında, yazılım geliştirme süreçleri sürekli olarak evrim geçiriyor. Manuel altyapı yönetimi, bir zamanlar standart bir uygulama olsa da, beraberinde birçok zorluğu getiriyor: insan hatası riski, uzun dağıtım süreleri, ortamlar arası tutarsızlıklar ve en önemlisi ölçeklenebilirlik sorunları. Örneğin, yeni bir özelliği devreye almak için onlarca sunucuyu tek tek yapılandırmak, hem yorucu hem de hata payı yüksek bir işlemdir. Bu durum, özellikle hızla büyüyen startup’lar ve büyük ölçekli kurumsal şirketler için ciddi bir darboğaz oluşturur. Bir startup’ın ürününü piyasaya sürmesi veya mevcut bir e-ticaret platformunun Kara Cuma gibi yoğun dönemlerde ani trafik artışlarına yanıt vermesi gerektiğinde, manuel süreçler operasyonel bir kabusa dönüşebilir.

İşte tam bu noktada Altyapı Kod Olarak (Infrastructure as Code – IaC) kavramı devreye giriyor. IaC, sunucular, veritabanları, ağ yapılandırmaları ve diğer bulut kaynakları gibi altyapı bileşenlerini kod dosyaları aracılığıyla tanımlama ve yönetme pratiğidir. Bu yaklaşım, geleneksel manuel süreçlerin aksine, altyapının versiyon kontrol sistemlerinde (örneğin Git) saklanmasını, test edilmesini ve otomatik olarak dağıtılmasını sağlar. Böylece altyapı, yazılım kodu gibi ele alınır ve aynı disiplin ve süreçlerden geçer.

IaC’nin benimsenmesi, geliştirme ekiplerine birçok önemli avantaj sunar. Her şeyden önce, dağıtım süreçleri inanılmaz derecede hızlanır. Yeni bir ortamı saniyeler veya dakikalar içinde ayağa kaldırmak mümkün hale gelir. İkincisi, tutarlılık sağlanır. Kod tabanlı tanımlamalar sayesinde, geliştirme, test ve üretim ortamları arasında neredeyse mükemmel bir uyum elde edilir, bu da “benim makinemde çalışıyordu” gibi sorunların önüne geçer. Üçüncüsü, hata riski önemli ölçüde azalır. Otomatik dağıtım, manuel yapılandırmadan kaynaklanan yanlış yazım hatalarını veya eksik adımları ortadan kaldırır. Son olarak, IaC maliyet kontrolü konusunda da önemli faydalar sunar. Kullanılmayan veya gereksiz kaynakları tespit etmek ve otomatik olarak sonlandırmak daha kolay hale gelir, böylece bulut faturanızda önemli ölçüde tasarruf sağlanabilir. DevOps kültürünün ve CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) pratiklerinin merkezinde yer alan IaC, modern bulut bilişim ortamlarında başarılı olmanın vazgeçilmez bir bileşenidir.

Terraform Nedir ve Temel Kavramları Nelerdir?

Altyapı Kod Olarak (IaC) dünyasının en popüler ve güçlü araçlarından biri hiç şüphesiz HashiCorp Terraform’dur. Terraform, deklaratif bir yaklaşımla altyapınızı tanımlamanıza, sağlamanıza ve yönetmenize olanak tanıyan açık kaynaklı bir araçtır. Farklı bulut sağlayıcıları (AWS, Azure, Google Cloud) ve diğer servislerle (Kubernetes, VMWare vb.) entegre olabilen evrensel yapısı sayesinde, çoklu bulut stratejileri uygulayan şirketler için vazgeçilmez bir çözüm haline gelmiştir.

Terraform’un temelinde birkaç ana kavram bulunur:

• Providers (Sağlayıcılar): Terraform’un belirli bir altyapı platformu veya hizmetiyle etkileşim kurmasını sağlayan eklentilerdir. Örneğin, AWS kaynaklarını yönetmek için aws sağlayıcısını, Azure kaynakları için azurerm sağlayıcısını kullanırız. Bu sağlayıcılar, API çağrıları yaparak kaynakları oluşturur, günceller veya siler.
• Resources (Kaynaklar): Yönetmek istediğimiz altyapı bileşenleridir. Bir AWS EC2 örneği, bir S3 kovası, bir veritabanı veya bir sanal ağ gibi her şey bir Terraform kaynağı olarak tanımlanır. Kaynaklar, istenen durumu (desired state) bildiren deklaratif kod blokları ile tanımlanır.
• Data Sources (Veri Kaynakları): Mevcut altyapıdaki bilgileri okumak için kullanılır. Örneğin, mevcut bir AMI (Amazon Machine Image) ID’sini almak veya var olan bir VPC’nin (Virtual Private Cloud) ID’sini sorgulamak için veri kaynaklarından faydalanırız. Bu, Terraform’un yeni kaynaklar oluştururken mevcut kaynaklarla etkileşim kurmasını sağlar.
• Modules (Modüller): Terraform kodunu mantıksal olarak gruplandırmak ve tekrar kullanılabilir hale getirmek için kullanılan temel yapıdır. Bir modül, bir veya daha fazla kaynak tanımını kapsayan bir klasörden ibarettir. Örneğin, bir web sunucusu (EC2), güvenlik grubu ve yük dengeleyiciyi içeren bir modül oluşturarak, bu yapılandırmayı farklı projelerde veya ortamlarda kolayca tekrar kullanabilirsiniz. Bu, kod tekrarını azaltır ve büyük altyapıların yönetimini basitleştirir.

Terraform’un iş akışı genellikle şu komutlarla ilerler:

1. terraform init: Çalışma dizinini başlatır, sağlayıcı eklentilerini indirir ve backend yapılandırmasını kurar.
2. terraform plan: Kodunuzun mevcut altyapıyla karşılaştırıldığında ne gibi değişiklikler yapacağını gösteren bir yürütme planı oluşturur. Bu adım, dağıtım öncesi olası hataları ve istenmeyen değişiklikleri tespit etmek için kritik öneme sahiptir.
3. terraform apply: plan tarafından belirlenen değişiklikleri gerçek altyapıda uygular. Bu komut genellikle bir onay gerektirir, ancak otomasyon senaryolarında -auto-approve bayrağı ile bu onay adımı atlanabilir.
4. terraform destroy: Terraform tarafından yönetilen tüm kaynakları kaldırır. Dikkatli kullanılması gereken, geri dönüşü olmayan bir işlemdir.

Terraform’un en kritik bileşenlerinden biri ise state dosyasıdır (genellikle terraform.tfstate). Bu dosya, Terraform’un yönettiği gerçek altyapı kaynakları ile kodunuzda tanımladığınız istenen durum arasındaki eşleşmeyi sağlar. Yani, Terraform’un “nerede olduğunu” ve “ne yaptığını” kaydettiği bir referans noktasıdır. State dosyası, kaynakların ID’leri, öznitelikleri ve bağımlılıkları gibi hassas bilgileri içerebilir. Bu nedenle, state dosyasının güvenli, versiyonlanabilir ve merkezi bir yerde saklanması, özellikle ekip ortamlarında çalışırken hayati önem taşır. İşte bu yüzden uzaktan state yönetimi, özellikle AWS S3 gibi çözümlerle, vazgeçilmez bir uygulama haline gelmiştir.

Basit bir AWS EC2 örneği ile Terraform kod yapısına göz atalım:

resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890" # Lütfen güncel ve bölgenize uygun bir AMI ID kullanın
  instance_type = "t2.micro"
  tags = {
    Name = "MyWebServer"
    Environment = "Dev"
  }
}
    

Bu kod bloğu, AWS üzerinde tek bir EC2 örneği oluşturmak için yeterlidir. Ancak gerçek dünya senaryolarında, bu kod çok daha karmaşık hale gelebilir ve birden fazla kaynaktan oluşur.

Neden Uzaktan Terraform Durumu (State) Yönetmeliyiz: AWS S3 Backend'in Gücü

Terraform'un state dosyası (.tfstate), yönettiği altyapının mevcut durumunu içeren kritik bir JSON dosyasıdır. Başlangıçta, Terraform bu dosyayı yerel çalışma dizininizde oluşturur. Ancak, bu yerel yaklaşım, bireysel projeler veya tek kişilik ekipler için uygun olsa da, daha büyük ekipler veya üretim ortamları için ciddi sınırlamalara ve risklere sahiptir. Yerel state dosyasının dezavantajları şunlardır:

• Takım Çalışması Zorluğu: Birden fazla geliştirici aynı altyapı üzerinde çalıştığında, yerel state dosyaları kolayca çakışabilir ve tutarsızlıklara yol açabilir. Bir geliştirici değişiklik yapıp state dosyasını güncellediğinde, diğerlerinin bu güncellemeyi manuel olarak alması gerekir, bu da hata eğilimini artırır.
• Versiyon Kontrolü Eksikliği: Yerel state dosyası, genellikle Git gibi versiyon kontrol sistemlerine doğrudan dahil edilmez (güvenlik ve boyut nedeniyle). Bu durum, altyapının belirli bir zamandaki durumunu takip etmeyi veya önceki bir duruma geri dönmeyi zorlaştırır.
• Güvenlik Riski: State dosyası, IP adresleri, DNS kayıtları ve hatta hassas API anahtarları veya veritabanı şifreleri gibi bilgileri şifrelenmemiş olarak içerebilir. Yerel makinede saklanması, yetkisiz erişim durumunda ciddi bir güvenlik açığı oluşturur.
• Kayıp Riski: Yerel makinenin çökmesi veya dosyanın yanlışlıkla silinmesi, Terraform'un altyapınızla olan bağlantısını kaybetmesine ve altyapınızı yönetememesine neden olabilir. Bu durum, felaketle sonuçlanabilir ve altyapıyı yeniden oluşturma veya manuel olarak senkronize etme gibi zahmetli süreçler gerektirebilir.

Bu sorunları aşmak için Terraform, "remote backend" (uzaktan durum arka ucu) kavramını sunar. Uzaktan state yönetimi, state dosyasını merkezi ve güvenli bir depolama konumuna taşır. AWS S3 (Simple Storage Service) bu amaç için en yaygın ve önerilen çözümlerden biridir. AWS S3 backend'i kullanmanın faydaları ise saymakla bitmez:

• Takım İşbirliği: Tüm ekip üyeleri, merkezi bir state dosyasına erişebilir ve altyapı değişikliklerini güvenli bir şekilde koordine edebilir.
• Kilitleme Mekanizması: Terraform, S3 ile birlikte AWS DynamoDB'yi kullanarak state kilitleme (state locking) mekanizması sağlar. Bu, birden fazla kullanıcının aynı anda terraform apply çalıştırmasını engeller ve state dosyasının bozulmasını önler.
• Versiyonlama: S3 kovalarında versiyonlama etkinleştirildiğinde, state dosyasının her sürümü otomatik olarak saklanır. Bu sayede, yanlışlıkla yapılan bir değişiklik durumunda kolayca önceki bir sürüme geri dönülebilir (rollback).
• Şifreleme: S3, dosyaları depolarken AES-256 sunucu tarafı şifrelemesi (SSE-S3) veya AWS Key Management Service (KMS) ile şifreleme seçenekleri sunar. Bu, state dosyasındaki hassas verilerin güvende olmasını sağlar.
• Merkezi Yönetim ve Denetim: State dosyasının merkezi bir konumda olması, güvenlik politikalarının uygulanmasını ve erişim kontrollerinin yönetilmesini kolaylaştırır.

Peki, AWS S3 backend nasıl yapılandırılır? İlk olarak, Terraform state dosyanızı saklamak için bir S3 kovasına ve state kilitleme için bir DynamoDB tablosuna ihtiyacınız vardır. Bu kaynakları da aslında Terraform ile oluşturabiliriz, tıpkı aşağıdaki örnekte olduğu gibi:

resource "aws_s3_bucket" "terraform_state" {
  bucket = "my-unique-terraform-state-bucket-12345" # Benzersiz bir isim seçmelisiniz
  acl    = "private"

  versioning {
    enabled = true # State dosyasının versiyonlanmasını sağlar
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256" # Varsayılan şifreleme
      }
    }
  }

  tags = {
    Name        = "Terraform State Bucket"
    Environment = "Dev"
  }
}

resource "aws_dynamodb_table" "terraform_state_lock" {
  name           = "terraform-state-lock-table" # Kilitleme için DynamoDB tablosu
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}
    

Bu kaynaklar oluşturulduktan sonra, Terraform yapılandırma dosyanızda (genellikle main.tf veya ayrı bir backend.tf dosyasında) S3 backend'ini tanımlayabilirsiniz:

terraform {
  backend "s3" {
    bucket         = "my-unique-terraform-state-bucket-12345"
    key            = "dev/infrastructure.tfstate" # State dosyasının S3 içindeki yolu
    region         = "us-east-1"
    encrypt        = true # S3 üzerinde şifrelenmiş depolama
    dynamodb_table = "terraform-state-lock-table" # Kilitleme için DynamoDB tablosu
  }
}
    

Bu yapılandırmayı ekledikten sonra, ilk terraform init komutunu çalıştırdığınızda, Terraform state dosyanızı belirtilen S3 kovasına otomatik olarak taşıyacak ve DynamoDB tablosunu kilitleme mekanizması için kullanacaktır. Bu sayede, altyapı yönetiminiz daha güvenli, işbirlikçi ve esnek hale gelir.

GitHub Actions ile Otomatik Altyapı Dağıtımı Nasıl Yapılır?

Altyapımızı kod olarak tanımladık ve state dosyamızı güvenli bir şekilde yönetmeyi öğrendik. Şimdi sıra geldi bu altyapıyı otomatik olarak dağıtmaya. Sürekli Entegrasyon (CI) ve Sürekli Dağıtım (CD) prensipleri, yazılım geliştirmenin ayrılmaz bir parçası haline gelmiştir ve bu prensipler altyapı yönetimine de uygulanabilir. CI/CD süreçleri, kod değişikliklerinin otomatik olarak test edilmesini, derlenmesini ve dağıtılmasını sağlayarak geliştirme döngüsünü hızlandırır ve hataları azaltır.

GitHub Actions, GitHub deposu içinde doğrudan CI/CD iş akışları oluşturmanıza ve otomasyonu tetiklemenize olanak tanıyan güçlü bir araçtır. Bir kod değişikliği (örneğin bir push veya pull request) gibi belirli olaylar tarafından tetiklenebilen özelleştirilebilir iş akışları (workflows) tanımlayabilirsiniz. GitHub Actions, bu otomasyonu YAML dosyaları aracılığıyla yönetir, bu da iş akışlarınızın da kod olarak versiyonlanabilmesi anlamına gelir.

Bir GitHub Actions iş akışı (workflow) temel olarak şu bileşenlerden oluşur:

• on: İş akışını tetikleyecek olayları tanımlar (örneğin, push, pull_request, schedule).
• jobs: İş akışının içinde çalışacak bir veya daha fazla işi tanımlar. Her iş, birbirinden bağımsız olarak veya bağımlılıklar tanımlanarak çalışabilir.
• steps: Her bir işin içinde yürütülecek komutları veya eylemleri (actions) tanımlar. Bir adım, bir komut çalıştırmak veya bir GitHub Action'ı kullanmak olabilir.

Terraform ile altyapı dağıtımını otomatikleştirmek için GitHub Actions'ı nasıl kullanacağımıza adım adım bakalım:

1. GitHub Repository Oluşturma: Terraform kodunuzu içeren bir GitHub deposu oluşturun veya mevcut bir depoyu kullanın.
2. AWS Kimlik Bilgileri ve GitHub Secrets: GitHub Actions'ın AWS kaynaklarınıza erişebilmesi için kimlik bilgilerine ihtiyacı vardır. AWS'te bir IAM kullanıcısı oluşturun, bu kullanıcıya Terraform'un oluşturacağı kaynakları yönetme yetkisi veren bir politika (least privilege prensibiyle) atayın ve bu kullanıcının Erişim Anahtarı Kimliği (Access Key ID) ile Gizli Erişim Anahtarını (Secret Access Key) alın. Bu anahtarları doğrudan YAML dosyanıza yazmak yerine, GitHub Secrets olarak depolamanız hayati derecede önemlidir. Deponuzda "Settings -> Secrets -> Actions" bölümüne giderek AWS_ACCESS_KEY_ID ve AWS_SECRET_ACCESS_KEY adında iki yeni sır oluşturun.
3. Workflow YAML Dosyasını Oluşturma: Deponuzun kök dizininde .github/workflows/ adında bir klasör oluşturun ve içine main.yml (veya istediğiniz başka bir isimde) bir YAML dosyası ekleyin. Bu dosya, CI/CD iş akışınızı içerecektir.

Aşağıda, bir push olayı (özellikle main branch'e) veya bir pull_request açıldığında Terraform planı oluşturup, main branch'e yapılan birleştirme (merge) sonrası Terraform'u uygulayan örnek bir GitHub Actions workflow YAML dosyası bulunmaktadır:

name: Terraform AWS Altyapısı Dağıtımı

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  terraform:
    name: 'Terraform Plan ve Uygulama'
    runs-on: ubuntu-latest # İşin çalışacağı işletim sistemi

    steps:
      - name: 'Depoyu Kontrol Et'
        uses: actions/checkout@v3 # Depoyu GitHub Actions ortamına kopyalar

      - name: 'Terraform CLI Kur'
        uses: hashicorp/setup-terraform@v2 # Terraform CLI'ı kurar
        with:
          terraform_version: 1.5.0 # İstediğiniz Terraform sürümü

      - name: 'AWS Kimlik Bilgilerini Yapılandır'
        uses: aws-actions/configure-aws-credentials@v2 # AWS kimlik bilgilerini ayarlar
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1 # Kullanacağınız AWS bölgesi

      - name: 'Terraform Başlat'
        id: init
        run: terraform init # Terraform backend'ini başlatır

      - name: 'Terraform Plan Oluştur'
        id: plan
        run: terraform plan -no-color -input=false -out=tfplan.out
        # -no-color: çıktının renkli olmamasını sağlar
        # -input=false: interaktif girişleri kapatır
        # -out=tfplan.out: plan çıktısını bir dosyaya kaydeder

      - name: 'Terraform Planı Yorumlarda Göster'
        if: github.event_name == 'pull_request' # Sadece pull requestler için çalışır
        uses: actions/github-script@v6
        with:
          script: |
            const output = ## Terraform Plan 
            \\\
            ${process.env.TF_PLAN_OUTPUT}
            \\\;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })
          env:
            TF_PLAN_OUTPUT: ${{ steps.plan.outputs.stdout }} # Plan çıktısını yorum olarak ekler

      - name: 'Terraform Uygula'
        # Sadece main branch'e yapılan push'larda otomatik olarak uygular
        if: github.ref == 'refs/heads/main' && github.event_name == 'push' 
        run: terraform apply -auto-approve tfplan.out
    

Bu iş akışı, her push veya pull_request olayında Terraform planını çalıştıracak ve pull_request durumunda plan çıktısını doğrudan GitHub yorumlarına ekleyecektir. Bu sayede, ekip üyeleri birleştirme yapmadan önce yapılacak değişiklikleri kolayca gözden geçirebilir. main branch'e birleştirme (merge) işlemi sonrası yapılan push'larda ise, Terraform otomatik olarak apply komutunu çalıştırarak altyapı değişikliklerini AWS'e uygulayacaktır. Bu sayede, altyapı dağıtım süreçleriniz tam anlamıyla otomatikleşir, hata payı azalır ve ekip verimliliği artar.

Pratik Bir Senaryo: Web Uygulaması Altyapısını Otomatikleştirmek

Teorik bilgileri pekiştirmek ve konuyu daha anlaşılır kılmak adına, gerçek dünya tabanlı bir senaryoyu ele alalım. Diyelim ki basit bir blog veya statik bir web sitesi için AWS üzerinde temel bir altyapı kurmak istiyoruz. Bu altyapı, bir sanal sunucu (EC2), bir güvenlik grubu, statik web sitesi barındırma için bir S3 kovası ve bir DNS kaydından (Route 53) oluşacak. Tüm bu bileşenleri Terraform ile tanımlayacak ve GitHub Actions aracılığıyla otomatik olarak dağıtacağız.

Adım 1: Terraform Proje Yapısı

Proje dizinimizde aşağıdaki dosyaları oluşturalım:

• main.tf: Ana altyapı kaynak tanımlamaları.
• variables.tf: Değişken tanımlamaları.
• outputs.tf: Dağıtım sonrası çıktıların gösterimi.

main.tf (Ana Kaynak Tanımlamaları)

Bu dosya, EC2 örneği, güvenlik grubu, S3 kovası ve isteğe bağlı olarak Route 53 DNS kaydını içerecektir.

# AWS Sağlayıcısını Tanımlama
provider "aws" {
  region = var.aws_region
}

# Terraform State Yönetimi için S3 Backend
terraform {
  backend "s3" {
    bucket         = "my-web-app-terraform-state-bucket-12345" # Benzersiz olmalı
    key            = "prod/webapp-infrastructure.tfstate"
    region         = "us-east-1" # Backend S3 kovasının bulunduğu bölge
    encrypt        = true
    dynamodb_table = "webapp-terraform-state-lock"
  }
}

# Web Sunucusu (EC2 Instance)
resource "aws_instance" "web_server" {
  ami           = var.ami_id
  instance_type = var.instance_type
  key_name      = var.key_pair_name
  vpc_security_group_ids = [aws_security_group.web_sg.id]

  tags = {
    Name        = "WebAppWebServer"
    Environment = "Production"
  }
}

# Güvenlik Grubu (Security Group)
resource "aws_security_group" "web_sg" {
  name        = "webapp_security_group"
  description = "Allow HTTP, HTTPS and SSH inbound traffic"
  vpc_id      = var.vpc_id # Mevcut bir VPC ID'si

  ingress {
    description = "HTTP from anywhere"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH from your IP"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["${var.my_ip}/32"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Statik Web Sitesi için S3 Kovası
resource "aws_s3_bucket" "website_bucket" {
  bucket = var.s3_website_bucket_name # Benzersiz ve düşük harfli olmalı
  acl    = "public-read"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "PublicReadGetObject"
        Effect    = "Allow"
        Principal = "*"
        Action    = ["s3:GetObject"]
        Resource  = ["arn:aws:s3:::${var.s3_website_bucket_name}/*"]
      },
    ]
  })

  website {
    index_document = "index.html"
    error_document = "error.html"
  }

  tags = {
    Name        = "WebAppWebsiteBucket"
    Environment = "Production"
  }
}

# S3 kovasını bir Terraform state kovası olarak da kullanacağız
# Bu yüzden yukarıdaki backend blogu için de bir bucket tanımlaması yapmalıyız
resource "aws_s3_bucket" "terraform_state_for_backend" {
  bucket = "my-web-app-terraform-state-bucket-12345" # Backend'de kullanılanla aynı isim
  acl    = "private"
  versioning {
    enabled = true
  }
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

resource "aws_dynamodb_table" "terraform_state_lock_for_backend" {
  name           = "webapp-terraform-state-lock" # Backend'de kullanılanla aynı isim
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "LockID"
  attribute {
    name = "LockID"
    type = "S"
  }
}

# Route 53 DNS Kaydı (İsteğe bağlı, mevcut bir Hosted Zone gerektirir)
# data "aws_route53_zone" "selected" {
#   name         = var.domain_name
#   private_zone = false
# }

# resource "aws_route53_record" "www" {
#   zone_id = data.aws_route53_zone.selected.zone_id
#   name    = "www.${var.domain_name}"
#   type    = "A"

#   alias {
#     name                   = aws_s3_bucket.website_bucket.website_domain
#     zone_id                = aws_s3_bucket.website_bucket.hosted_zone_id
#     evaluate_target_health = true
#   }
# }
    

variables.tf (Değişken Tanımlamaları)

variable "aws_region" {
  description = "AWS bölgesi"
  type        = string
  default     = "us-east-1"
}

variable "ami_id" {
  description = "EC2 instance için Amazon Machine Image ID"
  type        = string
  default     = "ami-0abcdef1234567890" # Lütfen kendi bölgeniz için geçerli bir AMI ID kullanın
}

variable "instance_type" {
  description = "EC2 instance tipi"
  type        = string
  default     = "t2.micro"
}

variable "key_pair_name" {
  description = "EC2'ye SSH erişimi için kullanılan anahtar çifti adı"
  type        = string
  default     = "my-ec2-keypair" # Mevcut bir anahtar çifti adı olmalı
}

variable "vpc_id" {
  description = "EC2 instance'ının başlatılacağı VPC ID'si"
  type        = string
  default     = "vpc-0abcdef1234567890" # Mevcut bir VPC ID'si olmalı
}

variable "my_ip" {
  description = "SSH erişimine izin verilecek IP adresi"
  type        = string
  default     = "0.0.0.0" # Kendi genel IP adresinizi kullanın (örn: "XXX.XXX.XXX.XXX")
}

variable "s3_website_bucket_name" {
  description = "Statik web sitesi için S3 kovası adı"
  type        = string
  default     = "my-unique-webapp-static-site-12345" # Benzersiz olmalı
}

# variable "domain_name" {
#   description = "Route 53 Hosted Zone için domain adı"
#   type        = string
#   default     = "example.com" # Kendi domain adınızı kullanın
# }
    

outputs.tf (Çıktı Tanımlamaları)

output "web_server_public_ip" {
  description = "Web sunucusunun genel IP adresi"
  value       = aws_instance.web_server.public_ip
}

output "s3_website_endpoint" {
  description = "Statik web sitesi S3 kovasının endpoint adresi"
  value       = aws_s3_bucket.website_bucket.website_endpoint
}
    

Adım 2: GitHub Actions Entegrasyonu

Yukarıdaki Terraform kodunu GitHub deponuza ekleyin. Ardından, daha önce gösterilen GitHub Actions YAML dosyasını (.github/workflows/main.yml) deponuza ekleyin. AWS kimlik bilgilerini GitHub Secrets olarak ayarladığınızdan emin olun. Bu senaryoda kullanılan terraform init, plan ve apply adımları, Terraform kodunuzu otomatik olarak AWS'e dağıtacaktır.

Vaka Analizi: Küçük Bir E-Ticaret Sitesi

Bir e-ticaret startup'ı düşünelim. Yeni bir ürün lansmanı öncesinde, geliştirme, test ve üretim ortamlarını hızla kurmaları gerekiyor. Manuel olarak her ortamı tek tek yapılandırmak, haftalar sürebilir, tutarsızlıklara yol açabilir ve lansman gecikmelerine neden olabilir. Bu startup, yukarıdaki gibi Terraform ve GitHub Actions entegrasyonunu kullanarak altyapı dağıtımını otomatikleştirmeye karar verdi. Sonuçlar inanılmazdı:

• Hız: Her yeni ortam, dakikalar içinde tam olarak yapılandırılmış ve kullanıma hazır hale geldi.
• Tutarlılık: Kod tabanlı altyapı sayesinde, geliştirme ortamındaki sorunlar üretimde tekrarlanmadı çünkü tüm ortamlar aynı koddan türetildi.
• Güvenilirlik: Otomatikleştirilmiş dağıtım süreçleri, insan hatasını ortadan kaldırdı ve başarılı dağıtım oranını önemli ölçüde artırdı.
• Maliyet Etkinliği: Kullanılmayan test ortamları, belirli bir süre sonra otomatik olarak kapatıldı veya yok edildi, bu da AWS faturalarında büyük tasarruf sağladı.

Bu vaka analizi, IaC'nin ve CI/CD'nin sadece büyük şirketler için değil, aynı zamanda çevik ve hızlı hareket etmesi gereken küçük ekipler ve startup'lar için de ne kadar değerli olduğunu açıkça göstermektedir. Altyapıyı kod olarak yönetmek ve dağıtımı otomatikleştirmek, modern yazılım geliştirmenin temel taşıdır.

Gelişmiş Stratejiler ve En İyi Uygulamalar

Terraform, AWS S3 ve GitHub Actions ile temel altyapı otomasyonunu kurduktan sonra, projelerinizi daha da ölçeklenebilir, güvenli ve yönetilebilir hale getirmek için bazı gelişmiş stratejileri ve en iyi uygulamaları değerlendirebilirsiniz.

1. Modülerizasyon ve Yeniden Kullanılabilirlik:

Büyük projelerde, tüm altyapıyı tek bir main.tf dosyasında tutmak hızla karmaşık hale gelebilir. Terraform modülleri, kodunuzu mantıksal, yeniden kullanılabilir birimlere ayırmanıza olanak tanır. Örneğin, bir EC2 web sunucusu kurulumu, bir VPC veya bir veritabanı kümesi için ayrı modüller oluşturabilirsiniz. Bu modülleri, farklı ortamlarda (dev, staging, prod) veya farklı projelerde tekrar tekrar kullanabilirsiniz. Modüller, kod tekrarını (DRY - Don't Repeat Yourself) azaltır ve altyapı yönetiminizi daha düzenli hale getirir.

# main.tf dosyasında bir modülü çağırma örneği
module "web_app_servers" {
  source = "./modules/web-server" # Yerel bir modül yolu
  
  instance_type = "t3.medium"
  ami_id        = var.ami_id
  vpc_id        = var.vpc_id
  # ... diğer değişkenler
}
    

2. Ortamlar Arası Yönetim (Dev, Staging, Prod):

Gerçek dünya uygulamalarında, geliştirme, test (staging) ve üretim (production) gibi farklı ortamlar bulunur. Bu ortamların her biri için ayrı Terraform state dosyaları ve ayrı Terraform yapılandırmaları tutmak genellikle en iyi yaklaşımdır. Her ortam için ayrı bir klasör yapısı kullanabilir ve her klasörde kendi main.tf, variables.tf ve backend.tf dosyalarını bulundurabilirsiniz. GitHub Actions iş akışlarınızda, farklı branch'lere (örneğin dev, staging, main) yapılan push'lar için farklı ortamların dağıtımını tetikleyebilirsiniz.

3. Güvenlik Entegrasyonu ve En Az Yetki Prensibi (Least Privilege):

• IAM Rolleri: GitHub Actions'ın AWS kaynaklarınıza erişmesi için kullanılan IAM kullanıcısı yerine, AWS OIDC (OpenID Connect) ile GitHub Actions'a bir IAM rolü atamak daha güvenli bir yöntemdir. Bu sayede, uzun ömürlü kimlik bilgilerine ihtiyaç duyulmaz.
• KMS ile Şifreleme: AWS S3'teki Terraform state dosyanızı şifrelemek için KMS (Key Management Service) kullanmak, hassas verilerinizi daha da güvende tutar. S3 bucket yapılandırmanıza bir KMS anahtarı ekleyerek bunu sağlayabilirsiniz.
• Secret Yönetimi: Veritabanı şifreleri, API anahtarları gibi hassas bilgileri asla Terraform kodunuzda veya state dosyasında açık metin olarak saklamayın. Bunları AWS Secrets Manager veya HashiCorp Vault gibi özel gizli yönetim çözümleriyle entegre edin ve Terraform'un bu araçlardan dinamik olarak çekmesini sağlayın.

4. Terraform Kodu İnceleme ve Kalite Kontrolü:

Terraform kodunuzu Git deponuza göndermeden önce terraform fmt ile biçimlendirin ve terraform validate ile sözdizimi hatalarını kontrol edin. Ayrıca, kod incelemeleri (pull request review) sırasında, diğer ekip üyelerinin Terraform plan çıktılarını incelemesini sağlayarak istenmeyen değişikliklerin önüne geçebilirsiniz.

5. Geri Alma (Rollback) Stratejileri:

Her ne kadar otomasyon hata riskini azaltsa da, üretimde beklenmedik sorunlar ortaya çıkabilir. Bu durumlarda, hızlı ve güvenli bir şekilde önceki bir duruma geri dönebilmek kritik öneme sahiptir. S3 bucket'ınızda etkinleştirilen versiyonlama, state dosyanızın geçmişini tutar. Yanlış giden bir dağıtım durumunda, Terraform'u önceki bir state dosyası sürümünü kullanarak yeniden çalıştırmak bir geri alma stratejisi olabilir.

6. Maliyet Yönetimi ve Etiketleme (Tagging):

Bulut kaynakları maliyetli olabilir. Terraform ile oluşturduğunuz tüm kaynaklara tutarlı bir etiketleme stratejisi uygulayın. Örneğin, her kaynağa Environment (Dev, Prod), Project, Owner gibi etiketler ekleyin. Bu etiketler, AWS Maliyet Yönetimi araçlarında maliyetleri izlemenize, raporlamanıza ve optimize etmenize yardımcı olacaktır.

Bu gelişmiş stratejiler ve en iyi uygulamalar, altyapı otomasyon yolculuğunuzda karşılaşabileceğiniz zorlukları aşmanıza ve daha dayanıklı, güvenli ve verimli bir sistem kurmanıza yardımcı olacaktır. Sürekli öğrenme ve mevcut araçları derinlemesine anlama, bu alandaki başarının anahtarıdır.

Sonuç: Altyapı Otomasyonu ile Geleceğe Yönelik Bir Adım

Bu makale boyunca, modern bulut altyapısı yönetiminin temel taşlarından olan Altyapı Kod Olarak (IaC) felsefesini, özellikle de Terraform'un gücünü, AWS S3 Remote Backend ile state yönetiminin önemini ve GitHub Actions ile entegre CI/CD süreçlerinin nasıl kurulduğunu detaylı bir şekilde inceledik. Gördük ki, manuel süreçlerin getirdiği riskler ve verimsizlikler, otomasyon araçları sayesinde kolayca aşılabilir ve geliştirme ekiplerine önemli avantajlar sağlanabilir.

Özellikle, Terraform'un deklaratif yapısı, altyapımızı kod olarak tanımlamamıza ve versiyon kontrol altında tutmamıza olanak tanırken, AWS S3'ün sağladığı uzaktan state yönetimi, takım çalışmasını kolaylaştırmış, state dosyasının güvenliğini artırmış ve versiyonlama özellikleriyle geri alma senaryolarında bize büyük esneklik sunmuştur. DynamoDB ile entegrasyonu sayesinde state kilitleme mekanizması, birden fazla kullanıcının aynı anda değişiklik yapmasını engelleyerek state dosyasının bozulmasının önüne geçmiştir. Tüm bu altyapı tanımlamalarını ve yönetimini GitHub Actions ile birleştirmek ise, kod değişikliklerinin otomatik olarak algılanıp, planlanıp ve güvenli bir şekilde uygulanmasını sağlayarak, geliştiricilerin altyapı dağıtım süreçlerine daha az zaman ayırıp asıl işlerine odaklanmalarına imkan tanımıştır.

Altyapı otomasyonu, sadece dağıtım hızını artırmakla kalmaz; aynı zamanda tutarlılığı, güvenilirliği ve ölçeklenebilirliği de beraberinde getirir. Bir web uygulaması altyapısı örneğinde gösterildiği gibi, karmaşık bulut kaynaklarını bile kod ile yönetmek, operasyonel yükü önemli ölçüde azaltır ve ekiplerin yeniliğe daha fazla odaklanmasını sağlar. Gelişmiş stratejiler ve en iyi uygulamalar bölümünde ele aldığımız modülerizasyon, güvenlik entegrasyonları ve maliyet yönetimi gibi konular ise, otomasyon yolculuğunuzda karşılaşabileceğiniz zorluklara karşı size rehberlik edecek, daha sağlam ve sürdürülebilir sistemler kurmanıza yardımcı olacaktır.

Sonuç olarak, Terraform, AWS S3 Remote Backend ve GitHub Actions üçlüsü, modern DevOps pratiklerinin merkezinde yer alan güçlü bir kombinasyondur. Bu araçları etkin bir şekilde kullanarak, şirketler altyapılarını daha çevik, hatasız ve maliyet etkin bir şekilde yönetebilirler. Unutmayın, bu alandaki teknoloji sürekli gelişiyor; bu nedenle sürekli öğrenmeye ve yeni araçları keşfetmeye açık olmak, sizi her zaman bir adım önde tutacaktır. Altyapı otomasyonu, sadece bir teknolojik geçiş değil, aynı zamanda operasyonel mükemmelliğe ve iş çevikliğine ulaşmanın anahtarıdır. Şimdiden bu araçları denemeye başlayarak geleceğin altyapı yönetimine yönelik sağlam bir adım atabilirsiniz.

Sıkça Sorulan Sorular

• Soru 1: Terraform state dosyası neden bu kadar hassastır ve güvenliği neden önemlidir?
  Cevap: Terraform state dosyası, yönettiği tüm altyapı kaynaklarının gerçek zamanlı durumunu (ID'ler, konfigürasyonlar, ilişkiler) ve hatta bazı durumlarda hassas bilgileri (veritabanı şifreleri, API anahtarları) içerebilir. Bu dosyanın yetkisiz kişilerce ele geçirilmesi ciddi güvenlik ihlallerine yol açabilir. Ayrıca, dosyanın bozulması veya kaybolması, Terraform'un altyapınızla olan bağlantısını kaybetmesine ve altyapı yönetiminin felç olmasına neden olabilir. Bu yüzden güvenli, şifrelenmiş ve versiyonlanabilir bir yerde saklanması hayati önem taşır.
• Soru 2: GitHub Actions yerine başka CI/CD araçları kullanarak Terraform dağıtımı yapabilir miyim?
  Cevap: Kesinlikle! GitHub Actions, GitHub ile derin entegrasyonu nedeniyle popüler bir seçenektir, ancak Jenkins, GitLab CI/CD, CircleCI, Travis CI, Bitbucket Pipelines veya AWS CodePipeline gibi birçok güçlü alternatif bulunmaktadır. Terraform'un platformdan bağımsız yapısı sayesinde, çoğu CI/CD aracıyla kolayca entegre edilebilir ve otomatik altyapı dağıtımı için kullanılabilir. Seçim genellikle mevcut ekosisteminiz ve tercih ettiğiniz özellik setine bağlıdır.
• Soru 3: AWS S3'te Terraform state dosyalarını şifrelemek için KMS kullanmak zorunlu mu?
  Cevap: Hayır, zorunlu değildir ancak şiddetle tavsiye edilir. S3 bucket'ınızda versiyonlamayı etkinleştirdiğinizde, varsayılan olarak AES256 sunucu tarafı şifrelemesi (SSE-S3) ile şifrelenir. Ancak, AWS KMS (Key Management Service) ile şifreleme (SSE-KMS) kullanmak, şifreleme anahtarlarınız üzerinde daha fazla kontrol, denetim ve merkezi yönetim imkanı sunar. Bu, özellikle yüksek güvenlik gerektiren ortamlar ve uyumluluk standartları için tercih edilen bir yöntemdir.
• Soru 4: Terraform modülleri ne işe yarar ve ne zaman kullanmalıyım?
  Cevap: Terraform modülleri, altyapı kodunuzu tekrar kullanılabilir, organize edilmiş ve parametreleştirilebilir birimlere ayırmanıza olanak tanır. Bir modül, bir veya daha fazla kaynak tanımını kapsayan bir klasörden ibarettir. Modülleri kullanmanın temel faydaları şunlardır: kod tekrarını azaltma (DRY prensibi), karmaşıklığı yönetme, ekipler arasında tutarlılığı artırma ve test edilebilirliği geliştirme. Altyapınız büyüdükçe, farklı ortamlar için benzer yapılandırmaları tekrarlamanız gerektiğinde veya ekip üyeleri arasında standartlaştırılmış altyapı bileşenleri sağlamak istediğinizde modülleri kullanmalısınız.
• Soru 5: Altyapı dağıtımında terraform apply -auto-approve komutunu kullanmak güvenli midir?
  Cevap: terraform apply -auto-approve komutu, plan çıktısını incelemeden ve manuel onay almadan değişiklikleri doğrudan uygular. Geliştirme veya test ortamlarında otomatik dağıtımlar için kullanışlı olabilir. Ancak, üretim ortamlarında bu komutu doğrudan kullanmak dikkatli bir yaklaşım değildir. Genellikle, bir pull request aşamasında terraform plan çıktısını gözden geçirmek ve ardından, değişiklikler onaylandıktan sonra (örneğin main branch'e birleştirildiğinde) manuel veya koşullu bir apply tetiklemek daha güvenli ve kontrollü bir yaklaşımdır. Bu, istenmeyen veya hatalı değişikliklerin üretim ortamına ulaşmasını engellemek için bir güvenlik katmanı sağlar.