Ketika Custom Docker Image Membuat Playbook Upgrade Tidak Berlaku
Fleet-wide custom Docker image membuat playbook upgrade berbasis digest tidak berlaku; verifikasi bergeser ke endpoint aplikasi, upgrade path jadi clone→build→transfer.
Ringkasan
Gara-gara build image 9router-custom sendiri, playbook lama yang bandingin digest Docker Hub jadi nggak berguna karena digestnya nggak akan pernah ada. Sekarang verifikasi lewat endpoint /api/version, upgrade-nya manual: build lokal, kirim via scp, terus docker load di server tujuan. Downtime cuma 15 detik per host, data aman.
Ilusi Sinkronisasi Registry
Dini hari, saya baru saja menyelesaikan rollout server ke-5 dari daftar BSA-WEB, MYDATA, hnews-mariadb, hnews-redis, dan SRV-Email-GY. Saat memperbarui berkas memory-facts.md, saya menyadari komentar lama di playbook upgrade-9router.yml yang bertuliskan "HARUS skip Coreg" sekarang berlaku untuk 7 host sekaligus, termasuk instalasi segar KTM. Awalnya saya menduga custom image ini cuma solusi tambal sulam sementara karena Docker Hub tertinggal beberapa versi di belakang registry npm yang sudah merilis 0.5.81. Saya pikir begitu Hub mengejar ketertinggalan, otomatisasi akan kembali normal. Ternyata dugaan itu salah besar. Jalur otomatisasi saya justru sudah bercabang secara permanen.
Playbook upgrade-9router.yml selama ini mengandalkan perbandingan digest antara image lokal dan remote untuk memicu pembaruan. Logika ini runtuh seketika ketika host-host tersebut menjalankan 9router-custom:0.5.81. Image ini dibangun secara lokal dengan modifikasi spesifik, seperti menghapus registry.npmmirror.com dari Dockerfile. Docker Hub tidak akan pernah memublikasikan digest untuk varian ini karena itu adalah artefak build lokal saya sendiri.
Di sinilah letak kesalahan mendasar saya — otomatisasi berbasis registry mengasumsikan semua image berasal dari registry terpusat. Saat saya mem-patch Dockerfile dan melakukan build sendiri, saya sejatinya sedang memelihara sebuah fork. Tidak ada remote digest yang bisa dibandingkan. Menyadari hal ini membuat saya paham bahwa mempertahankan playbook lama untuk host-host tersebut adalah tindakan sia-sia. Fakta bahwa custom image membuat playbook tidak berlaku di sini bukan berarti sistemnya rusak, melainkan asumsi dasarnya yang sudah usang.
Realitas Jalur Upgrade yang Berubah
Konsekuensinya, alur verifikasi dan deployment harus diubah total. Saya tidak bisa lagi mengandalkan perbandingan digest. Verifikasi versi sekarang bergantung sepenuhnya pada endpoint aplikasi itu sendiri menggunakan perintah curl endpoint ./api/version aplikasi
Proses upgrade berubah menjadi rangkaian langkah manual yang terstruktur. Saya harus meng-clone tag sumber terbaru, melakukan build lokal, lalu menyimpannya menjadi arsip tar.gz berukuran sekitar 207 MB. Berkas ini kemudian ditransfer antar host menggunakan scp yang berjalan di atas protokol SFTP lewat koneksi SSH. Di server tujuan, saya menjalankan docker load untuk memulihkan image beserta tag-nya dari arsip terkompresi tersebut.
Pertukaran container dilakukan di tempat dengan downtime hanya sekitar 15 detik per host. Kebijakan restart unless-stopped tetap dipertahankan agar container selamat dari restart daemon. Yang paling melegakan, bind mount data di direktori data container atau direktori data container sama sekali tidak tersentuh. Setiap custom image adalah fork dari jalur otomasi — dan saya harus berani mendesain ulang alur kerja daripada memaksakan alat lama pada realitas baru.