Siklus Hidup Container

Container yang sudah dibuat tidak selamanya berada di satu status. Sepanjang masa hidupnya, container bisa dinyalakan, dihentikan sementara, dihentikan penuh, dinyalakan ulang otomatis lewat restart policy, sampai akhirnya dihapus saat sudah tidak dibutuhkan. Sysadmin/DevOps Engineer yang mengelola container di production wajib paham detail setiap transisi ini, karena cara menghentikan container yang keliru bisa memicu data corruption pada aplikasi stateful, sementara restart policy yang salah pilih bisa membuat container yang seharusnya mati justru terus dinyalakan ulang tanpa henti. Developer sehari-hari juga perlu tahu cara membersihkan container bekas testing supaya disk mesin development tidak penuh oleh sampah container yang menumpuk. Bab ini membahas cara menghentikan dan menyalakan container dengan aman, mekanisme pause/unpause, cara menghapus container beserta variasinya, pilihan restart policy yang tersedia, dan strategi cleanup container di level operasional.

9.1 Starting dan Stopping Container

Menghentikan container terdengar sederhana, tapi ada perbedaan besar antara menghentikan container secara graceful (memberi kesempatan aplikasi menutup diri dengan rapi) dan menghentikan secara paksa. Perbedaan ini penting terutama untuk aplikasi yang sedang memproses transaksi database, menulis file, atau memegang koneksi network yang butuh ditutup dengan benar sebelum proses berhenti.

9.1.1 Docker Stop dan Sinyal Terminasi

Perintah docker stop menghentikan container secara graceful dengan mengirim sinyal SIGTERM ke proses utama (PID 1) di dalam container, memberi kesempatan aplikasi menangkap sinyal tersebut dan membersihkan diri (menutup koneksi database, menyelesaikan request yang sedang berjalan, menulis file yang masih di buffer) sebelum benar-benar berhenti. Siapkan container contoh untuk dipraktikkan.

docker run -d --name demo-app nginx:1.27

Hentikan container dengan docker stop.

docker stop demo-app

Kalau proses utama tidak kunjung berhenti dalam rentang waktu tertentu setelah menerima SIGTERM, Docker daemon otomatis mengirim SIGKILL yang langsung mematikan proses tanpa ampun. Rentang waktu tunggu ini defaultnya 10 detik untuk container Linux dan 30 detik untuk container Windows, kalau tidak dikonfigurasi lain. Ubah rentang waktu tunggu ini lewat opsi --timeout saat container butuh waktu lebih lama untuk shutdown dengan rapi, misalnya aplikasi yang sedang menyelesaikan job antrean panjang.

docker start demo-app
docker stop --timeout 30 demo-app

Opsi --timeout ini menggantikan opsi lama --time (disingkat -t) yang sudah deprecated sejak Docker Engine versi 28.0, meski --time masih berfungsi untuk kompatibilitas ke belakang. Kalau container butuh sinyal terminasi selain SIGTERM, misalnya aplikasi yang cuma merespons SIGINT, tentukan lewat opsi --signal pada docker stop, atau tetapkan permanen di image lewat instruksi STOPSIGNAL pada Dockerfile.

docker stop --signal SIGINT demo-app

9.1.2 Docker Kill dan Menyalakan Ulang Container

Untuk kasus darurat yang butuh container berhenti seketika tanpa proses graceful shutdown sama sekali, gunakan docker kill yang langsung mengirim SIGKILL (atau sinyal lain lewat opsi --signal) tanpa masa tunggu.

docker start demo-app
docker kill demo-app

Di lapangan, docker kill baru dipakai kalau docker stop gagal atau container benar-benar perlu dihentikan sesegera mungkin, misalnya saat container tersebut menyebabkan resource host melonjak tak terkendali. Untuk kondisi normal, selalu utamakan docker stop supaya aplikasi di dalamnya sempat membersihkan diri. Menyalakan kembali container yang sudah berhenti (baik lewat stop maupun kill) cukup lewat docker start, tanpa perlu membuat container baru.

docker start demo-app
docker ps --filter name=demo-app

Satu pitfall yang sering menjebak Developer: docker start menyalakan kembali container dengan konfigurasi yang persis sama seperti saat pertama kali dibuat lewat docker run atau docker create, termasuk port mapping dan environment variable-nya. Kalau ingin mengubah konfigurasi tersebut, container lama harus dihapus dulu dan dibuat ulang dengan opsi baru; docker start saja tidak bisa mengubah konfigurasi container yang sudah ada.

9.2 Pausing dan Unpausing

Selain berhenti total, container juga bisa dibekukan sementara tanpa benar-benar menghentikan prosesnya. Kondisi ini berguna saat kita perlu "membekukan" sebuah container sesaat, misalnya untuk mengambil snapshot kondisi filesystem-nya tanpa gangguan proses yang terus menulis data, tanpa harus kehilangan state di memori seperti yang terjadi kalau container dihentikan penuh.

Perintah docker pause membekukan seluruh proses di dalam container memakai cgroup freezer milik kernel Linux, sebuah mekanisme yang menghentikan sementara penjadwalan proses tanpa mengirim sinyal apa pun ke proses tersebut. Karena tidak ada sinyal yang dikirim, aplikasi di dalam container tidak sadar sedang dibekukan, jadi state di memorinya tetap utuh persis seperti sebelum dibekukan.

docker run -d --name demo-pause nginx:1.27
docker pause demo-pause

Cek status container yang sedang dibekukan lewat docker ps; kolom STATUS menampilkan keterangan (Paused) di belakang durasi berjalannya.

docker ps --filter name=demo-pause

CONTAINER ID   IMAGE         STATUS
8f3a1b2c4d5e   nginx:1.27    Up 2 minutes (Paused)

Selama dibekukan, container tidak merespons request apa pun, termasuk percobaan docker exec ke dalamnya, karena seluruh proses di dalamnya memang sedang tidak dijadwalkan CPU sama sekali. Kembalikan container ke kondisi berjalan normal lewat docker unpause.

docker unpause demo-pause

Di lapangan, docker pause jarang dipakai untuk operasional harian karena efeknya membekukan seluruh proses tanpa terkecuali, cukup ekstrem dibanding docker stop yang masih memberi kesempatan aplikasi merespons. Kegunaan paling umum docker pause justru di sisi Developer atau tooling otomatis, misalnya untuk menghentikan sementara container saat resource host sedang dibutuhkan proses lain yang lebih prioritas, tanpa kehilangan state container yang sedang dibekukan itu.

Bersihkan container contoh sebelum lanjut ke sub-bab berikutnya.

docker rm -f demo-app demo-pause

9.3 Removing Container

Container yang sudah berhenti tidak otomatis hilang dari sistem, kecuali memang dijalankan dengan opsi --rm sejak awal. Writable layer milik container yang sudah berhenti tetap tersimpan di disk host dan tetap memakan ruang, sehingga penghapusan container yang sudah tidak dipakai jadi bagian rutin dari operasional Docker.

9.3.1 Docker RM dan Variasinya

Perintah dasar docker rm menghapus satu atau lebih container sekaligus, tapi hanya berhasil pada container yang statusnya sudah berhenti.

docker create --name demo-rm-1 alpine sleep 300
docker create --name demo-rm-2 alpine sleep 300
docker rm demo-rm-1 demo-rm-2

Coba hapus container yang masih berjalan tanpa opsi tambahan untuk melihat perilaku error-nya.

docker run -d --name demo-rm-running nginx:1.27
docker rm demo-rm-running

Docker menolak dengan pesan Error response from daemon: cannot remove container "/demo-rm-running": container is running: stop the container before removing or force remove. Ini pengaman supaya kita tidak sengaja menghapus container yang sedang aktif melayani traffic. Untuk memaksa penghapusan container yang masih berjalan sekaligus, tambahkan opsi -f (--force), yang secara internal mengirim SIGKILL ke container sebelum menghapusnya.

docker rm -f demo-rm-running

Karena docker rm -f memakai SIGKILL, bukan SIGTERM seperti docker stop, aplikasi di dalam container tidak sempat sama sekali membersihkan diri sebelum dimatikan. Di production, hindari kebiasaan langsung memakai docker rm -f pada container yang sedang melayani traffic aktif; lakukan docker stop terlebih dulu supaya aplikasi sempat menutup koneksi dan menyelesaikan request yang sedang berjalan, baru kemudian docker rm tanpa paksaan.

Container yang dibuat dengan anonymous volume (volume tanpa nama eksplisit) meninggalkan volume tersebut tetap ada di disk meski containernya sudah dihapus, kecuali ditambahkan opsi -v pada docker rm untuk ikut menghapus volume anonim yang terhubung ke container tersebut.

docker run -d --name demo-rm-vol -v /data nginx:1.27
docker rm -fv demo-rm-vol

Opsi -v ini hanya menghapus volume anonim, bukan named volume. Kalau container memakai named volume, volume tersebut tetap aman tersimpan meski container dan opsi -v dipakai bersamaan, karena named volume memang dirancang untuk bertahan lepas dari siklus hidup container mana pun yang memakainya.

9.3.2 Menghapus Banyak Container Sekaligus

Untuk menghapus banyak container berstatus berhenti sekaligus, kombinasikan docker rm dengan docker ps -aq yang mengeluarkan daftar ID container. Filter --filter status=exited memastikan hanya container yang sudah berhenti yang ikut terjaring.

docker rm $(docker ps -aq --filter status=exited)

Cara ini cukup umum dipakai, tapi lebih aman dan lebih ringkas memakai docker container prune yang dibahas di sub-bab cleanup. Perintah manual di atas tetap berguna kalau kita perlu kombinasi filter yang lebih spesifik, misalnya menghapus container berstatus berhenti dari image tertentu saja.

9.4 Container Restart Policies

Restart policy adalah aturan yang menentukan apakah Docker daemon harus otomatis menyalakan ulang container ketika container tersebut berhenti, baik karena proses di dalamnya keluar sendiri, mengalami crash, maupun karena Docker daemon di-restart. Restart policy jadi andalan utama Sysadmin/DevOps Engineer supaya service penting di production tetap menyala kembali otomatis tanpa perlu campur tangan manual setiap kali terjadi crash.

9.4.1 Pilihan Restart Policy

Docker menyediakan empat pilihan restart policy yang ditentukan lewat opsi --restart pada docker run.

Terapkan restart policy saat membuat container baru lewat opsi --restart.

docker run -d --name demo-restart --restart on-failure:3 alpine sh -c "exit 1"

Cek riwayat restart yang terjadi lewat docker inspect, yang menampilkan jumlah percobaan restart pada field RestartCount.

docker inspect --format '{{.RestartCount}}' demo-restart

Untuk container yang sudah telanjur berjalan tanpa restart policy atau perlu diganti kebijakannya, gunakan docker update tanpa perlu membuat ulang container dari awal.

docker run -d --name demo-web nginx:1.27
docker update --restart unless-stopped demo-web

9.4.2 Pitfall Restart Policy di Production

Satu pitfall yang sering menjebak Sysadmin/DevOps Engineer di lapangan: memakai always pada container yang sebenarnya sedang dalam kondisi crash loop (terus gagal start karena konfigurasi salah) justru membuat Docker terus-menerus mencoba menyalakannya ulang tanpa henti, membebani resource host dan mempersulit proses debugging karena log terus berganti setiap kali container di-restart. Untuk service yang rawan crash loop akibat kesalahan konfigurasi, on-failure dengan max-retries yang wajar (misalnya 5) lebih aman ketimbang always tanpa batas, karena memberi jeda alami untuk mendeteksi masalah sebelum resource host ikut terganggu.

Restart policy juga tidak berlaku untuk container yang dihentikan lewat docker kill atau docker stop secara manual oleh kita sendiri, kecuali policy-nya always dan daemon Docker sempat direstart setelahnya. Perilaku ini disengaja, supaya Sysadmin/DevOps Engineer tetap punya kendali penuh untuk mematikan container secara sengaja tanpa restart policy langsung menyalakannya lagi.

9.5 Container Cleanup

Container yang menumpuk tanpa dibersihkan lambat laun memenuhi disk host, terutama di mesin development yang setiap hari membuat container baru untuk testing. Docker menyediakan beberapa cara membersihkan container bekas secara aman dan terkontrol.

9.5.1 Docker Container Prune

Perintah docker container prune menghapus semua container berstatus berhenti sekaligus, jauh lebih ringkas dibanding menyusun perintah manual dengan docker ps -aq.

docker container prune

WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
7a1b2c3d4e5fbb1a1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b

Total reclaimed space: 12.4MB

Docker meminta konfirmasi terlebih dulu karena perintah ini bersifat destruktif dan tidak bisa dibatalkan; container yang sudah dihapus lewat prune tidak bisa dikembalikan lagi. Untuk skenario otomatis seperti skrip CI yang tidak bisa menunggu input interaktif, tambahkan opsi -f (--force) supaya prompt konfirmasi dilewati.

docker container prune -f

Opsi --filter mempersempit cakupan container yang ikut dihapus, misalnya hanya container berhenti yang sudah dibuat lebih dari 24 jam lalu, supaya container yang baru saja berhenti (mungkin masih dibutuhkan untuk debugging) tidak ikut terhapus.

docker container prune --filter "until=24h" -f

Filter label juga berguna untuk membatasi prune hanya pada container dengan label tertentu, misalnya container hasil testing yang sengaja diberi label khusus supaya mudah dibedakan dari container penting lainnya.

docker container prune --filter "label=env=testing" -f

9.5.2 Docker System Prune

Kalau cleanup yang dibutuhkan lebih menyeluruh, bukan cuma container, docker system prune sekaligus menghapus seluruh container berhenti, network yang tidak dipakai container mana pun, dangling image (image tanpa tag yang tidak lagi direferensikan), dan build cache yang menganggur.

docker system prune

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - unused build cache

Are you sure you want to continue? [y/N] y

Perlu dicatat, docker system prune secara default tidak menghapus volume sama sekali, sehingga data yang tersimpan di named volume maupun anonymous volume tetap aman. Menambahkan opsi --volumes hanya ikut menghapus anonymous volume yang tidak dipakai container mana pun; named volume tetap aman tersimpan meski opsi ini dipakai.

docker system prune --volumes -f

Untuk menghapus named volume yang sudah tidak dipakai, gunakan perintah terpisah docker volume prune. Secara default docker volume prune pun hanya menyasar anonymous volume; named volume yang tidak terhubung ke container mana pun baru ikut terhapus kalau ditambahkan opsi --all.

docker volume prune --all -f

Trustworthiness soal perintah ini penting ditekankan: docker volume prune --all berpotensi menghapus data permanen kalau ada named volume berisi data penting yang kebetulan sudah tidak terhubung ke container mana pun, misalnya container yang memakainya sudah keburu dihapus lebih dulu tanpa disengaja. Volume memang sengaja tidak pernah dihapus otomatis oleh Docker justru untuk mencegah risiko kehilangan data semacam ini. Sebelum menjalankan docker volume prune --all di server production, selalu cek dulu daftar volume yang ada lewat docker volume ls dan pastikan tidak ada data penting yang masih dibutuhkan.

Di lapangan, Sysadmin/DevOps Engineer biasanya menjadwalkan docker system prune -f (tanpa --volumes) secara berkala lewat cron job pada server dengan traffic build image yang tinggi, supaya disk tidak cepat penuh oleh dangling image dan build cache yang menumpuk setiap hari, sambil tetap menjaga volume data tetap aman dari penghapusan otomatis.