Lewati ke konten utama

Tutorial Terraform AWS: Mengotomatiskan Penerapan Agen di EC2

Pelajari cara mengotomatiskan infrastruktur AWS dengan Terraform. Bangun instance EC2 dengan agen SSM, kelola state di S3, dan lakukan skala menggunakan modul.
· 11 mnt Baca

Jelajahi bersama AI

Saya telah menghabiskan banyak waktu mengklik di AWS Console, meluncurkan instance EC2 secara manual, mengonfigurasi security group, dan pada akhirnya membuat kesalahan yang butuh berjam-jam untuk dilacak. Kedengarannya familier? Anda membuat instance di availability zone yang salah, lupa memberi tag pada sebuah resource, atau menghabiskan satu sore untuk mengulang persis konfigurasi yang Anda buat bulan lalu karena tidak mendokumentasikan langkah-langkahnya. 

Provisioning infrastruktur secara manual bukan hanya melelahkan, tetapi juga rawan kesalahan, tidak dapat diskalakan, dan mustahil diaudit. Di sinilah Terraform mengubah segalanya. Bayangkan Anda mendefinisikan seluruh infrastruktur AWS dalam berkas teks yang bisa Anda kelola versinya, tinjau, dan deploy secara otomatis. Tidak perlu lagi mengklik puluhan layar. Tidak ada lagi percakapan "tapi di mesin saya berhasil" dengan tim Anda.

Dalam tutorial ini, saya akan menunjukkan cara mengotomatiskan infrastruktur AWS menggunakan Terraform, dengan fokus pada contoh dunia nyata: melakukan provisioning instance EC2 dengan agen SSM (Systems Manager) yang otomatis terpasang saat boot. Di akhir, Anda akan memahami dasar-dasar Infrastructure as Code dan memiliki kode yang siap langsung dideploy ke akun AWS Anda sendiri.

Jika Anda baru di AWS, pertimbangkan untuk mengikuti salah satu kursus kami, seperti AWS Concepts, Pengenalan AWS Boto di Python, atau AWS Security and Cost Management. 

Apa Itu Terraform?

Terraform adalah alat open-source Infrastructure as Code (IaC) yang dibuat oleh HashiCorp untuk mendefinisikan, melakukan provisioning, dan mengelola resource cloud menggunakan HashiCorp Configuration Language (HCL). 

Alih-alih mengklik konsol cloud atau menulis skrip bash imperatif, Anda menyatakan infrastruktur yang diinginkan dalam berkas konfigurasi, dan Terraform menangani detail untuk mewujudkannya. Pergeseran dari infrastruktur imperatif ke deklaratif ini merupakan perubahan mendasar dalam cara kita memandang resource cloud. 

Pendekatan imperatif vs. deklaratif untuk meluncurkan instance AWS EC2

Pendekatan imperatif vs. deklaratif untuk meluncurkan instance AWS EC2

Dengan pendekatan imperatif, Anda menulis instruksi langkah demi langkah: "pertama buat security group ini, lalu tunggu sampai ada, kemudian luncurkan instance ini dengan security group tersebut, lalu pasang volume ini, kemudian buat tag berikut." Anda bertanggung jawab atas urutan pasti dan penanganan error di tiap langkah. 

Dengan pendekatan deklaratif Terraform, Anda cukup mendefinisikan kondisi akhir: "Saya ingin sebuah instance EC2 dengan spesifikasi ini, terhubung ke security group ini, dengan tag berikut." Terraform menganalisis dependensi, menentukan urutan yang benar, dan mengeksekusi rencana. Jika ada kegagalan, Terraform tahu persis di mana proses terhenti.

Mengapa memilih Terraform khususnya untuk AWS? 

  1. Pertama, ekosistem komunitasnya sangat besar; Anda akan menemukan modul, contoh, dan solusi untuk hampir setiap layanan AWS yang dapat dibayangkan. 
  2. Kedua, Terraform bersifat netral penyedia. Pelajari sekali, dan keterampilan serta polanya bekerja di AWS, Azure, GCP, dan platform lainnya. Hindari ketergantungan vendor sambil mempertahankan alur kerja yang konsisten. 
  3. Ketiga, sistem manajemen state Terraform melacak setiap resource, sehingga pembaruan dan perubahan menjadi terprediksi. Terraform tahu apa yang telah Anda buat dan dapat memodifikasi atau menghapusnya dengan aman.

Sebelum masuk ke konfigurasi praktis, Anda perlu memahami tiga konsep kunci yang menjadi fondasi Terraform:

  • Resources adalah komponen infrastruktur yang Anda buat—instance EC2, bucket S3, security group. 
  • Providers adalah plugin yang memungkinkan Terraform berinteraksi dengan berbagai platform; penyedia AWS menerjemahkan HCL Anda menjadi panggilan API AWS. 
  • HCL adalah sintaks yang mudah dibaca manusia untuk mendefinisikan infrastruktur, dirancang agar ekspresif sekaligus sederhana.

Dengan dasar-dasar ini jelas, mari siapkan lingkungan Anda untuk mulai membangun infrastruktur yang sesungguhnya. 

Menyiapkan Lingkungan Terraform untuk AWS

Sebelum menulis kode Terraform, Anda perlu memasang CLI dan mengonfigurasi kredensial AWS. Izinkan saya memandu keduanya.

Pasang Terraform

Pemasangan Terraform berbeda-beda tergantung sistem operasi:

  • Di macOS, gunakan Homebrew: pertama pasang tap HashiCorp dengan brew tap hashicorp/tap, lalu pasang Terraform dengan brew install hashicorp/tap/terraform. 

  • Di Windows, unduh biner dari hashicorp.com dan tambahkan ke PATH Anda, atau gunakan Chocolatey: choco install terraform. 

  • Di Linux, unduh paket yang sesuai atau gunakan manajer paket distribusi Anda. 

Setelah terpasang, verifikasi instalasi dengan menjalankan terraform version.

Konfigurasi Kredensial AWS

Mengonfigurasi kredensial AWS memerlukan akun AWS, access key, dan secret dari IAM. Jangan pernah gunakan akun root Anda. Sebagai gantinya, buat pengguna IAM dengan akses programatik dan izin yang sesuai (AdministratorAccess). Pendekatan standar menggunakan berkas kredensial AWS di ~/.aws/credentials:

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

Sebagai alternatif, setel variabel lingkungan: AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY. Untuk lingkungan produksi, gunakan peran IAM yang dilampirkan ke instance EC2 atau sistem CI/CD alih-alih kredensial jangka panjang.

Jika Anda berpikir untuk menggunakan ekosistem selain milik Amazon atau sekadar ingin mendapatkan gambaran umum bagaimana “tiga besar” dibandingkan, saya merekomendasikan membaca Perbandingan Layanan AWS, Azure, dan GCP untuk Data Science & AI ini.

Mendeploy Agen EC2 dengan Terraform di AWS

Dengan fondasi yang siap, mari kita bangun sesuatu yang nyata: sebuah instance EC2 yang secara otomatis memasang agen SSM saat startup.

Menyiapkan struktur proyek

Proyek Terraform diuntungkan dari pendekatan yang jelas dan terstruktur. Buat tiga berkas: main.tf untuk definisi resource, variables.tf untuk input, dan outputs.tf untuk nilai yang Anda perlukan setelah deployment. Pemisahan ini menjaga kode Anda tetap teratur dan mudah dirawat.

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

Inilah alasannya: seiring proyek bertambah besar, mencampur semuanya dalam satu berkas menjadi sulit dirawat. Variabel memungkinkan Anda menggunakan ulang kode yang sama di berbagai lingkungan (dev, staging, production) dengan mengubah input. Output menyediakan nilai yang Anda perlukan, seperti ID instance atau alamat IP, tanpa perlu mencari secara manual di AWS Console.

Sekarang mari buat infrastrukturnya: sebuah instance EC2 dengan agen SSM yang sudah terpasang. Di berkas main.tf, tambahkan konfigurasi berikut:

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"
}

Konfigurasi Instance Terraform EC2

Konfigurasi Instance Terraform EC2

Blok data melakukan query ke AWS untuk AMI Amazon Linux 2 terbaru. Filter memastikan Anda mendapatkan tipe image yang tepat, dan owners = ["amazon"] memastikan Anda menggunakan AMI resmi Amazon. Pendekatan ini bekerja di semua region tanpa modifikasi—Terraform secara otomatis menemukan AMI regional yang benar.

Bagian krusialnya adalah user_data: skrip shell yang berjalan saat instance pertama kali boot. Skrip ini mengunduh dan memasang agen SSM, lalu mengaktifkannya agar berjalan otomatis. Peran IAM menyediakan izin yang diperlukan SSM untuk mengelola instance.

Pola yang sama berlaku untuk agen apa pun. Ingin CloudWatch untuk log dan metrik? Cukup modifikasi skrip user_data untuk memasang agen CloudWatch sebagai gantinya. Prinsipnya sama: definisikan apa yang ingin Anda pasang, dan Terraform memastikan itu terjadi pada setiap instance.

Untuk berkas output.tf, Anda dapat menambahkan, misalnya, ID instance. Lalu, setelah Anda menjalankan semua perintah Terraform yang akan saya bahas di bab berikut, nilainya akan ditampilkan di terminal.

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

Inisialisasi dan penerapan konfigurasi

Dengan konfigurasi yang sudah ditulis, alur kerja Terraform memiliki tiga perintah. Pertama, perintah berikut mengunduh plugin penyedia AWS dan menyiapkan direktori Anda:

terraform init

Inisialisasi Terraform

terraform init

Kedua, terraform plan menampilkan secara tepat apa yang akan dibuat, diubah, atau dihapus oleh Terraform. Pratinjau ini membantu Anda menangkap kesalahan sebelum membuat perubahan nyata:

terraform plan

Rencana Terraform

terraform plan

Tinjau output dengan saksama. Anda akan melihat instance EC2, peran IAM, instance profile, dan lampiran kebijakan yang akan dibuat Terraform.

Terakhir, terraform apply mengeksekusi perubahan. Terraform meminta konfirmasi sebelum melanjutkan. Ketik yes setelah menjalankan perintah ini:

terraform apply

Penerapan Terraform

terraform apply

Jika semuanya berhasil, Anda akan melihat pesan berikut setelah resource dibuat. 

Resource Terraform Dibuat

Konfirmasi: Resource Terraform dibuat

Dalam hitungan menit, Anda akan memiliki instance EC2 yang berjalan dengan SSM terkonfigurasi, dapat diakses tanpa kunci SSH. Pastikan Anda memeriksa AWS Console untuk melihat resource yang baru dibuat.

Mengelola State Terraform di AWS S3

Setelah menjalankan perintah di atas, Anda akan melihat berkas baru di direktori bernama terraform.tfstate. Berkas state Terraform memetakan konfigurasi Anda ke resource AWS nyata. Mari kita telusuri berkas ini untuk memahami isinya.

Memahami berkas state

Berkas state berisi setiap detail tentang infrastruktur yang Anda deploy: ID resource, alamat IP, dan dependensi. Terraform membandingkan state ini dengan konfigurasi Anda dan state aktual AWS untuk menentukan tindakan yang harus diambil. Kehilangan berkas state berarti Terraform kehilangan jejak semua yang pernah dibuatnya.

Menyimpan state di laptop berisiko. Jika mesin Anda crash, state hilang. Jika beberapa anggota tim bekerja pada infrastruktur yang sama, state lokal yang bertentangan dapat menyebabkan korupsi. Solusinya: penyimpanan state jarak jauh.

Untuk pembahasan mendalam tentang S3 dan EFS, lihat AWS Storage Tutorial ini.

Mengonfigurasi backend S3 jarak jauh

Backend S3 Terraform menyimpan state di lokasi terpusat dan andal yang dapat diakses seluruh tim Anda. Pertama, buat bucket S3:

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

Versioning sangat penting: ini memungkinkan Anda memulihkan dari insiden dengan kembali ke versi state sebelumnya.

Sekarang, tambahkan konfigurasi backend ke kode Terraform Anda:

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
  }  
}

Jalankan terraform init lagi untuk memigrasikan state lokal Anda ke S3. Terraform akan meminta konfirmasi sebelum memindahkan berkas state.

Terraform S3 Remote Backend

Backend jarak jauh Terraform S3

Setelah menjalankan perintah, bucket S3 akan berisi berkas state baru. Anda dapat memeriksanya di AWS Console.

Mengunci state dengan berkas kunci S3 native

Anda mungkin melihat bahwa kita menambahkan perintah berikut ke berkas main.tf: use_lockfile = true. Pengaturan ini mengaktifkan fitur terbaru Terraform: penguncian state S3 native. Sebelumnya, Anda memerlukan tabel DynamoDB terpisah untuk locking.

State lock Terraform

State lock Terraform

Penyederhanaan ini menghilangkan satu layanan AWS dari setup infrastruktur Anda sekaligus memberikan perlindungan yang sama terhadap kondisi balapan. Beberapa engineer dapat bekerja pada infrastruktur dengan aman, karena hanya perubahan satu orang yang akan diterapkan pada satu waktu.

Menskalakan Infrastruktur dengan Terraform di AWS

Seiring infrastruktur Anda tumbuh, nilai hardcode dan kode hasil salin-tempel menjadi mimpi buruk perawatan. Sistem variabel dan modul Terraform menyelesaikan masalah ini.

Refactor dengan variabel input

Sebelumnya, kita membuat berkas variables.tf. Sekarang Anda dapat memindahkan nilai yang sebelumnya di-hardcode di main.tf ke berkas baru ini yang akan berisi variabel kita:

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"
}

Sekarang referensikan variabel dalam resource Anda di berkas main.tf:

provider "aws" {
  region = var.aws_region
}

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

Perhatikan bahwa bucket AWS S3 bersifat unik, sehingga Anda tidak bisa menggunakan variabel pada region di parameter backend pada main.tf. Di sini, Anda harus mempertahankan region yang di-hardcode seperti “eu-central-1” alih-alih var.region_aws.

Kini setelah variabel kita didefinisikan, Anda juga dapat mendefinisikan lingkungan berbeda, seperti development atau production, di mana variabelnya mungkin berbeda. Ini dilakukan dengan membuat berkas baru berakhiran .tfvars.

Misalnya, Anda dapat membuat terraform-dev.tfvars untuk development dan terraform-prod.tfvars untuk production:

Development:

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

Production:

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

Kemudian, Anda dapat melakukan deploy ke lingkungan yang berbeda dengan menentukan berkas yang sesuai:

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

Variabel menyelesaikan masalah nilai yang spesifik lingkungan, tetapi bagaimana dengan menduplikasi seluruh pola infrastruktur? Di sinilah modul menjadi penting.

Membuat modul resource yang dapat digunakan ulang

Modul mengemas resource terkait menjadi komponen yang dapat digunakan ulang. Cara terbaik menggunakan modul adalah dengan membuat folder khusus. Misalnya, Anda dapat membuat struktur direktori seperti ini:

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

Anda dapat memindahkan berkas variables.tf yang dibuat sebelumnya (atau membuat yang baru) ke folder modul. Perubahan utama terjadi di berkas main.tf. Yang ada di modul harus berisi resource kita. Jadi semuanya mulai dari AMI hingga bagian bawah berkas dipindahkan ke sana:

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"
}

Untuk menggantikan perubahan ini, Anda mempertahankan sisa berkas tetapi menambahkan parameter module yang merujuk ke modul tertentu.

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
}

Sekarang, jika Anda menjalankan perintah init, plan, dan apply dengan setup ini, Anda akan tetap mendeploy resource yang sama seperti sebelumnya. Perbedaannya adalah modul memungkinkan Anda meluncurkan infrastruktur dengan konfigurasi serupa yang dapat digunakan ulang. Modul adalah kunci untuk menskalakan Terraform melampaui proyek sederhana.

Sekarang mari beralih ke topik penting lainnya: keamanan.

Praktik Terbaik Keamanan untuk Terraform di AWS

Kode infrastruktur memerlukan ketelitian keamanan yang sama seperti kode aplikasi. Karena itu, melindungi deployment Terraform Anda sangatlah penting.

Mengelola secret dan data sensitif

Jangan pernah meng-commit secret ke Git. Sama sekali tidak. Gunakan AWS Secrets Manager untuk nilai sensitif. Anda dapat menggunakan resource berikut di Terraform untuk melakukannya:

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

Untuk secret yang spesifik lingkungan, Anda dapat menggunakan variabel lingkungan dengan awalan TF_VAR_. 

Misalnya, Anda dapat menggunakan variable "aws_access_key" {} di berkas variables.tf dan mengekspornya di terminal dengan export TF_VAR_aws_access_key=<access_key_value>. Terraform secara otomatis memuat ini sebagai nilai variabel tanpa mengeksposnya di kode.

Menangani configuration drift

Topik konfigurasi penting lainnya adalah drift. Ini terjadi ketika seseorang memodifikasi infrastruktur melalui AWS Console atau CLI, melewati Terraform. Jalankan terraform plan secara rutin untuk mendeteksi drift. Output plan menunjukkan resource yang ada tetapi tidak sesuai dengan konfigurasi Anda.

Ketika drift muncul, Anda memiliki dua pilihan: perbarui kode Terraform Anda agar sesuai dengan kondisi nyata, atau jalankan terraform apply untuk memaksa infrastruktur kembali ke kondisi yang diinginkan. Pilihan yang benar bergantung pada apakah perubahan manual tersebut disengaja.

Membersihkan resource

Terakhir, penting juga untuk menghapus semua resource setelah kita yakin tidak membutuhkannya, guna menghindari biaya yang tidak perlu. Anda dapat membersihkan resource dengan perintah berikut:

terraform destroy

Tinjau rencana penghancuran dengan cermat. Terraform akan menghapus setiap resource yang dibuatnya. Untuk produksi, pertimbangkan menggunakan terraform destroy -target untuk menghapus resource tertentu alih-alih semuanya.

Kesimpulan

Anda telah mempelajari alur kerja inti Terraform: mendefinisikan infrastruktur dalam kode, meninjau perubahan dengan plan, menerapkannya dengan apply, dan melacak semuanya dengan manajemen state. Kita membahas deployment EC2 dengan pemasangan agen otomatis, memindahkan state ke S3 dengan locking native, menskalakan dengan variabel dan modul, serta mengamankan infrastruktur dengan manajemen secret.

Perlakukan kode infrastruktur dengan ketelitian yang sama seperti kode aplikasi. Gunakan version control, minta code review untuk perubahan, dan uji terlebih dahulu di lingkungan non-produksi. Pipeline CI/CD dapat mengotomatiskan terraform apply, menjadikan pembaruan infrastruktur semulus deployment aplikasi.

Langkah Anda berikutnya: eksplorasi GitHub Actions atau GitLab CI untuk menjalankan Terraform secara otomatis saat Anda melakukan push kode. Pendekatan Infrastructure as Code ini, dipadukan dengan automasi, mengubah cara tim mengelola resource cloud, menggantikan pekerjaan manual di konsol dengan infrastruktur yang andal, berulang, dan terkelola versi.

Rekomendasi saya adalah membangun pengetahuan ini dan mendaftar ke AWS Cloud Practitioner (CLF-C02) skill track, yang mengajarkan semua yang perlu Anda ketahui untuk meraih sertifikasi CLF-C02 dari Amazon.

FAQ Terraform AWS

Bagaimana saya bisa menggunakan Terraform untuk mengelola banyak lingkungan AWS secara efisien?

Gunakan variabel dan berkas .tfvars terpisah untuk setiap lingkungan. Buat terraform.dev.tfvars, terraform.staging.tfvars, dan terraform.prod.tfvars dengan nilai spesifik lingkungan seperti region, tipe instance, dan tag. Deploy ke lingkungan berbeda menggunakan terraform apply -var-file="terraform.prod.tfvars". Pendekatan ini memungkinkan Anda mempertahankan satu codebase sambil menyesuaikan konfigurasi per lingkungan tanpa menduplikasi kode.

Apa praktik terbaik untuk mengamankan data sensitif dalam konfigurasi Terraform di AWS?

Jangan pernah meng-commit secret ke Git. Gunakan AWS Secrets Manager untuk menyimpan nilai sensitif seperti kata sandi database, lalu referensikan dengan data source di Terraform. Untuk secret yang spesifik lingkungan, gunakan variabel lingkungan dengan awalan TF_VAR_—Terraform secara otomatis memuatnya tanpa mengekspos di kode. Aktifkan enkripsi pada bucket state S3 Anda dan batasi izin IAM hanya untuk pengguna dan sistem CI/CD yang diperlukan.

Apakah backend S3 Terraform masih memerlukan DynamoDB untuk penguncian state?

Tidak. Anda dapat menggunakan penguncian state S3 native dengan menyetel use_lockfile = true dalam konfigurasi backend. Terraform membuat berkas .tflock langsung di S3 menggunakan conditional writes, sehingga tidak perlu tabel DynamoDB terpisah. Ini menyederhanakan setup, mengurangi biaya, dan memberi perlindungan yang sama terhadap modifikasi bersamaan saat banyak anggota tim mengerjakan infrastruktur.

Bagaimana saya menangani configuration drift ketika seseorang memodifikasi infrastruktur secara manual?

Jalankan terraform plan secara rutin untuk mendeteksi drift. Output plan menampilkan resource yang tidak sesuai dengan konfigurasi Anda akibat perubahan manual di AWS Console atau CLI. Anda punya dua opsi: perbarui kode Terraform agar sesuai dengan perubahan manual jika itu disengaja, atau jalankan terraform apply untuk memaksa infrastruktur kembali ke kondisi yang diinginkan dalam kode. Perlakukan infrastruktur seperti kode aplikasi—semua perubahan harus melalui Terraform.

Bisakah saya menggunakan kode Terraform yang sama untuk mendeploy resource di berbagai region AWS?

Tentu! Gunakan variabel aws_region alih-alih meng-hardcode region di blok provider. Gunakan data source (seperti data "aws_ami") alih-alih ID AMI yang di-hardcode, karena ID AMI berbeda di setiap region. Definisikan region di berkas .tfvars Anda: aws_region = "us-east-1" untuk satu lingkungan dan aws_region = "eu-west-1" untuk yang lain. Referensikan di provider Anda: provider "aws" { region = var.aws_region }. Ini membuat kode Anda benar-benar portabel lintas region.

Benito Martin

Penulis

Benito Martin

Sebagai Founder Martin Data Solutions serta Data Scientist, ML, dan AI Engineer lepas, saya memiliki portofolio beragam dalam Regression, Classification, NLP, LLM, RAG, Neural Networks, Ensemble Methods, dan Computer Vision.

  • Berhasil mengembangkan sejumlah proyek ML end-to-end, termasuk pembersihan data, analitik, pemodelan, dan deployment di AWS dan GCP, menghadirkan solusi yang berdampak dan dapat diskalakan.
  • Membangun aplikasi web yang interaktif dan skalabel menggunakan Streamlit dan Gradio untuk berbagai use case industri.
  • Mengajar dan membimbing mahasiswa dalam data science dan analitik, mendorong perkembangan profesional mereka melalui pendekatan pembelajaran yang dipersonalisasi.
  • Merancang konten kursus untuk aplikasi retrieval-augmented generation (RAG) yang disesuaikan dengan kebutuhan enterprise.
  • Menulis blog teknis AI & ML berdampak tinggi, mencakup topik seperti MLOps, vector database, dan LLM, dengan capaian keterlibatan yang signifikan.

Dalam setiap proyek yang saya tangani, saya memastikan menerapkan praktik terkini dalam rekayasa perangkat lunak dan DevOps, seperti CI/CD, code linting, formatting, pemantauan model, pelacakan eksperimen, dan penanganan error yang tangguh. Saya berkomitmen menyajikan solusi menyeluruh, mengubah wawasan data menjadi strategi praktis yang membantu bisnis bertumbuh dan memaksimalkan pemanfaatan data science, machine learning, dan AI.

Topik

Terkait

blogs

40 Pertanyaan Wawancara DBMS Teratas di 2026

blogs

Spaghetti Plot dan Jalur Badai