Belajar Network Engineer - Ansible untuk Network

#Pendahuluan

Setelah di episode 12 kalian bisa mengotomasi perangkat dengan Python, muncul masalah skala: sepuluh script milik tiga engineer dengan gaya berbeda adalah beban baru. Di sinilah Ansible masuk — kerangka otomasi yang menyamakan cara tim mendefinisikan state: apa yang harus ada, bukan langkah demi langkah bagaimana membuatnya.

Mengapa network engineer wajib bisa Ansible di 2026? Karena ia menjadi standar de facto otomasi jaringan multi-vendor: agentless, YAML yang mudah dibaca reviewer non-programmer, dan modul resmi untuk Cisco/Arista/Juniper/Fortinet.

#Model Ansible: Agentless dan Idempotent

Dua kata kunci yang membedakannya dari script Python biasa:

• Agentless: tidak ada daemon terinstall di switch/router; control node menjalankan semuanya lewat SSH (atau API). Perangkat lama pun bisa ikut.
• Idempotent: playbook yang sama dijalankan berkali-kali menghasilkan state akhir yang sama. Jika VLAN 40 sudah ada, Ansible tidak "membuat lagi" — ia melaporkan ok, bukan changed. Inilah fondasi aman untuk eksekusi berulang.

Struktur proyek minimal:

net-ansible/
├── ansible.cfg          # konfigurasi global
├── inventory/hosts.yml  # daftar perangkat + grup
├── group_vars/all.yml   # variabel bersama
└── playbooks/
    └── baseline.yml     # kebijakan standar

#Inventory: Peta Perangkat Kalian

Inventory adalah sumber kebenaran tentang perangkat apa saja yang dikelola — format YAML-nya:

all:
  children:
    distribution:
      hosts:
        dist-sw1: { ansible_host: 192.168.99.11 }
        dist-sw2: { ansible_host: 192.168.99.12 }
    access:
      hosts:
        acc-lt1: { ansible_host: 192.168.99.21 }
        acc-lt2: { ansible_host: 192.168.99.22 }

Grup inilah kekuatannya: satu playbook bisa menarget access: saja atau semua. Variabel per-grup/per-host hidup di group_vars/host_vars — misal NTP server beda antara pusat dan cabang tanpa menulis dua playbook.

Untuk platform jaringan, deklarasikan koneksi di group_vars:

ansible_connection: ansible.netcommon.network_cli
ansible_network_os: cisco.ios.ios
ansible_user: "{{ vault_net_user }}"
ansible_password: "{{ vault_net_pass }}"

#Playbook Pertama: Baseline NTP + VLAN

Kebijakan klasik yang selalu butuh diterapkan massal: pastikan semua switch punya NTP dan VLAN standar:

---
- name: Baseline konfigurasi switch
  hosts: all
  gather_facts: false
  tasks:
    - name: Pastikan NTP server terpasang
      cisco.ios.ios_config:
        lines:
          - ntp server 10.0.99.10 prefer
          - ntp server 10.0.99.11
 
    - name: Pastikan VLAN standar ada
      cisco.ios.ios_vlans:
        config:
          - { vlan_id: 30, name: GUEST }
          - { vlan_id: 35, name: IOT }
          - { vlan_id: 99, name: MANAGEMENT }
        state: merged

Jalankan bertahap seperti profesional:

ansible-playbook playbooks/baseline.yml --limit access --check --diff
# review output diff... yakin? baru apply sungguhan:
ansible-playbook playbooks/baseline.yml --limit access

--check (dry-run) + --diff menampilkan baris konfigurasi apa yang akan berubah — padanan compare_config NAPALM, tapi bawaan framework. Jalankan kedua playbook itu dua kali: run kedua harusnya semua ok, nol changed. Itulah idempotensi yang bisa kalian buktikan.

#Template Jinja2: Konfigurasi dari Data

Keajaiban sesungguhnya muncul saat konfigurasi dirender dari data. Template interface uplink:

{% for intf in uplinks %}
interface {{ intf.name }}
 description {{ intf.desc }}
 switchport mode trunk
 switchport trunk allowed vlan {{ intf.vlans | join(',') }}
{% endfor %}

Data per host di host_vars/acc-lt1.yml:

uplinks:
  - { name: gi1/0/47, desc: DIST-SW1, vlans: [10, 20, 30, 99] }
  - { name: gi1/0/48, desc: DIST-SW2, vlans: [10, 20, 30, 99] }

Task merender dan menerapkannya:

- name: Render & apply uplink config
  cisco.ios.ios_config:
    src: templates/uplink.j2

Konsekuensinya besar: menambah cabang = menambah data, bukan menulis konfigurasi baru. Desain episode 25 nanti praktis lahir dari struktur data ini.

#Ansible Vault: Kredensial Aman Bersama

Tim butuh berbagi playbook TANPA berbagi password plaintext di git. Jawabannya vault:

ansible-vault create group_vars/all/vault.yml
# isi: vault_net_user: netadmin
#       vault_net_pass: S3cr3t!
ansible-playbook playbooks/baseline.yml --ask-vault-pass

Isi vault terenkripsi AES, tetap bisa di-commit ke repo secara aman. Pasangkan disiplinnya: file vault tidak pernah di-decrypt ke layar di ruangan ramai, passphrase tersimpan di password manager tim.

#Ke Mana Setelah Ini

Ansible membuka rantai NetDevOps penuh: playbook dipicu otomatis dari Git (CI), hasil validasi dicatat, rollback jadi re-run versi sebelumnya. Untuk eksplorasi lanjutan setelah series ini: collections lain (cisco.iosxr, junipernetworks.junos, fortinet.fortios), role untuk struktur besar, AWX/AAP sebagai portal eksekusi tim, plus integrasi testing dengan Batfish/pyATS.

#Common Pitfalls

• Menarget all saat uji — typo target mengirim eksperimen ke seluruh jaringan; biasakan --limit sejak lab.
• Lupa gather_facts: false — fakta gathering default men-target sistem Linux dan hanya membuang waktu di perangkat jaringan.
• Hardcode nilai di task — IP/NTP/VLAN tertanam dalam logika; pindahkan ke vars agar playbook reusable lintas site.
• Vault passphrase di repo — enkripsi yang dikunci dengan kunci yang sama tempatnya; simpan passphrase di manager terpisah.

#Penutup

Inti yang harus dibawa pulang:

• Ansible = agentless + idempotent: state didefinisikan sekali, eksekusi berulang tetap aman.
• Inventory + group_vars/host_vars mengubah daftar perangkat menjadi data yang bisa ditarget presisi.
• Workflow profesional: --limit → --check --diff → review PR → apply → verifikasi.
• Jinja2 template memisahkan desain (template) dari data (vars); vault melindungi rahasia bersama.

Di episode 14 kita angkat perspektifnya: SDN dan intent-based networking — pemisahan control/data plane, peran controller, OpenFlow sampai NETCONF/YANG, serta bagaimana "intent" mengubah cara kita mendeklarasikan jaringan. Sampai jumpa!