Belajar DevOps Engineer - Configuration Management (Ansible)

#Pendahuluan

Di episode 9 Terraform membuat infrastruktur: VM, network, database. Tetapi VM yang baru lahir hanyalah "mesin kosong". Siapa yang menginstal nginx di dalamnya? Siapa yang membuat user dan SSH key? Siapa yang memastikan semua lima puluh server punya konfigurasi yang identik? Di episode inilah Configuration Management (CM) bekerja — dan Ansible adalah tool CM paling populer di ekosistem DevOps.

Ansible melengkapi Terraform: Terraform menyediakan (provision), Ansible mengonfigurasi (configure). Keduanya declarative, dan keduanya idempotent. Yang membuat Ansible istimewa: ia agentless — tidak perlu menginstal software apa pun di server target, cukup SSH. Ini mengurangi satu lapisan operasional dibanding pendahulunya (Puppet, Chef) yang butuh agent.

#Declarative vs Imperative dalam CM

Sama seperti episode 9, ada dua gaya:

• Imperative: "install nginx, copy file config, restart service" — urutan langkah yang harus dijalankan persis.
• Declarative: "nginx harus terinstall, service nginx harus aktif" — Ansible yang menentukan bagaimana mewujudkannya.

Keunggulan deklaratif adalah idempotensi: menjalankan playbook yang sama berkali-kali selalu menghasilkan keadaan yang sama. Ansible memeriksa keadaan aktual server dulu, lalu hanya melakukan perubahan jika diperlukan.

#Komponen Inti Ansible

Semua komunikasi berjalan melalui SSH — ini berarti keamanan koneksi (kunci SSH, user terbatas) menjadi bagian dari praktik kalian sehari-hari.

#Praktik: Configure Server dengan Ansible

Mulai dengan inventory — daftar server dan grupnya:

[web]
web-01 ansible_host=10.0.1.11
web-02 ansible_host=10.0.1.12
 
[db]
db-01 ansible_host=10.0.1.21
 
[all:vars]
ansible_user=deploy
ansible_python_interpreter=/usr/bin/python3

Lalu playbook yang menginstal nginx, menyalin konfigurasi, dan memastikan service berjalan:

- name: Konfigurasi web server
  hosts: web
  become: true
  vars:
    app_port: 8080
 
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
 
    - name: Salin konfigurasi site
      ansible.builtin.template:
        src: nginx-site.conf.j2
        dest: /etc/nginx/sites-available/myapp
      notify: reload nginx
 
    - name: Aktifkan site
      ansible.builtin.file:
        src: /etc/nginx/sites-available/myapp
        dest: /etc/nginx/sites-enabled/myapp
        state: link
 
    - name: Pastikan nginx berjalan
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
 
  handlers:
    - name: reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Perhatikan pola template + notify + handlers: template file nginx-site.conf.j2 akan merender variabel app_port; jika file berubah, task reload nginx hanya dijalankan ketika ada perubahan — ini menghindari restart yang tidak perlu.

Jalankan playbook:

ansible-inventory -i inventory.ini --list
ansible-playbook -i inventory.ini playbook.yml
ansible-playbook -i inventory.ini playbook.yml --check   # dry-run

--check menjalankan mode dry-run — Ansible memperlihatkan perubahan yang akan dilakukan tanpa mengeksekusinya. Ini analog terraform plan dari episode 9.

#Role: Struktur yang Profesional

Playbook satu file cepat berantakan. Role adalah struktur standar untuk memaketkan konfigurasi yang bisa dipakai ulang:

roles/nginx/
├── tasks/main.yml          # task utama
├── handlers/main.yml       # reload service
├── templates/
│   └── nginx-site.conf.j2  # template konfigurasi
├── vars/main.yml           # variabel role
├── defaults/main.yml       # default yang bisa di-override
└── meta/main.yml           # metadata dan dependensi

- name: Install nginx
  ansible.builtin.apt:
    name: nginx
    state: present
  when: ansible_os_family == "Debian"

Playbook utama menjadi ramping:

- name: Setup web server
  hosts: web
  become: true
  roles:
    - common
    - nginx
    - myapp

Dengan role, konfigurasi "server web" bisa dipakai ulang untuk puluhan environment — dan dibagikan via Ansible Galaxy seperti package manager untuk playbook.

#Ansible dalam Alur DevOps

Ansible tidak berdiri sendiri. Dalam alur nyata:

• Terraform membuat server (episode 9) → menulis IP ke inventory → Ansible mengonfigurasinya → image di-capture → Kubernetes (episode 8) menjalankan workload → Prometheus (episode 11) memonitor.

#Pitfall Umum

• Playbook tidak idempotent — gunakan module, bukan perintah shell mentah (shell, command) yang dijalankan berulang.
• Berlari dengan root — gunakan user terbatas + become hanya untuk task yang benar-benar butuh privilege.
• Secret ditulis di playbook — gunakan ansible-vault atau inject dari vault server (episode 16).
• Tanpa --check di environment penting — selalu cek perubahan sebelum apply ke produksi.
• Mengandalkan SSH password — konfigurasikan key-based auth dan disable password login.

#Penutup

Inti yang harus dibawa pulang:

• Ansible agentless via SSH; declarative dan idempotent seperti Terraform, tetapi mengelola keadaan di dalam mesin.
• Inventory mendefinisikan host dan grup; playbook mendefinisikan task; role memaketkan semuanya agar reusable.
• --check adalah dry-run yang wajib dibiasakan sebelum mengubah produksi.
• Terraform + Ansible adalah pasangan klasik: provision, lalu configure.

Di episode 11 selanjutnya kita masuk ke Observability: logging, metrics, dan tracing — lapisan yang membuat sistem produksi bisa dipahami. Tanpa observability, kalian tidak akan pernah tahu apakah deployment berhasil, mengapa latensi naik, atau di mana request menghilang.