Penyelesaian Masalah Runtime Kontena Docker: Panduan Praktikal Langkah-demi-Langkah

Senario

Perkhidmatan web pengeluaran anda baru sahaja memulangkan 502. Papan pemantauan menunjukkan kontena yang menjalankan API anda telah hilang. Anda SSH ke hos dan lihat kontena terperangkap dalam gelung but semula—atau lebih teruk, telah keluar dengan ralat runtime OCI. Ini bukan kerosakan kod aplikasi; ia adalah runtime kontena gagal untuk memulakan atau mengekalkan eksekusi. Artikel ini membimbing anda melalui laluan penyelesaian masalah dunia sebenar untuk isu runtime kontena Docker pada hos Linux.

Simptom

Penunjuk biasa bahawa runtime, bukan aplikasi anda, yang menjadi masalah:

• Kontena keluar serta-merta dengan kod 137 (SIGKILL) atau 139 (SIGSEGV).
• docker inspect menunjukkan mesej State.Error seperti: OCI runtime exec failed: exec failed: unable to start container process: exec: '/bin/sh': stat /bin/sh: no such file or directory.
• Pemeriksaan kesihatan gagal dan kontena berada dalam gelung backoff but semula.
• Daemon Docker memulangkan: Error response from daemon: containerd: container did not start before required deadline.
• Kontena dibunuh kerana OOM atau mencapai had cgroup.

Diagnosis

Mula dengan docker ps -a untuk mendapatkan ID kontena dan status keluar. Kemudian gunakan docker inspect untuk melihat kiraan but semula, kod keluar, dan ralat yang tepat. Sentiasa kumpul log sebelum menyentuh kontena.

Perintah berguna:

docker ps -a --filter 'name=your-service'
docker inspect <container_id> --format '{{.State.ExitCode}} {{.State.Error}}'
docker logs <container_id> --tail 200 --timestamps
docker stats --no-stream

Runtime Docker bergantung pada containerd dan runc. Semak kesihatan mereka:

systemctl status docker containerd
docker info | grep -i runtime
runc --version

Jika ralat berlaku pada peringkat rendah, periksa mesej kernel:

dmesg | tail -50
journalctl -u containerd --since '10 minutes ago'

Kawalan Risiko

• Sentiasa simpan keadaan semasa dengan docker inspect dan docker logs sebelum sebarang tindakan.
• Utamakan penutupan secara lembut: docker stop -t 30 <container_id> daripada membunuh serta-merta.
• Jangan jalankan docker rm -f pada kontena pengeluaran tanpa mengambil log dan mengesahkan imej gantian tersedia.
• Apabila memulakan kontena baharu, tetapkan had memori dan CPU, contohnya --memory=512m --cpus=0.5, untuk mengelakkan kehabisan sumber hos.
• Jika menggunakan runtime tersuai seperti gVisor, sahkan runtime dipasang dan dikonfigurasi dengan betul sebelum but semula.

Gulung Balik

Jika kegagalan berlaku sejurus selepas penggunaan, gulung balik ke tag imej sebelumnya yang diketahui baik. Contohnya:

docker pull your-app:stable
docker run -d --name your-app-rollback --env-file .env your-app:stable

Kemas kini pengurus penggunaan anda (Kubernetes, Docker Swarm, atau unit systemd) untuk menggunakan tag lama. Jika ralat disebabkan oleh fail binari hilang atau entrypoint salah dalam imej, gulung balik kepada imej yang berfungsi sebelum ini biasanya boleh memulihkan perkhidmatan dalam beberapa minit.

Pengesahan

Selepas pemulihan, sahkan kontena stabil:

• docker ps menunjukkan kontena berjalan.
• docker logs --tail 20 menunjukkan log permulaan normal.
• Titik akhir kesihatan perkhidmatan memulangkan 200 OK.
• Jalankan docker inspect untuk mengesahkan tiada lonjakan polisi but semula.

Pantau selama sekurang-kurangnya 10 minit untuk memastikan pembaikan tahan lama.

Bila Menghantar Tiket OpsGlobal

Naik taraf kepada OpsGlobal jika:

• Ralat runtime masih berterusan selepas gulung balik ke imej yang baik.
• Anda melihat mesej seperti runc: symbol lookup error atau overlayfs: mount error dalam log sistem.
• Berbilang hos dalam kluster menunjukkan corak kegagalan yang sama.
• Anda mengesyaki isu peringkat kernel atau perkakasan (ralat halaman, ralat I/O, masalah NUMA).

OpsGlobal boleh melakukan diagnostik mendalam pada daemon Docker, containerd, runc, dan parameter kernel, kemudian menggunakan pembaiki panas atau konfigurasi kestabilan jangka panjang.