3 VPS, 1 Playbook: Cara Mulai Pakai Ansible untuk Server Sendiri

Satu VPS masih bisa diurus dengan ingatan. Dua VPS mulai bikin kita mencatat. Begitu masuk VPS ketiga, keempat, dan kelima, catatan itu berubah jadi pekerjaan penuh: memperbarui paket satu per satu, menyalin konfigurasi nginx yang sama tiga kali, dan berdoa semoga tidak ada server yang terlewat. Di titik inilah ansible untuk VPS masuk sebagai jawaban yang lebih rapi daripada mengetik perintah yang sama berulang-ulang lewat SSH.

Oke, lanjuutt.. Sebelum menulis playbook pertama, ada beberapa hal yang perlu kita pahami dulu, termasuk kenapa Ansible sering lebih cocok untuk pemilik 2-5 VPS daripada solusi yang lebih berat.

Kenapa Ansible Cocok untuk Pemilik Beberapa VPS

Hal paling menyenangkan dari Ansible: tidak ada agent yang perlu dipasang di server. Semua tugas dikirim lewat SSH biasa, memakai Python yang sudah ada di hampir setiap distro Linux. Dokumentasi resmi Ansible menyebutnya sebagai sistem konfigurasi yang bisa dijalankan berulang, dan playbook-nya sebaiknya disimpan di version control.

Ada tiga sifat yang membuatnya nyaman untuk server kecil-kecilan:

Agentless. Tidak ada daemon tambahan yang harus di-monitor, tidak ada port baru yang dibuka, tidak ada memori yang dimakan di VPS 1 GB.
Idempoten. Modul Ansible memeriksa keadaan akhir lebih dulu. Kalau paket sudah terpasang, tugasnya berhenti tanpa mengubah apa pun. Menjalankan playbook yang sama sepuluh kali hasilnya tetap sama.
Terserah kita mau sejauh apa. Mulai dari satu file YAML berisi lima baris tugas, atau langsung pakai role yang bisa dipakai ulang. Tidak ada langkah “setup cluster” yang wajib.

Bandingkan dengan pendekatan skrip bash yang dikirim lewat for loop ke daftar IP: skrip bash akan tetap menjalankan perintah walaupun kondisinya sudah benar, dan tidak punya cara bawaan untuk melaporkan “sudah sesuai” versus “baru diubah”.

Langkah 1 — Pasang ansible-core di Komputer Admin

Kita tidak perlu memasang Ansible di VPS. Cukup di satu komputer yang kita pakai untuk mengurus server, biasanya laptop atau LXC admin.

Paket ansible versi lengkap isinya ratusan collection. Untuk mengurus VPS sendiri, ansible-core sudah cukup dan jauh lebih ringan. Rilis terbaru saat artikel ini ditulis adalah ansible-core 2.22.0 (PyPI, 2 November 2026), dan paket komunitas ansible 14.5.0 menjadi yang terkini dengan core 2.21.

Di Ubuntu atau Debian:


sudo apt update
sudo apt install -y pipx
pipx install --include-deps ansible
ansible --version

Cara paling aman menurut dokumentasi resmi adalah pip, dan pipx membuatnya terisolasi tanpa mengacaukan Python sistem. Kalau lebih suka jalur distro, Ubuntu menyediakan PPA ppa:ansible/ansible, Fedora menyediakan sudo dnf install ansible-core, dan Arch cukup sudo pacman -S ansible-core.

Satu catatan: komputer admin tidak bisa Windows. Ansible hanya jalan sebagai control node di sistem mirip Unix.

Langkah 2 — Susun Inventory

Inventory adalah daftar server yang kita urus. Format paling sederhana adalah INI, dan lokasi bawaannya /etc/ansible/hosts. Namun lebih praktis menyimpannya di folder proyek, misalnya ~/ansible/hosts.


[vps]
srv-web ansible_host=203.0.113.10 ansible_user=deploy
srv-db  ansible_host=203.0.113.11 ansible_user=deploy
srv-app ansible_host=203.0.113.12 ansible_user=deploy

[vps:vars]
ansible_ssh_private_key_file=~/.ssh/id_ed25519_vps

Beberapa hal yang sering terlewat:

Nama host di baris pertama bebas, yang dipakai Ansible untuk koneksi adalah ansible_host. Jadi kita bisa memberi nama srv-web walau DNS-nya belum ada.
Gunakan user non-root. ansible_user=deploy dengan sudo (lewat become) lebih aman daripada login root langsung.
Kunci privat cukup ditulis sekali di bagian :vars. Dokumentasi Ansible mencontohkan variabel ansible_ssh_private_key_file persis untuk kebutuhan ini.

Kalau server sudah punya banyak peran, kelompokkan:


[web]
srv-web

[db]
srv-db

[app]
srv-app

Satu host boleh masuk beberapa grup, dan Ansible hanya memproses satu instance per host. Untuk mengurus seluruh isi grup, cukup sebut namanya di playbook.

Langkah 3 — Bikin ansible.cfg

Daripada mengetik opsi panjang setiap kali, simpan di ansible.cfg sebelah file inventory:


[defaults]
inventory = ./hosts
host_key_checking = True
interpreter_python = auto_silent
callback_result_format = yaml

host_key_checking sengaja dibiarkan True. Banyak tutorial mematikannya supaya tidak repot saat pertama konek, tetapi mematikan pemeriksaan kunci host berarti kita melepas salah satu pertahanan terhadap server palsu di jaringan yang sama. Lebih baik terima kunci fingerprint-nya sekali di awal, lalu biarkan.

Langkah 4 — Uji Koneksi dengan Perintah Ad-hoc

Sebelum menulis playbook, pastikan SSH-nya benar. Ansible punya perintah satu baris (ad-hoc) yang tidak butuh file YAML:


ansible vps -m ansible.builtin.ping

Kalau berhasil, keluarannya seperti ini:


srv-web | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Perhatikan "changed": false. Modul ping Ansible bukan ICMP, ia hanya memastikan bisa login dan menjalankan Python di server. Hasil UNREACHABLE berarti masalah SSH atau kunci, bukan masalah Ansible.

Sekali sudah tersambung, cek fakta server sekaligus:


ansible vps -m ansible.builtin.setup -a "filter=ansible_distribution*"

Ini akan menampilkan distro dan versinya untuk tiap VPS. Berguna saat server kita campuran, misalnya dua Ubuntu 24.04 dan satu Debian 13.

Langkah 5 — Playbook Pertama yang Benar-Benar Berguna

Contoh paling membosankan tapi paling sering dibutuhkan: memastikan paket dasar terpasang dan waktu server sinkron. Simpan sebagai dasar.yml:


---
- name: Paket dasar semua VPS
  hosts: vps
  become: true

  tasks:
    - name: Pastikan paket dasar terpasang
      ansible.builtin.apt:
        name:
          - curl
          - htop
          - chrony
          - unattended-upgrades
        state: present
        update_cache: true

    - name: Pastikan chrony jalan
      ansible.builtin.service:
        name: chrony
        state: started
        enabled: true

    - name: Timezone ke Asia/Jakarta
      community.general.timezone:
        name: Asia/Jakarta

Dua hal yang perlu diperhatikan dari contoh di atas:

Nama modul memakai FQCN (ansible.builtin.apt, bukan apt). Dokumentasi Ansible menyarankan ini sejak 2.10 karena satu nama modul bisa ada di beberapa collection.
Modul timezone ada di collection community.general, bukan di core. Kalau belum terpasang, jalankan ansible-galaxy collection install community.general.

Jalankan dengan:


ansible-playbook dasar.yml

Hasil akhirnya berupa rekap ok, changed, failed, dan unreachable per host. Inilah laporan yang tidak pernah kita dapat dari skrip bash.

Langkah 6 — Selalu Coba `--check` Dulu

Kebiasaan yang menyelamatkan banyak server: jalankan playbook dalam mode check sebelum benar-benar menerapkannya.


ansible-playbook dasar.yml --check --diff

Menurut dokumentasi, --check menjalankan playbook tanpa mengubah apa pun dan hanya melaporkan perubahan yang akan dilakukan, sedangkan --diff menunjukkan beda isi file. Untuk playbook yang menyentuh konfigurasi nginx atau sshd, kombinasi ini wajib.

Ada batasan yang jujur perlu disebut: tidak semua modul mendukung check mode. Modul yang menjalankan perintah shell mentah biasanya akan dilewati dengan status skipped. Jadi --check adalah jaring pengaman, bukan jaminan penuh.

Langkah 7 — Naik ke Role Saat Tugas Mulai Berulang

Begitu playbook satu file sudah berisi 100 baris dan kita mulai menyalin blok yang sama untuk nginx dan PHP, waktunya memecahnya jadi role:


ansible-galaxy init roles/nginx

Perintah ini membuat struktur tasks/, handlers/, templates/, dan defaults/. Setelah itu playbook utama cukup memanggilnya:


- hosts: web
  become: true
  roles:
    - nginx

Jangan buru-buru ke tahap ini. Role yang dibuat sebelum isinya jelas biasanya malah jadi tempat menimbun tugas acak.

Kapan Ansible Bukan Jawaban yang Tepat

Ansible bagus untuk konfigurasi, bukan untuk segalanya. Beberapa kondisi di mana kita sebaiknya berhenti dan memilih alat lain:

Satu VPS saja. Menulis inventory dan playbook untuk satu server biasanya lebih lambat daripada tiga perintah SSH. Kecuali kita memang sedang menyiapkan pola untuk server berikutnya.
Butuh state terus-menerus. Ansible berjalan saat dipanggil, bukan menjaga keadaan. Kalau butuh sesuatu yang mengawasi dan memulihkan kondisi secara berkelanjutan, itu urusan systemd, monitoring, atau orchestrator.
Deploy aplikasi yang berubah tiap commit. Untuk itu pipeline CI/CD lebih pas; Ansible biasanya dipakai menyiapkan servernya, bukan menggantikan deploy harian.
Butuh konkurensi besar dan cepat. Ansible defaultnya berjalan berurutan per batch host. Untuk ratusan host, alat berbasis agent biasanya lebih efisien.

Untuk pemilik 3-5 VPS yang isinya nginx, PHP, PostgreSQL, dan beberapa container Docker, Ansible justru berada di titik manis: ringan, tidak menambah beban server, dan hasilnya bisa dibaca ulang sebagai dokumentasi.

Kesimpulan

Memulai ansible untuk VPS tidak perlu langsung membuat role rapi atau struktur folder sempurna. Cukup empat langkah: pasang ansible-core di komputer admin, tulis inventory berisi IP dan user, uji dengan ansible vps -m ansible.builtin.ping, lalu jalankan satu playbook kecil dengan --check lebih dulu. Setelah itu, setiap penambahan server hanya berarti satu baris baru di inventory, bukan satu sesi SSH lagi.

Yang paling terasa bukan soal kecepatan, melainkan ketenangan: kita tahu server mana yang sudah sesuai dan mana yang belum, tanpa harus mengingat-ingat. Kalau VPS kita sudah lebih dari dua, ini investasi satu sore yang lumayan terbayar. Selamat mencoba, dan mulai dari playbook sekecil mungkin, ya.