Docker Update

Empat chapter pertama section ini memasang angka pada saat container lahir: kuota CPU di CPU Limit dan Reservation, langit-langit memori dan swap di Memory Limit dan Swap, slot proses di PIDs Limit dan Ulimit, dan rem blok di IO dan Block Limit. Di dunia nyata, angka yang benar pagi bisa terbukti salah sore — kampanye diskon mendatangkan trafik yang tidak masuk perkiraan siapa pun, dan batas yang tertera di compose.yaml mendadak terasa seperti baju dua ukuran lebih kecil. Solusi klasiknya menyakitkan: ubah berkas, docker compose up -d, container lama dibuang, container baru dibuat — dan di tengah jam sibuk, pembuangan itu berarti downtime yang tidak direncanakan. Chapter ini memperkenalkan jalur kedua yang dijaga langsung oleh kernel: docker update, perintah yang menulis ulang batas CPU, memori, dan PIDs pada container yang sedang berjalan tanpa menyentuh prosesnya sama sekali — beserta aturan main yang wajib menyertainya tentang drift dari berkas compose, verifikasi lewat inspect dan stats, dan batas jujurnya: apa saja yang bisa diubah, dan apa yang tetap menuntut recreate.

Insiden Backend Sempit di Tengah Kampanye #

Kampanye flash sale toko berjalan dua jam ketika Siti melihat grafik latensi mulai menanjak. Sejak insiden laporan rekap beberapa pekan silam, tim sudah memasang pagar di compose.yaml: cpus: 1.0 dan mem_limit: 256m untuk backend — pagar yang cukup di hari biasa. Foto pertama kerangka diagnosis menunjukkan pagar itu kini justru penjara:

$ docker stats --no-stream toko-backend-1

Output yang Dihasilkan:

CONTAINER ID   NAME             CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O      PIDS
20269502f039   toko-backend-1   92.31%    228.5MiB / 256MiB     89.26%    15.4MB / 18.7MB  4.02MB / 0B    11

Mari kita telaah tiga angka yang sempit itu:

1. CPU 92.31% berarti nyaris satu core penuh terpakai — persentase docker stats dihitung terhadap satu core penuh, sebagaimana kita bedah di chapter Docker Stats; dengan kuota backend hanya satu core, angka ini berarti sisa kepala tinggal 8% sebelum penjadwal mulai me-throttle request di jam tersibuk toko.
2. MEM 89.26% dari 256 MiB — pemakaian 228,5 MiB menyisakan 27 MiB; satu laporan rekap berukuran sedang cukup untuk mengirimkan backend ke tangan OOM killer, drama yang sudah pernah kita bedah di Membaca Container Exit.
3. PIDS 11 masih sehat — jumlah task node stabil, jadi sesak ini murni urusan angka besar, bukan kebocoran thread.

docker update Angka Baru Tanpa Recreate #

Siti membutuhkan ruang napas dalam hitungan menit, bukan jendela maintenance. Perintahnya satu baris:

$ docker update --cpus 2 --memory 512m --memory-swap 1g --pids-limit 300 toko-backend-1

Output yang Dihasilkan:

toko-backend-1

Output sependek itu adalah kabar baiknya. Mari kita telaah apa yang sebenarnya terjadi di balik satu baris nama:

1. Nama container tercetak berarti daemon menerima seluruh perubahan — bila ada nilai yang ditolak, daemon memuntahkan galat dan tidak menerapkan apa pun sebagian.
2. Daemon menulis ulang berkas cgroup container yang sedang berjalan — cpu.max, memory.max, memory.swap.max, dan pids.max ditimpa angka baru persis seperti saat container diciptakan, hanya kali ini tanpa menciptakan apa pun.
3. Perubahan berlaku segera tanpa restart — kernel membaca nilai cgroup pada setiap keputusan penjadwalan dan penghitungan memori berikutnya; proses node tidak putus, koneksi database tidak ter-drop, sesi pengguna yang sedang mengisi keranjang tetap hidup.
4. --memory-swap 1g dengan --memory 512m memberi jatah swap 512 MB — semantik total RAM ditambah swap yang kita bedah tuntas di Memory Limit dan Swap; total napas memori berlipat dari 256 MiB menjadi 1 GiB gabungan.
5. Arah turun perlu kehati-hatian — menaikkan limit aman kapan saja, tetapi menurunkan --memory di bawah pemakaian memori saat ini bisa ditolak runtime; kebijakan menurunkan batas sebaiknya menunggu beban mereda dulu.

Verifikasi Angka Turun ke Dua Tempat #

Perubahan yang tidak diverifikasi masih tergolong hipotesis setengah diuji — kebiasaan dari kerangka lima langkah di Strategi Diagnostik. Dua tempat pemeriksaannya:

$ docker inspect --format '{{.HostConfig.NanoCpus}} {{.HostConfig.Memory}} {{.HostConfig.MemorySwap}} {{.HostConfig.PidsLimit}}' toko-backend-1

Output yang Dihasilkan:

2000000000 536870912 1073741824 300

$ docker stats --no-stream toko-backend-1

Output yang Dihasilkan:

CONTAINER ID   NAME             CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O      PIDS
20269502f039   toko-backend-1   91.8%    229.8MiB / 512MiB     44.88%    15.6MB / 19.0MB  4.09MB / 0B    11

Mari kita telaah dua potret setelah perubahan:

1. Empat angka metadata sesuai pesanan — dua core (2000000000 nanodetik), 512 MiB RAM, total swap 1 GiB, dan 300 slot PIDs; docker update mengubah metadata konfigurasi container seakan-akan angka itu dipasang sejak awal.
2. MEM USAGE / LIMIT kini membaca 512MiB — pemakaian nyaris tidak berubah (229,8 MiB), tetapi langit-langitnya naik dua kali lipat; persentase anjlok dari 89% ke 45% — ruang napas memori kembali.
3. CPU% masih berkisar 92% — dan itu justru kabar baik — persentase tetap dihitung terhadap satu core penuh sesuai konvensi chapter Docker Stats, jadi angka pemakaian tidak turun dengan sendirinya; yang berubah adalah plafonnya: 92% dulu berarti sisa kepala hanya 8% dari kuota satu core, kini 92% berarti belum separuh dari plafon 200% — lonjakan beban berikutnya bahkan boleh melampaui 100% tanpa langsung di-throttle CFS.
4. BLOCK I/O tetap satu siklus hidup — angka kumulatif tidak reset karena container tidak pernah dibuat ulang; jejak 4 MB itu terakumulasi sejak sebelum perubahan — bukti diam-diam bahwa proses yang sama masih berjalan.

Dalam beberapa menit latensi kembali turun ke dua digit milidetik — insiden mereda tanpa satu pun request gagal. Namun pekerjaan Siti baru separuh selesai, dan separuh sisanya adalah bagian yang paling sering dilupakan.

Apa Saja yang Bisa Diubah #

docker update bukan tongkat ajaib untuk semua konfigurasi container — ia hanya bisa menulis ulang hal-hal yang memang hidup di cgroup dan kebijakan daemon. Peta lengkapnya:

Batasnya punya alasan teknis yang jelas. Batas resource hidup di berkas cgroup — berkas yang bisa ditulis ulang kapan saja dan dibaca kernel berulang-ulang, sehingga mengubahnya seolah mengubah anggaran di tengah tahun fiskal. Sebaliknya, environment, pemetaan port, mount, dan image dipahat ke konfigurasi container pada saat diciptakan — semuanya ikut serta dalam pembentukan namespace dan proses awalnya, dan mengubahnya berarti membentuk container yang berbeda. Untuk kelompok kedua, jalannya tetap: ubah compose.yaml lalu docker compose up -d — persis pola yang akan kita rangkai sebagai pasangan update di bawah.

Darurat dan Permanen update versus compose.yaml #

Di sinilah disiplin operasional chapter ini berada. docker update mengubah container, bukan berkas — dan selama compose.yaml belum ikut diedit, keadaan container dan definisi di berkas saling bertentangan. Konflik itu punya nama: drift.

Alur lengkap yang benar memuat lima langkah — tiga yang sudah kita jalankan, dua yang wajib menyusul:

1. Diagnosis lewat stats dan inspect — voni sempit dengan angka, bukan firasat; sudah kita lakukan di pembuka.
2. docker update untuk ruang napas segera — tanpa downtime, insiden mereda; juga sudah.
3. Edit compose.yaml di hari yang sama — definisi permanen diubah agar menyamai keadaan darurat:

services:
  backend:
    build:
      context: ./api
      target: runtime
    cpus: 2.0
    mem_limit: 512m
    memswap_limit: 1g
    pids_limit: 300

4. Terapkan lewat recreate di jendela maintenance — saat trafik turun, definisi baru resmi menggantikan container darurat:

$ docker compose up -d backend

Output yang Dihasilkan:

[+] Running 1/1
 ✔ Container toko-backend-1  Recreated  0.5s
 ✔ Container toko-backend-1  Started    0.9s

5. Verifikasi ulang — satu docker stats --no-stream terakhir memastikan container baru lahir dengan angka yang sama; drift tertutup, berkas dan mesin kembali berbicara satu bahasa.

Perbandingan dua jalur itu dirangkum dalam satu tabel keputusan:

–restart juga Ikut Bisa Diubah #

Satu kemampuan docker update yang spesial karena sering menyelamatkan: kebijakan restart. Seluruh peta kebijakan dari chapter Restart Policy — no, on-failure, always, unless-stopped — bisa dipasang dan diganti lepas pada container yang berjalan. Pola pemakaiannya yang paling sering menyelamatkan sudah kita praktikkan di chapter Mengatasi Container Crash: saat crash loop menggeser-geser log, docker update --restart=no worker-gambar membekukan kebangkitan otomatis supaya galat mentah berhenti di tempat dan bisa dibaca dengan tenang — lalu setelah akar masalah diperbaiki, kebijakan yang semestinya dikembalikan dengan satu docker update lagi.

Perlu diperhatikan bahwa aturan drift berlaku sama persis di sini: bila container dikelola compose, kebijakan yang dipasang lewat docker update akan ditimpa kembali oleh nilai restart: di berkas pada recreate berikutnya. Ubah berkasnya bila kebijakan baru memang dimaksudkan permanen — docker update hanya untuk jendela di antara dua recreate.

Loop-nya sendiri singkat — daftar nama dari docker ps, lalu update satu per satu:

$ for c in $(docker ps --filter name=toko- --format '{{.Names}}'); do docker update --pids-limit 300 "$c"; done

Output yang Dihasilkan:

toko-proxy-1
toko-backend-1
toko-db-1
toko-cache-1
toko-frontend-1

Filter name=toko- menangkap seluruh container project berdasarkan prefiks namanya; setiap baris keluaran adalah nama container yang berhasil diubah. Dan seperti semua docker update: compose.yaml tetap harus menyusul di hari yang sama — loop mempercepat tangan, bukan menggantikan berkas.

docker update adalah jawaban untuk menit-menit darurat: angka berubah, container tidak mati, insiden mereda. Namun kebiasaan menulis --cpus dan --memory sebagai flag docker run satu per satu — seperti yang kita lakukan sepanjang empat chapter ini — tidak akan bertahan di dunia dengan belasan service; kebiasaan itu punya sintaks yang jauh lebih rapi, tempat limit menjadi bagian dari definisi service, ikut versi bersama kode, dan diterapkan konsisten ke seluruh lingkungan. Chapter berikutnya, Resource di Compose, memindahkan seluruh perangkat section ini ke dalam compose.yaml — kunci cpus, mem_limit, memswap_limit, dan pids_limit yang baru saja kita edit secara darurat — beserta cara mengatur anggaran resource Docker Desktop yang memayungi semuanya.

Referensi #

• docker container update — daftar resmi flag yang bisa diubah pada container berjalan.
• Runtime options with Memory, CPUs, and GPUs — semantik limit yang ditulis ulang oleh update.
• Compose file reference — kunci cpus, mem_limit, memswap_limit, dan pids_limit pada definisi service.
• Start containers automatically — kebijakan restart yang dapat diubah lewat docker update --restart.