Perubahan Image Bitnami: Cara Migrasi Docker dan Helm

Masih ada image: bitnami/postgresql:16 di file compose kamu, atau chart Helm dari Bitnami di cluster? Kalau iya, image itu kemungkinan besar sudah tidak menerima pembaruan keamanan, bahkan bisa gagal ditarik saat server baru dibuat. Penyebabnya adalah perubahan katalog Bitnami yang diumumkan pertengahan 2025.

Intinya, Bitnami (milik Broadcom) memindahkan image lama ke repositori arsip bitnamilegacy dan hanya menyisakan sebagian kecil image gratis. Artikel ini menjelaskan apa yang berubah menurut pengumuman resmi di GitHub, lalu memberi langkah mengaudit dan memindahkan workload kamu.

Apa yang sebenarnya berubah di katalog Bitnami?

Pengumuman resmi di repositori bitnami/containers (issue #83267, dibuka 16 Juli 2025) merinci perubahannya:

• Mulai 28 Agustus 2025, katalog publik beralih ke subset terbatas "community tier". Pembuatan image berbasis Debian dihentikan, dan image yang ada dipindah bertahap ke repositori legacy.
• Image gratis yang tersisa berada di bitnamisecure, lebih diperkeras, tapi hanya tag latest dan ditujukan untuk pengembangan.
• Image yang ada, termasuk tag versi, dipindah ke bitnamilegacy. Di sana image tidak mendapat pembaruan maupun dukungan, dan pengumuman menyebutnya sebagai cadangan sementara untuk migrasi.
• Penghapusan katalog lama di docker.io/bitnami sempat diundur dan dijadwalkan pada 29 September 2025. Sebelumnya ada beberapa "brownout", yaitu jendela waktu (24 sampai 48 jam) ketika sekelompok image sengaja tidak tersedia.
• Chart yang sudah dikemas tetap ada di docker.io/bitnamicharts tapi tidak diperbarui, dan bisa gagal dipasang kecuali image bawaannya diganti. Kode sumber chart di GitHub tetap berlisensi Apache 2.0.
• Untuk produksi, Bitnami mengarahkan pengguna ke Bitnami Secure Images, layanan komersial.

Sealed Secrets, charts-syncer, dan minideb disebut tidak terdampak.

Langkah mengaudit dan bermigrasi

Langkah 1. Temukan semua referensi Bitnami

Mulai dari kode dan konfigurasi:

grep -rnE "bitnami(charts)?/" --include="*.yml" --include="*.yaml" --include="Dockerfile*" .

Lalu cek apa yang benar-benar berjalan. Di server Docker:

docker ps --format '{{.Image}}' | grep bitnami

Di Kubernetes:

kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep bitnami | sort -u
helm list -A

Perintah helm list membantu melihat release yang berasal dari chart Bitnami. Jangan lupa Dockerfile yang memakai FROM bitnami/... sebagai image dasar.

Langkah 2. Kelompokkan berdasarkan risiko

Buat daftar sederhana: image apa, dipakai di mana, menyimpan data atau tidak. Database dan message broker (PostgreSQL, MySQL, MariaDB, Redis, RabbitMQ, MongoDB) adalah prioritas, karena migrasinya menyangkut data. Image tanpa data, seperti Nginx atau alat CLI, biasanya cukup diganti dan di-deploy ulang.

Langkah 3. Pasang jembatan sementara bila perlu

Kalau ada layanan yang harus tetap jalan sementara kamu menyiapkan pengganti, arahkan ke bitnamilegacy. Untuk compose, ubah bitnami/postgresql:16 menjadi bitnamilegacy/postgresql:16. Untuk Helm, pengumuman resmi mencontohkan:

helm upgrade nama-release <chart> --version <versi-sama> \
  --set image.repository=bitnamilegacy/postgresql \
  --set global.security.allowInsecureImages=true

Gunakan grep pada README chart untuk menemukan semua parameter repository yang perlu ditimpa, termasuk image pendamping seperti metrics exporter. Ingat, ini hanya jembatan. Image di bitnamilegacy tidak akan ditambal bila ada celah baru.

Langkah 4. Pilih pengganti

Ada empat arah utama:

Tidak ada satu jawaban untuk semua. Tim kecil sering memilih image resmi untuk Docker Compose, dan operator untuk database di Kubernetes.

Langkah 5. Petakan konfigurasi sebelum mengganti

Ini bagian yang paling sering membuat migrasi gagal. Image Bitnami punya konvensinya sendiri: variabel environment berawalan nama aplikasi (misalnya POSTGRESQL_PASSWORD), data disimpan di bawah /bitnami/, dan proses berjalan sebagai user non-root dengan UID 1001. Image resmi biasanya memakai nama variabel lain (misalnya POSTGRES_PASSWORD untuk image postgres) dan path data yang berbeda.

Baca dokumentasi image pengganti, lalu tulis tabel pemetaan: variabel lama ke variabel baru, path volume lama ke path baru, dan UID pemilik file.

Langkah 6. Pindahkan data dengan dump, bukan menyambung volume

Menyambungkan volume lama ke image baru memang terlihat cepat, tapi rawan masalah izin file dan struktur folder. Untuk database, cara yang lebih aman adalah dump dari container lama lalu restore ke container baru. Contoh untuk PostgreSQL:

docker exec db-lama pg_dumpall -U postgres > semua.sql
docker exec -i db-baru psql -U postgres < semua.sql

Biasakan juga backup terjadwal setelah migrasi selesai, seperti di backup database otomatis.

Langkah 7. Kunci versi dan pantau pembaruan

Setelah pindah, tulis tag versi yang jelas (misalnya postgres:17), bukan latest, agar deploy bisa diulang dengan hasil sama. Lalu pasang pengingat pembaruan, misalnya Renovate atau Dependabot di repositori, supaya kamu tahu saat ada versi baru tanpa harus memeriksa manual.

Bagaimana dengan Dockerfile yang memakai Bitnami sebagai dasar?

Ganti FROM ke image dasar resmi bahasa atau runtime yang kamu pakai, lalu sesuaikan langkah build. Perhatikan perbedaan user: banyak image resmi berjalan sebagai root secara bawaan, jadi tambahkan instruksi USER bila aplikasi sebelumnya mengandalkan user non-root ala Bitnami. Dasar membangun image ada di apa itu Docker.

Checklist migrasi:

• Semua referensi bitnami/ dan bitnamicharts/ sudah ditemukan, termasuk di Dockerfile dan CI
• Layanan berdata diberi prioritas
• Jembatan bitnamilegacy punya tenggat penghapusan
• Pemetaan variabel, path data, dan UID sudah ditulis
• Data dipindah lewat dump dan restore, lalu diverifikasi
• Versi image dikunci dan pengingat pembaruan aktif