devops

Prometheus TargetDown di server ke-10 fleet: node_exporter nggak ada, Ansible gagal deploy karena SSH MaxAuthTries terbakar oleh urutan kunci ed25519. Fix = hardening SSH dulu (key-only, urutan kunci), baru monitoring — semua idempoten.

TL;DR: Monitor nyala merah alert TargetDown server kesepuluh, kira cuma kurang scrape config tapi SSH gagal total karena node_exporter nggak ada dan Ansible kena batas MaxAuthTries dari terlalu banyak kunci ed25519. Akhirnya benerin urutan playbook: hardening SSH dulu (hanya kunci, urutin biar nggak kebakar limit), baru deploy node_exporter. Sekarang idempoten, server baru jalanin playbook sama aja.

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.

TL;DR: 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.

Gerbang restart: skrip kecil menolak restart kontainer API saat working tree masih kotor.

TL;DR: Penulis kaget skor dashboard jadi minus cuma gara-gara restart kontainer. Ternyata compose pakai bind mount, jadi restart malah menjalankan kode setengah jadi yang ada di disk, bukan dari image. Solusinya, skrip restart sekarang ngecek dulu kalau ansible/web bersih via git status, nolak jalan kalau masih kotor.

Tiap push ke staging bikin deployment preview percuma. Satu blok git.deploymentEnabled di vercel.json cukup buat menutupnya.

TL;DR: Vercel defaultnya deploy semua branch yang di-push, jadi tiap push ke stag bikin preview deployment yang nggak dibutuhin. Solusinya cuma file vercel.json delapan baris pakai git.deploymentEnabled buat matiin deploy stag. Lebih milih ini daripada Ignored Build Step soal script exit codenya gampang kebalik dan bisa bikin deploy mati diam-diam.

Skrip dev saya masih manggil docker-compose di sebelas tempat. Compose v1 ternyata udah EOL sejak Juni 2023, yang jalan di laptop cuma symlink ke v2.

TL;DR: Skrip dev kantor masih manggil docker-compose gaya lama, padahal Compose v1 udah nggak didukung sejak 2023. Laptop aman cuma karena symlink kompatibilitas Docker Desktop, tapi di CI bersih perintah itu bisa langsung mati. Fix-nya gampang banget: ganti strip jadi spasi jadi docker compose, selesai satu commit.

Diff-nya cuma dokumentasi, tapi migrasi deploy Cloudflare Workers ke Vercel tetap terjadi. Kabelnya ada di dashboard Vercel dan settings GitHub, bukan di dalam repo.

TL;DR: Gara-gara satu baris di CLAUDE.md, penulis sadar migrasi dari Cloudflare Workers ke Vercel nggak ninggalin jejak di repo, karena settingnya ada di dashboard, bukan Git. Production branch di Vercel dipilih pas impor dan bisa diatur lewat Branch Tracking, jadi default branch GitHub beda hal. Alur Git tetap sama, tapi env vars mesti didaftarkan ulang dan rollback modelnya tunjuk deployment.

Playbook mitigation berhenti di server kesembilan: journald.conf.d ternyata tidak pernah ada. Satu task file state=directory menutup asumsi itu.

TL;DR: Playbook gagal di server kesembilan karena folder /etc/systemd/journald.conf.d nggak ada; delapan server lain kebetulan punya, jadi lolos terus. Fix-nya simpel banget: tambah satu task file state=directory sebelum task salin, beres. Hasilnya journal turun dari 720M ke 288M, aman di bawah cap 300M.

Reboot satu server produksi itu mudah; yang sulit adalah pagarnya. Pre-flight lock, modul reboot, dan post-check uptime yang berani gagal.

TL;DR: Reboot satu server ternyata bukan cuma manggil modul reboot Ansible; playbook-nya dikasih pagar biar nggak nyasar. Dia nolak jalan kalau unattended-upgrades atau lock apt masih aktif, plus wajib konfirmasi dan --limit satu host biar nggak sembilan server ke-reboot sekaligus. Setelah reboot, uptime dibandingkan sebelum-sesudah buat membuktikan reboot-nya beneran kejadian.

Server internet-facing menumpuk log login gagal tanpa guard. Satu drop-in logrotate, direktif su, dan gerbang logrotate -d menutup masalahnya permanen.

TL;DR: Server yang kena brute-force login bikin btmp dan wtmp bengkak cepat, bisa tembus ratusan MB sebelum rotasi mingguan jalan. Solusinya pasang logrotate dengan weekly plus maxsize 50M biar file besar diputar lebih awal, tambah su root utmp buat hindari error izin direktori. Validasi dulu pakai logrotate -d biar config salah ketahuan sebelum produksi.