Cloud

Cloud #

Ketika kita mengelola infrastruktur pada pusat data tradisional statis, berkas inventaris fisik (hosts.ini) adalah metode yang sangat andal. Server fisik jarang bertambah atau berkurang, dan alamat IP cenderung tetap selama bertahun-tahun. Namun, lanskap ini berubah secara dramatis di lingkungan komputasi awan (cloud computing) modern. Dengan adanya fitur penskalaan otomatis (autoscaling), daur ulang mesin virtual secara cepat, dan penyediaan sumber daya sesuai kebutuhan (on-demand provisioning), mesin virtual dapat dibuat, dihentikan, dan dihapus dalam hitungan menit. Memelihara daftar IP secara manual pada berkas inventaris statis dalam kondisi dinamis seperti ini tidak hanya melelahkan, tetapi juga mustahil dilakukan tanpa kesalahan. Di sinilah Dynamic Inventory (Inventaris Dinamis) hadir sebagai solusi terstandar. Artikel ini membedah kebutuhan inventaris dinamis, alur kerja komunikasi API cloud, integrasi AWS, GCP, dan Azure, hingga teknik optimasi caching untuk mencegah hambatan limit panggilan API.

Kebutuhan Inventory Dinamis #

Infrastruktur cloud modern menuntut pendekatan otomatisasi yang adaptif. Bayangkan sebuah sistem e-commerce yang sedang mengalami lonjakan lalu lintas data. Modul autoscaling cloud akan secara otomatis melipatgandakan jumlah instans web server dari 5 menjadi 20 mesin virtual dalam hitungan detik guna membagi beban kerja.

Jika kita tetap menggunakan metode inventaris statis, otomatisasi kita akan menghadapi kebuntuan operasional:

  1. Buta Target: Ansible tidak akan mengetahui keberadaan 15 web server baru yang baru saja diluncurkan karena IP mereka belum terdaftar di hosts.ini.
  2. Kehilangan Keterhubungan: Ansible akan membuang-buang waktu mencoba menghubungi server lama yang sudah dihapus oleh autoscaling, memicu status kegagalan eksekusi (failed tasks) yang semu.
  3. Hambatan Kecepatan Rilis: Kita terpaksa menulis skrip manual tambahan untuk melakukan sinkronisasi IP setiap kali playbook dijalankan.

Dengan inventaris dinamis, Ansible tidak lagi membaca berkas IP pasif. Sebagai gantinya, Ansible bertindak proaktif dengan melakukan kueri langsung ke API Cloud Provider sesaat sebelum playbook dijalankan untuk menanyakan: “Instans server apa saja yang aktif saat ini?”. Respon metadata dari API tersebut kemudian dirakit menjadi inventaris memori secara instan.

Alur Kerja Komunikasi API Cloud #

Untuk memahami bagaimana data server diidentifikasi secara dinamis, diagram sekuens di bawah ini menggambarkan siklus hidup pemanggilan API dari control node menuju cloud provider hingga eksekusi playbook dimulai:

sequenceDiagram
    participant ControlNode as "Control Node (Ansible Engine)"
    participant Plugin as "aws_ec2 Inventory Plugin"
    participant Cache as "Cache Lokal (jsonfile)"
    participant CloudAPI as "AWS EC2 Web API"
    participant Targets as "Managed Nodes (Instance EC2)"

    ControlNode->>Plugin: Jalankan Playbook (Mulai Pemuatan Inventaris)
    Plugin->>Cache: Periksa Cache Lokal
    alt "Cache Valid (< 300 detik)"
        Cache-->>Plugin: Kembalikan Data Instance Ter-cache
    else "Cache Kadaluarsa / Tidak Ada"
        Plugin->>CloudAPI: "Kirim Request API (DescribeInstances)"
        CloudAPI-->>Plugin: "Kembalikan JSON Respon (Metadata VM)"
        Plugin->>Cache: Simpan Respon Baru ke Cache Lokal
    end
    Plugin->>Plugin: "Parsing Metadata (Filter Status 'running', Mapping Tag)"
    Plugin-->>ControlNode: "Kembalikan Inventaris Ter-group (role_webserver, env_production)"
    ControlNode->>Targets: "Jalankan Otomatisasi Playbook via SSH"

Melalui alur ini, kita tidak perlu khawatir lagi tentang perubahan alamat IP karena Ansible akan selalu mendapatkan daftar server ter-update secara real-time.

Perbandingan Plugin vs Script #

Dalam sejarah perkembangan Ansible, terdapat dua metode untuk mengimplementasikan inventaris dinamis:

  1. Inventory Scripts (Metode Lama / Legacy): Merupakan skrip executable mandiri yang ditulis dalam bahasa pemrograman (seperti Python atau Bash) yang dipanggil oleh Ansible untuk menghasilkan keluaran teks berformat JSON terstandar. Metode ini mandiri namun sulit dikonfigurasi, memerlukan pemeliharaan kode skrip yang rumit, dan tidak mendukung integrasi caching bawaan Ansible secara native.
  2. Inventory Plugins (Metode Modern / Direkomendasikan): Merupakan plugin internal Ansible (bagian dari ekosistem Core atau Collections) yang dikonfigurasi menggunakan berkas YAML sederhana. Metode ini jauh lebih aman, efisien, terintegrasi secara native dengan sistem cache Ansible, dan memanfaatkan parameter deklaratif standar.

Kita sangat direkomendasikan untuk selalu menggunakan Inventory Plugins untuk setiap proyek baru karena merupakan standar masa depan Ansible.

Integrasi AWS EC2 #

Untuk menghubungkan Ansible dengan Amazon Web Services (AWS) secara dinamis, kita menggunakan plugin resmi amazon.aws.aws_ec2.

1. Persiapan Dependensi #

Instal koleksi AWS dari Ansible Galaxy serta SDK resmi AWS Python (boto3 dan botocore) di control node kita:

# Aktifkan virtual environment kita terlebih dahulu jika ada
# source ~/ansible-env/bin/activate

# Instal koleksi AWS
ansible-galaxy collection install amazon.aws

# Instal library AWS SDK untuk Python
pip install boto3 botocore

2. Konfigurasi Kredensial AWS #

Pastikan control node memiliki akses autentikasi ke AWS API. Cara paling aman adalah menggunakan variabel lingkungan standar AWS atau berkas kredensial AWS CLI (~/.aws/credentials):

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="ap-southeast-1"

3. Pembuatan Berkas Konfigurasi Plugin #

Nama berkas konfigurasi untuk plugin inventaris dinamis AWS wajib diakhiri dengan ekstensi khusus, yaitu aws_ec2.yml atau aws_ec2.yaml agar dikenali secara otomatis oleh mesin parser Ansible.

# File: inventory/production/aws_ec2.yml
---
# Deklarasikan plugin yang digunakan
plugin: amazon.aws.aws_ec2

# Batasi pencarian instans hanya pada region tertentu (hemat waktu query)
regions:
  - ap-southeast-1

# Filter instans: hanya ambil VM yang menyala (running)
filters:
  instance-state-name:
    - running

# Buat grup dinamis secara otomatis berdasarkan tag instans AWS (Keyed Groups)
keyed_groups:
  # Membuat grup berdasarkan nilai tag "Role". 
  # Jika instans memiliki tag Role="webserver", grup yang dihasilkan adalah "role_webserver".
  - key: tags.Role
    prefix: role
    separator: "_"
  # Membuat grup berdasarkan nilai tag "Environment".
  # Jika instans memiliki tag Environment="production", grup yang dihasilkan adalah "env_production".
  - key: tags.Environment
    prefix: env
    separator: "_"
  # Membuat grup berdasarkan Availability Zone AWS.
  # Jika instans berada di zone "ap-southeast-1a", grup yang dihasilkan adalah "zone_ap_southeast_1a".
  - key: placement.availability_zone
    prefix: zone
    separator: "_"

# Tentukan prioritas pemetaan alamat pengenal host target.
# Ansible akan mencoba membaca field di bawah ini secara berurutan:
hostnames:
  - private-ip-address # Pilihan utama untuk server internal VPC tanpa IP Publik
  - ip-address         # Fallback jika private IP tidak tersedia (menggunakan IP Publik)
  - dns-name           # Fallback menggunakan alamat DNS publik AWS

# Definisikan variabel koneksi tambahan secara dinamis menggunakan ekspresi Jinja2
compose:
  # Memetakan alamat host SSH menggunakan private IP address dari AWS API
  ansible_host: private_ip_address
  # Menentukan user SSH default secara dinamis. Jika OS adalah Ubuntu, gunakan user 'ubuntu'.
  # Jika OS lain, gunakan 'ec2-user'.
  ansible_user: "tags.OS | default('ubuntu')"
  # Memberikan tag lingkungan ke host vars
  server_environment: tags.Environment

Untuk memverifikasi hasil pemetaan kueri dinamis AWS tersebut, jalankan perintah graph berikut di terminal kita:

ansible-inventory -i inventory/production/aws_ec2.yml --graph

Integrasi Google Cloud Platform #

Bagi kita yang menjalankan infrastruktur di Google Cloud Platform (GCP), kita menggunakan plugin google.cloud.gcp_compute.

1. Persiapan Dependensi # 

# Instal koleksi GCP
ansible-galaxy collection install google.cloud

# Instal library autentikasi Google
pip install google-auth requests

2. Konfigurasi Berkas Inventaris GCP #

Siapkan berkas kunci akun layanan (Service Account JSON Key) dari konsol GCP, lalu buat file konfigurasi diakhiri dengan nama gcp_compute.yml:

# File: inventory/production/gcp_compute.yml
---
plugin: google.cloud.gcp_compute

# ID Proyek GCP kita
projects:
  - my-corporate-gcp-project-123

# Zone yang akan dipindai
zones:
  - asia-southeast1-a
  - asia-southeast1-b

# Filter pencarian instans berdasarkan label GCP
filters:
  - status = RUNNING
  - labels.environment = production

# Pembuatan grup dinamis otomatis berbasis label VM GCP
keyed_groups:
  - key: labels.role
    prefix: role
    separator: "_"
  - key: zone
    prefix: zone
    separator: "_"

# Konfigurasi metode otentikasi API GCP
auth_kind: serviceaccount
service_account_file: /opt/ansible/secrets/gcp-service-account-key.json

# Pemetaan alamat IP host target
compose:
  ansible_host: networkInterfaces[0].networkIP # IP Private internal GCP
  ansible_user: "gcp-deployer"

Integrasi Microsoft Azure #

Untuk pengguna Microsoft Azure, plugin azure.azcollection.azure_rm adalah standar yang harus digunakan.

1. Persiapan Dependensi # 

# Instal koleksi Azure
ansible-galaxy collection install azure.azcollection

# Instal dependensi Python Azure
pip install -r ~/.ansible/collections/ansible_collections/azure/azcollection/requirements-azure.txt

2. Konfigurasi Berkas Inventaris Azure #

Buat berkas konfigurasi bernama azure_rm.yml (atau akhiri dengan azure_rm.yaml):

# File: inventory/production/azure_rm.yml
---
plugin: azure.azcollection.azure_rm

# Batasi kueri pada Resource Group produksi kita
include_vm_resource_groups:
  - production-rg

# Gunakan identitas Managed Service Identity (MSI) atau Service Principal untuk otentikasi
auth_source: auto

# Buat grup berdasarkan Tag Azure VM
keyed_groups:
  - key: tags.role
    prefix: role
    separator: "_"
  - key: tags.environment
    prefix: env
    separator: "_"

# Konektivitas SSH via Private IP
use_private_ip: true

Penggabungan Hibrida dan Constructed Grouping #

Di dunia nyata, kita sering mengelola infrastruktur hibrida (hybrid infrastructure): beberapa server fisik berada di pusat data lokal (dikelola secara statis) sedangkan ratusan VM aplikasi berada di AWS EC2 (dikelola secara dinamis).

Ansible memfasilitasi penggabungan ini dengan sangat mudah. Cukup arahkan inventaris ke sebuah folder, dan letakkan berkas statis berdampingan dengan berkas konfigurasi plugin dinamis:

inventory/production/
  ├── hosts.ini            # Server lokal (statis)
  ├── aws_ec2.yml          # VM AWS EC2 (dinamis)
  └── group_vars/          # Variabel bersama
      ├── all.yml
      └── role_web.yml

Menggunakan Plugin Constructed untuk Pengelompokan Tingkat Lanjut #

Ketika kita menggabungkan sumber inventaris, kita mungkin membutuhkan klasifikasi grup baru yang lebih kompleks yang didasarkan pada kombinasi tag dinamis. Kita dapat menggunakan plugin bawaan constructed:

# File: inventory/production/constructed.yml
---
plugin: ansible.builtin.constructed

# Buat grup baru berdasarkan ekspresi kondisi logika
groups:
  # Membuat grup "secure_webservers" jika host berada di grup "role_web"
  # DAN berada di zona Asia Tenggara 'zone_ap_southeast_1a'
  secure_webservers: "'role_web' in group_names and 'zone_ap_southeast_1a' in group_names"

  # Membuat grup berdasarkan sistem operasi target
  ubuntu_nodes: "'ubuntu' in ansible_host"

Manajemen Caching dan Rate Limit #

Melakukan kueri langsung ke API cloud provider (seperti AWS, GCP, Azure) setiap kali kita menjalankan playbook atau perintah ad-hoc adalah salah satu kesalahan terbesar yang harus dihindari.

Mengapa Caching Itu Wajib? #

  1. Rate Limiting: Cloud provider menerapkan batasan jumlah kueri API (rate limits) per detik untuk mencegah penyalahgunaan. Jika pipeline CI/CD kita menjalankan playbook berulang kali dalam waktu singkat, API cloud akan memblokir koneksi kita (throttling).
  2. Degradasi Kecepatan: Panggilan API memakan waktu antara 3 hingga 10 detik tergantung latensi jaringan. Menunggu kueri API selesai pada setiap eksekusi playbook akan memperlambat alur kerja deployment kita secara signifikan.

Mengaktifkan Caching di ansible.cfg #

Kita dapat mengaktifkan penyimpanan cache lokal di mesin control node kita untuk menyimpan hasil respon kueri API selama jangka waktu tertentu. Tambahkan konfigurasi berikut di file ansible.cfg proyek kita:

# File: ansible.cfg
[defaults]
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_fact_cache
fact_caching_timeout = 86400

[inventory]
# Aktifkan penyimpanan cache untuk inventaris dinamis
cache = True

# Gunakan plugin penyimpanan berkas lokal JSON
cache_plugin = jsonfile

# Lokasi penyimpanan file cache di piringan keras
cache_connection = /tmp/ansible_inventory_cache

# Masa berlaku cache dalam detik (300 detik = 5 menit)
cache_timeout = 300

Dengan konfigurasi di atas, Ansible hanya akan melakukan panggilan API ke AWS/GCP/Azure sekali saja setiap 5 menit. Sisa eksekusi playbook dalam kurun waktu tersebut akan membaca database cache lokal yang dimuat secara instan (0.1 detik).

Jika kita baru saja meluncurkan server baru di cloud dan ingin memaksa Ansible mengabaikan cache lama untuk mendeteksi server baru tersebut secara instan, jalankan perintah berikut dengan parameter penyegar cache:

ansible-inventory -i inventory/production/ --list --refresh-cache

Ringkasan #

  • Solusi Skalabilitas Cloud — Inventaris dinamis memecahkan masalah pemeliharaan IP manual pada infrastruktur elastis (seperti autoscaling) dengan melakukan kueri API secara real-time.
  • Standar Modern Plugin — Selalu gunakan Inventory Plugins berbasis konfigurasi YAML deklaratif daripada menggunakan skrip kustom JSON yang rumit untuk proyek baru.
  • Pemanfaatan Keyed Groups — Tag instans di konsol cloud (AWS, GCP, Azure) secara otomatis dikonversi oleh plugin menjadi nama grup Ansible terstruktur (seperti role_webserver).
  • Integrasi Hibrida — Kita dapat menggabungkan server statis lokal (hosts.ini) dengan server dinamis cloud (aws_ec2.yml) dalam satu direktori inventaris yang sama.
  • Konstruksi Grup Logis — Gunakan plugin constructed untuk membangun klasifikasi grup baru yang kompleks berdasarkan gabungan logika nama grup dan wilayah zona target.
  • Pencegahan Throttling API — Konfigurasi cache inventaris di ansible.cfg wajib diaktifkan guna mempercepat eksekusi playbook serta menghindari blokir rate limit dari cloud provider.
  • Pembersihan Cache Manual — Jalankan perintah --refresh-cache untuk memaksa pembaruan data inventaris seketika saat ada perubahan mendesak pada infrastruktur virtual.

← Sebelumnya: Variable   Berikutnya: Anti-Pattern →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact