Ana içeriğe geç

Terraform AWS Eğitimi: EC2’de Aracı Dağıtımını Otomatikleştirme

Terraform ile AWS altyapısını nasıl otomatikleştireceğinizi öğrenin. SSM ajanlı EC2 örnekleri oluşturun, durumu S3’te yönetin ve modüllerle ölçekleyin.
· 11 dk. oku

Yapay Zeka ile Keşfedin

AWS Konsolu’nda saatlerce tıklayıp durarak EC2 örnekleri başlattığım, güvenlik gruplarını elle ayarladığım ve kaçınılmaz olarak saatler süren hatalar yaptığım çok oldu. Tanıdık geliyor mu? Yanlış kullanılabilirlik alanında örnek oluşturursunuz, bir kaynağa etiket eklemeyi unutursunuz ya da adımları belgelemediğiniz için geçen ay kurduğunuz yapılandırmayı birebir yeniden oluşturmakla bir öğleden sonrayı harcarsınız. 

Altyapıyı manuel sağlamak yalnızca zahmetli değil, aynı zamanda hataya açık, ölçeklenemez ve denetlenmesi imkansızdır. İşte Terraform tam da burada oyunu değiştiriyor. Tüm AWS altyapınızı sürümleyebileceğiniz, gözden geçirebileceğiniz ve otomatik olarak dağıtabileceğiniz metin dosyalarında tanımladığınızı hayal edin. Artık onlarca ekranı tıklamak yok. Artık ekibinizle “benim makinemde çalışıyordu” sohbetleri yok.

Bu eğitimde, gerçek bir örneğe odaklanarak Terraform ile AWS altyapısını nasıl otomatikleştireceğinizi göstereceğim: otomatik olarak yapılandırılan bir SSM (Systems Manager) ajanına sahip bir EC2 örneği sağlama. Sonunda, Kod Olarak Altyapı’nın temellerini anlayacak ve kendi AWS hesabınıza hemen dağıtabileceğiniz çalışan bir koda sahip olacaksınız.

AWS’de yeniyseniz, AWS Kavramları, Python’da AWS Boto’ya Giriş veya AWS Güvenlik ve Maliyet Yönetimi. 

Terraform Nedir?

Terraform, HashiCorp tarafından oluşturulan, HashiCorp Configuration Language (HCL) kullanarak bulut kaynaklarını tanımlamanıza, sağlamanıza ve yönetmenize olanak tanıyan açık kaynaklı bir Kod Olarak Altyapı (IaC) aracıdır. 

Bulut konsollarında tıklamak veya yönergeli bash betikleri yazmak yerine, istediğiniz altyapıyı yapılandırma dosyalarında beyan edersiniz; gerisini Terraform halleder. Buyruksal yaklaşımdan bildirime dayalı altyapıya bu geçiş, bulut kaynaklarını ele alış biçimimizde temel bir değişimi temsil eder. 

AWS EC2 örneği başlatmak için buyurucu vs. bildirime dayalı yaklaşım

AWS EC2 örneği başlatmak için buyurucu vs. bildirime dayalı yaklaşım

Buyurucu yaklaşımlarda adım adım talimatlar yazarsınız: “önce bu güvenlik grubunu oluştur, sonra var olmasını bekle, ardından bu güvenlik grubuyla şu örneği başlat, sonra bu birimi ekle, sonra bu etiketleri oluştur.” Her adımın sıralamasından ve hata yönetiminden siz sorumlusunuz. 

Terraform’un bildirime dayalı yaklaşımıyla yalnızca hedef durumu tanımlarsınız: “Şu özelliklere sahip, şu güvenlik grubuna bağlı, şu etiketlere sahip bir EC2 örneği istiyorum.” Terraform bağımlılıkları analiz eder, doğru sırayı belirler ve planı uygular. Bir şey başarısız olursa, Terraform tam olarak nerede kaldığını bilir.

Peki özellikle AWS için neden Terraform’u seçmelisiniz? 

  1. Öncelikle, topluluk ekosistemi çok büyük; hayal edebileceğiniz neredeyse her AWS hizmeti için modüller, örnekler ve çözümler bulursunuz. 
  2. İkincisi, Terraform sağlayıcıdan bağımsızdır. Bir kez öğrenin; aynı beceriler ve kalıplar AWS, Azure, GCP ve diğer platformlarda çalışır. Satıcı bağımlılığından kaçınırken tutarlı bir iş akışı korursunuz. 
  3. Üçüncüsü, Terraform’un durum yönetim sistemi her kaynağı izler; güncellemeleri ve değişiklikleri öngörülebilir kılar. Terraform ne oluşturduğunuzu bilir ve bunları güvenle değiştirebilir veya silebilir.

Uygulamalı yapılandırmaya dalmadan önce, Terraform’un temelini oluşturan üç kilit kavramı anlamanız gerekir:

  • Kaynaklar, oluşturduğunuz altyapı bileşenleridir—EC2 örnekleri, S3 kovaları, güvenlik grupları. 
  • Sağlayıcılar, Terraform’un farklı platformlarla etkileşime geçmesini sağlayan eklentilerdir; AWS sağlayıcısı HCL’nizi AWS API çağrılarına çevirir. 
  • HCL, altyapıyı tanımlamak için kullanacağınız, hem ifade gücü yüksek hem de basit olacak şekilde tasarlanmış insan tarafından okunabilir sözdizimidir.

Bu temeller netleştiyse, gerçek altyapı oluşturmaya başlamak için ortamınızı hazırlayalım. 

Terraform AWS Ortamınızı Kurma

Herhangi bir Terraform kodu yazmadan önce CLI’ın kurulu ve AWS kimlik bilgilerinin yapılandırılmış olması gerekir. İkisini de adım adım anlatalım.

Terraform’u kurun

Terraform kurulumu işletim sistemine göre değişir:

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

  • Windows’ta, ikili dosyayı hashicorp.com’dan indirip PATH’e ekleyin veya Chocolatey kullanın: choco install terraform. 

  • Linux’ta, uygun paketi indirin veya dağıtımınızın paket yöneticisini kullanın. 

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

AWS Kimlik Bilgilerini Yapılandırın

AWS kimlik bilgilerini yapılandırmak için bir AWS hesabı, bir erişim anahtarı ve IAM’den bir gizli anahtar gerekir. Asla kök hesabınızı kullanmayın. Bunun yerine, programatik erişime ve uygun izinlere (AdministratorAccess) sahip bir IAM kullanıcısı oluşturun. Standart yaklaşım, ~/.aws/credentials konumundaki AWS kimlik bilgileri dosyasını kullanmaktır:

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

Alternatif olarak, ortam değişkenlerini ayarlayın: AWS_ACCESS_KEY_ID ve AWS_SECRET_ACCESS_KEY. Üretim ortamlarında, uzun ömürlü kimlik bilgileri yerine EC2 örneklerine veya CI/CD sistemlerine ekli IAM rollerini kullanın.

Amazon ekosisteminden farklı bir ekosistem kullanmayı düşünüyorsanız ya da sadece “büyük üçlü”nün nasıl karşılaştırıldığına dair iyi bir genel bakış istiyorsanız, şu içeriği okumanızı öneririm: Veri Bilimi ve Yapay Zeka için AWS, Azure ve GCP Hizmet Karşılaştırması.

AWS’de Terraform ile Bir EC2 Ajanı Dağıtma

Temeli attığımıza göre, gerçek bir şey inşa edelim: başlatıldığında SSM ajanını otomatik olarak kuran bir EC2 örneği.

Proje yapısının kurulması

Terraform projeleri net ve yapılandırılmış bir yaklaşımdan fayda sağlar. Üç dosya oluşturun: kaynak tanımları için main.tf, girdiler için variables.tf ve dağıtımdan sonra ihtiyaç duyacağınız değerler için outputs.tf. Bu ayrım kodunuzu düzenli ve sürdürülebilir tutar.

 aws-terraform
├── main.tf
├── output.tf
└── variables.tf

Bunun önemi şurada: Projeler büyüdükçe, her şeyi tek bir dosyada karıştırmak sürdürülemez hâle gelir. Değişkenler, girdileri değiştirerek (geliştirme, hazırlık, üretim) aynı kodu farklı ortamlar arasında yeniden kullanmanıza olanak tanır. Çıkışlar ise örnek kimlikleri veya IP adresleri gibi değerlere, AWS Konsolu’nda elle arama yapmak zorunda kalmadan ulaşmanızı sağlar.

EC2 kaynak yapılandırmasını yazma

Şimdi altyapıyı oluşturalım: önceden kurulmuş SSM ajanına sahip bir EC2 örneği. main.tf dosyasına aşağıdaki yapılandırmayı ekleyin:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  owners = ["amazon"]
}

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
  
  iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
  
  user_data = <<-EOF
              #!/bin/bash
              cd /tmp
              sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
              sudo systemctl enable amazon-ssm-agent
              sudo systemctl start amazon-ssm-agent
              EOF
  
  tags = {
    Name = "TerraformWebServer"
  }
}

resource "aws_iam_instance_profile" "ssm_profile" {
  name = "ec2-ssm-profile"
  role = aws_iam_role.ssm_role.name
}

resource "aws_iam_role" "ssm_role" {
  name = "ec2-ssm-role"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

Terraform EC2 Örneği Yapılandırması

Terraform EC2 Örneği Yapılandırması

data bloğu, AWS’den en güncel Amazon Linux 2 AMI’yi sorgular. Filtreler doğru imaj türünü aldığınızdan emin olur ve owners = ["amazon"] resmi Amazon AMI’lerini kullandığınızı garanti eder. Bu yaklaşım tüm bölgelerde değişiklik yapmadan çalışır—Terraform doğru bölgesel AMI’yi otomatik olarak bulur.

Kritik kısım user_data: örnek ilk kez başlarken çalışan bir kabuk betiği. Bu betik SSM ajanını indirip kurar, ardından otomatik başlaması için etkinleştirir. IAM rolü, SSM’in örneği yönetmesi için gereken izinleri sağlar.

Aynı kalıp herhangi bir ajan için çalışır. Günlükler ve metrikler için CloudWatch mu istiyorsunuz? user_data betiğini CloudWatch ajanını yükleyecek şekilde değiştirmeniz yeterli. İlke aynıdır: neyin kurulmasını istediğinizi tanımlayın, Terraform her örnekte bunun gerçekleşmesini sağlar.

output.tf dosyası için örneğin kimliğini ekleyebilirsiniz. Sonrasında bir sonraki bölümde ele alacağım tüm Terraform komutlarını çalıştırdığınızda, bu değer terminalde görünecektir.

output "instance_id" {
  description = "EC2 instance ID for SSM connection"
  value       = aws_instance.web_server.id
}

Yapılandırmayı başlatma ve uygulama

Yapılandırmayı yazdıktan sonra, Terraform iş akışı üç komuttan oluşur. İlk olarak, aşağıdaki komut AWS sağlayıcı eklentisini indirir ve dizininizi hazırlar:

terraform init

Terraform Başlatma

terraform init

İkinci olarak, terraform plan Terraform’un tam olarak neleri oluşturacağını, değiştireceğini veya sileceğini gösterir. Bu önizleme, gerçek değişiklikler yapmadan önce hataları yakalamanızı sağlar:

terraform plan

Terraform Planı

terraform plan

Çıktıyı dikkatlice inceleyin. Terraform’un oluşturacağı EC2 örneğini, IAM rolünü, örnek profilini ve ilke ekini göreceksiniz.

Son olarak, terraform apply değişiklikleri uygular. Terraform, devam etmeden önce onay ister. Bu komutu çalıştırdıktan sonra yes yazın:

terraform apply

Terraform Uygulama

terraform apply

Her şey yolunda giderse, kaynaklar oluşturulduğunda aşağıdaki mesajı göreceksiniz. 

Terraform Oluşturulan Kaynaklar

Onay: Terraform kaynakları oluşturuldu

Birkaç dakika içinde, SSM yapılandırılmış, SSH anahtarlarına gerek olmadan erişilebilen bir EC2 örneğiniz olacak. Yeni oluşturulan kaynakları görmek için AWS Konsolu’nu kontrol ettiğinizden emin olun.

Terraform Durumunu AWS S3’te Yönetme

Yukarıdaki komutları çalıştırdıktan sonra dizinde terraform.tfstate adlı yeni bir dosya göreceksiniz. Terraform’un durum dosyası, yapılandırmanızı gerçek AWS kaynaklarıyla eşleştirir. İçeriğini anlamak için bu dosyayı inceleyelim.

Durum dosyasını anlama

Durum dosyası, dağıtılmış altyapınızla ilgili tüm ayrıntıları içerir: kaynak kimlikleri, IP adresleri ve bağımlılıklar. Terraform, hangi işlemleri yapacağına karar vermek için bu durumu, yapılandırmanızı ve AWS’nin gerçek durumunu karşılaştırır. Durum dosyasını kaybederseniz, Terraform oluşturduğu her şeyin takibini kaybeder.

Durumu dizüstü bilgisayarınızda tutmak tehlikelidir. Makineniz çökerse durum yok olur. Aynı altyapı üzerinde birden fazla ekip üyesi çalışıyorsa, çakışan yerel durumlar bozulmaya yol açar. Çözüm: uzaktan durum depolama.

S3 ve EFS’ye derinlemesine bakmak için şu içeriğe göz atın: AWS Depolama Eğitimi.

Uzak S3 arka ucu yapılandırma

Terraform’un S3 arka ucu, durumu ekibinizin tamamının erişebileceği, merkezi ve dayanıklı bir konumda saklar. Önce bir S3 kovası oluşturun:

aws s3api create-bucket \
  --bucket datacamp-terraform-state \
  --region eu-central-1 \ 
   --create-bucket-configuration LocationConstraint=eu-central-1

aws s3api put-bucket-versioning \
  --bucket datacamp-terraform-state \
  --versioning-configuration Status=Enabled

Sürümleme kritik önemdedir: kazalardan önceki durum sürümlerine dönerek kurtulmanızı sağlar.

Şimdi, arka uç yapılandırmasını Terraform kodunuza ekleyin:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }

  backend "s3" {
    bucket = "datacamp-terraform-state"
    key    = "terraform.tfstate"
    region = "eu-central-1"
    use_lockfile = true
  }  
}

Yerel durumunuzu S3’e taşımak için yeniden terraform init çalıştırın. Terraform, durum dosyasını taşımadan önce onay isteyecektir.

Terraform S3 Uzak Arka Uç

Terraform S3 uzak arka uç

Komutu çalıştırdıktan sonra, S3 kovası yeni durum dosyasını içermelidir. Bunu AWS konsolundan kontrol edebilirsiniz.

Yerel S3 kilit dosyalarıyla durumu kilitleme

Muhtemelen main.tf dosyasına şu ayarı eklediğimizi fark etmişsinizdir:  use_lockfile = true. Bu ayar, Terraform’un en yeni özelliğini etkinleştirir: yerel S3 durum kilitleme. Önceden kilitleme için ayrı bir DynamoDB tablosuna ihtiyaç vardı.

Terraform durum kilitleme

Terraform durum kilitleme

Bu sadeleştirme, yarış koşullarına karşı aynı korumayı sağlarken altyapı kurulumunuzdan bir AWS hizmetini tamamen çıkarır. Birden fazla mühendis, aynı anda yalnızca bir kişinin değişikliklerinin uygulanacağını bilerek güvenle çalışabilir.

AWS’de Terraform ile Altyapıyı Ölçekleme

Altyapınız büyüdükçe, sabit değerler ve kopyala‑yapıştır kodlar bakım kabusuna dönüşür. Terraform’un değişken sistemi ve modülleri bu sorunu çözer.

Girdi değişkenleriyle yeniden düzenleme

Daha önce variables.tf dosyasını oluşturmuştuk. Şimdi main.tf içinde sabitlenmiş değerleri bu yeni dosyaya, yani değişkenlerimizi içerecek dosyaya taşıyabilirsiniz:

variable "aws_region" {
  description = "AWS region for resources"
  type        = string
  default     = "eu-central-1"
}

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

Şimdi main.tf dosyanızdaki kaynaklarda değişkenlere referans verin:

provider "aws" {
  region = var.aws_region
}

resource "aws_instance" "web_server" {
  instance_type = var.instance_type
  # ... rest of configuration
  
  tags = {
    Environment = var.environment
  }
}

AWS S3 kovalarının benzersiz olduğunu unutmayın; bu nedenle main.tf’deki backend parametresinde bölgede değişken kullanamazsınız.  Burada var.region_aws yerine “eu-central-1” gibi sabit bir bölge tutmalısınız.

Artık değişkenlerimizi tanımladığımıza göre, değişkenlerin farklı olabileceği geliştirme veya üretim gibi farklı ortamlar da tanımlayabilirsiniz. Bu, .tfvars uzantılı yeni dosyalar oluşturarak yapılır.

Örneğin, geliştirme için terraform-dev.tfvars ve üretim için terraform-prod.tfvars oluşturabilirsiniz:

Geliştirme:

aws_region    = "eu-central-1"
instance_type = "t2.micro"

Üretim:

aws_region    = "eu-central-1"
instance_type = "t3.medium"

Ardından, uygun dosyayı belirterek farklı ortamlara dağıtabilirsiniz:

terraform apply -var-file="terraform-dev.tfvars”

Değişkenler, ortama özgü değerler sorununu çözer; peki ya tüm altyapı kalıplarını çoğaltmak? İşte burada modüller vazgeçilmez olur.

Yeniden kullanılabilir kaynak modülleri oluşturma

Modüller, ilgili kaynakları yeniden kullanılabilir bileşenler hâlinde paketler. Modülleri kullanmanın en iyi yolu belirli bir klasör oluşturmaktır. Örneğin, şu şekilde bir dizin yapısı oluşturabilirsiniz:

modules/
  ec2-with-ssm/
    main.tf
    variables.tf
    outputs.tf

Daha önce oluşturduğunuz variables.tf dosyasını (veya yeni bir tane) modül klasörüne taşıyabilirsiniz. Kilit değişiklik main.tf dosyasında gerçekleşir. Modül içindeki dosya kaynaklarımızı içermelidir. Yani AMI’den dosyanın sonuna kadar her şeyi buraya taşıyın:

data "aws_ami" "amazon_linux" {
  most_recent = true
  
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  owners = ["amazon"]
}

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type
  
  iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
  
  user_data = <<-EOF
              #!/bin/bash
              cd /tmp
              sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
              sudo systemctl enable amazon-ssm-agent
              sudo systemctl start amazon-ssm-agent
              EOF
  
  tags = {
    Name = "TerraformWebServer"
  }
}

resource "aws_iam_instance_profile" "ssm_profile" {
  name = "ec2-ssm-profile"
  role = aws_iam_role.ssm_role.name
}

resource "aws_iam_role" "ssm_role" {
  name = "ec2-ssm-role"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

Bu değişikliği yerine koymak için dosyanın geri kalanını korur, ancak belirli modüle referans veren bir modül parametresi eklersiniz.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }

  backend "s3" {
    bucket = "datacamp-terraform-state"
    key    = "terraform.tfstate"
    region = "eu-central-1"
    use_lockfile = true
  }
}

provider "aws" {
  region = var.aws_region
}

module "web_server" {
  source = "./modules/ec2-with-ssm"
  
  instance_type = var.instance_type
}

Şimdi, bu kurulumla init, plan ve apply komutlarını çalıştırırsanız, öncekiyle aynı kaynakları dağıtmış olursunuz. Fark şu ki, modüller benzer yapılandırmalara sahip altyapıyı yeniden kullanılabilir şekilde başlatmanıza olanak tanır. Terraform’u basit projelerin ötesine ölçeklemenin anahtarıdırlar.

Şimdi bir başka önemli konuya geçelim: güvenlik.

AWS’de Terraform için Güvenlik En İyi Uygulamaları

Altyapı kodu, uygulama koduyla aynı güvenlik titizliğini gerektirir. Bu nedenle, Terraform dağıtımlarınızı korumak kritik önemdedir.

Sırlar ve hassas verileri yönetme

Asla sırları Git’e işlemeyin. Asla. Hassas değerler için AWS Secrets Manager kullanın. Bunu Terraform’da şu kaynakla yapabilirsiniz:

resource "aws_secretsmanager_secret" "example" {
  name = "example"
}

Ortama özgü sırlar için TF_VAR_ önekiyle ortam değişkenlerini kullanabilirsiniz. 

Örneğin, variables.tf dosyasında variable "aws_access_key" {} kullanıp, terminalde export TF_VAR_aws_access_key=<access_key_value> ile dışa aktarabilirsiniz. Terraform bunları kodda açığa çıkarmadan değişken değeri olarak otomatik yükler.

Yapılandırma sapmasını yönetme

Bir başka önemli konu da sapmadır. Bu, birinin Terraform’u atlayarak AWS Konsolu veya CLI üzerinden altyapıyı değiştirmesiyle oluşur. Sapmayı tespit etmek için düzenli olarak terraform plan çalıştırın. Plan çıktısı, yapılandırmanızla eşleşmeyen kaynakları gösterir.

Sapma olduğunda iki seçeneğiniz vardır: Elle yapılan değişiklik kasıtlıysa Terraform kodunuzu gerçeğe uydurun veya terraform apply çalıştırıp altyapıyı kodda tanımlanan istenen duruma geri döndürün. Doğru seçim, manuel değişikliğin kasıtlı olup olmadığına bağlıdır.

Kaynakları temizleme

Son olarak, gereksiz maliyetlerden kaçınmak için artık ihtiyaç duymadığımız tüm kaynakları kaldırmak da önemlidir. Kaynakları aşağıdaki komutla temizleyebilirsiniz:

terraform destroy

Yıkım planını dikkatlice inceleyin. Terraform, oluşturduğu her kaynağı silecektir. Üretimde, her şeyi silmek yerine belirli kaynakları kaldırmak için terraform destroy -target kullanmayı düşünün.

Sonuç

Terraform’un temel iş akışını öğrendiniz: altyapıyı kodla tanımlayın, değişiklikleri plan ile önizleyin, apply ile uygulayın ve her şeyi durum yönetimiyle takip edin. Otomatik ajan kurulumu ile EC2 dağıtımını ele aldık, durumu yerel kilitlemeyle S3’e taşıdık, değişkenler ve modüllerle ölçekledik ve sır yönetimiyle altyapıyı güvenceye aldık.

Altyapı koduna uygulama koduyla aynı titizlikle yaklaşın. Sürüm kontrolü kullanın, değişiklikler için kod incelemesi zorunlu kılın ve önce üretim dışı ortamlarda test edin. CI/CD ardışık düzenleri terraform apply’ı otomatikleştirerek altyapı güncellemelerini uygulama dağıtımları kadar sorunsuz hâle getirebilir.

Bir sonraki adımınız: kod gönderdiğinizde Terraform’un otomatik çalışması için GitHub Actions veya GitLab CI’ı keşfedin. Otomasyonla birleşen bu Kod Olarak Altyapı yaklaşımı, ekiplerin bulut kaynaklarını yönetme biçimini dönüştürür; manuel konsol çalışmalarının yerini güvenilir, tekrarlanabilir ve sürüm kontrollü altyapı alır.

Önerim, bu bilginin üzerine koyarak AWS Cloud Practitioner (CLF-C02) beceri yoluna kaydolmanız; bu yol, Amazon’un CLF-C02 sertifikasını almak için bilmeniz gereken her şeyi öğretir.

Terraform AWS SSS

Terraform’u birden fazla AWS ortamını verimli şekilde yönetmek için nasıl kullanabilirim?

Değişkenler ve her ortam için ayrı .tfvars dosyaları kullanın. Bölge, örnek türleri ve etiketler gibi ortama özgü değerlerle terraform.dev.tfvars, terraform.staging.tfvars ve terraform.prod.tfvars oluşturun. Farklı ortamlara, terraform apply -var-file="terraform.prod.tfvars" kullanarak dağıtın. Bu yaklaşım, kodu çoğaltmadan yapılandırmaları ortama göre özelleştirirken tek bir kod tabanını korumanızı sağlar.

AWS’de Terraform yapılandırmalarında hassas verileri güvence altına almanın en iyi uygulamaları nelerdir?

Asla sırları Git’e işlemeyin. Veritabanı parolaları gibi hassas değerleri depolamak için AWS Secrets Manager kullanın, ardından Terraform’da veri kaynaklarıyla bunlara referans verin. Ortama özgü sırlar için TF_VAR_ önekiyle ortam değişkenlerini kullanın—Terraform bunları kodda açığa çıkarmadan otomatik yükler. S3 durum kovası üzerinde şifrelemeyi etkinleştirin ve IAM izinlerini yalnızca gerekli kullanıcılar ve CI/CD sistemleriyle sınırlandırın.

Terraform’un S3 arka ucu hâlâ durum kilitleme için DynamoDB gerektiriyor mu?

Hayır. Arka uç yapılandırmanızda use_lockfile = true ayarını yaparak yerel S3 durum kilitlemeyi kullanabilirsiniz. Terraform, S3’te koşullu yazma işlemleriyle doğrudan bir .tflock dosyası oluşturur; ayrı bir DynamoDB tablosu ihtiyacını ortadan kaldırır. Bu, kurulumu basitleştirir, maliyetleri düşürür ve birden fazla ekip üyesi altyapı üzerinde çalışırken eşzamanlı değişikliklere karşı aynı korumayı sağlar.

Birisi altyapıyı elle değiştirdiğinde yapılandırma sapmasını nasıl ele alırım?

Sapmayı tespit etmek için düzenli olarak terraform plan çalıştırın. Plan çıktısı, AWS Konsolu veya CLI’da yapılan manuel değişiklikler nedeniyle yapılandırmanızla eşleşmeyen kaynakları gösterir. İki seçeneğiniz var: manuel değişiklik kasıtlıysa Terraform kodunuzu buna göre güncelleyin veya terraform apply çalıştırarak altyapıyı kodda tanımlanan istenen duruma geri döndürün. Altyapıyı uygulama kodu gibi ele alın—tüm değişiklikler Terraform üzerinden geçmelidir.

Aynı Terraform kodunu farklı AWS bölgelerine kaynak dağıtmak için kullanabilir miyim?

Kesinlikle! Sağlayıcı bloğunda bölgeleri sabitlemek yerine aws_region değişkenini kullanın. Bölgeler arasında AMI kimlikleri farklı olduğundan sabit AMI kimlikleri yerine veri kaynaklarını (data "aws_ami" gibi) kullanın. Bölgeyi .tfvars dosyalarınızda tanımlayın: bir ortam için aws_region = "us-east-1", diğeri için aws_region = "eu-west-1". Sağlayıcıda şu şekilde referans verin: provider "aws" { region = var.aws_region }. Bu, kodunuzu gerçekten bölgeler arası taşınabilir kılar.

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