Belajar System Engineer - Configuration Management

#Pendahuluan

Di episode 8 kita mengotomasi satu server dengan script dan cron. Sekarang bayangkan kalian harus menerapkan konfigurasi yang sama di 50, 100, bahkan 1000 server — script yang dikirim manual tidak akan berjalan. Di sinilah configuration management (CM) berperan: satu definisi konfigurasi, diterapkan ke semua server secara konsisten.

Mengapa episode ini penting? Karena skala adalah perbedaan paling fundamental antara sysadmin dan System Engineer. CM tools seperti Ansible memungkinkan kalian mendeskripsikan "keadaan akhir" server (state) — bukan langkah-langkah manual — dan biarkan tool yang menyamakannya. Prinsip intinya disebut idempotency, dan memahami prinsip ini akan mengubah cara kalian berpikir tentang operasi.

#Kenapa Ansible?

Ada beberapa CM tool: Ansible, Puppet, Chef, SaltStack. Ansible menjadi pilihan paling populer karena:

Kekurangannya: performa lebih lambat untuk skala ribuan node (bebas agent tapi harus koneksi SSH tiap run) dan tidak memiliki model daemon seperti Puppet — tetapi untuk mayoritas kebutuhan System Engineer, Ansible sudah lebih dari cukup.

#Idempotency: Konsep Kunci

Idempotent berarti: menjalankan operasi beberapa kali memberikan hasil yang sama seperti sekali. Contoh non-idempotent:

- name: Tambahkan baris ke file (akan dobel tiap run)
  ansible.builtin.shell: |
    echo "server=prod" >> /etc/app.conf

Dan yang idempotent:

- name: Pastikan direktori ada
  ansible.builtin.file:
    path: /srv/app
    state: directory
    mode: "0755"

Module Ansible didesain idempotent: file dengan state: directory hanya membuat direktori jika belum ada. Perintah shell/command mentah tidak — gunakan sebagai jalan terakhir.

#Arsitektur Ansible

#Inventory

Inventory adalah daftar server yang dikelola. Contoh dasar:

[web]
web01 ansible_host=10.0.1.11
web02 ansible_host=10.0.1.12
 
[db]
db01 ansible_host=10.0.3.11
 
[prod:children]
web
db

#Playbook

Playbook adalah file YAML berisi daftar task yang dijalankan ke host tertentu:

---
- name: Konfigurasi server web
  hosts: web
  become: true
  vars:
    http_port: 80
  tasks:
    - name: Update cache paket
      ansible.builtin.apt:
        update_cache: true
      when: ansible_os_family == "Debian"
 
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
 
    - name: Pastikan nginx berjalan
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
 
    - name: Deploy konfigurasi site
      ansible.builtin.template:
        src: templates/default.conf.j2
        dest: /etc/nginx/sites-available/default
      notify: reload nginx
 
  handlers:
    - name: reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Pola penting yang harus diperhatikan:

• become: true — jalankan sebagai root via sudo.
• state: present/started/enabled — deklarasi state, bukan perintah.
• notify + handlers — reload service hanya jika konfigurasi berubah. Ini contoh idempotency: run kedua yang tidak mengubah apa pun tidak akan me-reload nginx.

#Template Jinja2

Ansible memakai Jinja2 untuk template. Contoh template nginx:

server {
    listen {{ http_port }} default_server;
    server_name {{ inventory_hostname }};
    root /srv/app/public;
 
    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Dengan template, satu file konfigurasi bisa menghasilkan output berbeda per server berdasarkan variabelnya.

#Praktik: Playbook Lengkap

Skenario: provisioning server web dari nol di VM kalian.

# 1. Install ansible (di mesin kontrol, bukan target)
sudo apt install -y ansible
ansible --version
 
# 2. Buat inventory & playbook (lihat file di atas)
 
# 3. Uji koneksi ke target
ansible web -i inventory/hosts.ini -m ping
 
# 4. Jalankan playbook
ansible-playbook -i inventory/hosts.ini playbooks/web.yml
 
# 5. Jalankan sekali lagi — perhatikan: "changed" jadi "ok"
ansible-playbook -i inventory/hosts.ini playbooks/web.yml

Pada run kedua, semua task akan berstatus ok (tidak ada changed) — itulah idempotency bekerja. Jika ada task yang terus changed, itu sinyal konfigurasi tidak stabil dan perlu diperbaiki.

#Ansible Roles: Organisasi untuk Skala

Untuk playbook yang tumbuh, pecah menjadi roles — struktur folder standar:

roles/nginx/
├── tasks/main.yml
├── handlers/main.yml
├── templates/
├── files/
└── vars/main.yml

Dengan roles, tugas yang sama (nginx, postgres, hardening) bisa dipakai ulang di banyak playbook — ini fondasi cara tim besar mengorganisasi konfigurasi.

#Kesalahan Umum

1. Memakai shell/command untuk semuanya — kehilangan idempotency; pakai module khusus bila ada.
2. Playbook yang bukan "ok" di run kedua — konfigurasi tidak stabil.
3. Hardcode password di playbook — simpan di vault (ansible-vault) atau secret manager.
4. Tidak memakai handlers — service di-restart setiap run walau tidak ada perubahan.
5. Inventory dan playbook tidak di-version control — konfigurasi harus ada di git.

#Penutup

Inti yang harus dibawa pulang:

• Ansible adalah CM populer: agentless, berbasis YAML, idempotent.
• Idempotency = aman dijalankan berulang; deklarasi state, bukan perintah.
• notify + handlers memastikan restart hanya saat diperlukan.
• Roles mengorganisasi playbook untuk skala; vault untuk rahasia.

Di episode 10 selanjutnya kita membangun kemampuan "melihat" server kalian: monitoring & logging dengan Prometheus/Grafana dan syslog/ELK. Sampai jumpa di episode 10!