Container State

Semua kunci pada Chapter Kunci compose.yaml mendeskripsikan container yang ideal — tetapi begitu stack menyala, Docker terus-menerus melaporkan keadaan sungguhan setiap container, dan laporan itu datang dalam tiga bahasa: state di docker inspect, wajah pada kolom STATUS di docker ps, dan exit code saat sebuah container berhenti. Ketiganya saling melengkapi dan sudah kita pakai bergantian sejak Chapter Lifecycle Container sampai Mengatasi Container Crash. Chapter ini menyatukan ketiga bahasa tersebut menjadi tiga tabel rujukan — tujuh state resmi, tujuh exit code, dan sebelas varian kolom STATUS — supaya satu pandangan cepat cukup untuk membaca apa pun yang sedang terjadi pada container kita.

Tujuh State Container #

Peta lima state besar dari Chapter Lifecycle Container berdiri di atas state resmi yang dilaporkan daemon, dan daemon mengenal tujuh di antaranya — lima yang sering kita singgahi ditambah dua state sesaat yang hanya terlihat pada momen tertentu. Tabel berikut memetakan semuanya beserta perintah yang menjadi pintu masuk dan pintu keluarnya:

Dua state yang paling sering tertukar adalah Paused dan Exited, padahal keduanya berbeda secara fundamental. Container Paused masih memegang seluruh memorinya: prosesnya hidup, socket dan koneksi terbuka tetap terbuka, dan docker unpause melanjutkan eksekusi persis dari titik pembekuan — freezer cgroup hanya menahan jatah waktu CPU, bukan membunuh prosesnya. Container Exited kebalikannya: prosesnya sudah mati, memori sudah dibebaskan ke kernel, dan docker start menjalankan ulang ENTRYPOINT dari baris pertama — kelanjutan, bukan kelanjutan yang sama.

State Restarting adalah jeda di antara dua kebangkitan, dan panjangnya mengikuti pola backoff kebijakan restart dari Chapter *Restart Policy`: jeda percobaan ulang dimulai dari 100 milidetik lalu berlipat ganda pada setiap kegagalan berikutnya. Pola inilah yang membuat crash loop terlihat seperti denyut yang makin jarang — container mati, menyala lagi setelah 100 ms, mati lagi, menyala setelah 200 ms, dan seterusnya sampai kebijakan menyerah atau kegagalan hilang.

Tujuh Exit Code yang Paling Sering Muncul #

Saat container berhenti, berita kematiannya dirangkum dalam satu angka: exit code dari PID 1. Konvensinya dua lapis — aplikasi melaporkan keberhasilan dengan 0 dan kegagalannya dengan kode nonzero pilihannya, sedangkan Docker dan kernel melaporkan kematian paksa dengan rumus 128 + nomor sinyal, konvensi yang kita bedah pada Chapter Memahami Exit Code:

Dua alat membaca angka ini secara langsung. docker wait memblokir terminal sampai container berhenti lalu mencetak exit code-nya; docker inspect membacanya kapan saja dari field .State.ExitCode dan .State.OOMKilled — pasangan yang kita gunakan untuk mengotopsi container lapar:

$ docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' lapar

Output yang Dihasilkan:

137 true

Mari kita telaah kedua nilai pada output tersebut:

1. 137 — container mati oleh SIGKILL; angka ini sendiri belum membedakan docker kill dari OOM kill, karena keduanya berakhir pada sinyal yang sama.
2. true pada .OOMKilled — pembedanya ada di sini: kernel mencatat bahwa proses ini dibunuh karena melampaui batas memori cgroup, warisan eksperimen limit 512 MB pada Chapter CPU dan Memory Limit.

Sebelas Wajah Kolom STATUS #

Kolom STATUS pada docker ps menggabungkan state, exit code, dan hasil healthcheck ke dalam satu wajah ringkas. Satu cuplikan output memperlihatkan beberapa wajah sekaligus:

$ docker ps -a

Output yang Dihasilkan:

CONTAINER ID   IMAGE                COMMAND                  CREATED          STATUS                    PORTS                    NAMES
f7c2a91b3e55   nginx:1.29-alpine    "/docker-entrypoint.…"   5 minutes ago    Up 5 minutes               0.0.0.0:8080->80/tcp     web
c4d8e1f3a7b2   postgres:18-alpine   "docker-entrypoint.s…"   5 minutes ago    Up 5 minutes (healthy)    5432/tcp                 db-katalog
e3a9c210d5f4   redis:7-alpine       "docker-entrypoint.s…"   2 minutes ago    Up 2 minutes (Paused)                              cache
468fa01723fb   nginx                "/docker-entrypoint.…"   10 minutes ago   Exited (0) 2 minutes ago                           siklus
b2d4f6a8c0e1   myapp:dev            "node server.js"         3 minutes ago    Restarting (1) 3 seconds ago                        api-kecil
...

Mari kita telaah tiga baris yang paling banyak bercerita:

1. (healthy) pada db-katalog — healthcheck image postgres menjawab lulus; status ini yang menjadi gerbang service_healthy pada Compose.
2. (Paused) pada cache — anotasi di dalam kurung menempel pada Up, artinya proses masih hidup namun dibekukan.
3. Restarting (1) pada api-kecil — angka dalam kurung adalah exit code kegagalan terakhir; aplikasi keluar kode 1 dan sedang menunggu jeda backoff.

Sebelas varian berikut menutup hampir seluruh wajah yang akan kita jumpai sehari-hari:

Cara membaca angka dalam kurung mengikuti satu aturan: angka adalah exit code terakhir dari PID 1, sedangkan teks adalah anotasi keadaan. Exited (0) dan Restarting (1) sama-sama membawa exit code di kurungnya; (Paused), (healthy), dan (unhealthy) membawa nama keadaan. Kombinasi Up plus unhealthy adalah yang paling licik — container menyala sempurna tetapi aplikasinya gagal melayani, kondisi yang kita bedah pada Chapter Container Health dan yang membuat healthcheck begitu berharga di produksi.

State dan status kini punya kamus lengkapnya, tetapi keadaan container hanyalah separuh cerita — container juga selalu tinggal di sebuah jaringan, dan bentuk jaringan itu menentukan siapa yang bisa menjangkaunya. Chapter berikutnya, Network Driver, memetakan enam driver jaringan Docker beserta alamat-alamat istimewa di dalamnya.

Referensi #

• docker ps — referensi kolom STATUS beserta seluruh flag penyaringnya.
• docker wait — memblokir sampai container berhenti dan mencetak exit code.
• Start and stop containers — perilaku stop, kill, dan kebijakan restart secara resmi.