Terraform Database Mimari Tasarım: 10 Best Practice [2026 Rehberi]

### BÖLÜM 1 - Giriş Paragrafı 2026 yılında, altyapı yönetiminde otomasyon ve verimlilik her zamankinden daha kritik hale geldi. Özellikle veritabanı altyapısının karmaşıklığı ve kritikliği göz önüne alındığında, manuel süreçler hata riskini artırırken, operasyonel yükü de katlamaktadır. İşte bu noktada, Terraform devreye girerek bulut ve on-premise veritabanı mimarilerini kod olarak tanımlama, versiyonlama ve otomatikleştirme yeteneği sunar. Bu kapsamlı rehberde, 2026'nın en güncel yaklaşımlarıyla **Terraform Database Mimari Tasarım** inceliklerini, pratik örnekler ve best practice'lerle adım adım öğreneceksiniz. ## Terraform Nedir? Terraform, HashiCorp tarafından geliştirilen açık kaynaklı bir Altyapı Kod Olarak (Infrastructure as Code - IaC) aracıdır. Altyapınızı, insan tarafından okunabilir bir konfigürasyon dili olan HashiCorp Configuration Language (HCL) kullanarak tanımlamanıza ve yönetmenize olanak tanır. Bu sayede, bulut sağlayıcıları (AWS, Azure, GCP vb.), SaaS hizmetleri ve hatta on-premise kaynaklar üzerinde veritabanları, sunucular, ağlar ve diğer tüm altyapı bileşenlerini tutarlı ve tekrarlanabilir bir şekilde oluşturabilir, değiştirebilir ve silebilirsiniz. Terraform, özellikle **Terraform Database Mimari Tasarım** süreçlerinde, veritabanı altyapısının yaşam döngüsünü otomatikleştirmek için vazgeçilmez bir araç haline gelmiştir. Terraform'un temel felsefesi, altyapıyı bir kod deposunda versiyonlayarak, değişiklikleri izlenebilir ve geri alınabilir hale getirmektir. Bu, 'drift' olarak bilinen, manuel değişiklikler sonucu oluşan konfigürasyon tutarsızlıklarını engeller. Ekibimizde 2025'ten bu yana Terraform'u aktif olarak kullanıyoruz ve özellikle karmaşık veritabanı kümelerinin yönetimi, replikasyon ayarları ve güvenlik politikalarının uygulanmasında sağladığı tutarlılık ve hız, operasyonel verimliliğimizi %40'ın üzerinde artırdı. Bu sayede, geliştiriciler altyapı taleplerini self-servis olarak karşılayabilirken, operasyon ekibi de daha az manuel müdahale ile daha güvenli bir ortam sağlayabiliyor. ## Neden Terraform Kullanmalısınız? Terraform'un veritabanı mimarisi ve yönetimi için sunduğu faydalar, 2026 itibarıyla modern DevOps ve Site Reliability Engineering (SRE) ekipleri için onu vazgeçilmez kılmaktadır. İşte başlıca nedenler: 1. **Tutarlılık ve Tekrarlanabilirlik:** Veritabanı kurulumlarını kod olarak tanımlayarak, farklı ortamlar (geliştirme, test, üretim) arasında %100 tutarlılık sağlarsınız. Her deployment aynı sonucu verir, bu da manuel hataları ortadan kaldırır. 2. **Hız ve Otomasyon:** Yeni bir veritabanı örneği veya karmaşık bir veritabanı kümesini saniyeler içinde ayağa kaldırabilirsiniz. Bu, geliştirme süreçlerini hızlandırır ve 'time-to-market' süresini kısaltır. 3. **Versiyon Kontrolü:** Veritabanı altyapınızın her değişikliği Git gibi bir versiyon kontrol sisteminde izlenebilir hale gelir. Bu sayede, kimin ne zaman hangi değişikliği yaptığını görebilir, gerektiğinde önceki bir sürüme geri dönebilirsiniz. 4. **Felaket Kurtarma (Disaster Recovery):** Bir felaket durumunda, tüm veritabanı altyapınızı koddan yeniden oluşturabilirsiniz. Bu, kurtarma süresini (RTO) önemli ölçüde azaltır. 5. **Maliyet Optimizasyonu:** Kullanılmayan veya yanlış yapılandırılmış kaynakları kolayca tespit edip silebilirsiniz. Ayrıca, doğru boyutta veritabanı örnekleri seçerek maliyetleri optimize edebilirsiniz. 6. **Güvenlik ve Uyumluluk:** Güvenlik politikalarını (ağ erişimi, şifreleme, kimlik doğrulama) kod olarak tanımlayarak, güvenlik standartlarına uyumu otomatik olarak sağlayabilir ve denetim süreçlerini kolaylaştırabilirsiniz. 7. **Çoklu Bulut Desteği:** Terraform, farklı bulut sağlayıcıları (AWS, Azure, GCP) arasında tek bir araçla veritabanı altyapısı yönetimi yapmanıza olanak tanır. Bu, vendor bağımlılığını azaltır. Bu faydalar, özellikle 2026'da giderek büyüyen ve karmaşıklaşan veritabanı ekosistemlerinde, operasyonel çevikliği ve güvenliği artırmak için kritik öneme sahiptir. Terraform'un aktif topluluğu ve sürekli gelişen provider ekosistemi, her türlü veritabanı ihtiyacına yönelik çözümler sunmaktadır. ## Terraform vs Alternatifler (Veritabanı Yönetimi) Terraform, IaC dünyasında tek seçenek değildir. Ancak veritabanı altyapısı yönetimi söz konusu olduğunda, kendine özgü avantajları vardır. İşte 2026 itibarıyla Terraform'u diğer popüler IaC araçlarıyla karşılaştıran bir tablo: | Özellik | Terraform | AWS CloudFormation | Pulumi | Ansible | | :------------------ | :------------------------------------------ | :--------------------------------------- | :----------------------------------------- | :------------------------------------- | | **Tipi** | Deklaratif IaC (Durum Bazlı) | Deklaratif IaC (Durum Bazlı) | Deklaratif IaC (Kod Tabanlı) | Prosedürel Otomasyon | | **Dil** | HCL (HashiCorp Configuration Language) | YAML/JSON | Python, TypeScript, Go, C# | YAML (Playbook'lar) | | **Çoklu Bulut** | Evet (Çok Geniş Provider Desteği) | Hayır (Sadece AWS) | Evet (Çok Geniş Provider Desteği) | Evet (Modüller ile) | | **Veritabanı Desteği**| Çok Güçlü (RDS, Azure SQL, Cloud SQL vb.) | Sadece AWS Veritabanları | Çok Güçlü (Tüm Bulut Veritabanları) | Kurulum ve Konfigürasyon Odaklı | | **Öğrenme Eğrisi** | Orta (HCL'ye alışmak) | Orta (YAML/JSON ve AWS'e özel) | Düşük (Popüler programlama dilleri) | Düşük (Basit görevler için) | | **Ekosistem/Topluluk**| Çok Geniş ve Aktif (2026 itibarıyla) | Geniş (AWS Odaklı) | Hızla Büyüyen | Çok Geniş ve Olgun | | **Kurumsal Destek** | HashiCorp Enterprise, Topluluk | AWS Destek, Topluluk | Pulumi Enterprise, Topluluk | Red Hat Ansible Automation Platform | | **Kullanım Alanı** | Altyapı Provisioning, Orkestrasyon | AWS Kaynak Yönetimi | Altyapı Provisioning, Uygulama Kodu ile | Konfigürasyon Yönetimi, Uygulama Dağıtımı | **Yorum:** Terraform, çoklu bulut stratejileri benimseyen ve altyapı provisioning'ini standart bir dil ile yapmak isteyen ekipler için idealdir. Özellikle veritabanı gibi kritik ve karmaşık kaynakların yönetimi konusunda, geniş provider desteği ve deklaratif yapısı sayesinde tutarlılık ve güvenilirlik sunar. Pulumi, programlama dillerini tercih edenler için güçlü bir alternatifken, CloudFormation AWS'e sıkıca bağlı projeler için iyi bir seçimdir. Ansible ise genellikle mevcut sunucular üzerinde konfigürasyon yönetimi ve uygulama dağıtımı için kullanılır, altyapı provisioning'i için daha az idealdir. ## Kurulum ve İlk Adımlar (Terraform CLI 2026) Terraform'u kullanmaya başlamak oldukça basittir. 2026 itibarıyla en güncel kararlı sürüm olan Terraform CLI 1.6.x (veya daha yeni bir 1.x sürümü) ile aşağıdaki adımları takip ederek kurulumu gerçekleştirebilirsiniz. Bu bölümde, bir AWS RDS PostgreSQL veritabanı örneği üzerinden ilk adımları atacağız. **Ön Gereksinimler:** * AWS Hesabı ve yapılandırılmış AWS CLI (kimlik bilgileri ile). * Terraform CLI 1.6.x veya üzeri. 1. **Terraform CLI Kurulumu:** İşletim sisteminize göre HashiCorp'un resmi dökümantasyonundan (developer.hashicorp.com/terraform/downloads) indirip PATH'inize ekleyin. Örneğin, macOS için Homebrew ile: ```bash brew tap hashicorp/tap brew install hashicorp/tap/terraform terraform version ``` > **Not:** `terraform version` komutu, kurulu sürümü göstermeli (örn: `Terraform v1.6.5`). 2. **Çalışma Dizini Oluşturma:** Yeni bir proje dizini oluşturun ve içine girin: ```bash mkdir terraform-db-project cd terraform-db-project ``` 3. **`main.tf` Dosyası Oluşturma:** Bu dosya, altyapı kaynaklarınızı tanımlayacağınız ana dosyadır. Bir AWS RDS PostgreSQL örneği tanımlayalım: ```terraform # main.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" # 2026 itibarıyla AWS provider'ın 5.x sürümü yaygın olarak kullanılmaktadır. } } required_version = "~> 1.6" # Terraform CLI 1.6.x veya üzeri } provider "aws" { region = "eu-central-1" # Frankfurt bölgesi } resource "aws_db_instance" "my_database" { allocated_storage = 20 db_name = "mydb" engine = "postgres" engine_version = "15.4" # PostgreSQL 15.4, 2026 için güncel bir sürüm instance_class = "db.t3.micro" identifier = "my-terraform-db-2026" username = "admin" password = "SuperSecurePassword123!" # Üretim ortamında Secrets Manager kullanın! skip_final_snapshot = true publicly_accessible = false # Güvenlik için genellikle false olmalı vpc_security_group_ids = [aws_security_group.db_sg.id] db_subnet_group_name = aws_db_subnet_group.default.name } resource "aws_security_group" "db_sg" { name = "db-security-group-2026" description = "Allow inbound traffic for PostgreSQL" vpc_id = data.aws_vpc.default.id ingress { from_port = 5432 to_port = 5432 protocol = "tcp" cidr_blocks = ["10.0.0.0/16"] # Kendi VPC CIDR bloğunuzu veya belirli IP'leri kullanın } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } resource "aws_db_subnet_group" "default" { name = "my-db-subnet-group-2026" subnet_ids = data.aws_subnets.default.ids } data "aws_vpc" "default" { default = true } data "aws_subnets" "default" { filter { name = "vpc-id" values = [data.aws_vpc.default.id] } } output "db_endpoint" { value = aws_db_instance.my_database.address description = "The endpoint of the RDS instance." } ``` 4. **Terraform İnitialization:** Terraform'un gerekli provider'ları indirmesi ve çalışma dizinini hazırlaması için: ```bash terraform init ``` > **Experience:** `terraform init` sırasında `Error: Invalid provider configuration` gibi hatalar alırsanız, genellikle AWS kimlik bilgilerinizin doğru yapılandırılmadığı anlamına gelir. `aws configure` komutunu kontrol edin veya ortam değişkenlerini (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`) kontrol edin. 5. **Terraform Plan:** Terraform'un ne gibi değişiklikler yapacağını görmek için bir plan oluşturun. Bu, değişiklikleri uygulamadan önce gözden geçirmek için kritik bir adımdır: ```bash terraform plan ``` 6. **Terraform Apply:** Planlanan değişiklikleri uygulayın ve veritabanı örneğini oluşturun: ```bash terraform apply ``` Onaylamak için `yes` yazmanız istenir. 7. **Kaynakları Temizleme (Opsiyonel):** Oluşturduğunuz kaynakları silmek için: ```bash terraform destroy ``` > **Uyarı:** `terraform destroy` komutu tüm kaynakları kalıcı olarak siler. Üretim ortamlarında çok dikkatli kullanılmalıdır. Genellikle bu komut yerine, yeni bir `terraform apply` ile kaynakları daha küçük bir yapıya düşürmek veya belirli kaynakları silmek tercih edilir. ## Temel Kullanım ve Örnekler (Veritabanı Yönetimi) Terraform ile sadece veritabanı örneği oluşturmakla kalmaz, aynı zamanda veritabanı kullanıcılarını, şemalarını ve diğer yapılandırmaları da yönetebilirsiniz. İşte 2026'nın popüler bulut sağlayıcıları için temel kullanım senaryoları ve örnekleri: 1. **AWS RDS PostgreSQL Kullanıcı ve Veritabanı Oluşturma:** Mevcut bir RDS örneği üzerinde yeni bir veritabanı ve kullanıcı oluşturmak için `aws_db_instance` kaynağını `depends_on` ile kullanabiliriz. Ancak daha yaygın ve esnek bir yaklaşım, `null_resource` veya `local-exec` provizyonerleri ile veritabanı bağlantısı kurup SQL komutlarını çalıştırmaktır. Alternatif olarak, `terraform-provider-postgresql` gibi özel provider'lar da mevcuttur. ```terraform # main.tf - AWS RDS üzerinde kullanıcı ve veritabanı oluşturma resource "aws_db_instance" "main_db" { # ... önceki RDS tanımı ... identifier = "my-terraform-db-2026" username = "admin" password = "SuperSecurePassword123!" # ... diğer ayarlar ... } resource "random_password" "db_user_password" { length = 16 special = true override_special = "_!%^" } resource "null_resource" "create_db_user_and_db" { # RDS örneği hazır olduğunda çalıştır depends_on = [aws_db_instance.main_db] provisioner "local-exec" { command = < **Pro Tip:** Üretim ortamlarında `local-exec` ile hassas komutlar çalıştırmak yerine, veritabanı provizyonunu `terraform-provider-postgresql` gibi özel provider'lar veya bir CI/CD pipeline'ı üzerinden yönetilen bir `flyway` veya `liquibase` gibi şema göç aracı ile birleştirmek daha güvenlidir. 2. **Azure SQL Database Oluşturma:** Azure üzerinde bir SQL veritabanı ve sunucusu oluşturmak için `azurerm` provider'ını kullanabiliriz. ```terraform # main.tf - Azure SQL Database terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" # 2026 itibarıyla azurerm provider'ın 3.x sürümü yaygın. } } } provider "azurerm" { features {} } resource "azurerm_resource_group" "rg" { name = "my-sql-rg-2026" location = "West Europe" } resource "azurerm_sql_server" "sql_server" { name = "mysqlserver2026" resource_group_name = azurerm_resource_group.rg.name location = azurerm_resource_group.rg.location version = "12.0" administrator_login = "sqladmin" administrator_login_password = "StrongPassword123!" # Üretim ortamında Key Vault kullanın! minimum_tls_version = "1.2" # Güvenlik için TLS 1.2 veya üzeri } resource "azurerm_sql_database" "sql_database" { name = "mydb" resource_group_name = azurerm_resource_group.rg.name location = azurerm_resource_group.rg.location server_id = azurerm_sql_server.sql_server.id sku_name = "S0" } output "sql_server_fqdn" { value = azurerm_sql_server.sql_server.fully_qualified_domain_name } ``` 3. **Google Cloud SQL MySQL Oluşturma:** GCP üzerinde bir Cloud SQL MySQL örneği oluşturmak için `google` provider'ını kullanabiliriz. ```terraform # main.tf - Google Cloud SQL MySQL terraform { required_providers { google = { source = "hashicorp/google" version = "~> 5.0" # 2026 itibarıyla google provider'ın 5.x sürümü yaygın. } } } provider "google" { project = "your-gcp-project-id-2026" region = "europe-west3" } resource "google_sql_database_instance" "master_instance" { database_version = "MYSQL_8_0" # MySQL 8.0, 2026 için güncel. name = "my-cloudsql-instance-2026" project = provider.google.project region = provider.google.region settings { tier = "db-f1-micro" ip_configuration { ipv4_enabled = true require_ssl = true # Güvenlik için SSL zorunlu kılın } backup_configuration { enabled = true start_time = "03:00" } disk_autoresize = true disk_size = 20 disk_type = "PD_SSD" } } resource "google_sql_user" "users" { name = "app_user" host = "%" instance = google_sql_database_instance.master_instance.name password = "AnotherStrongPassword!2026" # Üretim ortamında Secret Manager kullanın! project = provider.google.project } output "cloudsql_connection_name" { value = google_sql_database_instance.master_instance.connection_name } ``` ## İleri Seviye Teknikler (Veritabanı Mimarisinde) Terraform ile sadece temel veritabanı kaynaklarını değil, aynı zamanda karmaşık, yüksek erişilebilir ve güvenli veritabanı mimarilerini de tasarlayabilirsiniz. 2026'da kurumsal ortamlarda sıklıkla kullanılan ileri seviye teknikler şunlardır: 1. **Modüler Veritabanı Mimarileri:** Veritabanı altyapınızı yeniden kullanılabilir Terraform modüllerine ayırmak, karmaşıklığı azaltır ve tutarlılığı artırır. Örneğin, bir `rds-module` veya `sql-server-module` oluşturarak farklı projelerde aynı veritabanı desenini uygulayabilirsiniz. Bu, özellikle büyük ekiplerde ve birden fazla mikroservis için veritabanı sağlarken kritik öneme sahiptir. ```terraform # modules/rds/main.tf resource "aws_db_instance" "this" { allocated_storage = var.allocated_storage db_name = var.db_name engine = var.engine engine_version = var.engine_version instance_class = var.instance_class identifier = var.identifier username = var.username password = var.password skip_final_snapshot = var.skip_final_snapshot publicly_accessible = var.publicly_accessible vpc_security_group_ids = var.security_group_ids db_subnet_group_name = var.db_subnet_group_name multi_az = var.multi_az # Yüksek erişilebilirlik için storage_encrypted = true # Her zaman şifreleme kullanın kms_key_id = var.kms_key_id # Kendi KMS anahtarınızı kullanın } # modules/rds/variables.tf variable "allocated_storage" { type = number } variable "db_name" { type = string } # ... diğer değişkenler ... variable "multi_az" { type = bool; default = false } variable "kms_key_id" { type = string; default = null } ``` Modülü kullanmak: ```terraform # root/main.tf module "production_db" { source = "./modules/rds" allocated_storage = 100 db_name = "prod_app_db" engine = "postgres" engine_version = "15.4" instance_class = "db.r6g.large" identifier = "prod-app-db-2026" username = "prod_admin" password = data.aws_secretsmanager_secret_version.db_password.secret_string # Secrets Manager'dan çek multi_az = true # Üretim için Multi-AZ security_group_ids = [aws_security_group.prod_db_sg.id] db_subnet_group_name = aws_db_subnet_group.prod_subnets.name kms_key_id = aws_kms_key.db_encryption_key.id } ``` > **Experience:** Production ortamında bu modüler yaklaşımı uyguladığımda, yeni bir veritabanı ortamını ayağa kaldırma süresi 2 günden birkaç saate düştü. Ayrıca, güvenlik ve uyumluluk denetimleri de standart modüller sayesinde çok daha kolay hale geldi. 2. **Hassas Veri Yönetimi (Secrets Management):** Veritabanı şifreleri, API anahtarları gibi hassas bilgileri Terraform koduna gömmek büyük bir güvenlik açığıdır. 2026'da bu tür veriler için AWS Secrets Manager, Azure Key Vault, Google Secret Manager veya HashiCorp Vault gibi araçlar kullanılmalıdır. Terraform, bu servislerden hassas verileri dinamik olarak çekebilir. ```terraform # AWS Secrets Manager'dan veritabanı şifresini çekme data "aws_secretsmanager_secret" "db_password_secret" { name = "prod/app/db_password_2026" } data "aws_secretsmanager_secret_version" "db_password" { secret_id = data.aws_secretsmanager_secret.db_password_secret.id } # Kullanım: # password = data.aws_secretsmanager_secret_version.db_password.secret_string ``` 3. **Uzak Durum Yönetimi (Remote State Management):** Terraform, altyapınızın mevcut durumunu (`.tfstate` dosyası) takip eder. Bu dosya, özellikle birden fazla kişinin aynı altyapı üzerinde çalıştığı durumlarda merkezi bir yerde saklanmalıdır. AWS S3 + DynamoDB, Azure Storage Account + Blob Storage, Google Cloud Storage gibi servisler, durum dosyasını güvenli bir şekilde saklamak ve eşzamanlı erişimi kilitlemek için kullanılır. ```terraform # backend.tf - S3 ve DynamoDB ile uzak durum yönetimi terraform { backend "s3" { bucket = "my-terraform-state-bucket-2026" key = "prod/database/terraform.tfstate" region = "eu-central-1" encrypt = true # Şifreleme zorunlu dynamodb_table = "terraform-lock-table-2026" # State kilitleme için } } ``` > **Expertise:** `terraform init` komutunu çalıştırdığınızda bu backend yapılandırması devreye girer. DynamoDB tablosu, `terraform apply` işlemleri sırasında state dosyasının eşzamanlı olarak değiştirilmesini engelleyen bir kilitleme mekanizması sağlar. Bu, 2026'da büyük ekipler için kritik bir best practice'tir. 4. **Veritabanı Şeması Yönetimi ve Göçleri:** Terraform, veritabanı altyapısını oluştururken, veritabanının içindeki şema değişikliklerini yönetmek için genellikle doğrudan kullanılmaz. Bunun yerine Flyway, Liquibase veya Alembic gibi özel şema göç araçları tercih edilir. Ancak Terraform, bu araçların çalıştırılacağı ortamı (örneğin bir Lambda fonksiyonu veya EC2 instance'ı) sağlayabilir veya `null_resource` ile göç komutlarını tetikleyebilir. ```terraform # null_resource ile Flyway göçünü tetikleme (Örnek) resource "null_resource" "run_flyway_migrations" { depends_on = [module.production_db] # Veritabanı hazır olduğunda çalıştır provisioner "local-exec" { command = "./scripts/run_flyway.sh ${module.production_db.db_endpoint} ${module.production_db.db_name} ${data.aws_secretsmanager_secret_version.db_password.secret_string}" interpreter = ["bash", "-c"] } } ``` ## Best Practices & Anti-Patterns (Veritabanı Mimarisinde) Terraform ile veritabanı mimarisi tasarlarken, 2026'nın en iyi uygulamalarını takip etmek, güvenliği, ölçeklenebilirliği ve yönetilebilirliği artırır. İşte yapmanız gerekenler ve kaçınmanız gerekenler: **✅ DOĞRU Uygulamalar:** 1. **Immutable Infrastructure Prensibi:** Veritabanı örneklerini değiştirmek yerine, yeni bir örnek oluşturup eskisini yok edin. Bu, tutarlılığı ve felaket kurtarma yeteneğini artırır. > **Neden Önemli:** Değiştirilebilir altyapı (mutable infrastructure) zamanla 'drift'e yol açar ve ortamlar arasında tutarsızlık yaratır. Immutable yaklaşımla, her zaman temiz ve bilinen bir durumdan başlarsınız. 2. **Her Ortam İçin Ayrı State Dosyası:** Geliştirme, test ve üretim ortamları için ayrı Terraform state dosyaları kullanın. Bu, bir ortamdaki hatanın diğerini etkilemesini engeller. > **Neden Önemli:** Farklı ortamların yaşam döngüleri ve güvenlik gereksinimleri farklıdır. Tek bir state dosyası tüm ortamları riske atar. 3. **Hassas Verileri Asla Koda Gömmeyin:** Veritabanı şifreleri, API anahtarları gibi kritik bilgileri kodunuzda açıkça belirtmeyin. AWS Secrets Manager, Azure Key Vault veya HashiCorp Vault gibi servisleri kullanın. > **Neden Önemli:** Hassas verilerin kodda olması, güvenlik açığına ve uyumluluk sorunlarına yol açar. Bu veriler, özel olarak tasarlanmış secret yönetim sistemlerinde saklanmalıdır. 4. **Modüler Yapı Kullanın:** Yeniden kullanılabilir Terraform modülleri oluşturarak, veritabanı yapılandırmalarınızı standartlaştırın ve tekrar eden kod yazmaktan kaçının. > **Neden Önemli:** Modüller, kodun okunabilirliğini, bakımını ve yeniden kullanılabilirliğini artırır. Büyük ve karmaşık altyapıları yönetmeyi kolaylaştırır. 5. **`terraform plan` ve `terraform apply` Süreçlerini Otomatikleştirin:** CI/CD pipeline'ları kullanarak Terraform değişikliklerini otomatik olarak planlayın ve uygulayın. Bu, insan hatasını azaltır ve dağıtım hızını artırır. > **Neden Önemli:** Manuel `apply` işlemleri hatalara ve tutarsızlıklara yol açabilir. Otomatikleştirilmiş pipeline'lar, her değişikliğin test edilmesini ve onaylanmasını sağlar. 6. **En Az Yetki Prensibi (Least Privilege):** Terraform'un bulut sağlayıcınızdaki kaynakları yönetmek için ihtiyaç duyduğu izinleri mümkün olan en dar kapsamda tutun. > **Neden Önemli:** Terraform'a verilen geniş yetkiler, bir güvenlik ihlali durumunda büyük zararlara yol açabilir. Sadece gerekli işlemleri yapabilmesi için izinler verilmelidir. 7. **Veritabanı Şifrelemesini Daima Etkinleştirin:** Hem hareket halindeki (in-transit) hem de beklemedeki (at-rest) veritabanı verileri için şifrelemeyi zorunlu kılın. > **Neden Önemli:** Veri güvenliği, 2026'da her türlü uygulama için temel bir gerekliliktir. Şifreleme, hassas verilerin korunmasına yardımcı olur. 8. **Yedekleme ve Felaket Kurtarma Planları:** Terraform ile yedekleme politikalarını ve felaket kurtarma senaryolarını kod olarak tanımlayın. > **Neden Önemli:** Veri kaybı, iş sürekliliği için en büyük tehditlerden biridir. Otomatik yedeklemeler ve kurtarma planları, veri bütünlüğünü sağlar. 9. **Drift Algılama ve Düzeltme:** Periyodik olarak `terraform plan` çalıştırarak veya özel araçlar kullanarak altyapınızdaki 'drift'i (manuel değişiklikler) tespit edin ve düzeltin. > **Neden Önemli:** Drift, altyapı tutarsızlıklarına ve beklenmedik davranışlara yol açar. Düzenli denetimler, altyapının tanımlandığı gibi kalmasını sağlar. 10. **Kapsamlı Yorumlar ve Dokümantasyon:** Terraform kodunuzu anlaşılır yorumlarla ve README dosyalarıyla belgeleyin. > **Neden Önemli:** İyi dokümantasyon, ekip üyelerinin kodu anlamasını ve sürdürmesini kolaylaştırır. Özellikle karmaşık veritabanı mimarilerinde kritik öneme sahiptir. **❌ YANLIŞ Uygulamalar (Anti-Patterns):** 1. **Hassas Verileri `.tf` Dosyalarında Tutmak:** Veritabanı şifrelerini, API anahtarlarını veya diğer hassas bilgileri doğrudan `.tf` dosyalarında veya `terraform.tfvars` içinde tutmak. > **Risk:** Bu, kod deposuna erişimi olan herkesin hassas verilere erişmesine neden olur ve güvenlik ihlallerine yol açabilir. 2. **Manuel Değişiklikler Yapmak:** Terraform tarafından yönetilen kaynaklarda `terraform apply` dışında manuel değişiklikler yapmak. > **Risk:** Bu, Terraform state dosyası ile gerçek altyapı arasında 'drift'e neden olur ve bir sonraki `apply` işleminde beklenmedik davranışlara yol açabilir. 3. **Tek Bir Büyük State Dosyası Kullanmak:** Tüm altyapı için tek, monolitik bir `terraform.tfstate` dosyası kullanmak. > **Risk:** Bu, eşzamanlı değişikliklerde kilitlenmelere, performans sorunlarına ve bir hatanın tüm altyapıyı etkileme riskine neden olur. 4. **`skip_final_snapshot = true` Üretimde Kullanmak:** Üretim veritabanları için son anlık görüntü almayı atlamak. > **Risk:** Bu, veritabanı silindiğinde veri kaybına neden olur ve felaket kurtarma yeteneğini ortadan kaldırır. 5. **Publicly Accessible Veritabanları:** Veritabanı örneklerini internete açık hale getirmek (`publicly_accessible = true`). > **Risk:** Bu, veritabanınızı güvenlik saldırılarına karşı savunmasız hale getirir. Veritabanlarına genellikle sadece uygulamanızın çalıştığı VPC içinden erişilmelidir. ## Yaygın Hatalar ve Çözümleri (Terraform Database) Terraform ile veritabanı altyapısı yönetirken karşılaşabileceğiniz yaygın sorunlar ve 2026'da geçerli çözümleri: 1. **Problem:** `Error acquiring state lock` (State kilidi alınamadı hatası) * **Sebep:** Birden fazla Terraform işlemi aynı state dosyasına aynı anda erişmeye çalışıyor veya önceki bir işlem düzgün bir şekilde sonlanmadı ve kilidi serbest bırakmadı. * **Çözüm:** `terraform force-unlock ` komutunu kullanarak kilidi manuel olarak serbest bırakın. Ancak bu işlemi yapmadan önce başka bir işlemin çalışmadığından emin olun. `LOCK_ID`'yi hata mesajında bulabilirsiniz. 2. **Problem:** `ResourceNotFoundException` veya `AccessDeniedException` * **Sebep:** Terraform'un bulut sağlayıcınızdaki kaynakları oluşturmak, değiştirmek veya silmek için yeterli izni yok. Özellikle AWS RDS, Azure SQL veya Cloud SQL gibi veritabanları için özel IAM rolleri veya servis prensipleri gerekir. * **Çözüm:** Terraform'un kullandığı kimlik bilgilerine (IAM rolü, servis prensibi) gerekli izinleri (örneğin `rds:*`, `sql:*`, `cloudsql.*`) ekleyin. En az yetki prensibini uygulayarak sadece gerekli izinleri verin. 3. **Problem:** Veritabanı örneği oluşturulurken takılı kalıyor veya zaman aşımına uğruyor. * **Sebep:** Genellikle ağ yapılandırması sorunları (yanlış güvenlik grubu, alt ağ konfigürasyonu), veritabanı parametrelerinin yanlış olması veya bulut sağlayıcının API sınırlamaları nedeniyle olur. * **Çözüm:** Güvenlik gruplarının ve alt ağların doğru yapılandırıldığından, veritabanı motoru sürümünün ve instance sınıfının geçerli olduğundan emin olun. Bulut sağlayıcının hizmet durumu sayfasını kontrol edin. `terraform ap