Node

Node #

Dalam terminologi Ansible, kata “node” merujuk pada mesin — bisa berupa server fisik, VM, atau container. Ansible membedakan dua jenis node dengan peran yang sangat berbeda: control node dan managed node. Memahami perbedaan ini penting karena menentukan di mana Ansible diinstal, bagaimana koneksi bekerja, dan bagaimana kamu merancang infrastruktur otomasi.

Control Node #

Control node adalah mesin tempat Ansible diinstal dan dijalankan. Dari sinilah semua perintah Ansible dieksekusi — menjalankan playbook, memeriksa inventory, atau mengirim ad-hoc command.

Control Node bisa berupa:
  ✓ Laptop developer (untuk development dan testing)
  ✓ Server khusus CI/CD (untuk deployment otomatis)
  ✓ VM di cloud (untuk production automation)
  ✓ Bastion host (untuk lingkungan dengan akses terbatas)

Persyaratan control node lebih ketat dibanding managed node karena Ansible sendiri harus terinstal di sini:

Persyaratan Control Node:
  ✓ Linux, macOS, atau WSL (Windows Subsystem for Linux)
  ✓ Python 3.9 atau lebih baru
  ✓ Ansible terinstal (via pip atau package manager)
  ✓ Akses SSH ke semua managed node
  ✗ Windows native TIDAK didukung sebagai control node
Windows tidak didukung sebagai control node secara native. Jika kamu menggunakan Windows, gunakan WSL (Windows Subsystem for Linux) untuk menjalankan Ansible.

Managed Node #

Managed node adalah server yang dikelola oleh Ansible. Ini adalah target dari semua instruksi yang kamu definisikan di playbook — server web, database, cache, atau infrastruktur lainnya.

Persyaratan Managed Node:
  ✓ SSH server (OpenSSH) aktif
  ✓ Python 3.x tersedia
  ✓ User dengan akses SSH
  ✓ Privilege yang cukup untuk task yang akan dijalankan (sudo jika diperlukan)

Yang TIDAK diperlukan:
  ✗ Ansible terinstal
  ✗ Agent atau software tambahan apapun

Managed node bisa berupa apa saja yang bisa dijangkau via SSH dari control node: server fisik, VM, instance cloud, bahkan network device yang mendukung SSH.


Hubungan Control Node dan Managed Node #

Komunikasi antara keduanya selalu diinisiasi dari control node ke managed node — tidak pernah sebaliknya.

Control Node                     Managed Node(s)
─────────────                    ───────────────────────
                   SSH (port 22)
Ansible runs ──────────────────► web-01
                                 web-02
                                 db-01
                                 cache-01

Alur komunikasi:
  1. Control node membuka koneksi SSH ke managed node
  2. Control node mengirim module Python ke managed node
  3. Managed node mengeksekusi module
  4. Hasil dikirim kembali ke control node
  5. Control node menutup koneksi

Arah komunikasi ini punya implikasi keamanan: managed node tidak perlu akses outbound ke internet atau ke control node secara aktif. Cukup pastikan control node bisa menjangkau managed node via SSH.


Satu Control Node, Banyak Managed Node #

Satu control node bisa mengelola ratusan bahkan ribuan managed node. Ansible mengelola konkurensi ini dengan parameter forks — jumlah managed node yang dieksekusi secara paralel.

# ansible.cfg — mengatur parallelisme
[defaults]
forks = 20  # Ansible akan mengeksekusi 20 managed node secara bersamaan
Eksekusi dengan forks = 5, target = 10 server:

Batch 1 (paralel): web-01, web-02, web-03, web-04, web-05
                   ↓ selesai
Batch 2 (paralel): web-06, web-07, web-08, web-09, web-10

Nilai default forks adalah 5. Untuk infrastruktur besar, nilai ini perlu disesuaikan dengan kapasitas jaringan dan control node.


Managed Node yang Didukung #

Ansible bisa mengelola berbagai jenis sistem, tidak terbatas pada Linux:

Sistem Operasi:
  ✓ Linux (Ubuntu, Debian, RHEL, CentOS, Fedora, dll)
  ✓ macOS
  ✓ Windows (menggunakan WinRM atau OpenSSH, bukan SSH biasa)
  ✓ FreeBSD dan Unix lainnya

Network Devices:
  ✓ Cisco IOS, NX-OS
  ✓ Juniper JunOS
  ✓ Arista EOS
  ✓ Dan banyak lainnya via Ansible Collections

Cloud & Containers:
  ✓ AWS, GCP, Azure (via API, bukan SSH)
  ✓ Docker containers
  ✓ Kubernetes (via API)
Untuk managed node Windows, Ansible tidak menggunakan SSH secara default — melainkan WinRM (Windows Remote Management) atau OpenSSH for Windows. Konfigurasinya berbeda dari node Linux.

Struktur Umum dalam Produksi #

Di lingkungan produksi, lazim untuk menggunakan server khusus sebagai control node — sering disebut sebagai Ansible control machine atau automation server.

Infrastruktur Produksi Umum:

  ┌──────────────────────────────┐
  │   CI/CD Server               │
  │   (Jenkins / GitLab CI)      │
  │         │                    │
  │         ▼                    │
  │   Ansible Control Node ──────┼──── SSH ──► Production Servers
  │   (automation server)        │
  └──────────────────────────────┘

Playbook disimpan di Git → CI/CD trigger → Ansible menjalankan playbook

Pendekatan ini memisahkan concern dengan jelas: developer push kode ke Git, CI/CD pipeline yang memutuskan kapan deployment dilakukan, Ansible yang mengeksekusi perubahan ke server.


Ringkasan #

  • Control node adalah mesin tempat Ansible terinstal dan dijalankan — bisa laptop, server CI/CD, atau VM khusus.
  • Managed node adalah server yang dikelola — hanya butuh SSH dan Python, tidak perlu Ansible terinstal.
  • Komunikasi selalu dari control node ke managed node, tidak pernah sebaliknya.
  • Windows tidak didukung sebagai control node secara native — gunakan WSL.
  • Satu control node bisa mengelola ratusan managed node secara paralel menggunakan pengaturan forks.
  • Di produksi, control node biasanya diintegrasikan dengan CI/CD pipeline untuk otomasi deployment yang konsisten.

← Sebelumnya: Agentless   Berikutnya: Inventory →

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