Drift Handling #
Configuration drift adalah kondisi di mana server yang seharusnya identik ternyata berbeda — seseorang mengedit file konfigurasi langsung via SSH, sebuah update otomatis mengubah setting, atau script satu kali pakai meninggalkan jejak yang tidak dibersihkan. Drift adalah musuh konsistensi infrastruktur dan sering menjadi penyebab bug yang sangat sulit direproduksi. Ansible, karena sifatnya yang idempoten, secara natural menangani drift — tapi hanya jika kamu menjalankannya secara teratur dan memahami cara kerjanya.
Apa itu Configuration Drift #
Kondisi ideal:
web-01: nginx 1.24, config v2, SSL enabled ✓
web-02: nginx 1.24, config v2, SSL enabled ✓
web-03: nginx 1.24, config v2, SSL enabled ✓
Setelah drift (tanpa disadari):
web-01: nginx 1.24, config v2, SSL enabled ✓
web-02: nginx 1.24, config v2, SSL enabled ✓ ← admin edit langsung
web-03: nginx 1.26, config v1, SSL disabled ← update otomatis + edit manual
Drift biasanya terjadi karena:
- Admin melakukan “quick fix” langsung di server via SSH
- Update otomatis (unattended-upgrades) mengubah konfigurasi
- Eksekusi skrip manual yang tidak terdokumentasi
- Kegagalan di tengah playbook yang meninggalkan server dalam kondisi setengah jalan
Mendeteksi Drift dengan Check Mode #
Ansible --check mode menjalankan playbook tanpa benar-benar membuat perubahan — tapi melaporkan apa yang akan berubah jika dijalankan sungguhan:
# Deteksi drift tanpa membuat perubahan
ansible-playbook -i inventory/production/ site.yml --check
# Dengan --diff: tampilkan perubahan yang akan dilakukan secara detail
ansible-playbook -i inventory/production/ site.yml --check --diff
Output --diff untuk file yang mengalami drift:
TASK [Deploy konfigurasi nginx] **********************
--- before: /etc/nginx/nginx.conf
+++ after: /tmp/nginx.conf.j2
@@ -3,7 +3,7 @@
worker_processes auto;
events {
- worker_connections 2048; ← nilai yang ada di server saat ini
+ worker_connections 1024; ← nilai yang seharusnya (dari template)
}
Dari output ini kamu langsung tahu: ada yang mengubah worker_connections dari 1024 menjadi 2048 langsung di server.
Scheduled Drift Detection #
Jalankan check mode secara terjadwal untuk mendeteksi drift sebelum menjadi masalah:
# playbooks/detect-drift.yml
---
- name: Deteksi configuration drift
hosts: all
gather_facts: true
tasks:
- name: Cek apakah konfigurasi sesuai dengan yang diharapkan
template:
src: "{{ item.src }}"
dest: "{{ item.dest }}"
check_mode: true # Mode check untuk task spesifik ini
diff: true
register: drift_check
loop:
- src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
- src: app.conf.j2
dest: /etc/app/app.conf
- name: Laporkan jika ada drift
debug:
msg: >
DRIFT TERDETEKSI di {{ inventory_hostname }}:
{{ item.item.dest }} berbeda dari yang diharapkan!
loop: "{{ drift_check.results }}"
when: item.changed
loop_control:
label: "{{ item.item.dest }}"
Remediasi Drift #
Setelah drift terdeteksi, ada dua pendekatan untuk remediasi:
Remediasi Otomatis (Langsung Jalankan Playbook) #
# Jalankan playbook tanpa --check untuk memperbaiki drift
ansible-playbook -i inventory/production/ site.yml
# Jika ingin konfirmasi per task sebelum dieksekusi
ansible-playbook -i inventory/production/ site.yml --step
# Jika hanya ingin perbaiki host tertentu
ansible-playbook -i inventory/production/ site.yml --limit web-03
Karena Ansible idempoten, menjalankan playbook ke server yang sudah dalam kondisi benar tidak akan mengubah apa pun — hanya server yang mengalami drift yang akan dimodifikasi.
Investigasi Sebelum Remediasi #
Untuk perubahan yang tidak diketahui asal-usulnya, investigasi dulu sebelum langsung overwrite:
# Lihat apa yang berbeda
ansible-playbook site.yml --check --diff --limit web-03
# Ambil file konfigurasi aktual dari server untuk dianalisis
ansible -i inventory/production/ web-03 -m fetch \
-a "src=/etc/nginx/nginx.conf dest=/tmp/drift-analysis/ flat=yes"
# Bandingkan dengan yang seharusnya
diff /tmp/drift-analysis/nginx.conf templates/nginx.conf.j2
Mencegah Drift: Immutable Infrastructure #
Pendekatan paling efektif untuk mencegah drift adalah immutable infrastructure — server tidak pernah diubah langsung; jika konfigurasi perlu berubah, server diganti dengan yang baru:
Pendekatan tradisional (rentan drift):
Server berjalan lama → perubahan manual menumpuk → drift
Immutable infrastructure:
Konfigurasi berubah → buat server baru dengan config baru
→ pindahkan traffic → hapus server lama
Meski tidak selalu praktis untuk semua skenario, beberapa langkah yang mendekati immutability bisa diterapkan:
# Batasi akses SSH langsung — hanya via bastion/jump host
# yang tercatat di audit log
# Nonaktifkan unattended upgrades untuk mencegah drift dari update otomatis
- name: Nonaktifkan unattended-upgrades
apt:
name: unattended-upgrades
state: absent
when: ansible_os_family == "Debian"
# Gunakan file monitoring untuk mendeteksi perubahan tidak resmi
- name: Install auditd untuk monitoring perubahan file kritis
apt:
name: auditd
state: present
- name: Monitor perubahan di file konfigurasi kritis
blockinfile:
path: /etc/audit/rules.d/critical-files.rules
block: |
-w /etc/nginx/nginx.conf -p wa -k nginx_config_change
-w /etc/ssh/sshd_config -p wa -k ssh_config_change
Ringkasan #
- Configuration drift adalah kondisi server yang berbeda dari yang seharusnya — terjadi karena perubahan manual, update otomatis, atau eksekusi skrip tidak terdokumentasi.
--check --diffadalah cara paling cepat untuk mendeteksi drift tanpa membuat perubahan — lihat apa yang akan diubah sebelum benar-benar mengubah.- Jalankan playbook dengan check mode secara terjadwal untuk monitoring drift berkelanjutan.
- Remediasi drift semudah menjalankan playbook tanpa
--check— Ansible hanya memperbaiki yang berbeda, tidak menyentuh yang sudah benar.- Investigasi sebelum remediasi untuk drift yang sumbernya tidak diketahui — gunakan
fetchuntuk mengambil file aktual dan bandingkan.- Pendekatan jangka panjang: batasi akses SSH langsung, nonaktifkan update otomatis, dan gunakan audit logging untuk mendeteksi perubahan yang tidak resmi.