Konfigurasi #

Dalam ekosistem Ansible, fleksibilitas dan portabilitas proyek otomatisasi sangat ditentukan oleh bagaimana kita mengelola konfigurasinya. Tanpa konfigurasi yang terpusat dan terstandarisasi, kita akan terpaksa menuliskan argumen baris perintah (command-line flags) yang panjang dan berulang setiap kali menjalankan playbook. Untuk mengatasi hal ini, Ansible menyediakan mekanisme manajemen perilaku default melalui berkas konfigurasi bernama ansible.cfg. Berkas ini memungkinkan kita mendefinisikan direktori penyimpanan inventaris, metode autentikasi SSH, batas eksekusi paralel (forks), eskalasi hak akses, hingga optimalisasi performa jaringan. Artikel ini membedah peran ansible.cfg, aturan hierarki pencariannya, fitur keamanan pencegahan eskalasi, hingga parameter kinerja tingkat tinggi.

Peran ansible.cfg #

Berkas ansible.cfg adalah pusat kendali perilaku engine Ansible di mesin control node. Mengatur konfigurasi ini secara eksplisit membantu kita memastikan bahwa setiap anggota tim pengembang infrastruktur (platform engineers) menggunakan parameter yang sama saat menjalankan otomatisasi yang sama. Hal ini meminimalkan variasi eksekusi akibat perbedaan sistem operasi atau konfigurasi personal di masing-masing mesin lokal pengembang.

Secara teoritis, berkas konfigurasi ini memisahkan logika deklaratif playbook dengan metode eksekusi taktis. Kita dapat mendefinisikan perilaku default yang paling aman dan efisien untuk lingkungan proyek kita, lalu membagikannya ke repositori Git bersama seluruh kode otomatisasi lainnya.

Hierarki Pencarian File Konfigurasi #

Saat kita menjalankan perintah Ansible (seperti ansible atau ansible-playbook), mesin eksekusi Ansible akan mencari file ansible.cfg di beberapa lokasi secara berurutan. Ansible menggunakan sistem prioritas di mana file konfigurasi yang ditemukan di lokasi prioritas lebih tinggi akan menimpa (override) konfigurasi dari lokasi di bawahnya.

Berikut adalah 4 lokasi pencarian file ansible.cfg dari prioritas tertinggi hingga terendah:

Urutan pencarian konfigurasi ansible.cfg (Prioritas 1 ke 4):
  1. ANSIBLE_CONFIG (Environment Variable)      ← Mengabaikan semua berkas fisik
  2. ./ansible.cfg (Direktori proyek aktif)     ← Praktik terbaik untuk portabilitas proyek
  3. ~/.ansible.cfg (Home directory user)       ← Konfigurasi personal untuk user tertentu
  4. /etc/ansible/ansible.cfg (Global sistem)    ← Konfigurasi bawaan sistem pasca-instalasi

Alur keputusan pencarian tersebut divisualisasikan dalam diagram keputusan berikut:

flowchart TD
    A["Mulai Perintah Ansible"] --> B{"Apakah variabel ANSIBLE_CONFIG diatur?"}
    B -- "Ya (Prioritas 1)" --> C["Gunakan file dari ANSIBLE_CONFIG"]
    B -- "Tidak" --> D{"Apakah ./ansible.cfg ada di direktori aktif?"}
    D -- "Ya (Prioritas 2)" --> E{"Apakah direktori world-writable?"}
    E -- "Ya (Potensi Kerentanan)" --> F["Abaikan ./ansible.cfg (Gunakan fallback)"]
    E -- "Tidak" --> G["Gunakan ./ansible.cfg lokal"]
    D -- "Tidak" --> H{"Apakah ~/.ansible.cfg ada di home user?"}
    H -- "Ya (Prioritas 3)" --> I["Gunakan ~/.ansible.cfg personal"]
    H -- "Tidak" --> J{"Apakah /etc/ansible/ansible.cfg ada?"}
    J -- "Ya (Prioritas 4)" --> K["Gunakan /etc/ansible/ansible.cfg global"]
    J -- "Tidak" --> L["Gunakan Konfigurasi Bawaan Engine (Default Fallback)"]
    F --> H

Fitur Keamanan Direktori Proyek #

Salah satu keunikan penanganan keamanan di Ansible adalah pengabaian file konfigurasi ./ansible.cfg lokal secara otomatis apabila direktori tempat file tersebut berada bersifat world-writable (dapat ditulis oleh siapa saja di sistem, contohnya jika permission folder diatur ke 777 atau 775 dengan grup yang terlalu bebas).

Mengapa Aturan Ini Ada? #

Pada sistem multi-user Linux, jika direktori proyek bersifat world-writable, pengguna lain yang jahat dapat menaruh file ansible.cfg kustom di direktori tersebut. File konfigurasi tersebut bisa berisi parameter privilege escalation berbahaya atau memuat library plugin berbahaya. Ketika kita menjalankan perintah ansible dengan hak akses sudo, kita akan secara tidak sengaja mengeksekusi kode berbahaya milik pengguna lain tersebut.

Jika Ansible mendeteksi folder proyek tidak aman, Ansible akan memunculkan peringatan (warning) dan langsung melompat ke prioritas berikutnya (~/.ansible.cfg atau /etc/ansible/ansible.cfg):

[WARNING]: Avoid running Ansible from a directory writable by other users.
Hosting it in a world-writable directory is a security risk.

Solusinya: Kita harus memastikan hak akses direktori proyek kita dikonfigurasi secara ketat (hanya pemilik yang dapat memodifikasi berkas):

# Batasi hak akses direktori agar hanya pemilik yang memiliki akses tulis
chmod 755 ~/ansible-project
chmod 644 ~/ansible-project/ansible.cfg

Bedah Parameter defaults #

Blok [defaults] berisi parameter global yang mengatur perilaku dasar dari semua modul dan playbook Ansible. Berikut adalah rincian opsi penting yang sering kita gunakan:

1. inventory #

Opsi ini memberi tahu Ansible di mana letak berkas inventaris server default kita berada.

[defaults]
# Menggunakan berkas tunggal format INI atau YAML
inventory = hosts.ini

# Menggunakan direktori (Praktik Terbaik Produksi)
inventory = inventory/

Jika kita mengarahkan parameter ini ke sebuah direktori, Ansible akan memproses semua berkas di dalam direktori tersebut (baik format INI, YAML, maupun skrip inventaris dinamis) dan menggabungkannya menjadi satu kesatuan inventaris terpadu.

2. remote_user #

User sistem operasi default di managed node yang akan digunakan oleh Ansible saat menginisiasi koneksi SSH.

[defaults]
remote_user = ansible-deploy

Kita dapat menimpa nilai ini pada level playbook, level grup inventaris, atau menggunakan argumen -u saat mengeksekusi CLI.

3. private_key_file #

Mendefinisikan jalur absolut atau relatif ke file kunci privat SSH kita untuk autentikasi tanpa password.

[defaults]
private_key_file = ~/.ssh/id_ed25519

4. forks #

Mengatur jumlah maksimum koneksi paralel yang dapat dibuka oleh Ansible secara bersamaan ke managed node.

[defaults]
forks = 15

Secara default, nilai forks diatur sangat rendah, yaitu 5. Jika kita memiliki 100 server target, Ansible akan memproses tugas tersebut secara bertahap (5 server sekaligus), yang dapat memperlambat proses deploy. Meningkatkan nilai ini ke 15 atau 20 mempercepat eksekusi pada infrastruktur skala besar. Namun, kita harus berhati-hati karena nilai yang terlalu tinggi dapat membebani kapasitas CPU dan memori dari mesin control node.

5. host_key_checking #

Mengatur apakah Ansible harus memverifikasi kunci host (host key fingerprint) target server di berkas known_hosts lokal sebelum menghubunginya via SSH.

[defaults]
host_key_checking = True

# ANTI-PATTERN: Menonaktifkan host key checking secara permanen di semua lingkungan
host_key_checking = False

# BENAR: Selalu aktifkan di lingkungan produksi untuk menghindari serangan Man-in-the-Middle (MitM)
host_key_checking = True

Menonaktifkan pemeriksaan ini diperbolehkan hanya di lingkungan laboratorium pengembangan lokal (seperti vagrant atau container) guna memperlancar setup awal. Di lingkungan produksi, menonaktifkan fitur ini membuka celah keamanan serangan pembajakan koneksi.

6. stdout_callback #

Mengubah format visual keluaran (output display) dari Ansible pada terminal saat kita menjalankan perintah otomatisasi.

[defaults]
stdout_callback = yaml

Keluaran default Ansible (default callback) cenderung sangat verbose dan berantakan. Mengubahnya ke format yaml membuat laporan eksekusi task, status perubahan (changed), dan detail error tampil dengan struktur indentasi yang jauh lebih bersih dan mudah dibaca.

Bedah Parameter privilege_escalation #

Sebagian besar otomatisasi infrastruktur memerlukan hak akses administratif (root). Bagian [privilege_escalation] mengontrol bagaimana Ansible menaikkan hak aksesnya di managed node target.

[privilege_escalation]
# Aktifkan eskalasi hak akses secara default untuk semua task
become = True

# Metode eskalasi yang digunakan (sudo adalah standar emas Linux)
become_method = sudo

# User target eskalasi (hampir selalu root)
become_user = root

# Tentukan apakah Ansible harus meminta password sudo secara interaktif
become_ask_pass = False

Jika target managed node telah dikonfigurasi dengan aturan NOPASSWD di berkas /etc/sudoers (seperti yang telah kita bahas di artikel instalasi), kita wajib mengatur become_ask_pass = False. Sebaliknya, jika kebijakan keamanan server menuntut adanya password sudo setiap saat, atur parameter ini ke True, dan gunakan opsi --ask-become-pass (atau -K) saat menjalankan playbook untuk memasukkan password secara aman.

Optimasi Kinerja di ssh_connection #

Bagian [ssh_connection] adalah area paling penting bagi kita yang ingin melakukan tuning kecepatan eksekusi playbook Ansible. Di sinilah kita mengoptimalkan koneksi SSH bawaan.

1. pipelining #

Merupakan fitur optimasi terpenting di Ansible. Secara default, untuk setiap task, Ansible akan menyalin modul otomatisasi dalam bentuk file fisik ke direktori temporer target, mengeksekusinya, lalu menghapusnya. Hal ini membutuhkan beberapa siklus transfer koneksi SSH.

[ssh_connection]
pipelining = True

Mengaktifkan pipelining memangkas siklus di atas dengan cara mengirimkan skrip Python secara langsung melalui input standar (standard input / stdin) koneksi SSH aktif tanpa perlu menyalin berkas fisik ke disk target. Perbandingan performa dengan dan tanpa pipelining digambarkan di bawah ini:

flowchart TD
    subgraph "Tanpa Pipelining (Metode Standar)"
        direction TB
        A1["Control Node"] -->|"1. SSH Handshake"| B1["Managed Node"]
        A1 -->|"2. SFTP Copy Modul (File Temp)"| B1
        A1 -->|"3. SSH Exec Interpreter (Jalankan File)"| B1
        A1 -->|"4. SSH Exec Cleanup (Hapus File Temp)"| B1
        B1 -->|"5. Kirim JSON Output"| A1
    end
    subgraph "Dengan Pipelining (Dioptimalkan)"
        direction TB
        A2["Control Node"] -->|"1. SSH Handshake"| B2["Managed Node"]
        A2 -->|"2. Stream Python Script via stdin & Exec"| B2
        B2 -->|"3. Kirim JSON Output"| A2
    end

Mengaktifkan fitur ini dapat mempercepat eksekusi playbook hingga 2 sampai 3 kali lipat.

[!WARNING] Fitur pipelining = True tidak kompatibel jika sistem target server kita mengaktifkan aturan requiretty di berkas /etc/sudoers. Aturan requiretty menolak eksekusi perintah non-interaktif tanpa terminal fisik. Untuk menggunakan pipelining, kita harus menonaktifkan requiretty di konfigurasi sudoers server target kita.

2. ssh_args #

Parameter untuk memberikan opsi tambahan secara langsung ke klien SSH mesin control node kita.

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=accept-new

• ControlMaster=auto: Mengaktifkan multiplexing koneksi SSH. SSH akan menggunakan kembali soket koneksi yang sudah terbuka untuk eksekusi perintah berikutnya ke server yang sama, sehingga tidak perlu mengulangi jabat tangan (handshake) SSH yang memakan waktu.
• ControlPersist=60s: Menjaga agar koneksi soket SSH di latar belakang tetap terbuka selama 60 detik setelah tugas terakhir selesai. Jika ada tugas baru dalam kurun waktu tersebut, koneksi langsung terhubung secara instan.
• StrictHostKeyChecking=accept-new: Secara otomatis menambahkan fingerprint kunci host baru ke file known_hosts kita, tetapi tetap memblokir koneksi jika kunci host target mengalami perubahan (mencegah sabotase MitM).

Overriding via Environment Variables #

Setiap konfigurasi di dalam file ansible.cfg dapat kita timpa menggunakan variabel lingkungan (Environment Variables). Penulisan variabel lingkungan Ansible memiliki aturan penamaan yang konsisten: diawali dengan prefiks ANSIBLE_ diikuti nama kategori dan parameter dalam format huruf kapital.

Tabel di bawah ini memetakan parameter konfigurasi populer di ansible.cfg ke variabel lingkungan padanannya:

Penggunaan variabel lingkungan ini sangat bermanfaat dalam pipeline otomatisasi CI/CD. Kita tidak perlu merubah berkas konfigurasi fisik di dalam repositori Git, cukup dengan mendefinisikan variabel lingkungan pada runner CI/CD kita.

Contoh File Konfigurasi Siap Pakai #

Berikut adalah dua contoh berkas ansible.cfg yang siap kita salin dan gunakan sesuai dengan karakteristik lingkungan kerja kita.

1. Template ansible.cfg untuk Lingkungan Development #

Template ini dirancang untuk kecepatan eksekusi tinggi dan toleransi kemudahan kerja di lingkungan laboratorium lokal/sandbox.

# File: ansible.cfg (Development/Lab Sandbox)
[defaults]
# Menggunakan inventaris lokal proyek secara otomatis
inventory = ./inventory/hosts.ini

# Detail login default mesin sandbox
remote_user = vagrant
private_key_file = .vagrant/machines/default/virtualbox/private_key

# Paralelisme standar lab
forks = 5

# Toleransi sidik jari kunci SSH (Cocok untuk mesin yang sering dibuat ulang)
host_key_checking = False

# Nonaktifkan pembuatan file retry yang mengotori folder proyek
retry_files_enabled = False

# Format tampilan log yang rapi
stdout_callback = yaml

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

[ssh_connection]
# Mengaktifkan optimalisasi koneksi
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15s

2. Template ansible.cfg untuk Lingkungan Produksi #

Template ini dirancang dengan standar keamanan ekstra ketat, audit log lengkap, dan optimalisasi kinerja skala enterprise.

# File: ansible.cfg (Production Environment Only)
[defaults]
# Jalur folder inventaris terstruktur produksi
inventory = ./inventory/production/

# User deployer terdedikasi
remote_user = ansible-deployer
private_key_file = /opt/ansible/.ssh/deployer_private_key.ed25519

# Koneksi paralel tinggi untuk server skala besar
forks = 25

# KEAMANAN: Selalu aktifkan validasi kunci host untuk menghindari pembajakan
host_key_checking = True

# Lokasi penyimpanan log aktivitas otomatisasi untuk keperluan audit kepatuhan
log_path = /var/log/ansible/production-execution.log

# Matikan file retry
retry_files_enabled = False

# Gunakan format YAML yang terstruktur
stdout_callback = yaml

[privilege_escalation]
become = True
become_method = sudo
become_user = root
# Jangan simpan password become di sini, gunakan Ansible Vault jika ask_pass dinonaktifkan
become_ask_pass = False

[ssh_connection]
# Pipelining wajib aktif untuk performa server skala besar
pipelining = True

# Keamanan tambahan: Gunakan accept-new dan kunci SSH yang ketat
ssh_args = -o ControlMaster=auto -o ControlPersist=120s -o StrictHostKeyChecking=yes -o ConnectTimeout=10

Ringkasan #

• Pusat Kendali Proyek — File ansible.cfg mendefinisikan parameter default jalannya otomatisasi, memastikan konsistensi eksekusi antar anggota tim pengembang.
• Hierarki Precedence — Pencarian konfigurasi memiliki 4 tingkat prioritas; penentuan lewat Environment Variable (ANSIBLE_CONFIG) dan file proyek lokal (./ansible.cfg) berada pada tingkat tertinggi.
• Fitur Proteksi Keamanan — Ansible akan mengabaikan berkas ./ansible.cfg lokal jika direktori proyek kita diatur sebagai world-writable (permission longgar seperti 777) demi mencegah pembajakan hak akses.
• Tuning Forks — Menyesuaikan nilai forks (misal 15-25) meningkatkan kecepatan paralelisme tugas pada infrastruktur skala besar dengan konsekuensi penggunaan sumber daya control node.
• Host Key Checking Produksi — Selalu aktifkan pemeriksaan host_key_checking = True di produksi guna melindungi sistem dari ancaman Man-in-the-Middle.
• SSH Pipelining — Mengaktifkan pipelining = True mentransmisikan skrip eksekusi langsung ke input standar Python target server tanpa salinan file fisik, memangkas durasi deploy hingga 3 kali lebih cepat.
• Optimasi Multiplexing — Konfigurasi ControlMaster dan ControlPersist menjaga soket koneksi SSH tetap hidup di latar belakang untuk digunakan kembali, menghilangkan latensi negosiasi jabat tangan SSH berulang kali.

← Sebelumnya: Instalasi   Berikutnya: Struktur Direktori →