Belajar Database Administrator - Automation & IaC

#Pendahuluan

Di episode 3-13 kita melakukan banyak klik dan perintah manual: provisioning instance, konfigurasi file, buat user. Ini melelahkan, rawan salah, dan — yang paling berbahaya — tidak terdokumentasi. Siapa yang mengubah shared_buffers kemarin? Tidak ada yang tahu. Infrastructure as Code (IaC) menjawabnya: infrastruktur sebagai kode yang di-review, versi, dan bisa diulang.

Pergeseran mental terpenting: server is cattle, not pets. Kalau server bisa dimusnahkan dan dibangun ulang dari kode dalam 15 menit, tidak ada "mesin suci" yang harus dijaga — dan krisis di episode 20 jadi jauh lebih mudah diatasi.

#Terraform: Provisioning Sebagai Kode

Terraform mendeskripsikan infrastruktur (cloud, Docker, Kubernetes) sebagai konfigurasi deklaratif. Satu file, satu perintah terraform apply, seluruh setup tercipta.

provider "aws" { region = "ap-southeast-1" }
 
resource "aws_db_instance" "appdb" {
  identifier     = "appdb"
  engine         = "postgres"
  engine_version = "16.3"
  instance_class = "db.t4g.micro"
  allocated_storage     = 50
  multi_az              = true
  backup_retention_period = 14
  storage_encrypted     = true
  vpc_security_group_ids = [aws_security_group.db.id]
  skip_final_snapshot   = false
}
 
resource "aws_security_group" "db" {
  name        = "db-private"
  description = "Database hanya dari app tier"
  ingress {
    from_port = 5432
    to_port   = 5432
    protocol  = "tcp"
    security_groups = [aws_security_group.app.id]
  }
}

Perhatikan: semua parameter "jaring pengaman" dari episode 12 (multi_az, backup_retention_period, storage_encrypted, SG ketat) kini menjadi kode yang terekam di git. Setiap perubahan provisioning lewat pull request yang bisa direview — bukan klik diam-diam di konsol.

Alur kerja:

terraform init      # download provider
terraform plan      # lihat perubahan yang akan terjadi
terraform apply     # eksekusi
terraform destroy   # bongkar (hati-hati dengan data!)

Aturan emas: terraform plan sebelum apply, dan jangan pernah menyimpan terraform.tfstate yang berisi kredensial ke dalam git — pakai backend remote (S3 + DynamoDB lock, atau Terraform Cloud).

#Ansible: Konfigurasi State Server

Kalau Terraform menciptakan infrastruktur, Ansible menyetel konfigurasi di dalamnya — instalasi package, file config, user database. Ini menjembatani "server hidup" menuju "server production-ready" dari episode 3.

- name: Konfigurasi server database
  hosts: db_servers
  become: true
  tasks:
    - name: Install PostgreSQL 16
      ansible.builtin.apt:
        name: postgresql-16
        state: present
 
    - name: Setel shared_buffers
      ansible.builtin.lineinfile:
        path: /etc/postgresql/16/main/postgresql.conf
        regexp: '^shared_buffers'
        line: 'shared_buffers = 1GB'
      notify: restart postgresql
 
    - name: Buat role aplikasi
      community.postgresql.postgresql_user:
        name: app_user
        password: "{{ db_app_password }}"
        role_attr_flags: LOGIN
 
  handlers:
    - name: restart postgresql
      ansible.builtin.service:
        name: postgresql
        state: restarted

Kekuatan Ansible: idempotent — dijalankan 100 kali, hasilnya sama; hanya mengubah apa yang berbeda. {{ db_app_password }} memakai vault Ansible agar secret tidak menempel di file. Dengan ini, "mesin suci" dari episode 3 bisa diulang dari nol dengan satu perintah.

#Database-as-Code: Konsep yang Menyatukan

Database-as-code artinya semua aspek database dikelola lewat repositori: provisioning (Terraform), konfigurasi (Ansible), skema (migration), dan — yang sering dilupakan — dokumentasi. Manfaat yang langsung terasa:

• Reviewability: setiap perubahan infrastruktur database melalui code review, bukan obrolan.
• Reproducibility: staging dan production bisa identik karena lahir dari kode yang sama.
• Disaster recovery: server hilang? Bangun ulang dari kode + restore backup (episode 5, 15).
• Audit & compliance (episode 16): "siapa yang mengubah apa" tercatat otomatis di git.

Contoh alur end-to-end:

PR: ubah instance_class RDS → review → merge
   → CI menjalankan terraform plan
   → apply di staging → validasi
   → apply di production (window)

#Studi Kasus: Lab yang Bisa Dibangun Ulang

Terapkan di lab episode 0: tulis Terraform untuk VM database (atau Docker compose), tulis Ansible untuk seluruh setup episode 3 (PostgreSQL + konfigurasi + pgbouncer), lalu uji destruksi: terraform destroy, bangun ulang, dan ukur waktu sampai server siap. Jika 30 menit, kalian telah menggandakan ketahanan organisasi terhadap krisis.

Praktik yang menjaga kalian tetap aman:

• Selalu simpan state Terraform di remote + lock.
• Secret lewat variable/vault, tidak pernah di file.
• terraform plan otomatis di CI pada tiap PR.
• Backup tetap external — IaC tidak menggantikan backup (episode 5).
• Sebelum terraform destroy pada production, pastikan sudah ambil final snapshot.

#Pitfall Umum

1. State di git / local saja: hilang satu laptop, hilang jejak infrastruktur. Pakai backend remote.
2. Secret di main.tf: file ini masuk repo — satu leak = kredensial cloud bocor. Selalu variable/vault.
3. Terraform tanpa plan di CI: perubahan tak terduga lolos sampai production. Pasang gate terraform plan di PR.
4. Ansible tidak idempotent: task yang menambah data tiap run adalah bug tersembunyi — selalu uji double-run.
5. terraform destroy gegabah: tanpa snapshot, database (dan datanya) bisa hilang permanen. Hormati tombol ini.

#Penutup

Inti yang harus dibawa pulang:

• Terraform untuk provisioning (deklaratif, stateful, plan/apply); Ansible untuk configuration (idempotent).
• Database-as-code: provisioning + config + skema + dokumentasi dalam satu repositori yang direview.
• Pembagian kerja: Terraform (ciptakan), Ansible (setel), migration tool (skema).
• Uji ketahanan: musnahkan dan bangun ulang lab dari kode, ukur waktunya.

Di episode 15 selanjutnya kita bicara soal bencana yang paling ditakuti: disaster recovery & business continuity — mendefinisikan RPO/RTO yang realistis, replikasi lintas region, dan menjalankan DR drill plan yang benar-benar diuji. Sampai jumpa di episode 15!