Node #

Dalam terminologi otomatisasi Ansible, kata node merujuk pada entitas sistem komputasi — baik berupa server fisik, virtual machine (VM), container, maupun perangkat jaringan. Ansible membagi peran infrastruktur kita ke dalam dua kategori node yang sangat berbeda secara fungsional: Control Node dan Managed Node. Memahami batasan peran, persyaratan sistem, serta interaksi keamanan di antara kedua jenis node ini sangat penting agar kita dapat merancang arsitektur otomatisasi yang andal, aman, dan siap digunakan untuk kebutuhan skala produksi.

Control Node: Pusat Orkestrasi #

Control Node adalah jantung operasional dari seluruh ekosistem Ansible. Mesin ini bertindak sebagai pusat kendali di mana kita menginstal aplikasi Ansible, menyimpan konfigurasi inventori, serta menulis dan menjalankan skenario otomatisasi (playbooks). Seluruh keputusan logis, kompilasi tugas, dan evaluasi hasil dilakukan secara eksklusif di mesin ini.

Persyaratan Sistem Control Node: #

Sistem Operasi: Harus berupa OS berbasis Unix-like. Ini termasuk berbagai distribusi Linux (seperti Ubuntu, Debian, RHEL, Rocky Linux), macOS, atau BSD.
Interpreter Python: Memerlukan Python versi modern (versi 3.9 ke atas) karena core engine Ansible ditulis menggunakan bahasa Python.
Akses Jaringan: Harus memiliki kemampuan untuk membuka koneksi outbound ke server-server target (biasanya melalui port 22 untuk SSH atau port 5986 untuk WinRM).

Mengapa Windows Native Tidak Didukung Sebagai Control Node? #

Ansible mengandalkan beberapa fungsi sistem panggilan (system calls) internal Unix (seperti fcntl, fork, dan penanganan sinyal POSIX) untuk mengelola jalannya eksekusi tugas paralel secara efisien. Karena Windows tidak memiliki pustaka POSIX native ini, kita tidak bisa menginstal Ansible core secara langsung di sistem operasi Windows.

Solusi Penggunaan Windows: #

Bagi kita yang menggunakan laptop atau workstation berbasis Windows, kita dapat menggunakan WSL (Windows Subsystem for Linux). WSL memungkinkan kita untuk menjalankan lingkungan Linux lengkap di dalam Windows tanpa perlu menggunakan virtual machine tradisional yang berat. Kita cukup menginstal Ubuntu dari Microsoft Store di dalam WSL, lalu menginstal Ansible di dalamnya menggunakan perintah pip3 atau pengelola paket sistem.

# Contoh langkah instalasi Ansible di dalam WSL (Ubuntu)
sudo apt update
sudo apt install -y python3-pip python3-venv
pip3 install ansible-core

Managed Node: Target Otomasi #

Managed Node adalah server target yang konfigurasinya kita kelola menggunakan Ansible. Mesin-mesin ini sering kali diidentifikasi sebagai server aplikasi (web server), server database, server cache, hingga perangkat firewall di dalam inventori kita.

Berbeda dengan Control Node, persyaratan sistem untuk Managed Node sangatlah minim karena sifat arsitektur Ansible yang agentless:

Layanan SSH Aktif: Untuk server berbasis Linux/Unix, layanan OpenSSH server harus aktif berjalan dan dikonfigurasi untuk menerima koneksi dari Control Node.
Interpreter Python: Minimal harus memiliki Python 3.x terpasang. Python digunakan untuk mengeksekusi script modul temporer yang dikirimkan oleh Control Node.
Hak Akses Pengguna: Kita memerlukan akun pengguna SSH di Managed Node yang memiliki otoritas untuk menjalankan tugas otomatisasi kita.

Kita tidak perlu menginstal Ansible di Managed Node. Hal ini sangat memudahkan kita ketika ingin melakukan onboarding server baru. Kita cukup memastikan port SSH terbuka dan kunci publik SSH kita terdaftar di target, maka server tersebut langsung siap kita kelola.

Eskalasi Hak Akses (Privilege Escalation) #

Saat mengelola server target, banyak tugas administratif yang membutuhkan hak akses superuser (root), seperti menginstal paket, mengubah konfigurasi sistem di direktori /etc/, atau merestart layanan sistem. Ansible mengelola eskalasi hak akses ini secara aman menggunakan parameter become.

Mekanisme become di balik layar menggunakan alat bantu eskalasi bawaan sistem operasi target (secara default menggunakan sudo untuk Linux atau enable untuk perangkat jaringan).

Berikut contoh implementasi eskalasi hak akses di dalam playbook:

---
- name: Skenario dengan eskalasi hak akses root
  hosts: webservers
  become: true          # Mengaktifkan eskalasi hak akses untuk seluruh task di play ini
  become_method: sudo   # Menentukan metode eskalasi (sudo adalah default)
  become_user: root     # Menentukan user target setelah eskalasi (root adalah default)

  tasks:
    - name: Pasang paket sistem yang membutuhkan akses root
      apt:
        name: curl
        state: present

    - name: Tugas yang dijalankan sebagai user biasa (tanpa sudo)
      command: whoami
      become: false     # Menonaktifkan eskalasi khusus untuk task ini saja

Mengelola Otentikasi Sudo: #

Ada dua cara umum bagaimana kita mengonfigurasi otentikasi sudo pada Managed Node di lingkungan produksi kita:

Passwordless Sudo (Direkomendasikan): Kita mengonfigurasi user Ansible di target agar dapat menjalankan perintah sudo tanpa dimintai password (NOPASSWD). Metode ini sangat disarankan untuk otomatisasi tanpa interaksi manusia (non-interactive CI/CD pipelines).
```
# Konfigurasi di file /etc/sudoers target:
ansible_user ALL=(ALL) NOPASSWD:ALL
```
Sudo Password Prompt: Jika kebijakan keamanan perusahaan mengharuskan pengisian password untuk setiap akses sudo, kita harus menyertakan argumen --ask-become-pass (atau -K) saat menjalankan playbook agar Ansible meminta kita memasukkan password sudo sebelum eksekusi dimulai.
```
ansible-playbook -i inventory.ini site.yml --ask-become-pass
```

Pengelolaan Konkurensi: forks dan Batch Execution #

Secara default, Ansible mengeksekusi tugas secara paralel ke banyak Managed Node secara bersamaan. Kapasitas paralelisme ini dikontrol oleh parameter forks di file konfigurasi ansible.cfg. Nilai default forks adalah 5.

Jika kita memiliki 50 server target, dan kita membiarkan nilai default forks = 5, Ansible akan membagi eksekusi ke dalam 10 batch secara berurutan:

flowchart TD
    Start["Jalankan Playbook (Target = 6 Server, forks = 3)"] --> B1["Batch 1 (web-01, web-02, web-03)"]
    B1 -->|"Eksekusi Task Paralel"| R1["Menunggu semua node Batch 1 Selesai"]
    R1 --> B2["Batch 2 (web-04, web-05, web-06)"]
    B2 -->|"Eksekusi Task Paralel"| R2["Menunggu semua node Batch 2 Selesai"]
    R2 --> End["Selesai"]

Jika salah satu server pada Batch 1 berjalan lebih lambat dibanding server lainnya, Ansible akan tetap menunggu hingga seluruh server di Batch 1 selesai merespon sebelum memicu eksekusi untuk Batch 2.

Mengoptimalkan forks pada Produksi: #

Jika kita memiliki Control Node dengan spesifikasi CPU dan RAM yang mumpuni serta bandwidth jaringan yang memadai, kita sangat disarankan untuk menaikkan nilai forks guna mempersingkat waktu eksekusi otomatisasi.

# Edit file ansible.cfg untuk mengoptimalkan konkurensi
[defaults]
forks = 50  # Mengizinkan 50 server dikelola secara paralel sekaligus

Dukungan Ragam Managed Node #

Ansible tidak hanya terbatas untuk mengelola sistem operasi Linux. Kekuatan Ansible mencakup berbagai platform infrastruktur IT lainnya:

1. Windows Server #

Windows dikelola tanpa menggunakan SSH (meskipun versi OpenSSH modern kini didukung). Ansible memanfaatkan protokol WinRM (Windows Remote Management) yang berkomunikasi via HTTPS (port 5986). Kode modul dikirimkan bukan sebagai Python script, melainkan sebagai modul script PowerShell.

2. Network Devices (Perangkat Jaringan) #

Kita dapat menggunakan Ansible untuk mengonfigurasi router, switch, dan firewall dari vendor ternama seperti Cisco, Juniper, dan Arista. Karena perangkat jaringan biasanya tidak mengizinkan instalasi Python secara lokal, Ansible mengubah perilakunya menjadi Local Execution:

Modul dijalankan secara lokal di Control Node.
Modul mengompilasi perintah CLI atau payload XML/JSON.
Mengirimkan perintah tersebut ke perangkat jaringan target via koneksi raw SSH atau API (port 443).

3. Cloud Provider dan Cluster API #

Ansible dapat mengelola siklus hidup resource cloud (seperti AWS, GCP, Azure) dan cluster Kubernetes dengan cara berkomunikasi langsung dengan API endpoint cloud provider dari Control Node.

Arsitektur Produksi Modern #

Di lingkungan enterprise berskala besar, kita tidak disarankan untuk menjalankan Ansible langsung dari laptop pribadi untuk keperluan produksi karena masalah keamanan credential dan ketiadaan riwayat audit. Kita sebaiknya membangun arsitektur otomatisasi yang terpusat.

Arsitektur produksi yang ideal biasanya menggunakan:

Bastion/Jump Host: Server perantara yang diletakkan di zona demiliterisasi (DMZ). Control Node harus merutekan koneksi SSH miliknya melalui Bastion Host menggunakan opsi ProxyJump agar dapat menjangkau server produksi internal yang berada di jaringan privat.
Automation Controller (AWX / Tower): Platform web terpusat yang membungkus Ansible core. AWX menyediakan fitur akses kontrol berbasis peran (RBAC), penyimpanan credential terenkripsi, serta visualisasi dashboard grafik log eksekusi.
CI/CD Runner: Mengintegrasikan eksekusi playbook Ansible ke dalam pipeline Git (seperti GitLab CI atau GitHub Actions runner) yang bertindak sebagai Control Node otomatis saat mendeteksi adanya push perubahan kode infrastruktur.

Berikut gambaran arsitektur produksi modern dengan perantaraan Bastion Host:

flowchart TD
    subgraph "Zona Pengembang"
        Dev["Developer Push Kode Git"] --> Git["Git Repositori"]
    end

    subgraph "Zona Kontrol Terpusat"
        Git --> Runner["CI/CD Runner (Control Node)"]
    end

    subgraph "Zona Demiliterisasi (DMZ)"
        Runner -->|1. Tunneling SSH| Bastion["Bastion Host (Jump Box)"]
    end

    subgraph "Zona Privat Produksi"
        Bastion -->|2. Forward Koneksi SSH| MN1["Managed Node 1 (Web)"]
        Bastion -->|2. Forward Koneksi SSH| MN2["Managed Node 2 (DB)"]
    end

Ringkasan #

Control Node — Mesin terpusat berbasis Unix-like (Linux/macOS) tempat Ansible diinstal untuk mengompilasi dan mengontrol jalan eksekusi tugas otomatisasi.

WSL untuk Windows — Windows tidak didukung sebagai Control Node secara native, namun kita dapat mengakalinya menggunakan Windows Subsystem for Linux (WSL).

Managed Node — Server target yang dikelola (Linux, Windows, Network Devices) yang hanya memerlukan SSH/WinRM dan Python tanpa perlu instalasi Ansible.

become (Eskalasi Akses) — Parameter Ansible untuk naik ke tingkat hak akses superuser (sudo) guna melakukan tugas-tugas administratif.

forks (Konkurensi paralel) — Parameter konfigurasi untuk menentukan berapa banyak managed node yang dieksekusi secara bersamaan dalam satu waktu.

Arsitektur Sentralisasi — Pada skala enterprise, otomatisasi diintegrasikan melalui Bastion Host, automation controller (AWX), atau runner CI/CD terpusat.

← Sebelumnya: Agentless Berikutnya: Inventory →