Memperbarui kontainer tanpa downtime

Memperbarui container bukan berarti “tarik image baru”, melainkan “ganti versi yang sedang berjalan dengan versi baru dan tetap bisa rollback.” Perbedaannya baru terlihat sekali: saat versi baru gagal dijalankan.

Prosedur yang berhasil

cd /opt/myapp
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f --tail 100

Compose hanya membuat ulang service yang image-nya berubah dan membiarkan sisanya. Downtime hanya beberapa detik yang dibutuhkan untuk me-restart container.

Namun sebelum melakukannya, penuhi dua syarat.

Pertama: versi dipatok. File harus menentukan postgres:17.2, bukan postgres:latest. Jika tidak, suatu hari pull akan membawa versi major yang menulis ulang format data, dan rollback menjadi mustahil.

Kedua: backup masih baru. Pembaruan yang merusak database merusaknya secara permanen. Sebelum pergantian versi major, lakukan dump — lihat apa yang perlu di-backup.

Mengganti tanpa jeda

Untuk layanan web di belakang reverse proxy, downtime turun hampir ke nol jika container memiliki health check: proxy baru akan mulai mengirim permintaan ke instance yang sudah siap.

services:
  app:
    image: ghcr.io/example/app:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 5s
      timeout: 3s
      retries: 6
      start_period: 20s

docker inspect -f '{{.State.Health.Status}}' <container>

Tanpa health check, Compose menganggap container siap begitu prosesnya berjalan — padahal aplikasi masih membaca pengaturannya dan menerapkan migrasi.

Jangan hapus image lama sampai versi baru berjalan setidaknya satu jam. Rollback berarti memulihkan image: ...:1.4.2 dan menjalankan docker compose up -d, tetapi hanya selama image lama masih ada di disk. docker image prune -a tepat setelah pembaruan menghilangkan opsi itu dari Anda.

Rollback

sed -i 's|app:1.5.0|app:1.4.2|' compose.yaml
docker compose up -d app
docker compose logs -f --tail 50 app

Jika versi baru sudah mengubah skema database, rollback image saja tidak cukup — Anda perlu memulihkan dari backup. Itulah sebabnya pembaruan major dilakukan pada waktu sepi dan dengan backup yang sudah diverifikasi: lihat latihan restore.

Otomatisasi: berhati-hatilah

Watchtower dapat memperbarui container sendiri. Untuk layanan rumahan itu praktis; untuk produksi itu berisiko: pembaruan datang pada malam hari, merusak database, dan tidak ada yang menyadarinya. Kompromi yang wajar adalah notifikasi saja:

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --monitor-only --schedule "0 0 6 * * *"

Anda tahu bahwa versi baru telah rilis dan memperbaruinya secara manual pada waktu yang Anda pilih.

Me-reboot mesin

Paket sistem diperbarui terpisah dari container. Setelah pembaruan kernel Anda perlu reboot, dan container dengan restart: unless-stopped akan menyala kembali sendiri. Uji ini terlebih dahulu — dengan sudo reboot pada waktu sepi, bukan saat insiden. Reboot lunak dari panel berfungsi selama qemu-guest-agent terpasang di sistem.

Kesalahan umum

• pull tanpa up -d. Image baru sudah diunduh, tetapi container lama masih berjalan.
• Disk penuh dengan image lama. Jalankan docker image prune sebulan sekali — tetapi jangan tepat setelah pembaruan. Lihat ruang disk.
• Anda memperbarui semuanya sekaligus. Ada yang rusak — dan Anda tidak bisa menentukan apa. Perbarui satu service setiap kali.
• Anda tidak membaca catatan rilis. File konfigurasi yang tidak kompatibel adalah penyebab kegagalan paling umum setelah pergantian versi major; lihat penjelasannya di masalah Docker umum.