Belajar Ansible - Modern Execution Environments (AAP / AWX, ansible-navigator & ansible-builder)

#Pendahuluan

Setelah di episode 19 sebelumnya kita membahas integrasi Ansible ke dalam pipeline CI/CD dan kolaborasinya dengan Terraform, kalian sekarang sudah membayangkan bagaimana automasi berjalan di level organisasi. Namun ada satu masalah mendasar yang seringkali baru disadari ketika tim sudah berukuran puluhan engineer: environment yang berbeda antar mesin.

Pernahkah kalian mendengar kalimat "Di laptop saya jalan kok"? Itulah salah satu kutukan paling terkenal di dunia software engineering. Di dunia Ansible, kalimat itu biasanya berbunyi seperti ini: "Playbook ini jalan di mesin saya, kok di mesin kamu error?" Padahal penyebabnya seringkali sederhana: versi Python berbeda, versi ansible-core berbeda, collection yang belum di-install, atau library Python yang bentrok — yang dikenal sebagai dependency hell.

Episode 20 ini akan membawa kalian keluar dari masalah tersebut secara permanen. Kita akan membahas konsep Containerized Execution Environments (EE), lalu mempelajari dua tool andalan Red Hat Ansible: ansible-builder untuk membangun image container yang berisi seluruh environment Ansible, dan ansible-navigator untuk menjalankan automasi secara konsisten di dalam container. Terakhir, kita akan mengenal AWX / Ansible Automation Platform (AAP) — platform enterprise yang mengubah Ansible dari tool CLI menjadi sistem terpusat dengan web UI, REST API, RBAC, dan audit logging.

#Pembahasan Utama

#Masalah "Works on My Machine" di Control Node

Mari kita lihat dengan jujur apa yang terjadi di tim yang mengelola infrastruktur dengan Ansible tanpa standardisasi environment.

Bayangkan tiga engineer bernama Adi, Budi, dan Cici:

• Adi menginstal Ansible setahun lalu dan tidak pernah meng-upgrade. Versinya ansible-core 2.14.
• Budi baru bergabung dan menginstal versi terbaru ansible-core 2.19.
• Cici bekerja di tim yang playbook-nya bergantung pada collection community.postgresql versi tertentu, yang ternyata tidak kompatibel dengan versi yang dimiliki Adi.

Ketika mereka mengerjakan playbook yang sama, hasilnya bisa berbeda-beda. Adi mendapat error deprecation, Budi malah error karena behavior berubah, Cici harus men-debug bug yang tidak bisa direproduksi. Ditambah lagi setiap engineer memakai sistem operasi berbeda — macOS, Ubuntu, Windows WSL — yang menambah variabel tak terduga.

Masalah ini bisa dirangkum dalam tiga kata: inkonsistensi, ketidakreproduksian, dan kerentanan. Playbook yang hanya diuji di satu mesin adalah bom waktu di produksi.

Pendekatan tradisional untuk menyelesaikannya adalah virtualenv per proyek. Tapi virtualenv hanya menyelesaikan isolasi Python, tidak menyelesaikan: versi sistem package, konfigurasi SSH, ketersediaan collections, atau keterbatasan library dengan dependensi native (misal psycopg2 yang butuh compiler saat instalasi).

Solusi modern yang dipakai industri adalah containerization dari seluruh environment. Ini bukan konsep baru — Docker sudah mengajarkannya untuk aplikasi — dan sekarang paradigma yang sama diterapkan ke Ansible.

#Containerized Execution Environments (EE): Konsep Dasar

Execution Environment (EE) adalah image container yang berisi semua yang dibutuhkan untuk menjalankan automasi Ansible: ansible-core, collections, library Python, dependensi sistem, dan tool pendukung. Bayangkan EE sebagai "kitchen set lengkap yang bisa dibawa bepergian": semua peralatan, bahan, dan resep sudah di dalam satu kotak. Siapa pun yang membuka kotak itu akan mendapatkan dapur yang persis sama.

Keuntungan utama EE sangat jelas:

Di ekosistem Red Hat, ada tiga layer tooling yang bekerja bersama: ansible-builder (membangun image), ansible-navigator (menjalankan image), dan AWX/AAP (menjadwalkan dan mengelola eksekusi image di banyak node). Kita akan bahas ketiganya satu per satu.

#ansible-builder: Membangun Execution Environment

ansible-builder adalah tool yang mengambil definisi environment dalam YAML dan mengubahnya menjadi image container yang siap pakai. Ia membangun di atas image dasar ansible-runner dan menyuntikkan dependensi yang kalian definisikan.

#Instalasi ansible-builder

pipx install ansible-builder

ansible-builder --version

#Mendefinisikan Environment: execution-environment.yml

Inti dari ansible-builder adalah file execution-environment.yml. File ini memiliki tiga bagian utama: build_arg_defaults, dependencies, dan images:

---
version: 3
 
build_arg_defaults:
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "--force"
 
dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt
 
images:
  base_image:
    name: quay.io/ansible/ansible-runner:latest
 
additional_build_steps:
  prepend_final: |
    RUN whoami

Mari kita bedah tiap bagian:

File dependensi yang dirujuk disimpan di direktori yang sama:

---
collections:
  - name: community.postgresql
    version: "3.5.0"
  - name: community.general
    version: "9.2.0"

requirements.txt (Python)

psycopg2-binary==2.9.9
jmespath==1.0.1

bindep.txt (system packages)

libpq-dev

#Membangun Image

Dengan file execution-environment.yml dan dependensinya di satu direktori, jalankan:

ansible-builder build \
  --tag quay.io/acme/ee-devnull:latest \
  --container-runtime docker

Perintah ini menghasilkan struktur direktori context/ berisi Containerfile dan semua file dependensi, lalu mengeksekusi build:

Ansible Builder is building your execution environment image.
The build context can be found at: context/
 
Complete! The build context can be found at: context/
Tag: quay.io/acme/ee-devnull:latest

Setelah selesai, image bisa di-push ke registry:

docker push quay.io/acme/ee-devnull:latest

#ansible-navigator: Menjalankan Automasi di Dalam Container

Jika ansible-builder membangun "dapur", maka ansible-navigator adalah cara untuk "memasak" di dalamnya. ansible-navigator adalah CLI yang menjalankan Ansible di dalam container EE, lengkap dengan TUI (Text User Interface) untuk navigasi interaktif.

Keunggulan ansible-navigator: kalian tidak perlu menginstal Ansible sama sekali di mesin. Yang dibutuhkan hanyalah ansible-navigator dan container runtime (Docker/Podman).

#Instalasi & Penggunaan Dasar

pipx install ansible-navigator

Menjalankan playbook dengan ansible-navigator:

ansible-navigator run playbooks/deploy.yml -i inventory/production.yml

Bukan hanya playbook, ansible-navigator juga membungkus berbagai perintah Ansible lainnya:

ansible-navigator doc ansible.builtin.apt

ansible-navigator inventory --list

ansible-navigator collections

ansible-navigator run -m ansible.builtin.ping all

#Mengonfigurasi ansible-navigator

Konfigurasi default disimpan dalam file ansible-navigator.yml. Di sini kalian menentukan image EE yang dipakai, mode output, level logging, dan environment variable yang diteruskan:

---
ansible-navigator:
  execution-environment:
    enabled: true
    image: quay.io/acme/ee-devnull:latest
    pull-policy: missing
    container-engine: docker
    environment-variables:
      pass:
        - AWS_PROFILE
        - AWS_ACCESS_KEY_ID
        - AWS_SECRET_ACCESS_KEY
  playbook-artifact:
    enable: false
  logging:
    level: warning
  mode: stdout

Poin penting dari konfigurasi di atas:

• image menunjuk EE yang kita bangun dengan ansible-builder. Semua engineer cukup memakai file ini dan image yang sama.
• environment-variables.pass menentukan env var yang diizinkan diteruskan dari host ke container — cara yang aman untuk menyuntikkan kredensial tanpa menyimpannya di image.
• mode: stdout membuat output diformat seperti CLI Ansible biasa. Mode default (interaktif) menampilkan TUI yang bisa dinavigasi dengan keyboard — sangat membantu saat menelusuri hasil task satu per satu.
• pull-policy: missing artinya image hanya di-pull jika belum ada di lokal, mempercepat eksekusi berulang.

#Memahami TUI ansible-navigator

Dalam mode interaktif, ansible-navigator menampilkan tampilan layar penuh dengan panel-panel:

• Panel hasil eksekusi menampilkan task demi task, lengkap dengan status ok/changed/failed.
• Kalian bisa menekan tombol untuk memperluas detail task, melihat output standar/error, dan bahkan berpindah ke playbook source untuk melihat baris kode yang sedang dieksekusi.

Fitur ini sangat berguna saat debugging playbook yang panjang: kalian tidak perlu menebak-nebak dari log teks panjang, cukup navigasi langsung ke task yang gagal dan melihat konteksnya.

#AWX / Ansible Automation Platform (AAP): Ansible untuk Skala Enterprise

Di level ini, kita berbicara tentang banyak engineer, banyak project, dan kebutuhan akan kontrol. ansible-navigator tetap berjalan di laptop masing-masing engineer; untuk organisasi besar, Red Hat menyediakan Ansible Automation Platform (AAP), dengan AWX sebagai versi upstream open-source-nya.

AWX/AAP mengubah Ansible dari tool CLI menjadi platform terpusat dengan Web UI dan REST API. Bayangkan AWX sebagai "gedung pusat kontrol" tempat semua eksekusi Ansible diawasi, dijadwalkan, dan diaudit — alih-alih dijalankan secara tersebar dan tak terkontrol di laptop pribadi.

#Fitur Utama AWX / AAP

Mari kita analogikan dengan dunia nyata: kalau laptop engineer itu seperti mobil pribadi (fleksibel tapi tak terkontrol), maka AWX itu seperti sistem transportasi kota — semua kendaraan terdaftar, ada rute resmi, jadwal, dan rekaman perjalanan. Tidak ada yang bisa "membawa mobil pribadi" masuk ke jalan raya produksi tanpa izin.

#Alur Job Template di AWX

Job Template adalah konsep inti AWX: sebuah paket lengkap berisi project (repo Git), inventory, credentials, dan opsi eksekusi. Alurnya:

1. Project mengacu ke repository Git berisi playbook/role.
2. Inventory menentukan target server (statis atau dynamic dari cloud).
3. Credentials menyimpan SSH key dan vault password, dikunci oleh RBAC.
4. Job Template menggabungkan semuanya: pilih project + inventory + credentials + playbook.
5. Launch menjalankan template, yang memicu job. Semua output dan status terekam.

Sebagai contoh, menjalankan job template melalui REST API (bisa dipanggil dari pipeline CI/CD):

curl -X POST https://awx.example.com/api/v2/job_templates/5/launch/ \
  -H "Authorization: Bearer $AWX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"extra_vars": {"environment": "production"}}'

#Menginstal AWX

AWX didesain berjalan di Kubernetes dan diinstal melalui operator. Contoh singkat setelah cluster Kubernetes siap:

kubectl create ns awx
kubectl apply -f https://raw.githubusercontent.com/ansible/awx-operator/release/deploy/awx-operator.yaml

Kemudian buat instance AWX dengan Custom Resource:

---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
  namespace: awx
spec:
  service_type: nodeport

Setelah beberapa menit, UI AWX bisa diakses dan kalian bisa mengatur admin, organisasi, lalu mulai membuat project dan job template.

#Perbandingan: ansible CLI vs ansible-navigator vs AWX/AAP

Sekarang kita punya gambaran lengkap. Mari kita bandingkan ketiga pendekatan dalam satu tabel:

#Kesalahan Umum (Common Pitfalls)

Mengadopsi execution environments tidak lepas dari jebakan. Berikut yang paling sering ditemui:

1. Image yang tidak dipin versi-nya. Tanpa pin versi, EE yang dibangun hari ini dan bulan depan bisa berbeda isinya. Selalu pin versi di requirements.yml, requirements.txt, bindep.txt, dan tag image dasar.

2. Lupa menginstal dependensi sistem. Library Python seperti psycopg2 atau cryptography sering membutuhkan package sistem (misal libpq-dev). Jika tidak ada di bindep.txt, instalasi library gagal di tengah build. Uji build image secara rutin.

3. Secret yang tertanam di image. Jangan pernah meletakkan kredensial di dalam EE image. Gunakan mekanisme inject saat runtime, seperti environment-variables.pass di ansible-navigator atau credentials store di AWX.

4. Menjalankan ansible-navigator tanpa EE yang benar. Jika image salah atau pull-policy tidak tepat, eksekusi bisa memakai image yang salah secara diam-diam. Selalu verifikasi image yang dipakai sebelum menjalankan playbook produksi.

5. Menganggap AWX = install sekali jadi. AWX membutuhkan perawatan: backup database, upgrade operator, dan manajemen kredensial. Ini bukan alat yang bisa ditinggalkan begitu saja.

#Penutup

Pada episode 20 ini, kita telah membawa kalian dari masalah klasik dependency hell di control node menuju solusi modern yang dipakai industri. Kita sudah memahami Containerized Execution Environments sebagai cara untuk memastikan semua engineer dan CI menjalankan environment yang persis sama, lalu mempelajari ansible-builder untuk membangun image EE dari execution-environment.yml, ansible-navigator untuk menjalankan automasi di dalam container dengan TUI yang nyaman, dan terakhir AWX / Ansible Automation Platform untuk skala enterprise dengan RBAC, job scheduling, credentials store, dan audit logging.

Poin kunci yang perlu kalian bawa pulang:

• Masalah "works on my machine" lahir dari inkonsistensi environment antar mesin, dan solusinya adalah containerization.
• EE membungkus ansible-core, collections, library Python, dan dependensi sistem dalam satu image yang reproducible.
• ansible-builder membangun image, ansible-navigator menjalankannya secara konsisten.
• AWX/AAP mengubah Ansible menjadi platform terpusat dengan kontrol, keamanan, dan jejak audit yang lengkap.
• Pilih tool sesuai skala: CLI untuk lab, navigator untuk konsistensi, AWX untuk enterprise.

Di episode 21 selanjutnya kita akan kembali ke level teknis yang lebih dalam dengan topik Advanced Inventory Management & Dynamic Inventory. Kita akan membedah implementasi dynamic inventory untuk AWS, Google Cloud, Azure, dan VMware, mempelajari cara memfilter instance berdasarkan tag dan region, membuat grouping otomatis, hingga menulis custom inventory script yang terintegrasi dengan CMDB seperti NetBox. Ini akan melengkapi pengetahuan kalian tentang bagaimana inventory dikelola di dunia nyata yang penuh dengan server yang lahir dan mati setiap saat. Pastikan tetap semangat!