Infrastructure as Code: Mengapa Konfigurasi Server Anda Harus Ada di Git

Anda hendak mendeploy fitur baru. Kode aplikasi sudah siap, pengujian lulus, dan pull request telah disetujui. Tapi kemudian seseorang bertanya: "Apakah kita sudah memperbarui konfigurasi load balancer untuk endpoint baru?" Tidak ada yang yakin. Orang yang terakhir kali mengubah load balancer sedang cuti. Dashboard cloud menunjukkan konfigurasi saat ini, tapi tidak ada yang tahu apa yang berubah minggu lalu atau mengapa.

Skenario ini terjadi di tim setiap hari. Perubahan infrastruktur bergantung pada pengetahuan tribal, langkah manual, dan ketersediaan orang tertentu. Jika orang itu tidak ada, perubahan harus menunggu. Jika mereka lupa satu langkah, server rusak tanpa suara. Dan ketika terjadi masalah, mencari akar penyebab berarti menggali log obrolan, email, dan ingatan.

Ada cara yang lebih baik. Tulis infrastruktur Anda sebagai kode.

Apa Arti Infrastructure as Code Sebenarnya

Infrastructure as Code (IaC) adalah praktik mendefinisikan server, jaringan, database, load balancer, dan semua komponen infrastruktur lainnya dalam file teks. File-file ini disimpan di repositori version control, sama seperti kode aplikasi Anda.

Perubahan kunci terletak pada cara Anda mendeskripsikan infrastruktur. Alih-alih menulis perintah langkah demi langkah seperti "SSH ke server, jalankan perintah ini untuk menginstal Nginx, lalu edit file konfigurasi ini," Anda menulis deklarasi tentang bagaimana infrastruktur seharusnya terlihat. Contohnya: "Saya ingin server yang menjalankan Nginx versi 1.24, mendengarkan di port 443, dengan sertifikat TLS ini dan aturan proxy ini."

Alat yang memproses file-file ini membaca deklarasi Anda, membandingkannya dengan keadaan infrastruktur saat ini, dan melakukan perubahan yang diperlukan agar sesuai. Ini disebut manajemen desired state.

Berikut adalah contoh konfigurasi deklaratif sederhana di Terraform:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  user_data = <<-EOF
              #!/bin/bash
              apt-get update
              apt-get install -y nginx
              systemctl enable nginx
              systemctl start nginx
              EOF

  tags = {
    Name = "web-server"
  }
}

resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "Allow HTTP and SSH"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

File ini mendeklarasikan dengan tepat apa yang Anda inginkan: sebuah instance EC2 dengan Nginx terinstal dan security group yang mengizinkan lalu lintas web. Terraform membandingkan deklarasi ini dengan keadaan akun AWS Anda saat ini dan hanya melakukan perubahan yang diperlukan agar sesuai.

Bagaimana Ini Mengubah Pekerjaan Sehari-hari Anda

Ketika infrastruktur adalah kode, mengubah konfigurasi server tidak lagi berarti login ke mesin dan mengetik perintah. Itu berarti mengedit file, membuka pull request, mendapatkan review, dan menggabungkan perubahan. Server akan diperbarui secara otomatis ketika konfigurasi baru diterapkan.

Ini mengubah seluruh alur kerja:

• Setiap perubahan terlacak. Riwayat commit di repositori Anda memberi tahu dengan tepat seperti apa konfigurasi load balancer produksi pada Selasa lalu. Tidak perlu lagi menebak-nebak, tidak perlu lagi "Saya pikir seseorang mengubah pengaturan itu."

• Perubahan dapat direview. Sebelum perubahan infrastruktur mencapai produksi, perubahan tersebut melalui proses review kode yang sama seperti perubahan aplikasi. Anggota tim dapat memberikan komentar, menyarankan perbaikan, dan menangkap kesalahan sebelum menyebabkan downtime.

• Siapa pun bisa mengusulkan perubahan. Seorang developer yang membutuhkan connection pool database baru dapat menulis konfigurasi dan mengirimkan pull request. Mereka tidak perlu menunggu tim operasi memiliki waktu luang. Tim operasi mereview perubahan, bukan mengeksekusinya.

• Rollback menjadi mudah. Jika perubahan konfigurasi menyebabkan masalah, Anda mengembalikan commit dan menerapkan ulang. Anda tidak perlu mengingat urutan persis langkah manual untuk membatalkan perubahan.

Konsep Desired State

Ide terpenting dalam infrastructure as code adalah desired state. File konfigurasi Anda mendeskripsikan kondisi ideal infrastruktur Anda. Alat IaC secara terus-menerus memastikan bahwa keadaan aktual sesuai dengan desired state.

Jika seseorang secara manual mengubah pengaturan di server, alat mendeteksi penyimpangan dan mengembalikannya. Jika server crash dan diganti, alat menyediakan server baru dengan konfigurasi yang benar secara otomatis. Anda tidak menulis skrip yang berjalan sekali. Anda mendefinisikan target, dan sistem mempertahankan target itu.

Ini pada dasarnya berbeda dari pendekatan lama di mana Anda menulis skrip untuk menyiapkan server, menjalankannya sekali, dan berharap tidak ada yang berubah setelahnya. Dengan desired state, sistem dapat menyembuhkan dirinya sendiri dan mengaudit dirinya sendiri.

Apa yang Bukan Infrastructure as Code

Infrastructure as Code bukanlah alat tertentu. Terraform, AWS CloudFormation, Ansible, Pulumi, dan banyak lainnya adalah implementasi dari konsep ini. Alatnya tidak sepenting praktik memperlakukan konfigurasi infrastruktur sebagai kode yang dikontrol versi, dapat direview, dan deklaratif.

Ini juga bukan tentang menghilangkan pekerjaan manual sepenuhnya. Anda masih perlu memahami infrastruktur Anda. Anda masih membuat keputusan desain tentang jaringan, keamanan, dan penskalaan. Tapi keputusan-keputusan itu dienkode dalam file yang dapat direview, diuji, dan direproduksi.

Mengapa Ini Penting untuk CI/CD

Infrastructure as Code adalah fondasi untuk memperlakukan perubahan infrastruktur sama seperti Anda memperlakukan perubahan aplikasi di pipeline CI/CD Anda. Ketika infrastruktur Anda adalah kode, Anda dapat:

• Menjalankan pengujian otomatis pada perubahan infrastruktur sebelum menerapkannya
• Memvalidasi bahwa file konfigurasi benar secara sintaksis
• Memeriksa pelanggaran kebijakan keamanan secara otomatis
• Menerapkan perubahan melalui pipeline yang sama yang men-deploy aplikasi Anda
• Memastikan konsistensi antar lingkungan

Tanpa infrastructure as code, pipeline CI/CD Anda hanya dapat menangani kode aplikasi. Perubahan infrastruktur tetap manual, rentan kesalahan, dan tidak terlihat oleh pipeline. Ini menciptakan celah di mana deployment aplikasi diotomatisasi tetapi infrastruktur tempat mereka berjalan tidak.

Checklist Praktis untuk Memulai

Jika Anda mempertimbangkan untuk mengadopsi infrastructure as code, berikut adalah titik awal yang praktis:

• Pilih satu lingkungan untuk memulai. Jangan mencoba mengonversi seluruh infrastruktur Anda sekaligus. Mulailah dengan lingkungan staging atau development.
• Tulis file deklaratif, bukan skrip. Fokus pada apa yang Anda inginkan, bukan cara mencapainya. File deklaratif lebih mudah direview dan dipelihara.
• Simpan semuanya di version control. Repositori Anda harus berisi semua file konfigurasi, bukan hanya yang sering berubah.
• Review perubahan infrastruktur seperti kode. Wajibkan pull request dan persetujuan untuk perubahan infrastruktur, sama seperti yang Anda lakukan untuk perubahan aplikasi.
• Uji sebelum menerapkan. Gunakan alat yang dapat memvalidasi file konfigurasi Anda dan mensimulasikan perubahan sebelum mengenai server nyata.
• Dokumentasikan desired state, bukan langkah-langkahnya. File Anda harus mendeskripsikan konfigurasi target, bukan urutan perintah untuk mencapainya.

Intisari

Infrastructure as Code mengubah server dari kotak hitam yang dipahami oleh beberapa orang menjadi komponen yang terdokumentasi, dapat direproduksi, dan mudah dikelola. Setiap perubahan konfigurasi meninggalkan jejak di riwayat commit Anda. Setiap server dapat dibangun kembali dari awal dengan hasil yang konsisten. Setiap anggota tim dapat mengusulkan perbaikan infrastruktur tanpa memerlukan akses operasional yang dalam.

Lain kali seseorang bertanya apa yang berubah di produksi minggu lalu, Anda tidak perlu menebak. Anda akan membuka repositori dan memeriksa log commit. Itulah perbedaan antara infrastruktur sebagai seni dan infrastruktur sebagai kode.