Mendaftarkan KTM: Ketika Server Ke-10 Justru Membongkar Ilusi Otomatisasi
Server ke-10 fleet bongkar ilusi otomatisasi: SSH MaxAuthTries terbakar, cloud-init timpa hardening, node_exporter nggak ter-deploy. Pelajaran: fleet discipline berarti pipeline idempoten, bukan manual one-off.
Ringkasan
Tambah server ke-10 gagal karena SSH MaxAuthTries 6 habis dipakai kunci salah urutannya, plus cloud-init override PasswordAuthentication lewat file drop-in yang menang leksikal. Server baru juga nggak pasang node_exporter jadi monitoring buta. Pelajarannya: playbook harus idempoten kelola config cloud-init eksplisit, jangan asumsikan rollout lama pasti jalan.
Momen IP Baru di Inventory
Saya masih ingat persis momen ketika alamat IP 157.245.192.183 muncul di file hosts.yml. Commit 668f0ed di repositori server-old mendokumentasikan momen saat saya harus daftarkan KTM sebagai server ke-10 fleet. Awalnya saya cuma berpikir, "Tinggal jalankan playbook Ansible, beres." Saya kira rollover konfigurasi bakal mulus seperti sembilan server sebelumnya. Ternyata, tebakan itu meleset total.
Alih-alih sukses, dashboard Prometheus langsung merah karena scrape error. Log SSH juga menunjukkan kegagalan otentikasi bertubi-tubi. Server baru ini nggak punya node_exporter — dan yang lebih parah, PasswordAuthentication masih aktif meski saya merasa udah mengunci semua akses.
Jebakan Lexical Order dan MaxAuthTries
Masalah pertama muncul saat saya coba masuk lewat SSH. Kunci ed25519 saya ditolak, dan koneksi langsung putus. Saya awalnya mengira kunci publiknya belum tercopy. Padahal, masalahnya ada pada batas percobaan.
OpenSSH punya mekanisme MaxAuthTries yang default-nya 6 percobaan per koneksi (sshd_config(5)). Setiap kunci yang ditawarkan dan ditolak bakal membakar satu slot percobaan. Karena urutan kunci di agen SSH saya nggak sesuai, kunci yang salah diajukan lebih dulu. Hal ini menghabiskan jatah percobaan sebelum kunci yang benar sempat diverifikasi.
Saya sadar bahwa hardening SSH bukan sekadar mematikan PasswordAuthentication di file utama sshd_config.
Ilusi Konfigurasi Utama yang Tertimpa
Di sinilah letak kesalahan fatal saya. Saya mengira mengubah sshd_config udah cukup. Fakta di lapangan menunjukkan bahwa cloud-init sering kali menempatkan file 50-cloud-init.conf di direktori /etc/ssh/sshd_config.d/ yang berisi PasswordAuthentication yes.
Konfigurasi bawaan ini secara efektif menimpa pengaturan utama saya karena aturan first obtained value wins dan Include globs diproses leksikal (sshd_config(5)). File dengan awalan angka lebih tinggi bakal menang. Jadi, upaya hardening saya kalah telak oleh konfigurasi cloud provider. Saya harus memaksa Ansible untuk mengelola file drop-in tersebut secara eksplisit.
Monitoring Gap: Sembilan Server Lancar, Sepuluh Gak Ada
Belum lagi, server baru ini sama sekali nggak punya agen monitoring. Node Exporter adalah agen standar untuk mengumpulkan metrik hardware dan OS-level dari server Linux, mengekspos CPU, memori, disk, network, dan filesystem dalam format Prometheus [1]. Setiap server yang mau dipantau butuh Node Exporter jalan, yang bikin dia kandidat sempurna untuk otomatisasi Ansible.
Karena rollout sebelumnya dilakukan manual untuk beberapa node, server ini luput dari radar.
Disiplin Fleet yang Sebenarnya
Insiden ini memaksa saya mengubah pola pikir. Menambahkan node baru bukan cuma soal nambah satu baris IP. Ini tentang memastikan seluruh pipeline rollout bersifat idempoten. Saya merevisi playbook Ansible agar peran monitoring dan hardening SSH diterapkan seragam. Termasuk menghapus atau menimpa file konfigurasi cloud-init yang bandel itu.
Ke depannya, saya nggak bakal lagi mengandalkan asumsi "playbook lama pasti jalan". Setiap server baru adalah ujian nyata bagi ketahanan arsitektur otomatisasi yang saya bangun. Jika rollout masih butuh intervensi manual atau fire drill, berarti sistemnya belum matang. Otomatisasi yang sejati justru terlihat ketika penambahan server ke-11 besok pagi berjalan tanpa saya perlu menyentuh keyboard sama sekali.