Databricks-AWS Terraform Yapısı: Terragrunt, YAML ve Atlantis
AWS üzerinde çoklu Databricks workspace altyapısını yöneten Terraform mimarisi: Terragrunt modülleri, YAML tabanlı config ve Atlantis GitOps akışı.
Bu yazı, beş bölümlük Databricks on AWS serisinin son parçası olarak, önceki bölümlerde anlatılan workspace, RBAC ve compute yapılarının arkasındaki Terraform mimarisini ele alıyor. Repo, yeniden kullanılabilir Terraform modülleri ile ortam bazlı (dev/prd) dizin ağaçlarına ayrılmış; modüller ortamdan bağımsız çalışırken hangi modülün hangi değerlerle çalışacağına ortam ağacı karar veriyor. En kritik tasarım kararı ise insanların doğrudan HCL değil YAML düzenlemesi: Terragrunt, YAML'ı okuyup ortam öneki ekleyerek modül girdilerine dönüştürüyor, böylece dev/prd karışması insan hatasından çıkarılıyor.
Databricks'in her workspace'in ayrı bir API host'u olması nedeniyle, Terragrunt her workspace katmanı için otomatik provider override dosyası üretiyor; hesap düzeyi kaynaklar için mws provider'ı, workspace içi kaynaklar için workspace-scoped provider kullanılıyor ve bu ikisinin karıştırılması tipik bir kimlik doğrulama hatası kaynağı olarak vurgulanıyor.
Yazı ayrıca önemli bir Terragrunt tuzağına dikkat çekiyor: dependency blokları mock_outputs ile plan aşamasını kolaylaştırsa da, mock_outputs_allowed_terraform_commands listesine "init" eklenmediğinde ilk kurulumda gerçek state olmadığı için plan hata veriyor. Bu yüzden ilk apply sırası (workspace → pool → policy → compute → assignment → acl ve Unity Catalog zinciri) kesinlikle takip edilmesi gereken bir kural olarak sunuluyor. Son olarak, tüm değişikliklerin Atlantis üzerinden merge request akışıyla plan/apply edildiği, insanların doğrudan terraform apply çalıştırmadığı GitOps modeli anlatılıyor — mühendisler için bu, review edilebilirlik ve tekrarlanabilirlik açısından önemli bir pratik.