Belajar Ansible - Scaling Ansible untuk Enterprise

#Pendahuluan

Setelah di episode 28 sebelumnya kita membahas Windows automation — mengelola WinRM, IIS, Active Directory, dan Windows Update dari control node yang sama — pada episode kali ini kita naik satu level lebih tinggi: bagaimana membawa Ansible dari "bisa jalan di laptop developer" menjadi "platform automation kelas enterprise yang dikelola banyak tim".

Perjalanan Ansible itu seperti restoran. Ketika baru buka, satu juru masak bisa merangkap koki, kasir, dan pelayan — cukup satu dapur kecil dan beberapa menu. Tapi ketika pelanggan membludak dan tim bertambah, kalian butuh koki kepala yang mengatur menu, divisi yang memisahkan dapur dari ruang makan, sistem pemesanan terpusat, hingga standar kebersihan yang diaudit. Kalau tidak, chaos: menu ganda di dua cabang, resep berbeda di setiap chef, dan tidak ada yang tahu siapa yang boleh mengubah resep.

Kebanyakan tim Ansible mulai seperti dapur kecil: satu developer menjalankan ansible-playbook dari laptop, inventory di file lokal, semua orang punya akses ke production. Ini berjalan mulus sampai angka host dan anggota tim bertambah. Maka muncul pertanyaan-pertanyaan klasik: Siapa yang menjalankan playbook ke production? Bagaimana caranya memisahkan konfigurasi dev dan prod tanpa duplikasi? Bagaimana caranya satu playbook menjangkau ribuan host tanpa lambat? Bagaimana memastikan hanya orang tertentu yang boleh mengubah secret?

Pada episode ini kita akan membahas empat pilar scaling: arsitektur enterprise (AAP/AWX/Semaphore, GitOps, distributed execution), struktur repository (monorepo vs multi-repo, environment segregation), kontrol akses dan delegasi (RBAC, credential management, audit logging), serta performa di skala besar (callback plugin, Mitogen, serial/forks).

#Pembahasan Utama

#Enterprise Architecture Patterns

Saat Ansible dikelola tim kecil, control node adalah laptop siapa pun yang membutuhkan. Ini tidak scalable karena tiga alasan: tidak ada audit trail (siapa yang menjalankan apa), tidak ada sentralisasi kredensial (password tersebar di laptop), dan tidak ada konkurensi yang aman (dua orang bisa menjalankan playbook yang bentrok).

Solusinya adalah control node terpusat: sebuah platform yang menjalankan playbook atas nama tim, menyimpan kredensial dengan aman, dan mencatat setiap eksekusi. Berikut pilihan utamanya:

Pola arsitektur yang umum di enterprise:

1. Centralized automation — satu instance AWX/AAP menjadi single point of execution. Semua engineer memicu job lewat web UI, CLI (awx / ansible-runner), atau REST API. Tidak ada playbook yang dijalankan dari laptop ke production.
2. GitOps workflow — repository Git adalah source of truth. Pull request di-review → di-merge → project sync di AWX/AAP mengambil versi terbaru → job berjalan. Automasi di-trigger oleh perubahan Git, bukan oleh manusia.
3. Distributed execution (automation mesh) — untuk fleksibilitas jaringan dan skala ribuan node, AAP mendukung hop nodes (execution nodes) yang menjalankan job lebih dekat ke target, mengurangi latency dan menghindari bottleneck satu control node.
4. Multi-team collaboration — tiap tim punya organization dan team sendiri di AWX/AAP, lengkap dengan role terpisah; mereka berbagi collection/role via internal Galaxy/Ansible Hub.

#Monorepo vs Multi-Repo

Pertanyaan arsitektur repository yang paling sering diperdebatkan. Masing-masing punya trade-off:

Contoh struktur monorepo enterprise yang membagi perhatian dengan rapi — perhatikan separation of concerns: inventory, playbooks, roles, collections, dan environment config semua di tempatnya masing-masing:

ansible-platform/
├── ansible.cfg
├── requirements.yml
├── inventory/
│   ├── production/
│   │   ├── hosts.yml
│   │   └── group_vars/
│   │       ├── webservers.yml
│   │       └── dbservers.yml
│   ├── staging/
│   │   ├── hosts.yml
│   │   └── group_vars/
│   └── dev/
│       ├── hosts.yml
│       └── group_vars/
├── playbooks/
│   ├── site.yml
│   ├── security-hardening.yml
│   └── windows-patching.yml
├── roles/
│   ├── nginx-website/
│   └── postgres-cluster/
├── collections/
│   └── internal/
│       └── platform-utils/
├── vault/
│   └── prod.secrets.yml
├── .github/workflows/ci.yml
└── docs/
    └── runbooks.md

#Environment Segregation: Dev, Staging, Production

Memisahkan environment bukan hanya soal folder, tapi juga soal mekanisme keamanan yang mencegah silang environment. Praktik yang direkomendasikan:

• Inventory terpisah — file YAML berbeda untuk tiap environment (seperti contoh di atas).
• Credential terpisah — vault password berbeda per environment; tim production memegang aksesnya.
• Vault ID berbeda — ansible-vault encrypt --vault-id prod@prod.pass dan --vault-id dev@dev.pass.
• Guard condition — playbook production dilindungi prompt konfirmasi atau limiter wajib:

- name: Site deployment
  hosts: "{{ target | default('all') }}"
  gather_facts: true
  pre_tasks:
    - name: Wajib menentukan environment target
      ansible.builtin.assert:
        that: env in ['dev', 'staging', 'production']
        fail_msg: "Set --extra-vars 'env=production' secara eksplisit!"
      when: env is defined

Dan contoh pemanfaatan group_vars per environment untuk memisahkan konfigurasi tanpa duplikasi playbook:

env: production
app_replicas: 8
log_level: warning
nginx_conf:
  worker_processes: auto
  keepalive_timeout: 65

env: staging
app_replicas: 2
log_level: info
nginx_conf:
  worker_processes: 4
  keepalive_timeout: 60

env: dev
app_replicas: 1
log_level: debug
nginx_conf:
  worker_processes: 2
  keepalive_timeout: 60

Dengan pola ini, playbook yang sama (site.yml) menghasilkan deployment yang benar di setiap environment hanya dengan mengarahkan ke inventory yang tepat:

ansible-playbook -i inventory/dev/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/staging/hosts.yml playbooks/site.yml \
  --vault-id staging@staging.pass
ansible-playbook -i inventory/production/hosts.yml playbooks/site.yml \
  --vault-id prod@prod.pass --limit "webservers"

#Access Control & Delegation: RBAC dan Credential Management

Di perusahaan besar, tidak semua orang berhak menjalankan playbook ke production. Ini dijawab dengan RBAC (Role-Based Access Control). Di AWX/AAP, hierarki RBAC-nya adalah:

• Organization — unit bisnis (misalnya: Payments, E-commerce).
• Team — grup kerja dalam organization (Platform, SRE, Database).
• User — individu; mendapat role via team atau langsung.
• Role — hak akses seperti Admin, Execute, Read, Update, Ad Hoc.
• Job Template — kombinasi project (repo), inventory, credential, dan playbook; disinilah permission dieksekusi.

Berkat model ini, delegasi menjadi rapi: tim SRE boleh execute template patching ke staging, tapi hanya read di production; akun service CI boleh memicu template tertentu; dan tidak ada seorang pun yang perlu menyentuh SSH key mentah.

Credential management adalah titik paling kritis. Prinsipnya:

1. Credential hidup di platform, bukan di laptop — SSH keys, password, cloud API keys disimpan di credential store AWX/AAP yang terenkripsi, bukan di file host_vars plaintext.
2. Terpisah per environment — credential production dan staging tidak boleh sama atau berbagi penyimpanan.
3. Rotasi otomatis — banyak enterprise mengintegrasikan AAP dengan HashiCorp Vault atau AWS Secrets Manager sehingga password ber-rotasi otomatis dan pemakaiannya bisa di-audit.
4. Jangan pernah menaruh credential di repository — meskipun terenkripsi Vault, credential "hidup" sebaiknya di platform; Git cukup berisi data, bukan rahasia.
5. no_log: true — pastikan task yang menangani rahasia tidak menulisnya ke output job; audit log platform akan menyimpan siapa yang memakai credential apa, bukan isinya.

Audit logging & compliance: setiap job run di AWX/AAP tercatat lengkap — siapa pemicunya, template apa, credential mana, output lengkap, dan status sukses/gagal. Ini adalah fondasi compliance (ingat episode 27): kalau auditor bertanya "siapa yang mengubah konfigurasi firewall production semalam?", jawabannya ada di audit log, bukan tebakan.

#Performance at Scale: Ribuan Host

Berurusan dengan ribuan host adalah tantangan performa. Beberapa pengaturan kunci:

• forks — jumlah proses paralel default. Nilai default 5 terlalu kecil; naikkan sesuai kapasitas control node. Menaikkan forks biasanya efek pertama yang paling terasa.
• serial — membatasi berapa banyak host yang diproses per gelombang; untuk patching atau rollout bertahap.
• throttle — membatasi konkurensi pada level task, bukan play; berguna untuk API yang membatasi rate (misalnya restart satu per satu).

Contoh pengaturan global di ansible.cfg:

[defaults]
forks = 50
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/facts_cache
fact_caching_timeout = 3600
 
[ssh_connection]
pipelining = true

Contoh batching yang benar untuk rollout bertahap — kombinasi serial dengan persentase dan persentase max_fail_percentage:

- name: Rolling update ribuan host
  hosts: webservers
  become: true
  serial: "20%"
  max_fail_percentage: 10
  tasks:
    - name: Deploy versi aplikasi terbaru
      ansible.builtin.service:
        name: webapp
        state: restarted

Atau throttle untuk kontrol per-task yang lebih halus:

- name: Restart service satu per satu
  hosts: all
  throttle: 1
  tasks:
    - name: Restart nginx (hanya 1 host pada satu waktu)
      ansible.builtin.service:
        name: nginx
        state: restarted

#Callback Plugin untuk Custom Output

Default output Ansible (default callback) cukup untuk eksperimen, tapi di enterprise sering ingin lebih: melihat durasi per task, format YAML yang lebih rapi, atau integrasi dengan sistem eksternal. Di sinilah callback plugin berperan — mereka mengubah cara Ansible melaporkan hasil eksekusi.

Callback yang umum dipakai:

Mengaktifkan callback untuk menampilkan durasi (timer) dan output YAML yang rapi:

[defaults]
stdout_callback = yaml
callback_whitelist = timer, profile_tasks
 
[callback_profile_tasks]
sort_order = descending

Dengan profile_tasks, di akhir playbook kalian akan melihat tabel top slowest tasks — senjata utama untuk menemukan task mana yang jadi bottleneck saat menjalankan playbook di ribuan host. Untuk integrasi laporan ke CI, gunakan junit:

ANSIBLE_STDOUT_CALLBACK=junit \
ansible-playbook -i inventory/production/hosts.yml playbooks/site.yml

Output JUnit-nya bisa langsung dikonsumsi oleh pipeline GitLab CI / GitHub Actions untuk test report, sehingga automation Ansible menjadi bagian dari quality gate perusahaan.

#Mitogen: Strategi Extreme Performance

Ketika Ansible sudah dioptimalkan tapi masih terasa lambat — biasanya karena overhead proses Python yang harus disalin ke remote untuk setiap task — Mitogen adalah senjata rahasia. Mitogen menggantikan mekanisme eksekusi SSH Ansible dengan eksekusi lazy berbasis memori dan streaming, yang mengurangi proses Python jarak jauh yang di-spawn per-task.

Efek yang dilaporkan oleh pengguna sangat signifikan: eksekusi playbook bisa 4–10x lebih cepat pada banyak workload, karena Mitogen mengamankan state antar task tanpa harus memulai ulang interpreter Python setiap task.

[defaults]
strategy_plugins = /usr/share/ansible/plugins/strategy
strategy = mitogen_linear

#Kesalahan Umum (Common Pitfalls)

1. Tidak ada control node terpusat

Playbook dijalankan dari laptop banyak orang → tidak ada audit trail, kredensial bocor, dan bisa bentrok. Enterprise tanpa AWX/AAP pada dasarnya bukan enterprise-grade.

2. Satu inventory untuk semua environment

all bisa menembak production. Selalu pisahkan file inventory per environment dan pastikan kredensial production tidak keluar dari platform.

3. forks dibiarkan default 5

Untuk ratusan/ribuan host ini sangat lambat. Naikkan bertahap sambil memantau CPU/memory control node.

4. Reboot/patch semua host sekaligus

Tanpa serial, playbook restart service ke semua host serentak = outage. Selalu batching dengan serial dan max_fail_percentage.

5. RBAC hanya di UI, bukan di jaringan

Jika engineer bisa bypass platform dengan SSH langsung, RBAC tidak ada artinya. Amankan network-nya juga.

6. Mengabaikan audit logging

Tanpa log eksekusi, kalian buta terhadap "siapa melakukan apa" — audit logging di AWX/AAP adalah fitur compliance yang sering dianggap remeh sampai audit tahunan datang.

#Penutup

Pada episode ini kita telah membahas scaling Ansible untuk enterprise: memahami pola arsitektur terpusat dengan AWX/AAP/Semaphore dan GitOps workflow, membandingkan strategi monorepo vs multi-repo beserta struktur repository yang rapi, menerapkan environment segregation dev/staging/production dengan inventory dan vault terpisah, mengimplementasikan RBAC dan credential management yang aman dengan audit logging, serta mengoptimalkan performa ribuan host lewat forks, pipelining, fact caching, callback plugin, batching dengan serial/throttle, hingga strategi ekstrim Mitogen.

Intinya, scaling Ansible bukan hanya soal teknis — ini soal governance: memastikan kode automation terpusat, siapa yang boleh mengubah apa, dan jejak audit yang lengkap. Dengan fondasi ini, kalian siap membangun platform automation yang bisa dipertanggungjawabkan di perusahaan mana pun.

Di episode 30 selanjutnya — sebagai episode penutup dari series ini — kita akan membahas Production Deployment Checklist & Best Practices: pre-production checklist (linting, testing Molecule, dry-run, validasi inventory), operational best practices, kesalahan umum yang wajib dihindari, monitoring operasi Ansible, hingga disaster recovery dan continuous improvement. Pastikan tetap semangat!