Best Practice #

Inventory yang baik adalah inventory yang masih bisa dipahami enam bulan setelah dibuat — oleh kamu sendiri maupun oleh anggota tim baru. Setelah memahami apa yang harus dihindari, saatnya membahas apa yang harus dilakukan. Best practice di sini bukan aturan kaku, tapi prinsip yang terbukti membuat inventory Ansible tetap bersih, konsisten, dan mudah di-maintain seiring pertumbuhan infrastruktur.

1. Satu Inventory per Lingkungan #

Pisahkan inventory untuk setiap lingkungan secara fisik — direktori terpisah, bukan hanya nama grup yang berbeda.

environments/
  ├── production/
  │   ├── hosts.ini
  │   └── group_vars/
  │       └── all.yml
  ├── staging/
  │   ├── hosts.ini
  │   └── group_vars/
  │       └── all.yml
  └── development/
      ├── hosts.ini
      └── group_vars/
          └── all.yml

Pemisahan fisik ini memaksa siapa pun yang menjalankan playbook untuk secara eksplisit memilih lingkungan, menghilangkan risiko deployment tidak sengaja ke environment yang salah.

2. Beri Nama Host yang Deskriptif #

Nama host yang baik mengandung informasi yang berguna tanpa perlu melihat konfigurasi lain.

# KURANG DESKRIPTIF: sulit dipahami tanpa konteks tambahan
[webservers]
10.0.1.10
server1
vm-34567

# LEBIH BAIK: nama yang mengandung informasi
[webservers]
prod-web-01.example.com
prod-web-02.example.com

[dbservers]
prod-db-primary.example.com
prod-db-replica-01.example.com

Pola yang konsisten: {env}-{role}-{nomor}.{domain} — misalnya prod-web-01.example.com, staging-db-01.internal. Nama ini langsung memberitahu lingkungan, fungsi, dan nomor urut server.

3. Kelompokkan secara Hierarkis #

Manfaatkan fitur grup-dalam-grup untuk membangun hierarki yang berguna:

# hosts.ini
[webservers_primary]
web-01.example.com
web-02.example.com

[webservers_cdn]
web-cdn-01.example.com

[webservers:children]
webservers_primary
webservers_cdn

[dbservers_primary]
db-01.example.com

[dbservers_replica]
db-02.example.com
db-03.example.com

[dbservers:children]
dbservers_primary
dbservers_replica

# Grup top-level untuk seluruh infrastruktur production
[production:children]
webservers
dbservers
cacheservers

Hierarki ini memungkinkan targeting yang fleksibel — jalankan task untuk semua web server, hanya web primary, atau seluruh infrastruktur production.

4. Pisahkan Variabel Berdasarkan Concern #

Jangan campur semua variabel dalam satu file. Pisahkan berdasarkan komponen atau topik:

group_vars/
  ├── all/
  │   ├── common.yml      # Variabel umum: timezone, ntp, user
  │   └── monitoring.yml  # Variabel monitoring yang berlaku global
  ├── webservers/
  │   ├── nginx.yml       # Konfigurasi nginx
  │   ├── ssl.yml         # Konfigurasi SSL/TLS
  │   └── app.yml         # Konfigurasi aplikasi
  └── dbservers/
      ├── postgresql.yml  # Konfigurasi PostgreSQL
      └── backup.yml      # Konfigurasi backup database

Ketika ada masalah dengan konfigurasi nginx, kamu langsung tahu harus melihat group_vars/webservers/nginx.yml — tidak perlu scroll ratusan baris file yang berisi semua variabel.

5. Dokumentasikan Variabel yang Tidak Obvious #

Variabel dengan nama yang jelas seperti http_port: 80 tidak perlu penjelasan. Tapi variabel dengan nilai yang mengandung keputusan desain perlu komentar:

# group_vars/webservers/nginx.yml

# Worker processes disesuaikan dengan jumlah CPU di instance c5.2xlarge (8 vCPU)
# Jika tipe instance berubah, update nilai ini
nginx_worker_processes: 8

# 10MB — dibatasi untuk mencegah abuse upload file besar
# Jika ada kebutuhan upload dokumen besar, diskusikan dulu sebelum menaikkan
nginx_client_max_body_size: "10m"

# Timeout lebih panjang karena beberapa API upstream lambat (legacy system)
# Target: ganti ke 30s setelah migrasi API selesai Q3 2024
nginx_proxy_read_timeout: 120

Komentar seperti ini menghemat berjam-jam debugging di masa depan ketika seseorang bertanya “kenapa nilainya 120, bukan 30?”

6. Gunakan Variabel untuk Membedakan Lingkungan, Bukan Kondisi #

Saat playbook perlu berperilaku berbeda di lingkungan berbeda, gunakan variabel — bukan kondisi when yang mengecek nama lingkungan:

# ANTI-PATTERN: mengecek nama lingkungan di playbook
- name: Aktifkan debug mode
  template:
    src: app.conf.j2
    dest: /etc/app/app.conf
  when: inventory_hostname in groups['staging']  # Jangan lakukan ini

# BENAR: gunakan variabel yang nilainya berbeda per lingkungan
# environments/staging/group_vars/all.yml
app_debug: true

# environments/production/group_vars/all.yml
app_debug: false

# Di playbook, cukup gunakan variabelnya:
- name: Render konfigurasi aplikasi
  template:
    src: app.conf.j2
    dest: /etc/app/app.conf
# Template akan menggunakan nilai app_debug sesuai lingkungan

Pendekatan ini membuat playbook tidak perlu tahu tentang lingkungan — semua perbedaan tersimpan di inventory.

7. Simpan Inventory di Git #

Inventory adalah bagian dari infrastruktur sebagai kode (Infrastructure as Code). Simpan di Git bersama playbook dan role:

ansible-project/
  ├── .gitignore
  ├── environments/
  │   ├── production/
  │   └── staging/
  ├── playbooks/
  └── roles/

# .gitignore — jangan commit file sensitif
*.retry
.vault_pass
*.pem
*.key

Dengan inventory di Git, setiap perubahan server — penambahan, penghapusan, perubahan konfigurasi — tercatat dalam history dan bisa di-review melalui pull request.

Checklist Review Inventory #

Gunakan checklist ini saat membuat atau mereview inventory baru:

STRUKTUR:
  □ Inventory dipisah per lingkungan (production/, staging/, development/)
  □ Variabel di group_vars/ dan host_vars/, bukan di file inventory
  □ group_vars/ diorganisir per concern jika variabel banyak

PENAMAAN:
  □ Nama grup: lowercase, plural, underscore (webservers, dbservers)
  □ Nama host: deskriptif, mengandung env dan role
  □ Nama variabel: snake_case, konsisten di seluruh project

KEAMANAN:
  □ Tidak ada password atau secret dalam plaintext
  □ File sensitif dienkripsi dengan Ansible Vault
  □ .vault_pass ada di .gitignore

KUALITAS:
  □ Variabel global di group_vars/all, bukan diduplikasi per grup
  □ Komentar untuk variabel yang nilainya tidak obvious
  □ ansible-inventory --graph berjalan tanpa error

Ringkasan #

• Satu inventory per lingkungan — pisahkan secara fisik (direktori terpisah) untuk mencegah kecelakaan deployment.
• Nama host yang deskriptif: pola {env}-{role}-{nomor}.{domain} memberikan konteks langsung tanpa perlu dokumentasi tambahan.
• Hierarki grup memungkinkan targeting fleksibel — dari satu host hingga seluruh infrastruktur dalam satu perintah.
• Pisahkan variabel berdasarkan concern di dalam direktori group_vars/ — mudah ditemukan, mudah di-maintain.
• Dokumentasikan variabel yang nilainya mengandung keputusan desain — komentar hari ini menghemat debugging besok.
• Gunakan variabel, bukan kondisi untuk membedakan perilaku antar lingkungan — playbook tidak perlu tahu tentang lingkungan.
• Simpan inventory di Git — setiap perubahan infrastruktur tercatat, bisa di-review, dan bisa di-rollback.

← Sebelumnya: Anti-Pattern   Berikutnya: Apa itu Playbook? →