Docker Restart Policy: Cara Mengelakkan Container Tidak Hidup Semula Selepas Reboot

Server Maintenance, Web Hosting, Web Security 0 Comments

Apa Itu Docker Restart Policy dan Mengapa Ia Penting?

Bayangkan anda baru sahaja selesai melakukan konfigurasi pelayan yang kompleks, menjalankan beberapa container Docker untuk aplikasi web, dan kemudian tiba-tiba berlaku gangguan elektrik atau sistem mengalami reboot secara automatik. Apabila pelayan kembali hidup, anda dapati semua servis anda tidak berjalan. Anda terpaksa log masuk melalui SSH dan menjalankan arahan docker start satu per satu untuk setiap container. Situasi ini bukan sahaja membuang masa, malah boleh menyebabkan downtime yang lama bagi pengguna akhir.

Di sinilah docker restart policy memainkan peranan yang sangat kritikal. Secara ringkas, ia adalah satu set arahan yang kita berikan kepada Docker Daemon untuk menentukan sama ada sesuatu container perlu dihidupkan semula secara automatik apabila ia terhenti, mengalami ralat, atau apabila sistem hos reboot. Tanpa polisi yang betul, container anda akan kekal dalam status Exited sehingga ada manusia yang menggerakkannya secara manual.

Bagi mereka yang menguruskan infrastruktur dalam skala produksi, bergantung kepada proses manual adalah satu risiko besar. Penggunaan polisi restart yang tepat memastikan ketersediaan aplikasi (high availability) sentiasa terjaga tanpa memerlukan pemantauan 24 jam daripada pihak pentadbir sistem.

Memahami Jenis-Jenis Docker Restart Policy

Docker menyediakan beberapa pilihan polisi yang boleh disesuaikan mengikut keperluan aplikasi anda. Tidak semua container memerlukan polisi yang sama. Sebagai contoh, container untuk database memerlukan kestabilan yang berbeza berbanding container untuk skrip migrasi data yang hanya perlu berjalan sekali sahaja.

Berikut adalah perincian lengkap mengenai pilihan yang ada dalam docker restart policy:

1. No (Default)

Ini adalah tetapan lalai (default) bagi setiap container. Docker tidak akan menghidupkan semula container secara automatik tidak kira apa pun sebab ia terhenti. Jika anda menjalankan container dengan docker run tanpa menyatakan polisi restart, maka no adalah apa yang digunakan.

Ini sangat berguna untuk tugas-tugas berbentuk one-off tasks atau skrip pembersihan yang hanya perlu berjalan sekali dan kemudian tamat.

2. On-Failure

Polisi ini lebih spesifik. Docker hanya akan menghidupkan semula container jika ia terhenti disebabkan oleh ralat (exit code yang bukan 0). Jika anda menghentikan container secara manual menggunakan arahan docker stop, Docker tidak akan menghidupkan semula container tersebut.

Anda boleh mengehadkan jumlah percubaan restart dengan menambah parameter max-retry. Contohnya, jika anda menetapkan on-failure:5, Docker akan cuba menghidupkan semula container sebanyak 5 kali sebelum ia menyerah kalah dan membiarkannya terhenti.

3. Always

Ini adalah pilihan yang paling agresif. Docker akan sentiasa menghidupkan semula container tidak kira apa pun status keluarannya. Sama ada ia terhenti kerana ralat, terhenti secara normal, atau apabila pelayan reboot, Docker akan memastikan container tersebut sentiasa berjalan.

Satu perkara penting tentang polisi always ialah jika anda menghentikan container secara manual, ia tetap akan dihidupkan semula apabila Docker Daemon dimulakan semula (reboot).

4. Unless-Stopped

Polisi ini hampir sama dengan always, tetapi dengan satu perbezaan besar. Jika anda menghentikan container secara manual menggunakan docker stop, Docker tidak akan menghidupkan semula container tersebut secara automatik apabila sistem reboot.

Ini adalah pilihan yang paling disyorkan untuk kebanyakan aplikasi produksi kerana ia menghormati keputusan pentadbir sistem yang sengaja menghentikan servis tersebut untuk tujuan penyelenggaraan.

Polisi	Reboot Sistem	Exit Code 0 (Normal)	Exit Code Non-Zero (Error)	Manual Stop
no	Tidak	Tidak	Tidak	Tidak
on-failure	Tidak	Tidak	Ya	Tidak
always	Ya	Ya	Ya	Ya (selepas reboot)
unless-stopped	Ya	Ya	Ya	Tidak

Cara Implementasi Docker Restart Policy

Terdapat dua cara utama untuk menetapkan polisi ini, iaitu semasa anda mencipta container pertama kali atau mengemaskini container yang sudah sedia ada.

Menggunakan Docker Run

Apabila anda menjalankan container menggunakan CLI, anda boleh menambah flag --restart. Berikut adalah beberapa contoh penggunaan:

Untuk database (PostgreSQL/MySQL):
docker run -d --name db-prod --restart unless-stopped postgres
Untuk skrip backup yang mungkin gagal:
docker run -d --name backup-job --restart on-failure:3 alpine backup-script.sh
Untuk web server yang kritikal:
docker run -d --name web-app --restart always nginx

Menggunakan Docker Compose

Dalam fail docker-compose.yml, anda hanya perlu menambah kunci restart di bawah servis yang berkenaan. Ini adalah cara yang lebih kemas dan mudah diuruskan untuk projek berskala besar.

services:
  web:
    image: nginx:latest
    restart: unless-stopped
    ports:
      - "80:80"
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password

Mengemaskini Container yang Sedang Berjalan

Jika anda terlupa menetapkan polisi semasa docker run, anda tidak perlu memadam dan mencipta semula container tersebut. Anda boleh menggunakan arahan docker update.

Contoh arahan:
docker update --restart unless-stopped nama_container_anda

Ini sangat berguna jika anda menguruskan website maintenance packages dan perlu memastikan semua container klien tidak terhenti selepas kemaskini kernel pelayan.

Kesilapan Biasa dalam Pengurusan Restart Policy

Ramai pengguna baru Docker terjebak dengan beberapa isu lazim yang menyebabkan mereka keliru mengapa container mereka berkelakuan pelik.

Terperangkap dalam “Restart Loop”

Ini adalah mimpi ngeri bagi setiap developer. Bayangkan anda mempunyai container yang mempunyai ralat konfigurasi yang serius. Setiap kali ia bermula, ia akan crash dalam masa 2 saat. Jika anda menggunakan restart: always, Docker akan terus cuba menghidupkan semula container tersebut setiap 2 saat.

Ini akan menyebabkan penggunaan CPU melonjak tinggi dan log pelayan anda dipenuhi dengan mesej ralat yang sama berulang kali. Dalam situasi ini, polisi on-failure dengan had max-retry adalah lebih selamat.

Menganggap ‘Always’ adalah Penyelesaian Segala Masalah

Ada kecenderungan untuk menetapkan semua container kepada always supaya “senang”. Namun, ini berbahaya. Jika anda mempunyai container yang melakukan migrasi database, anda tidak mahu ia berjalan semula secara automatik selepas selesai. Jika ia restart, ia mungkin cuba menjalankan migrasi yang sama berulang kali dan boleh merosakkan integriti data anda.

Mengabaikan Log Apabila Container Restart

Apabila container hidup semula secara automatik, anda mungkin tidak perasan bahawa ia sebenarnya pernah crash. Jika anda tidak memantau log, anda mungkin terlepas pandang isu memori (Out of Memory – OOM) yang berlaku secara berkala. Sentiasa gunakan docker logs untuk menyiasat mengapa restart berlaku.

Tip Pro: Gunakan alat pemantauan seperti Prometheus atau Grafana untuk menerima alert apabila container mengalami restart yang tidak normal, bukannya bergantung sepenuhnya kepada automasi Docker.

Syor Penggunaan untuk Persekitaran Produksi

Bagi anda yang menguruskan pelayan menggunakan web hosting Malaysia, kestabilan adalah kunci utama. Berikut adalah strategi yang saya syorkan berdasarkan pengalaman menguruskan pelbagai aplikasi:

Aplikasi Web/API: Gunakan unless-stopped. Ini memastikan aplikasi anda hidup selepas reboot pelayan, tetapi memberi anda kawalan penuh untuk mematikan servis semasa proses deployment atau debugging.
Database (MySQL, MongoDB, Redis): Gunakan always. Database biasanya adalah jantung kepada aplikasi. Kegagalan database untuk hidup semula akan menyebabkan keseluruhan sistem lumpuh.
Worker/Queue Process (Celery, RabbitMQ): Gunakan on-failure. Jika worker crash kerana bug dalam kod, restart berterusan tanpa pembaikan kod hanya akan membebankan queue.
Cron Jobs/Task Runners: Gunakan no. Tugas yang dijadualkan tidak sepatutnya hidup semula secara automatik selepas selesai.

Jika anda masih baru dalam dunia DevOps dan merasa terbeban dengan konfigurasi pelayan, anda boleh mendapatkan bantuan pakar di Ewallz Solutions untuk memastikan infrastruktur anda dioptimumkan.

Kesimpulan

Menguasai docker restart policy adalah langkah penting untuk berubah daripada sekadar menjalankan container kepada menguruskan orkestrasi container yang profesional. Dengan memilih polisi yang tepat, anda bukan sahaja mengurangkan risiko downtime, malah memudahkan urusan penyelenggaraan pelayan dalam jangka masa panjang.

Ingat, jangan gunakan always untuk semua perkara. Fahami sifat aplikasi anda sama ada ia bersifat stateful (seperti database) atau stateless (seperti web server) sebelum menetapkan polisi. Dengan kombinasi unless-stopped untuk servis utama dan on-failure untuk proses sokongan, pelayan anda akan menjadi lebih resilien dan stabil.

Soalan Lazim (FAQ)

1. Apakah perbezaan utama antara ‘always’ dan ‘unless-stopped’?

Perbezaan utamanya adalah apabila container dihentikan secara manual menggunakan docker stop. Bagi always, container akan tetap hidup semula selepas Docker Daemon reboot. Bagi unless-stopped, container akan kekal terhenti sehingga anda menghidupkannya semula secara manual.

2. Bolehkah saya menukar polisi restart tanpa memadam container?

Ya, anda boleh menggunakan arahan docker update --restart [POLISI] [NAMA_CONTAINER] untuk mengemaskini polisi restart bagi container yang sedang berjalan tanpa perlu menciptanya semula.

3. Mengapa container saya terus-menerus restart (boot loop)?

Ini biasanya berlaku apabila aplikasi di dalam container mengalami ralat kritikal sebaik sahaja ia bermula (seperti fail konfigurasi hilang atau port sudah digunakan). Kerana polisi restart aktif, Docker cuba menghidupkannya semula, tetapi ia crash lagi, menyebabkan kitaran berterusan.

4. Adakah Docker Compose menyokong semua polisi restart yang sama dengan Docker CLI?

Ya, semua pilihan seperti no, on-failure, always, dan unless-stopped boleh digunakan dalam fail docker-compose.yml di bawah bahagian servis.

5. Adakah restart policy mempengaruhi prestasi pelayan?

Secara umumnya tidak. Namun, jika terdapat banyak container yang mengalami “restart loop” secara serentak, ia boleh menyebabkan penggunaan CPU dan I/O disk meningkat secara mendadak, yang akhirnya boleh memperlahankan keseluruhan pelayan.