Làm thế nào để biết lý do tại sao một docker container thoát ra?

98

Tôi có một vùng chứa Docker đang chạy trong một máy chủ có RAM 1G (cũng có các vùng chứa khác đang chạy trong cùng một máy chủ). Ứng dụng trong vùng chứa Docker này sẽ giải mã một số hình ảnh, có thể tiêu tốn nhiều bộ nhớ.

Theo thời gian, vùng chứa này sẽ thoát ra. Tôi nghi ngờ là do hết bộ nhớ nhưng không chắc lắm. Tôi cần một phương pháp để tìm ra nguyên nhân gốc rễ. Vậy có cách nào để biết điều gì đã xảy ra đối với cái chết của container này không?

docker containers exit

— Li Bin
nguồn

5

Bạn có thể kiểm tra nhật ký cho vùng chứa đó thông qua docker logs <container-id>.

— techtabu

2

nhưng vùng chứa đã thoát, tôi đoán tôi không thể ghi lại nó nữa?

— Li Bin

Chỉ cần thử trên máy của tôi. Bạn vẫn có thể truy cập nhật ký ngay cả khi vùng chứa đã thoát.

— Samuel Toh

Ít nhất bạn đã thử?

— techtabu

techtabu, vâng, tôi đã làm. Dù sao thì nó cũng không giúp được gì

— Li Bin

117

Những người khác đã đề cập docker logs $container_idđể xem đầu ra của ứng dụng. Đây sẽ luôn là điều đầu tiên tôi kiểm tra.

Tiếp theo, bạn có thể chạy một docker inspect $container_idđể xem chi tiết về trạng thái, ví dụ:

    "State": {
        "Status": "exited",
        "Running": false,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 0,
        "ExitCode": 2,
        "Error": "",
        "StartedAt": "2016-06-28T21:26:53.477229071Z",
        "FinishedAt": "2016-06-28T21:26:53.478066987Z"
    },

Dòng quan trọng ở đó là "OOMKilled" sẽ đúng nếu bạn vượt quá giới hạn bộ nhớ vùng chứa và Docker giết ứng dụng của bạn. Bạn cũng có thể muốn tra cứu mã thoát để xem liệu nó có xác định được nguyên nhân khiến ứng dụng của bạn thoát hay không.

Lưu ý, điều này chỉ cho biết nếu chính docker giết quá trình của bạn và yêu cầu bạn phải đặt giới hạn bộ nhớ cho vùng chứa của mình. Bên ngoài docker, nhân Linux có thể làm mất quy trình của bạn nếu bản thân máy chủ hết bộ nhớ. Linux thường ghi vào nhật ký / var / log khi điều này xảy ra. Với Docker Desktop trên Windows và Mac, bạn có thể điều chỉnh bộ nhớ được phân bổ cho máy ảo Linux nhúng trong cài đặt docker.

— BMitch
nguồn

9

Tôi không hiểu ở đây là từ khi container của tôi không còn nữa thì "thanh tra" sẽ hoạt động như thế nào? Từ thảo luận ở trên, một khi ứng dụng chết, vùng chứa cũng sẽ chết. Bạn có nghĩa là khởi động lại cùng một hình ảnh sau đó kiểm tra?

— Li Bin

9

@LiBin một vùng chứa không bị xóa sạch khi nó chết, nó chỉ đơn giản là chuyển sang trạng thái dừng như trạng thái = đã dừng hoặc đã thoát. 'Docker ps -a' và xem cho chính mình

— Samuel Toh

Tôi đã thoát ra 0 mỗi khi chạy một hoạt động đòi hỏi nhiều bộ nhớ và OOMKilled là sai. Tăng trí nhớ khiến nó hoạt động trở lại.

— Andrei

1

Điều này có thể xảy ra nếu hạt nhân Linux, chứ không phải công cụ docker, giết các quy trình trong vùng chứa. Bạn sẽ thường thấy điều đó trong nhật ký hệ điều hành dưới / var / log trên máy chủ.

— BMitch

5

Bạn có thể tìm hiểu xem quá trình bên trong vùng chứa có được OOMkilled hay không bằng cách đọc nhật ký. OOMkill được khởi tạo bởi hạt nhân nên mỗi khi nó xảy ra sẽ có một loạt các dòng /var/log/kern.log, ví dụ:

python invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=995
oom_kill_process+0x22e/0x450
Memory cgroup out of memory: Kill process 31204 (python) score 1994 or sacrifice child
Killed process 31204 (python) total-vm:7350860kB, anon-rss:4182920kB, file-rss:2356kB, shmem-rss:0kB

— bay xốp
nguồn

Câu trả lời này đã giúp tôi tìm ra vấn đề với một vùng chứa mà docker sẽ khởi động lại khi thoát (kiểm tra docker không giúp ích nhiều ở đây).

— m90,

0

Mặc dù câu trả lời được chấp nhận là lựa chọn tốt nhất, đôi khi cũng có thể hữu ích khi kiểm tra nội dung của tạp chí từ máy chủ lưu trữ (trên linux).

Bạn có thể làm điều đó bằng cách gõ:

sudo journalctl -u docker

hoặc nối đuôi nó

sudo journalctl -u docker -f

hoặc chuyển đầu ra xuống ít hơn nếu quá dài đối với bộ đệm đầu cuối của bạn

journalctl -xn -u docker | less

— Roberto Manfreda
nguồn