Ana içeriğe geç

Terraform Docker: Kapsamlı Bir Rehber

Terraform ve Docker ile tekrarlanabilir konteyner dağıtımları oluşturarak altyapı-kod-olarak yaklaşımında ustalaşın. Sağlayıcı kurulumundan otomatik CI/CD'ye kadar hattı öğrenin.
· 13 dk. oku

Yapay Zeka ile Keşfedin

Geliştirme ve üretim ortamlarında Docker konteynerlerini saatlerce elle yönettim. Uyuşmayan yapılandırmalar, kayan durumlar ve yerel kurulumumun üretimle eşleşip eşleşmediğine dair belirsizlik her dağıtımı problemli hâle getiriyordu. Terraform'un Docker sağlayıcısını keşfettiğimde her şey değişti.

Bu eğitimde, yeniden üretilebilir, sürüm kontrollü bir altyapı oluşturmak için Terraform'u Docker ile nasıl entegre edeceğinizi adım adım göstereceğim. Konteynerleri sağlama, ağlar ve birimleri (volumes) yönetme, kaynak kısıtları uygulama ve ekip genelinde durumu koruma konularını öğreneceksiniz.

İster derleme sunucularını yönetin ister mikro hizmetleri orkestre edin, terminalinizi alın ve Docker altyapısını ele alma biçiminizi birlikte dönüştürelim.

Docker'da yeniyseniz, Introduction to Docker kursumuzla başlamanızı öneririm.

Terraform Docker Entegrasyonu Nedir?

Terraform, bildirimsel bir iş akışıyla kaynak yaşam döngülerini yöneten bir altyapı-kod-olarak aracıdır. Tek tek Docker komutları çalıştırmak yerine, istenen altyapı durumunu yapılandırma dosyalarında tanımlarsınız. Terraform ardından plan-uygula-yık (plan-apply-destroy) yaşam döngüsünü yürütür: gerekli değişiklikleri hesaplar, bir önizleme gösterir ve yalnızca onaydan sonra uygular.

Terraform Docker sağlayıcısı, HashiCorp Configuration Language (HCL) kodu ile Docker API arasında bir çeviri katmanı görevi görür. Yapılandırmada resource “docker_container" yazdığınızda, sağlayıcı bu bildirimi ilgili Docker API çağrılarına dönüştürür. Bu soyutlama, Docker kaynaklarının bulut altyapısı için kullanılan aynı iş akışıyla yönetilebilmesi anlamına gelir.

İşte Terraform'un Docker Compose'dan ayrıştığı nokta.

Compose, YAML dosyalarıyla proje tabanlı bir yaklaşımla konteynerleri yönetir, ancak gerçekte neyin var olduğunu izleyen bir durum dosyası tutmaz. 

Buna karşılık Terraform, oluşturduğu her kaydı terraform.tfstate içinde kaydeder; böylece yapılandırmam ile gerçeklik arasındaki sapmayı tespit edebilir. Biri bir konteyneri elle değiştirirse Terraform bunu fark eder ve tanımlı duruma geri döndürebilir.

Docker Compose vs Terraform Docker

Bu yaklaşım şu senaryolarda parlıyor:

  • Tekrarlanabilir derleme sunucuları için, tutarlılığı garanti ederek tek bir komutla tüm ortamı yok edip yeniden oluşturabilirsiniz. 
  • Test ortamlarında, her test çalıştırması için izole altyapı ayağa kaldırabilirsiniz. 
  • Değiştirilemez dağıtımlarda, konteynerleri yerinde değiştirmek yerine tamamen yenisiyle değiştirirsiniz; bu da dağıtım risklerini azaltır.

Ön Koşullar ve Kurulum

Terraform yapılandırmalarına dalmadan önce, gerekli araçların kurulu ve doğru yapılandırıldığını doğrulayalım.

Sistem gereksinimlerini karşılama

Önce, makinenizde Docker Engine'in çalıştığını doğrulayın. 

  • Linux: docker ps ile kontrol edin

  • macOS veya Windows: Docker Desktop'ın kurulu ve çalışır durumda olduğundan emin olun

Terraform sağlayıcısının Docker daemon'a erişmesi gerekir; bu yüzden Linux'ta /var/run/docker.sock Unix soketine veya Windows'ta adlandırılmış kanala erişim izniniz olduğundan emin olun.

Sonra, Terraform CLI'ı HashiCorp'un resmi sitesinden yükleyin. Terraform kurulumu işletim sistemine göre değişir:

  • Linux: Uygun paketi indirin veya dağıtımınızın paket yöneticisini kullanın. 

  • macOS: Homebrew kullanın. Önce brew tap hashicorp/tap ile HashiCorp tap'ini ekleyin, ardından brew install hashicorp/tap/terraform komutuyla Terraform'u kurun. 

  • Windows: İkili dosyayı hashicorp.com'dan indirip PATH'inize ekleyin ya da Chocolatey kullanın: choco install terraform. 

Kurulumdan sonra terraform version komutunu çalıştırarak doğrulayın. 

Docker ve Terraform'u doğruladıktan sonra sıradaki adım, sürdürülebilirlik için proje dosyalarını düzenlemektir.

Proje yapısını yapılandırma

Terraform projeleri, açık ve düzenli bir yaklaşımdan fayda sağlar. Genellikle Terraform projem için özel bir dizin oluşturur ve sürüm kontrolünü başlatırım:

mkdir terraform-docker-project
cd terraform-docker-project
git init

Altyapı-kod-olarak için sürüm kontrolü kritiktir. Docker altyapısındaki her değişiklik izlenebilir, gözden geçirilebilir ve geri alınabilir olmalıdır. Genelde Terraform'un çalışma dizinini ve durum dosyalarını .gitignore dosyasına ekleyerek sürüm kontrolü dışında tutarım:

.terraform/
*.tfstate
*.tfstate.backup
.terraform.lock.hcl

Son olarak, altyapımı tanımlayacağım boş bir main.tf dosyası oluştururum. Bu dosya sağlayıcı yapılandırmasını ve kaynak tanımlarını barındıracaktır.

Terraform Docker Sağlayıcısı ve Çekirdek Kaynaklar

Proje yapısını kurduğumuza göre, Docker sağlayıcısını yapılandırıp kaynakları tanımlamaya başlayalım.

Docker sağlayıcısını başlatma

Önce, main.tf'ye sağlayıcı yapılandırmasını ekleyerek:

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.0"
    }
  }
}

provider "docker" {
  host = "unix:///var/run/docker.sock"
}

required_providers bloğu, Terraform'un sağlayıcı eklentisini nereden indirmesi gerektiğini belirtir. Sürüm kısıtlamaları (~> 3.0) küçük sürüm güncellemelerine izin verirken kırıcı değişiklikleri engeller. Uzak Docker ana makineleri için host parametresini tcp://192.168.1.100:2376 gibi bir değere değiştirebilirsiniz.

Şimdi proje kök dizininde terraform init çalıştırın. Bu, Docker sağlayıcı eklentisini indirir ve .terraform/providers/ içine kaydeder. Komut, yüklenen tam sürümü çıktılar ve Terraform ekip genelinde tutarlı sağlayıcı sürümleri için bir kilit dosyası oluşturur.

Terraform Init

Konteyner imajlarını yönetme

Sağlayıcıyı başlattıktan sonra sıradaki adım, konteyner imajlarını tanımlamaktır. Konteyner oluşturmadan önce, kullanacakları imajları yönetmeniz gerekir; bu nedenle bir imaj kaynağı tanımlayın:

resource "docker_image" "nginx" {
  name         = "nginx:1.29"
  keep_locally = true
}

Bu kaynağı sağlayıcı bloğunun hemen ardına ekleyin. keep_locally parametresi önemlidir; terraform destroy çalıştırdığımda Terraform'un imajı kaldırmasını engeller. Aynı imajı paylaşan birden fazla konteyner olduğunda veya dağıtımlar arasında önbelleğe alınmış imajları korumak istediğimde kullanışlıdır.

Üretim dağıtımları için, değişmezliği sağlamak üzere imajları SHA256 özetiyle sabitleyin:

resource "docker_image" "nginx" {
 name = "nginx@sha256:b60f25eb5acdd79172de1a289891d9cfe4fc3669daddeeb68619240cbe839d9f"
}

Özet, konteyner kayıt defterinden alınabilir. nginx gibi Docker Hub imajları için resmi Docker web sitesindeki Etiketler (Tags) bölümünde bulabilirsiniz. Özet kullanmak, biri aynı etikete yeni bir imaj itmiş olsa bile her seferinde tam olarak aynı ikili imajın dağıtılmasını garanti eder.

Docker konteynerlerini sağlama

İmajlar tanımlandıktan sonra, onları referans alan konteynerleri oluşturma aşamasına geçelim:

resource "docker_container" "web" {
  name  = "nginx-web"
  image = docker_image.nginx.image_id

  ports {
    internal = 80
    external = 8080
  }

  env = [
    "NGINX_HOST=example.com",
    "NGINX_PORT=80"
  ]
}

İmaj, docker_image.nginx.image_id kullanılarak referanslanır. Bu, örtük bir bağımlılık oluşturur; Terraform, imaj mevcut olmadan konteyneri yaratmaya çalışmaz. ports bloğu, konteynerin 80 numaralı dahili portunu ana makinedeki 8080 portuna eşler; bu, docker run -p 8080:80 ile eşdeğerdir.

Ortam değişkenleri, env listesine string olarak yazılır. Parametrelerden herhangi biri değiştiğinde Terraform konteyneri yeniden oluşturur; böylece çalışan altyapı her zaman yapılandırmayla eşleşir.

Bu noktada terraform plan ile Terraform'un neler oluşturacağını görün, ardından altyapıyı sağlamak için terraform apply çalıştırın. Terraform imajı ve konteyneri oluşturacaktır. Bunu Docker Desktop'ta kaynağı kontrol ederek veya terminalde docker ps çalıştırarak doğrulayabilirsiniz.

Terraform'da Ağ, Depolama ve Kaynak Sınırları

Artık temel bir konteyner çalışıyor ve çekirdek iş akışını anladınız; şimdi altyapıyı üretime hazır özelliklerle genişletelim. Sıradaki bölümler, gerçek dünya dağıtımları için gerekli olan ağ, kalıcı depolama ve kaynak kısıtlarını ekleyerek bu temelin üzerine inşa edilecek

Ağ yönetimi

Konteynerler arasında iletişimi etkinleştirirken izolasyonu korumak için özel ağlar oluşturmak esastır. Konteyner bağlantılarını kontrol etmek için izole ağları şu şekilde oluşturabilirsiniz. Aşağıdaki kaynağı main.tf dosyasına ekleyin:

resource "docker_network" "app_network" {
  name   = "application_net"
  driver = "bridge"
}

Şimdi bu ağı kullanan ikinci bir konteyner ekleyin. Bunu web konteynerinden sonra ekleyin:

resource "docker_container" "api" {
  name  = "api-server"
  image = docker_image.nginx.image_id

  networks_advanced {
    name = docker_network.app_network.name
  }
}

Bu, özel bir köprü ağı (bridge) oluşturur ve api konteynerini ona bağlar. Aynı ağdaki konteynerler, konteyner adlarını ana bilgisayar adı olarak kullanarak iletişim kurabilir; bu, mikro hizmet mimarileri için idealdir. 

Ağ izolasyonunu docker network inspect application_net çalıştırarak ve yalnızca amaçlanan konteynerlerin bağlı olduğunu doğrulayarak test edin. Bu komutu, terraform plan ve terraform apply ile kaynakları oluşturduktan sonra çalıştırdığınızdan emin olun.

Network Creation Verification

Konteynerler arası iletişim için ağ yapılandırmasını tamamladığımıza göre, sıradaki kritik konu veri kalıcılığıdır.

Kalıcı birimleri yapılandırma

Konteyner yeniden başlatmalarından sonra da korunması gereken veriler için birim (volume) kaynakları ekleyin. Bunları konteyner tanımlarından önce ekleyin:

resource "docker_volume" "db_data" {
  name = "postgres_data"
}

Şimdi bu birimi kullanan bir veritabanı konteyneri ekleyin:

resource "docker_container" "database" {
  name  = "postgres"
  image = "postgres:15"

 env = [
    "POSTGRES_PASSWORD=mysecretpassword"
  ]

  volumes {
    volume_name    = docker_volume.db_data.name
    container_path = "/var/lib/postgresql/data"
  }
}

Bunun gibi yönetilen birimler, Docker tarafından oluşturulur ve Docker'ın veri dizininde saklanır. Ana makineden yapılandırma dosyalarını paylaşmak için bind mount kullanarak volume_name yerine host_path belirtin.

volumes {
  host_path      = "/opt/app/config"
  container_path = "/etc/app/config"
  read_only      = true
}

Verilerin konteyner yeniden başlatmalarında da korunmasını sağladıktan sonra, tek bir konteynerin sistem kaynaklarını tekeline almasını engellemek de aynı derecede önemlidir.

Kaynak kısıtları belirleme

Depolamanın ötesinde, her konteynerin ne kadar CPU ve belleği tüketebileceğini kontrol etmek sistem kararlılığı için kritiktir. Aşırı kaynak kullanımını engellemek için kaynak limitleri uygulayın.

Docker bazı kaynak limitlerini yerinde güncellemeye izin verse de, Terraform'un bildirimsel modeli, durumun yapılandırmanızla eşleşmesini sağlamak için çoğunlukla konteynerin değiştirilmesini gerektirir. Bu değiştirme sırasında kesinti olmaması için create_before_destroy yaşam döngüsü kuralını kullanırız. 

Önemli: Değiştirme sürecinde ad çakışmalarını önlemek için sabit name argümanını kaldırmalıyız. Bir seçenek olarak name_prefix argümanını kullanabilirsiniz.

resource "docker_container" "api" {
  name_prefix       = "api-server-"
  image      = docker_image.nginx.image_id
  memory     = 512
  cpu_shares = 1024

  networks_advanced {
    name = docker_network.app_network.name
  }

 lifecycle {
    create_before_destroy = true
  }
}

memory parametresi RAM'i megabayt cinsinden sınırlar. cpu_shares ise farklı çalışır. Bu, CPU çekişmesi olduğunda kullanılan göreli bir ağırlıktır. 1024 paya sahip bir konteyner, 512 paya sahip olandan iki kat fazla CPU süresi alır, ancak yalnızca ana makine yük altındayken. 

Sert CPU limitleri için cpu_set kullanarak konteynerleri belirli CPU çekirdeklerine de sabitleyebilirsiniz:

cpu_set = "0,1"
}

Bu kısıtları docker inspect background-worker --format='{{.HostConfig.Memory}} {{.HostConfig.CpuShares}} komutunu çalıştırıp Memory ve NanoCpus değerlerinin yapılandırmayla eşleştiğini kontrol ederek doğrulayın. 

Burada da yukarıda belirtildiği gibi, kaynakları oluşturmak için önce terraform plan ve terraform apply çalıştırmanız gerekir.

Bu noktada main.tf dosyası; sağlayıcı yapılandırması, bir imaj, bir ağ, bir birim ve çeşitli yapılandırmalara sahip üç konteyner içeriyor. 

Terraform'da Değişkenler, Modüller ve Gizli Bilgiler

Altyapı büyüdükçe, sabitlenmiş değerler esnekliğini yitirir. Bu bölüm, yapılandırmayı değişkenler, modüller ve uygun gizli bilgi yönetimi kullanarak nasıl yeniden kullanılabilir hâle getireceğinizi gösterir.

Girdi değişkenlerini kullanma

Yapılandırmaları esnek kılmanın ilk adımı, ana kodu değiştirmeden kolayca değiştirilebilecek sabit değerleri değişkenlere çıkarmaktır. Aynı dizinde variables.tf adlı yeni bir dosya oluşturarak yapılabilir:

variable "web_port" {
  description = "External port for web container"
  type        = number
  default     = 8080

  validation {
    condition     = var.web_port > 1024 && var.web_port < 65535
    error_message = "Port must be between 1024 and 65535."
  }
}

Şimdi main.tf içindeki web konteynerini bu değişkeni kullanacak şekilde güncelleyin:

resource "docker_container" "web" {
  name  = "nginx-web"
  image = docker_image.nginx.image_id

  ports {
    internal = 80
    external = var.web_port
  }

  env = [
    "NGINX_HOST=example.com",
    "NGINX_PORT=80"
  ]
}

Doğrulama bloğu, ayrıcalıklı portların kullanılmasını engeller. Varsayılan değeri geçersiz kılmak için bir terraform.tfvars dosyası oluşturun:

web_port = 9000

terraform apply çalıştırırken Terraform bu dosyadan değerleri otomatik olarak okur. Alternatif olarak, komut satırından değer geçebilirsiniz: terraform apply -var="web_port=9000".

Yeniden kullanılabilir modüller oluşturma

Değişkenler sabit değerler sorununu çözer; peki tüm kaynaklarıyla birlikte aynı deseni birden çok kez dağıtmanız gerekirse?

İşte modüllerin parladığı yer burası. Bir modülü, tüm bu parçaları tek bir pakette toplayan ve bu karmaşık kurulumu tek bir birim olarak "basmanıza" olanak tanıyan bir plan olarak düşünün.

Önce bir modül dizin yapısı oluşturun:

mkdir -p modules/web-app

Şimdi modules/web-app/variables.tf dosyasını oluşturup aşağıdakileri ekleyin:

variable "environment" {
  description = "Environment name"
  type        = string
}

variable "port" {
  description = "External port"
  type        = number
}

Ardından modules/web-app/main.tf adlı bir ana dosya oluşturup şu kaynağı ekleyin:

resource "docker_container" "app" {
  name  = "app-${var.environment}"
  image = var.image_id

  ports {
    internal = 80
    external = var.port
  }
}

Son olarak, modules/web-app/outputs.tf adlı bir çıktılar dosyası oluşturun; bu, esas olarak terraform apply çalıştırıldıktan sonra terminalde istenen değeri göstermek için kullanılır:

output "container_ip" {
  value       = docker_container.app.network_data[0].ip_address
  description = "IP address of the application container"
}

Modül tanımlarını ekledikten sonra modülleri yüklemek için terraform init, ardından aynı şablondan iki konteyner oluşturmak için terraform apply çalıştırın. Tüm kaynakları Docker Desktop'ta görebilmelisiniz.

Terraform ModulesModüllerle yeniden kullanılabilir altyapı kalıpları oluşturulduktan sonra, yapılandırma yönetiminin bir başka kritik yönü daha var: parola ve API anahtarları gibi hassas bilgileri güvenle ele almak.

Hassas verileri yönetme

Veritabanı parolaları gibi hassas değerler asla sabitlenmemelidir. Bunun yerine variables.tf dosyasını kullanıp sensitive = true ayarını yapabilirsiniz:

variable "db_password" {
  description = "Database root password"
  type        = string
  sensitive   = true
}

Şimdi main.tf içindeki veritabanı konteynerini veritabanı parolasına referans verecek şekilde güncelleyin:

resource "docker_container" "database" {
  name  = "postgres"
  image = "postgres:15"

  env = [
    "POSTGRES_PASSWORD=${var.db_password}"
  ]

  volumes {
    volume_name    = docker_volume.db_data.name
    container_path = "/var/lib/postgresql/data"
  }
}

Parolayı terraform.tfvars içine koyup sabitlemek yerine, bir ortam değişkeni olarak ayarlayın:

export TF_VAR_db_password="your-secure-password"
terraform apply

sensitive = true bayrağı, Terraform'un değeri konsol çıktısında göstermesini engeller. 

Ancak bu değerler terraform.tfstate içinde düz metin olarak saklanır; bu dosyayı güvene almak için şifrelemeli uzak arka uçlar (remote backends) kullanarak koruma sağlayabiliriz. Nasıl yapılacağına bakalım.

Terraform Durum Yönetimi ve CI/CD Entegrasyonu

Bu bölüm, üretim dağıtımları için gerekli olan durum mekaniğini ve otomasyon iş akışlarını kapsar. Ancak otomasyonu uygulamadan önce, Terraform'un altyapınızı durum dosyası aracılığıyla nasıl izlediğini anlamak önemlidir. 

Durum mekaniğini anlama

Durum, Terraform'un altyapıyı yönetebilme yetisinin temelidir. terraform.tfstate dosyası, yapılandırmayı gerçek Docker konteyner kimlikleri ve kaynak öznitelikleriyle eşler. terraform apply çalıştırıldığında Terraform bu durumu yapılandırmayla karşılaştırır ve gereken en az değişikliği hesaplar.

Mevcut durumu terraform show ile inceleyin; bu komut yönetilen her kaynağı gösterir. Ekipler için yerel durum dosyaları sorunlara, çakışmalara ve olası veri kayıplarına yol açar. Çözüm uzak arka uçlardır.

Bulut altyapısı olmadan Docker odaklı iş akışları için Terraform Cloud'un ücretsiz katmanı idealdir. main.tf içindeki terraform bölümüne bir arka uç bloğu ekleyin:

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.0"
    }
  }
  
  backend "remote" {
    organization = "your-org-name"
    
    workspaces {
      name = "docker-infrastructure"
    }
  }
}

Şu adreste ücretsiz bir hesap oluşturun: the Terraform website. Ardından terraform login ile verilen anahtarla kimlik doğrulayın ve terraform init ile durumu taşıyın. Bu, uzak bir çalışma alanında durum kilitleme ve bulut altyapısına gerek olmadan ekip iş birliği sağlar. 

Bununla birlikte, AWS veya GCP gibi Bulut sağlayıcılarında da uzak bir arka uç oluşturmak mümkündür.

Terraform Cloud Remote Backend

İş akışlarını otomatikleştirme

Durum yönetimi yapılandırılıp uzaktan saklandıktan sonra altyapı, ekip iş birliği için hazırdır. Son parça, tutarlı ve gözden geçirilebilir değişiklikler sağlamak üzere CI/CD ardışık düzenleriyle dağıtım sürecini otomatikleştirmektir.

Önce .github/workflows/terraform.yml oluşturun:

name: Terraform Docker Deploy

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        
      - name: Terraform Init
        run: terraform init
        
      - name: Terraform Plan
        if: github.event_name == 'pull_request'
        run: terraform plan
        
      - name: Terraform Apply
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve

Bu iş akışı, her çekme isteğinde terraform plan çalıştırarak, değerlendiricilere hangi altyapı değişikliklerinin gerçekleşeceğini gösterir. Değişiklikler main'e birleştirildiğinde terraform apply otomatik olarak çalışır; böylece her altyapı değişikliği, kod değişiklikleriyle aynı inceleme sürecinden geçer.

Terraform Docker Sorunlarını Giderme

Dikkatli yapılandırmaya rağmen sorunlar ortaya çıkabilir. Yaygın problemleri ve ne zaman alternatifleri düşünmeniz gerektiğini anlamak, daha iyi mimari kararlar almanıza yardımcı olur. 

“Permission denied”

Linux'taki en yaygın hata, Docker soketine bağlanırken alınan "permission denied" hatasıdır. Bu, kullanıcının /var/run/docker.sock'a erişim izni olmadığında gerçekleşir. Kullanıcıyı docker grubuna ekleyerek düzeltin:

sudo usermod -aG docker $USER

Ardından oturumu kapatıp tekrar açın.

WSL2 bağlantı sorunları

Windows ve WSL2'de, soket yolu farklı olduğundan bağlantı sorunları oluşur. Docker Desktop'ta "Expose daemon on tcp://localhost:2375 without TLS" ayarının etkin olduğundan emin olun, ardından main.tf içindeki sağlayıcıyı güncelleyin:

provider "docker" {
  host = "tcp://localhost:2375"
}

Özel kayıt defteri kimlik doğrulama hataları

Özel Docker kayıt defterleri için, sağlayıcı bloğuna kimlik doğrulaması ekleyin; kimlik bilgilerini değişken olarak tanımlayın ve sabitlemeden kaynaklanan sorunları önlemek için ortam değişkenleri aracılığıyla ayarlayın.

hclprovider "docker" {
  host = "unix:///var/run/docker.sock"
  
  registry_auth {
    address  = "registry.mycompany.com"
    username = var.registry_username
    password = var.registry_password
  }
}

Terraform'a Alternatifler

Sorun gidermenin ötesinde, belirli kullanım durumunuz için Terraform'dan daha uygun olabilecek araçları ne zaman tercih etmeniz gerektiğini anlamak da aynı derecede değerlidir.

Terraform vs Kubernetes

Kubernetes çok daha gelişmiş orkestrasyon özellikleri sunar: 

  • Kendini iyileştirme
  • Gelişmiş zamanlama
  • Servis keşfi
  • Yerleşik yük dengeleme

Yüksek kullanılabilirlik gerektiren karmaşık çok düğümlü dağıtımlar için Kubernetes daha iyi bir seçimdir. Terraform, Kubernetes altyapısını sağlayabilirken, Helm veya Kubernetes manifestleri uygulama dağıtımını yönetir.

Terraform vs Ansible

Ansible, konteynerlerin içindeki yapılandırma yönetiminde üstündür. Terraform altyapıyı sağlarken, Ansible yazılım yapılandırması ve paket kurulumunu yönetir. Bu iki araç sıklıkla birlikte çalışır: Terraform Docker konteynerlerini oluşturur, ardından Ansible içlerinde çalışan uygulamaları yapılandırır.

Terraform vs Docker Compose

Basit yerel geliştirme ortamları için Docker Compose en pragmatik seçenektir. Terraform, ortamlar arasında tekrarlanabilir dağıtımlarda ve diğer altyapı bileşenleriyle entegrasyon gerektiğinde öne çıkar.

Hangisini seçeceğinize yardımcı olmak için en önemli farkları bu tabloda özetledim:

Araç

Temel Güçlü Yönler

En İyi Kullanım Durumu

Terraform ile Karşılaştırma

Kubernetes

Gelişmiş orkestrasyon (kendini iyileştirme, gelişmiş zamanlama, yük dengeleme).

Yüksek Kullanılabilirlik gerektiren karmaşık çok düğümlü dağıtımlar.

Tamamlayıcı: Terraform altyapıyı (küme) sağlar, Kubernetes ise uygulama dağıtımını yönetir.

Ansible

Yapılandırma yönetimi, paket kurulumu ve yazılım kurulumu.

Konteynerlerin içindeki yazılım ve yapılandırmanın yönetimi.

Tamamlayıcı: Terraform Docker konteynerlerini oluşturur, Ansible içlerinde çalışan uygulamaları yapılandırır.

Docker Compose

Basit, pragmatik proje tabanlı yönetim.

Basit yerel geliştirme ortamları.

Alternatif: Compose yerel geliştirme için daha kolaydır; ancak Terraform, farklı ortamlar arasında tekrarlanabilir dağıtımlar için daha iyidir.

Docker'ın yerine geçecek bir araç arıyorsanız, en iyi Docker alternatifleri rehberimize göz atın.

Sonuç

Docker'ı Terraform'un yaşam döngüsü yönetimine almak, konteyner dağıtımlarını manuel süreçlerden tekrarlanabilir, sürüm kontrollü altyapıya dönüştürür. Bu eğitimde, sağlayıcı ve tek bir konteynerle başlayıp ardından ağ, depolama, değişkenler, modüller ve otomasyon ekleyerek adım adım eksiksiz bir altyapının nasıl kurulacağını gösterdim.

Temel ayrım, Terraform'un bildirimsel yapılandırmaya dayalı olarak kaynakları sağlama, oluşturma, güncelleme ve yok etme işlemlerini yönetmesidir. Otomatik ölçekleme ve kendini iyileştirmeyle tam orkestrasyon için Kubernetes veya Docker Swarm gibi araçlar gerekir. Terraform bu orkestratörleri sağlayabilir, ancak onların yerine geçmez.

Bir sonraki adım olarak, Docker sağlayıcısı için gelişmiş kaynak seçeneklerini (Swarm için Docker servisleri, gizli yönetimi ve eklenti yapılandırmaları gibi) bulmak üzere resmi Terraform Registry dokümantasyonunu keşfedin.

Konteynerlerle pratik yapmak isterseniz, etkileşimli Docker ve Kubernetes ile Konteynerleştirme ve Sanallaştırma beceri rotamıza kaydolmanızı öneririm.

Terraform Docker SSS

terraform destroy çalıştırırken Terraform'un Docker imajlarını kaldırmasını nasıl engellerim?

docker_image kaynağınızda keep_locally = true parametresini kullanın. Bu, altyapıyı yok ettikten sonra bile imajın yerel önbellekte tutulmasını Terraform'a söyler; bu, birden fazla konteyner aynı imajı paylaştığında veya dağıtımlar arasında önbelleğe alınmış imajları korumak istediğinizde faydalıdır.

Terraform Cloud neden "Cannot connect to Docker daemon" hataları veriyor?

Varsayılan olarak Terraform Cloud, uzaktan yürütme modunda çalışır; bu da komutların Docker'a erişimin olmadığı Terraform Cloud sunucularında çalıştığı anlamına gelir. Çalışma alanınızı yerel yürütme modunu kullanacak şekilde yapılandırmanız gerekir: Settings > General > Execution Mode > Local bölümüne gidin. Bu, durumu uzakta tutarken Terraform komutlarını Docker'a erişilebilen yerel makinenizde çalıştırır.

Veritabanı parolaları gibi hassas değerleri Terraform'da nasıl yönetebilirim?

Değişkenleri sensitive = true ile hassas olarak işaretleyin. Terraform Cloud için hassas değişkenleri çalışma alanı arayüzünde ayarlayın ve "Sensitive" olarak işaretleyin. Yerel yürütme için TF_VAR_ önekiyle ortam değişkenleri kullanın (örn. export TF_VAR_db_password="password"). Değerlerin terraform.tfstate içinde düz metin olarak saklandığını unutmayın; bu nedenle durum dosyanızı her zaman güvene alın.

Konteynerleri yönetmek için Terraform ve Docker Compose arasındaki fark nedir?

Docker Compose, durum dosyaları tutmadan proje tabanlı bir YAML yaklaşımıyla konteynerleri yönetir. Terraform ise her kaydı terraform.tfstate içinde saklayarak yapılandırma ile gerçeklik arasındaki sapmayı tespit edebilir. Terraform, ortamlar arasında tekrarlanabilir dağıtımlarda ve diğer altyapıyla entegrasyonda öne çıkarken; Docker Compose yerel geliştirme için daha basittir. Terraform, açık durum yönetimi ve yaşam döngüsü kontrolü (plan/apply/destroy) sağlar.

Docker konteyneri kaynak sınırlarını hatasız nasıl güncellerim?

Docker CLI yerinde güncellemeleri desteklese de, Terraform Docker sağlayıcısı genellikle durumu tutarlı tutmak için kaynağın değiştirilmesini zorunlu kılar. Bu değiştirme sırasında kesinti yaşamamak için lifecycle { create_before_destroy = true } bloğunu ekleyin. Kritik olarak, kaynak tanımınızdan sabit name argümanını da kaldırmanız (veya name_prefix kullanmanız) gerekir. name = "web-server" gibi sabit bir ad bırakırsanız, yeni konteyner eskisi yok edilmeden önce "name already in use" hatasıyla başlatılamaz.

Benito Martin

Yazar

Benito Martin

Martin Data Solutions’ın Kurucusu ve Serbest Çalışan Veri Bilimci, ML ve AI Mühendisi olarak Regresyon, Sınıflandırma, NLP, LLM, RAG, Sinir Ağları, Topluluk Yöntemleri ve Bilgisayarlı Görü alanlarında geniş bir portföy sunuyorum.

  • Veri temizleme, analitik, modelleme ve AWS ile GCP’de dağıtımı kapsayan uçtan uca birçok ML projesini başarıyla geliştirerek etkili ve ölçeklenebilir çözümler sundum.
  • Çeşitli sektör kullanım senaryoları için Streamlit ve Gradio ile etkileşimli ve ölçeklenebilir web uygulamaları geliştirdim.
  • Veri bilimi ve analitik alanlarında öğrencilere eğitim verdim ve mentorluk yaparak kişiselleştirilmiş öğrenme yaklaşımlarıyla mesleki gelişimlerini destekledim.
  • Kurumsal gereksinimlere uyarlanmış geri getirme destekli üretim (RAG) uygulamaları için kurs içerikleri tasarladım.
  • MLOps, vektör veritabanları ve LLM’ler gibi konuları ele alan, yüksek etki yaratan yapay zeka ve ML teknik blogları yazdım ve önemli etkileşim sağladım.

Üstlendiğim her projede CI/CD, kod linting’i, biçimlendirme, model izleme, deney takibi ve sağlam hata yönetimi gibi yazılım mühendisliği ve DevOps’taki güncel uygulamaları hayata geçiririm. Tam kapsamlı çözümler sunmaya; veri içgörülerini, işletmelerin büyümesine yardımcı olan ve veri bilimi, makine öğrenimi ile yapay zekâdan en iyi şekilde yararlanan pratik stratejilere dönüştürmeye kararlıyım.

Konular

İlgili