Debug các ứng dụng container hóa liên quan đến việc kiểm tra log, có một shell bên trong các container, kiểm tra cấu hình và trạng thái, và chẩn đoán các vấn đề phổ biến (crash, networking, tài nguyên). Biết cách khắc phục sự cố là kỹ năng thực tế thiết yếu.
docker ps -a
docker logs <container>
docker logs -f -- 100 <container>
docker inspect <container>
docker events
docker logs thường là bước đầu tiên — nó hiển thị output và lỗi của ứng dụng. docker ps -a cho thấy nếu một container đã thoát (và mã thoát của nó).
# chạy một shell tương tác bên trong một container ĐANG CHẠY để điều tra
docker exec -it <container> bash # hoặc sh (alpine)
# → kiểm tra tệp, chạy lệnh, kiểm tra môi trường, test kết nối từ bên trong
# nếu container không CHẠY DUY TRÌ, ghi đè entrypoint để có một shell
docker run -it --entrypoint sh myimage
docker exec -it ... bash cho một shell bên trong một container đang chạy — vô giá để kiểm tra tệp, kiểm tra môi trường, và test kết nối từ góc nhìn của container.
Container THOÁT ngay lập tức → kiểm tra `docker logs`; process chính đã crash hoặc kết thúc
(một container dừng khi process chính của nó thoát) — kiểm tra CMD/ENTRYPOINT, lỗi
KHÔNG KẾT NỐI ĐƯỢC giữa các container → kiểm tra chúng cùng network; dùng TÊN dịch vụ
(không phải localhost); xác minh cổng; `docker network inspect`
CỔNG không truy cập được → kiểm tra ánh xạ -p; app phải lắng nghe trên 0.0.0.0 (không 127.0.0.1)
HẾT BỘ NHỚ / bị kill → kiểm tra `docker stats`, giới hạn tài nguyên (OOMKilled trong inspect)
Lỗi QUYỀN → quyền sở hữu tệp/người dùng (người dùng không phải root vs quyền volume được mount)
Vấn đề IMAGE → rebuild không cache (--no-cache); kiểm tra build context/.dockerignore
Biết cách debug và khắc phục sự cố các container Docker là kỹ năng thực tế thiết yếu, vì các ứng dụng container hóa chắc chắn sẽ có các vấn đề (crash, vấn đề kết nối, lỗi cấu hình) phải được chẩn đoán, và môi trường container hóa thêm một lớp đòi hỏi các kỹ thuật debug cụ thể.
Các kỹ năng nền tảng — kiểm tra log (docker logs, thường là bước đầu tiên, hiển thị output và lỗi của ứng dụng), kiểm tra trạng thái (docker ps -a cho thấy nếu và tại sao một container đã thoát, bao gồm mã thoát), và kiểm tra cấu hình/trạng thái (docker inspect) — là cách bạn bắt đầu chẩn đoán hầu hết các vấn đề.
Có một shell bên trong một container (docker exec -it ... bash) là một kỹ thuật vô giá để điều tra từ góc nhìn của container — kiểm tra tệp, kiểm tra môi trường, và test kết nối — và biết cách có một shell ngay cả khi một container không chạy duy trì (ghi đè entrypoint) xử lý các trường hợp khó.
Hiểu các vấn đề phổ biến và chẩn đoán của chúng là đặc biệt có giá trị: container thoát ngay lập tức (process chính đã crash hoặc kết thúc — kiểm tra log và CMD/ENTRYPOINT), các vấn đề kết nối giữa các container (thành viên network, dùng tên dịch vụ không phải localhost), cổng không truy cập được (ánh xạ, và điểm cần lưu ý phổ biến là app phải lắng nghe trên 0.0.0.0 không phải 127.0.0.1), bị kill do hết bộ nhớ, và các lỗi quyền — đây là các vấn đề thực sự, tái diễn mà biết cách nhận ra và sửa chúng tiết kiệm thời gian đáng kể.
Vì các ứng dụng container hóa có các vấn đề phải được debug, và vì khắc phục sự cố hiệu quả (log, exec vào container, inspect, và nhận ra các mẫu lỗi phổ biến) là cần thiết để chẩn đoán và giải quyết chúng, biết cách debug các container Docker là kỹ năng thực tế thiết yếu, thường được áp dụng cho bất kỳ ai chạy các ứng dụng container hóa, một năng lực vận hành cốt lõi biến các vấn đề container gây bực bội thành các vấn đề có thể giải quyết được.