Belajar Ansible - Network Automation dengan Ansible

#Pendahuluan

Setelah di episode 21 sebelumnya kita membahas advanced inventory management dan dynamic inventory — dari plugin cloud provider hingga integrasi CMDB seperti NetBox dan ServiceNow — pada episode kali ini kita akan mengarahkan Ansible ke salah satu segmen infrastruktur yang paling sering diabaikan dalam dunia automasi: perangkat jaringan (network devices).

Kalian mungkin berpikir, "automasi itu urusan server, bukan urusan switch dan router." Kenyataannya, justru di sinilah automasi memberikan dampak paling besar dan paling cepat terasa. Bayangkan sebuah tim network engineer harus menambah VLAN baru ke 40 switch akses secara serentak. Melalui SSH manual ke 40 perangkat, mengetikkan perintah yang sama berulang kali, sambil berharap tidak ada satu pun yang typo — itu bisa menghabiskan setengah hari kerja, bahkan lebih jika ada perbedaan konfigurasi antar perangkat. Satu kesalahan ketik di perangkat ke-23 bisa membuat segmen jaringan down dan menghadirkan panggilan darurat di tengah malam.

Ansible mengubah pekerjaan itu menjadi satu playbook yang dijalankan sekali dan menyebar ke seluruh perangkat secara paralel. Ditambah konsep idempotency yang sudah kita kenal sejak awal, kalian bisa mendorong konfigurasi yang sama berulang kali tanpa efek samping. Pada episode ini kita akan membahas mengapa Ansible cocok untuk network automation, collection dan modul jaringan yang tersedia, tiga jenis koneksi (network_cli, httpapi, netconf), serta studi kasus nyata: backup running-config otomatis, deploy VLAN dan ACL, hingga templating konfigurasi untuk banyak switch sekaligus.

#Pembahasan Utama

#Mengapa Ansible Cocok untuk Network Automation?

Ada alasan kuat mengapa Ansible menjadi standar de facto untuk network automation:

• Agentless — sama seperti server, Ansible tidak perlu menginstall agent di perangkat jaringan. Cukup akses SSH atau API yang memang sudah ada. Ini penting karena mayoritas perangkat jaringan tidak bisa dipasangi agent sembarangan.
• Satu bahasa, banyak vendor — playbook YAML yang sama bisa dikonfigurasi untuk Cisco, Arista, Juniper, dan lain-lain hanya dengan mengganti collection dan ansible_network_os.
• Idempotent — ios_config hanya mengirim perintah jika konfigurasi belum ada, sehingga tidak ada config bloat dan tidak ada perubahan tak perlu.
• Paralel — forks (episode 15) memungkinkan Ansible mengelola puluhan hingga ratusan perangkat secara paralel.
• Integrasi inventory — dynamic inventory dari episode 21 (NetBox, ServiceNow, atau cloud) bisa langsung menyuplai daftar perangkat jaringan.

Analoginya sederhana: jika server adalah "warga kota" yang perlu diurus satu per satu, maka perangkat jaringan adalah "jembatan dan jalan raya" yang menghubungkan semuanya. Automasi server tanpa automasi jaringan ibarat membangun kota baru tapi tetap membuka-tutup jembatan secara manual.

#Network OS yang Didukung dan Collection Jaringan

Ansible mendukung hampir semua OS jaringan utama melalui model platform modules. Setiap vendor memiliki collection resminya sendiri:

Di luar collection vendor, ada collection ansible.netcommon yang menyediakan common network functionality — helper, filter, dan koneksi dasar yang dipakai lintas platform. Collection ini menjadi dependensi hampir semua collection jaringan, jadi pastikan selalu terpasang:

ansible-galaxy collection install ansible.netcommon cisco.ios arista.eos junipernetworks.junos

#Connection Types: network_cli, httpapi, dan netconf

Ini adalah konsep kunci yang membedakan automasi jaringan dari automasi server. Saat menangani perangkat jaringan, kalian tidak bisa begitu saja memakai koneksi ssh biasa dengan modul command — perangkat punya cara berinteraksi yang berbeda-beda. Ansible menyediakan tiga connection plugin khusus:

Perbedaan ketiganya bisa dilihat dalam satu perbandingan konfigurasi ansible.cfg berikut:

[defaults]
# network_cli: default untuk mayoritas platform
[network_cli:ios]
ansible_connection: network_cli
 
[network_cli:junos]
ansible_connection: netconf
 
[device_httpapi]
ansible_connection: httpapi
ansible_httpapi_use_ssl: true
ansible_httpapi_validate_certs: false

Biasanya koneksi ditentukan di level host/group inventory, bukan di ansible.cfg. Contohnya:

all:
  children:
    core_switches:
      hosts:
        sw-core-01:
          ansible_host: 192.168.1.10
          ansible_user: admin
          ansible_password: "{{ vault_admin_password }}"
          ansible_network_os: ios
          ansible_connection: network_cli
          ansible_become: true
          ansible_become_method: enable
    edge_routers:
      hosts:
        rtr-edge-01:
          ansible_host: 192.168.2.1
          ansible_network_os: iosxe
          ansible_connection: httpapi
          ansible_httpapi_use_ssl: true
          ansible_httpapi_validate_certs: false

Perhatikan variabel ansible_network_os dan ansible_become_method: enable. Untuk sebagian besar perangkat jaringan, mode privileged EXEC diakses dengan perintah enable, bukan sudo seperti di Linux. Inilah alasan mengapa ansible_become_method di-set ke enable.

#Mengumpulkan Fakta Perangkat dengan *_facts

Sama seperti server yang memiliki facts (ansible_facts), perangkat jaringan memiliki facts-nya sendiri yang diambil oleh modul seperti ios_facts, nxos_facts, atau eos_facts. Facts ini menjadi dasar untuk membuat konfigurasi adaptif — misalnya mengetahui versi IOS sebelum memutuskan perintah mana yang aman dipakai.

Playbook berikut mengambil facts dari semua perangkat Cisco di group all:

- name: Kumpulkan facts dari seluruh perangkat Cisco
  hosts: all
  gather_facts: false
  tasks:
    - name: Ambil facts IOS
      cisco.ios.ios_facts:
        gather_subset: all
 
    - name: Tampilkan ringkasan facts
      ansible.builtin.debug:
        msg: >
          Hostname: {{ ansible_net_hostname }}
          Platform: {{ ansible_net_version }}
          Serial: {{ ansible_net_serialnum }}
          Model: {{ ansible_net_model }}

Output ringkas yang muncul per perangkat kira-kira seperti ini:

TASK [Tampilkan ringkasan facts]
ok: [sw-core-01] => {
    "msg": "Hostname: sw-core-01 Platform: 15.2(4)E9 Serial: FCW2139G0XW Model: WS-C2960X-48TS"
}
ok: [sw-access-07] => {
    "msg": "Hostname: sw-access-07 Platform: 15.2(2)E5 Serial: FOC1750Z2GD Model: WS-C2960+48TC"
}

#Deploy Konfigurasi dengan ios_config

Modul *_config adalah jantung network configuration management. Modul ini menerima daftar perintah yang sedikit demi sedikit (disebut lines) dan menempatkannya di bawah sebuah parent context. Yang membuatnya unik dibanding sekadar mengirim perintah mentah adalah mekanisme idempotency: Ansible hanya mengirim perintah yang belum ada di perangkat.

Contoh klasik: menambah VLAN ke beberapa switch sekaligus.

- name: Deploy VLAN ke seluruh switch akses
  hosts: switches
  gather_facts: false
  tasks:
    - name: Buat VLAN 100 dan 200
      cisco.ios.ios_config:
        lines:
          - vlan 100
          - name VLAN_DATA
          - vlan 200
          - name VLAN_VOIP
        save_when: modified

Setelah konfigurasi berhasil diubah, save_when: modified akan menulis konfigurasi ke NVRAM sehingga perubahan tetap bertahan setelah reboot — setara dengan mengetik write memory di CLI.

Mengelola ACL juga mudah. Contoh berikut menerapkan ACL inbound di interface GigabitEthernet0/1 untuk membatasi akses SSH hanya dari network management:

- name: Terapkan ACL untuk interface management
  hosts: core_switches
  gather_facts: false
  tasks:
    - name: Buat ACL 101
      cisco.ios.ios_config:
        lines:
          - permit tcp host 10.10.10.10 any eq 22
          - permit tcp host 10.10.10.11 any eq 22
          - deny ip any any log
        parents: ip access-list extended MGMT-SSH
 
    - name: Terapkan ACL di interface
      cisco.ios.ios_config:
        lines:
          - ip access-group MGMT-SSH in
        parents: interface GigabitEthernet0/1
        before: no ip access-group MGMT-SSH in
        save_when: modified

Perhatikan keyword before: no ip access-group MGMT-SSH in. Ini mencegah ACL ter-tumpuk dua kali ketika perintah dijalankan berulang. Pola "hapus dulu, lalu terapkan" adalah trik idempotency yang sangat berguna untuk perintah yang bisa menerima duplikasi.

#Templating Konfigurasi untuk Banyak Perangkat

Salah satu kekuatan terbesar network automation adalah templating: satu file template Jinja2 (ingat episode 8) yang diisi nilai berbeda-beda per perangkat. Bayangkan kalian punya 40 switch akses dan setiap switch punya nomor VLAN trunk yang hampir sama, hanya beda beberapa detail. Dengan template, kalian cukup mendefinisikan sekali:

!
interface {{ interface }}
  description {{ interface_desc }}
  switchport mode trunk
  switchport trunk allowed vlan {{ trunk_vlans }}
  switchport trunk native vlan {{ native_vlan }}

Lalu playbook berikut me-render template dan mengirimkannya ke masing-masing switch, dengan nilai variabel dari host_vars setiap perangkat:

- name: Deploy konfigurasi trunk berbasis template
  hosts: switches
  gather_facts: false
  tasks:
    - name: Render template dan terapkan ke perangkat
      cisco.ios.ios_config:
        src: templates/vlan_trunk.j2
        save_when: modified

Isi variabel interface, trunk_vlans, dan native_vlan diambil dari host_vars masing-masing switch. Hasilnya: satu playbook, satu template, 40 perangkat dengan konfigurasi yang konsisten namun tetap unik sesuai kebutuhan masing-masing.

#Backup Running-Config Secara Otomatis

Kehilangan konfigurasi perangkat jaringan tanpa backup adalah mimpi buruk — perangkat baru yang salah konfigurasi saja bisa memutus jaringan, apalagi harus restore dari nol. Ansible bisa mengotomasi backup running-config setiap perangkat ke control node. Modul *_config menyediakan parameter backup yang menyimpan konfigurasi saat ini ke file ber-timestamp:

- name: Backup running-config seluruh perangkat
  hosts: all
  gather_facts: false
  tasks:
    - name: Ambil backup running-config
      cisco.ios.ios_config:
        backup: true
        backup_options:
          filename: "{{ ansible_host }}.cfg"
          dir_path: backups/

Menjalankan playbook ini akan menghasilkan struktur file backup di control node:

bash

backups/
├── 2026-08-02T14-30-05/
│   ├── 192.168.1.10.cfg
│   ├── 192.168.1.11.cfg
│   └── 192.168.2.1.cfg

#Manajemen Routing

Routing configuration juga sepenuhnya bisa diotomasi. Contoh berikut menambahkan route statis dan mengaktifkan OSPF pada perangkat Cisco:

- name: Konfigurasi routing
  hosts: edge_routers
  gather_facts: false
  tasks:
    - name: Tambah route statis
      cisco.ios.ios_config:
        lines:
          - ip route 10.20.0.0 255.255.0.0 192.168.2.254
        save_when: modified
 
    - name: Aktifkan OSPF di area 0
      cisco.ios.ios_config:
        lines:
          - network 192.168.2.0 0.0.0.255 area 0
          - network 192.168.1.0 0.0.0.255 area 0
        parents: router ospf 1
        save_when: modified

Modul *_config dengan parents memungkinkan kalian menembus beberapa level context sekaligus — persis seperti mengetik configure terminal lalu router ospf 1 secara manual, tapi otomatis dan aman.

#Kesalahan Umum (Common Pitfalls)

1. Menggunakan koneksi ssh dan modul command biasa

Ini kesalahan paling fatal. Perangkat jaringan tidak mengikuti cara kerja modul ansible.builtin.command yang mengirim perintah dan membaca exit code. Gunakan modul khusus (ios_config, ios_facts, dst.) dan connection network_cli/httpapi/netconf.

2. Lupa ansible_become_method: enable

Di perangkat Cisco, command EXEC privileged butuh perintah enable. Tanpa ansible_become: true dan ansible_become_method: enable, task akan gagal karena perintah ditolak oleh mode user EXEC.

3. Tidak memakai save_when: modified

Konfigurasi yang berhasil diterapkan di memory akan hilang saat perangkat reboot jika tidak disimpan. Selalu gunakan save_when: modified agar perubahan di-persist ke NVRAM (kecuali memang tidak diinginkan).

4. Salah menentukan ansible_network_os

Setiap platform harus memakai ansible_network_os yang benar (ios untuk Cisco IOS, nxos untuk NX-OS, junos untuk Juniper, dst.). Nilai yang salah akan membuat Ansible menggunakan modul yang keliru dan berpotensi mengirim perintah yang tidak dimengerti perangkat.

5. Overwriting konfigurasi tanpa parents atau before

Mengirim perintah tanpa context yang benar bisa mengganti seluruh konfigurasi interface secara tidak sengaja. Gunakan parents untuk menargetkan context, dan before untuk operasi idempotent seperti penghapusan duplikasi.

6. Mengabaikan backup

Jangan pernah men-deploy konfigurasi besar tanpa backup terlebih dahulu. Jadikan backup: true sebagai kebiasaan, atau jalankan playbook backup sebagai langkah pertama dalam pipeline network change management.

#Penutup

Pada episode ini kita telah membahas network automation dengan Ansible secara menyeluruh: alasan mengapa Ansible menjadi pilihan utama untuk perangkat jaringan, koleksi dan modul untuk berbagai vendor (Cisco IOS/NX-OS, Arista EOS, Juniper Junos), tiga jenis koneksi network_cli, httpapi, dan netconf, manajemen VLAN, ACL, routing, deploy konfigurasi berbasis template ke banyak switch sekaligus, serta backup running-config otomatis. Kita juga telah mengidentifikasi kesalahan umum yang sering membuat playbook jaringan gagal.

Dengan kemampuan ini, kalian telah melengkapi satu lagi dimensi penting dari automasi infrastruktur: dari server Linux, cloud, hingga perangkat jaringan yang menjadi tulang punggung komunikasi data. Sebuah skill langka yang sangat dihargai di industri, karena engineer yang bisa menjembatani DevOps dan networking masih jarang.

Di episode 23 selanjutnya, kita akan masuk ke era modern aplikasi: Kubernetes & Container Orchestration — mengelola container dan cluster Kubernetes menggunakan collection kubernetes.core dan community.docker, mulai dari modul k8s untuk Deployment dan Service, deployment Helm chart, hingga manajemen Docker container dan image secara terprogram. Pastikan tetap semangat!