Belajar Ansible - Pengenalan dan Penjelasan Ansible Collections & Galaxy

#Pendahuluan

Setelah di episode 12 sebelumnya kita membahas Ansible Roles dan bagaimana mengemas automasi menjadi unit yang terstandarisasi, pada episode kali ini kita akan membahas lapisan berikutnya dari ekosistem Ansible: Ansible Collections dan Ansible Galaxy.

Jika kalian pernah menginstall Ansible dan melihat peringatan tentang modul yang "deprecated" atau mencari modul untuk mengelola AWS EC2 atau Kubernetes tapi tidak menemukannya di package Ansible standar, itu karena ekosistem Ansible telah berubah secara fundamental. Ansible kini terpecah menjadi dua: engine inti yang ramping (ansible-core) dan koleksi modul komunitas yang terdistribusi dalam package bernama collection. Memahami model distribusi ini sangat penting karena di dunia kerja nyata, hampir semua automasi cloud dan k8s akan membutuhkan collection yang diinstall dari Galaxy.

Analogi yang tepat: bayangkan ansible-core seperti kernel Linux, dan collections seperti distribusi/paket software di atasnya. Kernel saja tidak berguna tanpa aplikasi, dan aplikasi yang baik dibangun di atas kernel yang stabil. Demikian pula, ansible-core menyediakan mesin eksekusi dan modul built-in dasar, sementara collection menyediakan ribuan modul untuk platform spesifik yang bisa dipilih sesuai kebutuhan, tanpa harus membawa semuanya.

Pada episode ini kita akan membahas evolusi dari classic Ansible ke collections, pemisahan ansible-core dan ansible-community, konsep namespace dan FQCN, tabel collection yang umum dipakai, bekerja dengan Ansible Galaxy (mencari, menginstall, membuat requirements.yml), serta praktik penggunaan FQCN di playbook.

#Pembahasan Utama

#Evolusi: Dari Classic Ansible ke Collections

Sebelum Ansible 2.10, Ansible dikirim sebagai satu package besar bernama ansible yang berisi engine ditambah ribuan modul di dalamnya. Model ini terlihat praktis, tapi punya masalah nyata:

Ukuran package raksasa — setiap instalasi membawa ratusan modul yang tidak pernah dipakai.
Rilis lambat — semua modul dirilis bersama engine, sehingga perbaikan modul cloud harus menunggu rilis besar.
Hirarki pemeliharaan tidak jelas — modul dari berbagai vendor (AWS, GCP, network) dikelola dalam satu repositori yang sama.

Mulai Ansible 2.10, Red Hat memisahkan keduanya:

ansible-core — package kecil berisi mesin eksekusi (executor, inventory, playbook parser), ansible.builtin (modul dasar), dan command-line tools seperti ansible, ansible-playbook, ansible-galaxy, dan ansible-vault.
Collections — paket modul, plugin, role, dan dokumentasi yang dikelompokkan per namespace (vendor/platform) dan dirilis secara independen.
ansible-community — package meta yang menginstall ansible-core plus kumpulan collection komunitas yang sudah teruji agar pengalaman pengguna tetap "satu perintah install".

Note

Jika kalian menjalankan pip install ansible, kalian sebenarnya menginstall package ansible-community, yang otomatis menarik ansible-core dan puluhan collection populer sekaligus. Sementara pip install ansible-core hanya menginstall engine minimal. Di produksi, banyak tim memilih ansible-core + requirements.yml agar collection yang terinstall benar-benar terkendali dan bisa di-pin versinya.

#Memahami Namespace dan Collection (FQCN)

Setiap collection memiliki identitas yang disebut FQCN (Fully Qualified Collection Name) dengan format tiga bagian:

Format FQCN

<namespace>.<collection>.<resource>

Contohnya ansible.builtin.apt, community.docker.docker_container, dan amazon.aws.ec2_instance. Mari kita uraikan:

Namespace — kelompok organisasi/vendor. Contoh: ansible, community, amazon, kubernetes, cisco, google.
Collection — nama package dalam namespace tersebut. Contoh: builtin, general, aws, core, ios.
Resource — nama module, plugin, atau role di dalam collection. Contoh: apt, docker_container, ec2_instance, k8s.

Seluruh resource di dalam collection memiliki dua bentuk pemanggilan: FQCN lengkap dan short name. Berikut perbandingannya:

FQCN (Recommended)	Short Name (Legacy)
`ansible.builtin.apt`	`apt`
`ansible.builtin.copy`	`copy`
`community.docker.docker_container`	`docker_container`
`amazon.aws.ec2_instance`	`ec2_instance`
`kubernetes.core.k8s`	`k8s`

Warning

Sejak Ansible 2.10, short name (tanpa namespace) dianggap deprecated untuk modul yang bukan bagian dari ansible.builtin. Menggunakan docker_container tanpa community.docker. akan memunculkan warning, dan di versi mendatang bisa menjadi error. Gunakan FQCN secara konsisten sejak awal; ansible-lint bahkan akan menandai short name sebagai violation.

#Koleksi Collection Populer yang Sering Dipakai

Agar kalian punya gambaran ekosistemnya, berikut tabel collection yang paling sering muncul di produksi:

Collection	Fungsionalitas	Contoh Modul
`ansible.builtin`	Modul inti yang selalu tersedia (di-include oleh `ansible-core`)	`apt`, `copy`, `template`, `command`, `file`
`ansible.posix`	Utilitas POSIX/Linux dasar	`firewalld`, `selinux`, `synchronize`, `mount`
`community.general`	Koleksi umum besar dari komunitas	`apache2_module`, `cron`, `ufw`, `parted`
`community.docker`	Manajemen Docker & container	`docker_container`, `docker_image`, `docker_network`
`community.mysql` / `community.postgresql`	Manajemen database	`mysql_db`, `postgresql_db`, `mysql_user`
`amazon.aws`	Layanan AWS	`ec2_instance`, `s3_bucket`, `iam_user`, `rds_instance`
`google.gcp`	Layanan Google Cloud	`gcp_compute_instance`, `gcp_storage_bucket`
`azure.azcollection`	Layanan Microsoft Azure	`azure_rm_virtualmachine`, `azure_rm_storageaccount`
`kubernetes.core`	Manajemen Kubernetes	`k8s`, `helm`, `kubectl`
`cisco.ios`, `arista.eos`, `junipernetworks.junos`	Network device automation	`ios_config`, `eos_config`, `junos_config`
`ansible.windows` / `community.windows`	Manajemen Windows	`win_service`, `win_package`, `win_updates`

Tip

Aturan praktis memilih collection: gunakan collection vendor resmi bila ada (misal amazon.aws untuk AWS, kubernetes.core untuk Kubernetes), baru fallback ke community.* jika tidak ada alternatif resmi. Collection resmi lebih terawat, lebih cepat dirilis saat ada breaking change API cloud, dan biasanya sudah memakai best practice keamanan.

#Bekerja dengan Ansible Galaxy

Ansible Galaxy (galaxy.ansible.com) adalah registry publik untuk content Ansible: collection dan role. Fungsinya mirip npm untuk JavaScript, PyPI untuk Python, atau Docker Hub untuk container image. Galaxy juga menyediakan CLI yang sudah dibundel di dalam ansible-galaxy.

#Mencari Collection

Ada dua cara mencari collection: melalui website Galaxy, atau langsung dari CLI menggunakan sub-command search:

Mencari collection di Galaxy

ansible-galaxy collection search kubernetes --author kubernetes
ansible-galaxy collection search "amazon.aws" --platforms amazon

Output-nya akan menampilkan daftar collection yang cocok lengkap dengan deskripsi dan skor popularitas:

Contoh output ansible-galaxy collection search

NAME                          DESCRIPTION
kubernetes.core               Ansible Collection for managing Kubernetes
kubernetes.core.helm          Helm integration for Ansible

Note

Perintah search membutuhkan koneksi internet ke Galaxy API. Di lingkungan yang terisolasi (air-gapped), alternatifnya adalah menginstall collection offline dari tarball, yang akan kita bahas di bagian akhir episode ini.

#Menginstall Collection

Instalasi collection dilakukan dengan ansible-galaxy collection install diikuti FQCN collection:

Install collection community.docker

ansible-galaxy collection install community.docker

Output yang muncul:

Output instalasi collection

Starting galaxy collection install process
Process install dependency map
Starting collection install process
Installing 'community.docker:3.4.8' to '.../ansible/collections/ansible_collections/community/docker'

Kalian juga bisa menginstall versi spesifik menggunakan ==:

Install collection dengan versi spesifik

ansible-galaxy collection install community.docker:==3.4.8

Atau menginstall beberapa collection sekaligus, termasuk dari file tarball:

ansible-galaxy collection install amazon.aws kubernetes.core community.docker

Tip

Secara default, collection diinstall ke direktori ~/.ansible/collections/ansible_collections/. Untuk menyimpan collection bersama project (agar seluruh anggota tim memakai versi yang sama), install ke direktori ./collections pada project dengan menambahkan flag -p ./collections, lalu jalankan Ansible dengan env var ANSIBLE_COLLECTIONS_PATH=./collections atau set collections_path di ansible.cfg.

#Melihat Collection yang Terinstall

Untuk memverifikasi collection apa saja yang sudah terinstall beserta versinya, gunakan sub-command list:

Daftar collection terinstall

ansible-galaxy collection list

Output-nya terlihat seperti ini:

Output ansible-galaxy collection list

# .../.ansible/collections/ansible_collections
Collection             Version
---------------------- -------
ansible.posix          1.5.4
ansible.utils          3.0.0
community.docker       3.4.8
kubernetes.core        2.4.0

#Manajemen Dependensi dengan `requirements.yml`

Menginstall collection satu per satu dengan perintah CLI memang praktis untuk eksperimen, tapi di produksi kita butuh reproducibility: tim harus bisa menginstall collection dengan versi yang persis sama di mana pun. Solusinya adalah file requirements.yml.

File requirements.yml bisa menampung collection dan role sekaligus. Untuk collection, sintaksnya:

requirements.yml

---
collections:
  - name: community.docker
    version: ">=3.4.0,<4.0.0"
  - name: amazon.aws
    version: "8.1.0"
  - name: kubernetes.core
    version: "2.4.0"
  - name: community.general
  - name: ansible.posix
  - name: cisco.ios
    source: https://galaxy.ansible.com

Perhatikan poin-poin berikut:

version bisa berupa versi tepat (8.1.0), rentang (>=3.4.0,<4.0.0), atau dikosongkan untuk mengambil versi terbaru.
source memungkinkan mengarahkan instalasi ke Galaxy server tertentu (misalnya private Galaxy/Artifactory internal perusahaan).
requirements.yml juga bisa menampung role dengan sintaks roles: (digunakan oleh ansible-galaxy role install -r).

Setelah file disiapkan, install semua dependensi sekaligus menggunakan flag -r:

Install semua collection dari requirements.yml

ansible-galaxy collection install -r requirements.yml

Important

Pin versi collection di requirements.yml dan commit file tersebut ke Git. Collection di-update sangat sering, dan sebuah modul yang berubah perilakunya di antara versi bisa merusak playbook yang tadinya berjalan mulus. Dengan mem-pin versi, seluruh anggota tim dan pipeline CI/CD menggunakan collection yang identik — ini prinsip reproducible builds yang sama seperti lockfile di npm.

#Menggunakan Collection dalam Playbook dengan FQCN

Sekarang mari kita lihat bagaimana collection digunakan di dalam playbook. Prinsipnya: tulis nama modul dengan FQCN lengkap.

playbook-menggunakan-collection.yml

---
- name: Kelola container dengan collection community.docker
  hosts: dockerhosts
  become: true
  tasks:
    - name: Pastikan image nginx ter-pull
      community.docker.docker_image:
        name: nginx:1.27
        source: pull
 
    - name: Jalankan container nginx
      community.docker.docker_container:
        name: webapp
        image: nginx:1.27
        ports:
          - "8080:80"
        state: started

Selain modul, collection juga membawa role. Untuk memakai role dari collection, formatnya adalah <namespace>.<collection>.<role_name>:

Memakai role dari collection

---
- name: Pakai role dari collection community.general
  hosts: all
  roles:
    - community.general.apache2

Kalian juga bisa membatasi scope penggunaan collection per play menggunakan keyword collections: di level play. Ini memungkinkan kalian menulis short name di dalam play tersebut tanpa warning:

Membatasi scope collection per play

---
- name: Play dengan collections scope
  hosts: webservers
  become: true
  collections:
    - community.docker
    - ansible.posix
  tasks:
    - name: Pull image
      docker_image:
        name: nginx:1.27
        source: pull

Warning

Gunakan keyword collections: di level play dengan hati-hati. Meskipun membuat penulisan lebih pendek, ia membuat asal-usul modul menjadi implisit, sehingga playbook lebih sulit dibaca dan di-audit. Banyak tim memilih FQCN eksplisit di setiap task sebagai standar, karena lebih self-documenting dan tidak ambigu.

#Collection dan Roles: Di Mana Role Saya Disimpan?

Sebuah pertanyaan yang sering muncul: "Collection itu berisi role juga, lalu apa bedanya dengan role biasa?" Jawabannya adalah distribusi. Role biasa disimpan di direktori roles/ project atau dibagikan via Galaxy sebagai role standalone. Collection adalah wadah distribusi yang bisa berisi modul, plugin, dan role sekaligus — dikelompokkan per namespace.

Perbandingannya:

Aspek	Role Standalone	Collection
Isi	Task, handler, vars, template, files	Modul + plugin + role + docs
Identitas	`<nama_role>`	`<namespace>.<collection>.<resource>`
Instalasi	`ansible-galaxy role install`	`ansible-galaxy collection install`
Kapan dipakai	Logika terkait satu komponen	Paket lengkap vendor/platform
Contoh nyata	`roles/nginx` buatan sendiri	`community.docker` (modul Docker + role)

Best practice umum: role untuk logika bisnis internal kalian (deploy aplikasi sendiri, konfigurasi khas perusahaan), collection untuk integrasi platform eksternal (cloud, network, database vendor).

#Kesalahan Umum (Common Pitfalls)

1. Lupa menginstall collection sebelum memakai modulnya

Error yang paling sering muncul di lapangan adalah couldn't resolve module/action 'community.docker.docker_container'. Ini hampir selalu karena collection belum diinstall. Solusi: jalankan ansible-galaxy collection install -r requirements.yml dulu, dan pastikan collections_path mengarah ke direktori yang sama dengan yang dipakai saat eksekusi playbook.

2. Menggunakan short name tanpa keyword collections:

Menulis docker_container langsung di playbook akan memunculkan warning deprecation dan bisa gagal di versi baru. Gunakan FQCN.

3. Tidak mem-pin versi collection

Playbook yang "tiba-tiba rusak" tanpa perubahan kode seringkali disebabkan collection yang ter-upgrade otomatis. Selalu pin versi di requirements.yml.

4. Mengira ansible dan ansible-core itu sama

pip install ansible menginstall package meta (ansible-community), sedangkan pip install ansible-core hanya engine. Di CI/CD, perbedaan ini penting: install sesuai kebutuhan dan pin versi keduanya.

5. Menginstall collection ke default path di shared server

Di server bersama, collection yang terinstall di ~/.ansible/collections hanya terlihat oleh user tersebut. Pastikan ANSIBLE_COLLECTIONS_PATH atau collections_path dikonfigurasi agar seluruh pipeline memakai lokasi yang sama.

#Penutup

Pada episode 13 ini kita telah belajar bahwa ekosistem Ansible modern terpecah menjadi ansible-core (engine ramping) dan collection (paket modul/plugin/role per namespace), dengan ansible-community sebagai package meta yang menggabungkan keduanya. Kita sudah memahami konsep namespace dan FQCN (<namespace>.<collection>.<resource>), mengenal collection populer seperti ansible.builtin, community.docker, amazon.aws, dan kubernetes.core, bekerja dengan Ansible Galaxy untuk mencari dan menginstall collection, mengelola dependensi dengan requirements.yml, memverifikasi instalasi dengan ansible-galaxy collection list, serta memakai collection di playbook dengan FQCN.

Poin kunci yang perlu kalian bawa pulang:

ansible-core = engine, collection = konten; pisahkan keduanya secara sadar.
FQCN adalah standar penulisan modul modern; short name deprecated.
requirements.yml + versi yang di-pin adalah kunci reproducible automasi.
Collection bisa berisi modul, plugin, dan role dalam satu namespace.
Verifikasi instalasi dengan ansible-galaxy collection list.

Dengan kemampuan menginstall dan memakai collection, kalian bisa membangun automasi yang melampaui sistem operasi dasar — mulai dari Docker, cloud, sampai Kubernetes. Namun semakin banyak variabel, credential, dan API key yang kalian tangani, semakin besar pula risiko kebocoran rahasia jika disimpan sebagai plaintext di repository.

Di episode 14 selanjutnya kita akan membahas Enkripsi Rahasia Menggunakan Ansible Vault — bagaimana melindungi password, API key, dan kredensial di dalam file playbook dengan enkripsi, mengenkripsi file dan string, menjalankan playbook terenkripsi, hingga multiple vault IDs untuk environment development dan production. Pastikan tetap semangat!