Làm sạch docker / overlay2 / có an toàn không

Tôi có một số vùng chứa docker đang chạy trên AWS EC2, thư mục / var / lib / docker / overlay2 phát triển rất nhanh về kích thước đĩa.

Tôi đang tự hỏi nếu nó là an toàn để xóa nội dung của nó? hoặc nếu docker có một số loại lệnh để giải phóng một số dung lượng đĩa.

CẬP NHẬT:

Tôi thực sự đã thử docker system prune -arồi, đã lấy lại được 0Kb.

Ngoài ra, kích thước đĩa / docker / overlay2 của tôi lớn hơn nhiều so với đầu ra từ docker system df

Sau khi đọc tài liệu về docker và câu trả lời của BMitch, tôi tin rằng đó là một ý tưởng ngu ngốc khi chạm vào thư mục này và tôi sẽ thử các cách khác để lấy lại dung lượng đĩa của mình.

Docker sử dụng / var / lib / docker để lưu trữ hình ảnh, vùng chứa và các ổ đĩa được đặt tên cục bộ của bạn. Xóa điều này có thể dẫn đến mất dữ liệu và có thể ngừng chạy động cơ. Thư mục con overlay2 đặc biệt chứa các lớp hệ thống tệp khác nhau cho hình ảnh và vùng chứa.

Để dọn dẹp các vùng chứa và hình ảnh không sử dụng, hãy xem docker system prune. Ngoài ra còn có các tùy chọn để xóa khối lượng và thậm chí cả hình ảnh được gắn thẻ, nhưng chúng không được bật theo mặc định do khả năng mất dữ liệu.

Tôi thấy điều này phù hợp nhất với tôi:

docker image prune --all

Theo mặc định, Docker sẽ không xóa các hình ảnh có tên, ngay cả khi chúng không được sử dụng. Lệnh này sẽ xóa các hình ảnh không sử dụng.

Lưu ý rằng mỗi lớp trong một hình ảnh là một thư mục bên trong /usr/lib/docker/overlay2/thư mục.

Tôi gặp sự cố này ... Đó là nhật ký rất lớn. Nhật ký ở đây:

/var/lib/docker/containers/<container id>/<container id>-json.log

Bạn có thể quản lý điều này trong dòng lệnh chạy hoặc trong tệp soạn thảo. Xem ở đó: Định cấu hình trình điều khiển ghi nhật ký

Cá nhân tôi đã thêm 3 dòng này vào tệp docker-compost.yml của mình:

my_container:
  logging:
    options:
      max-size: 10m

cũng gặp vấn đề với việc phát triển nhanh chóng overlay2

/var/lib/docker/overlay2- là một thư mục nơi docker lưu trữ các lớp có thể ghi cho vùng chứa của bạn. docker system prune -a- chỉ có thể hoạt động nếu ngăn chứa và loại bỏ.

trong tôi, tôi đã có thể tìm ra những gì tiêu tốn không gian bằng cách đi vào overlay2và điều tra.

thư mục đó chứa các thư mục có tên băm khác. mỗi người trong số họ có một số thư mục bao gồm cả diffthư mục.

diff thư mục - chứa sự khác biệt thực tế được viết bởi một vùng chứa có cấu trúc thư mục chính xác như vùng chứa của bạn (ít nhất là trong trường hợp của tôi - ubuntu 18 ...)

vì vậy tôi đã từng du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpnhận ra rằng /tmpbên trong vùng chứa của tôi là thư mục bị ô nhiễm .

vì vậy, như một cách giải quyết, tôi đã sử dụng -v /tmp/container-data/tmp:/tmptham số cho docker runlệnh để ánh xạ /tmpthư mục bên trong tới máy chủ lưu trữ và thiết lập một cron trên máy chủ lưu trữ để dọn dẹp thư mục đó.

nhiệm vụ cron rất đơn giản:

• sudo nano /etc/crontab
• */30 * * * * root rm -rf /tmp/container-data/tmp/*
• save and exit

LƯU Ý: overlay2là thư mục docker hệ thống và họ có thể thay đổi cấu trúc của nó bất cứ lúc nào. Mọi thứ ở trên đều dựa trên những gì tôi đã thấy trong đó. Chỉ phải đi vào cấu trúc thư mục docker vì hệ thống đã hết dung lượng và thậm chí không cho phép tôi chuyển vào thùng chứa docker.

CẢNH BÁO: KHÔNG SỬ DỤNG TRONG HỆ THỐNG SẢN XUẤT

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

Được rồi, trước tiên hãy thử cắt tỉa hệ thống

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

Không quá tuyệt vời, có vẻ như nó đã dọn sạch một vài megabyte. Hãy điên lên bây giờ:

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

Đẹp! Chỉ cần nhớ rằng điều này KHÔNG được khuyến khích trong bất kỳ thứ gì ngoại trừ một máy chủ vứt bỏ. Tại thời điểm này, cơ sở dữ liệu nội bộ của Docker sẽ không thể tìm thấy bất kỳ lớp phủ nào và nó có thể gây ra hậu quả không mong muốn.

Backgroud

Nguyên nhân cho vấn đề có thể được chia ra giữa việc chúng tôi định cấu hình sai các khối lượng vùng chứa và sự cố do docker làm rò rỉ (không phát hành) dữ liệu tạm thời được ghi vào các khối lượng này. Chúng ta nên ánh xạ (tới các thư mục lưu trữ hoặc các yêu cầu lưu trữ liên tục khác) tất cả các thư mục tạm thời / nhật ký / đầu của vùng chứa nơi ứng dụng của chúng ta ghi thường xuyên và / hoặc nhiều. Docker không chịu trách nhiệm về việc dọn dẹp tất cả cái gọi là EmptyDirs được tạo tự động nằm trong mặc định /var/lib/docker/overlay2/*/diff/*. Nội dung của các thư mục "không liên tục" này sẽ được docker tự động xóa sau khi vùng chứa bị dừng, nhưng rõ ràng là không (thậm chí không thể xóa chúng khỏi phía máy chủ nếu vùng chứa vẫn đang chạy - và nó có thể chạy trong nhiều tháng tại một thời điểm).

Cách giải quyết

Một giải pháp thay thế yêu cầu dọn dẹp thủ công cẩn thận và mặc dù đã được mô tả ở những nơi khác, bạn vẫn có thể tìm thấy một số gợi ý từ nghiên cứu điển hình của tôi, mà tôi đã cố gắng đưa ra hướng dẫn và tổng quát nhất có thể.

Vì vậy, những gì đã xảy ra là ứng dụng thủ phạm (trong trường hợp của tôi clair-scanner) đã quản lý để ghi hàng trăm hợp đồng dữ liệu trong vài tháng vào /diff/tmpthư mục con của dockeroverlay2

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

Vì vậy, vì tất cả các thư mục con /diff/tmpđó đều khá dễ hiểu (tất cả đều có dạng clair-scanner-*và có ngày tạo lỗi thời), tôi đã dừng vùng chứa được liên kết ( docker stop clair) và cẩn thận loại bỏ các thư mục con lỗi thời này diff/tmp, bắt đầu cẩn thận với một (cũ nhất) duy nhất, và kiểm tra tác động trên công cụ docker (yêu cầu khởi động lại [ systemctl restart docker] để lấy lại dung lượng đĩa):

rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)

Tôi đã lấy lại hàng trăm hợp đồng biểu diễn dung lượng đĩa mà không cần phải cài đặt lại docker hoặc xóa toàn bộ các thư mục của nó. Tất cả các vùng chứa đang chạy phải dừng lại tại một điểm, vì cần khởi động lại trình nền docker để lấy lại dung lượng đĩa, vì vậy trước tiên hãy đảm bảo rằng các vùng chứa chuyển đổi dự phòng của bạn đang chạy chính xác trên một / nút / s). Mặc dù vậy, tôi ước rằng docker prunelệnh cũng có thể bao gồm dữ liệu đã lỗi thời /diff/tmp(hoặc thậm chí /diff/*) (thông qua một công tắc khác).

Đây là một vấn đề đã 3 năm tuổi, bạn có thể đọc lịch sử phong phú và đầy màu sắc của nó trên các diễn đàn Docker, nơi một biến thể nhằm vào nhật ký ứng dụng của giải pháp trên đã được đề xuất vào năm 2019 và dường như đã hoạt động trong một số thiết lập: https: // Forum.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

KHÔNG LÀM ĐIỀU NÀY TRONG SẢN XUẤT

Câu trả lời được đưa ra bởi @ ravi-luthra về mặt kỹ thuật hoạt động nhưng nó có một số vấn đề!

Trong trường hợp của tôi, tôi chỉ đang cố gắng khôi phục dung lượng đĩa. Các lib/docker/overlaythư mục được dùng 30GB không gian và tôi chỉ chạy một vài container thường xuyên. Có vẻ như docker gặp một số vấn đề với rò rỉ dữ liệu và một số dữ liệu tạm thời không bị xóa khi vùng chứa dừng.

Vì vậy, tôi đã tiếp tục và xóa tất cả nội dung của lib/docker/overlaythư mục. Sau đó, phiên bản docker của tôi không thể sử dụng được. Khi tôi cố gắng chạy hoặc xây dựng bất kỳ vùng chứa nào, nó đã cho tôi lỗi này:

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

Sau đó, với một số thử nghiệm và lỗi, tôi đã giải quyết vấn đề này bằng cách chạy

(CẢNH BÁO: Thao tác này sẽ xóa tất cả dữ liệu của bạn bên trong ổ đĩa docker)

docker system prune --volumes -a

Vì vậy, không nên làm những việc dọn dẹp bẩn như vậy trừ khi bạn hoàn toàn hiểu cách hoạt động của hệ thống.

Mọi thứ trong / var / lib / docker đều là hệ thống tệp của vùng chứa. Nếu bạn dừng tất cả các vùng chứa của mình và cắt chúng, bạn sẽ kết thúc với thư mục trống. Bạn có thể không thực sự muốn điều đó, vì vậy đừng xóa ngẫu nhiên những thứ trong đó. Không xóa trực tiếp những thứ trong / var / lib / docker. Đôi khi bạn có thể bỏ qua nó, nhưng không thể tránh khỏi vì nhiều lý do.

Làm điều này thay thế:

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

Những gì bạn sẽ thấy là các tệp lớn nhất được hiển thị ở dưới cùng. Nếu bạn muốn, hãy tìm ra các vùng chứa các tệp đó, nhập các vùng chứa đó với docker exec -ti containername -- /bin/shvà xóa một số tệp.

Bạn cũng có thể thực docker system prune -a -fhiện công việc cron hàng ngày / hàng tuần miễn là bạn không để lại các thùng chứa và khối lượng đã dừng xung quanh mà bạn quan tâm. Tốt hơn là tìm ra lý do tại sao nó phát triển và sửa chúng ở cấp vùng chứa.

Gần đây tôi đã gặp sự cố tương tự, overlay2 ngày càng lớn hơn, nhưng tôi không thể tìm ra điều gì đã tiêu tốn phần lớn dung lượng.

df đã cho tôi thấy rằng overlay2 có kích thước khoảng 24GB.

Với việc dutôi đã cố gắng tìm ra thứ gì đã chiếm không gian… và không thành công.

Sự khác biệt đến từ thực tế là các tệp đã xóa (chủ yếu là tệp nhật ký trong trường hợp của tôi) vẫn được sử dụng bởi một quy trình (Docker). Vì vậy, tệp không hiển thị với dunhưng không gian mà nó chiếm sẽ hiển thị cùng df.

Khởi động lại máy chủ đã giúp. Khởi động lại vùng chứa docker có lẽ đã hữu ích rồi… Bài viết này trên linuxquestions.org đã giúp tôi tìm ra điều đó.

thêm vào nhận xét ở trên, trong đó mọi người đề xuất cắt bớt hệ thống như khối lượng treo lơ lửng rõ ràng, hình ảnh, bộ chứa thoát, v.v., Đôi khi ứng dụng của bạn trở thành thủ phạm, nó tạo ra quá nhiều nhật ký trong một thời gian nhỏ và nếu bạn sử dụng khối lượng trực tiếp rỗng (khối lượng cục bộ ) điền vào các phân vùng / var. Trong trường hợp đó, tôi thấy lệnh dưới đây rất thú vị để tìm ra, điều gì đang chiếm dung lượng trên đĩa phân vùng / var của tôi.

du -ahx / var / lib | sắp xếp -rh | đầu -n 30

Lệnh này sẽ liệt kê top 30, đang chiếm nhiều dung lượng nhất trên một đĩa. Có nghĩa là nếu bạn đang sử dụng bộ nhớ ngoài với các vùng chứa của mình, thì sẽ tốn rất nhiều thời gian để chạy lệnh du. Lệnh này sẽ không tính khối lượng gắn kết. Và nhanh hơn nhiều. Bạn sẽ nhận được chính xác các thư mục / tệp đang tiêu tốn dung lượng. Sau đó, bạn có thể vào các thư mục đó và kiểm tra xem tệp nào hữu ích hay không. nếu các tệp này là bắt buộc thì bạn có thể chuyển chúng sang một số bộ nhớ liên tục bằng cách thực hiện thay đổi trong ứng dụng để sử dụng bộ nhớ liên tục cho vị trí đó hoặc thay đổi vị trí của các tệp đó. Và phần còn lại, bạn có thể xóa chúng.

Tôi đã sử dụng "docker system snine -a" nó đã làm sạch tất cả các tệp trong volume và overlay2

    [root@jasontest volumes]# docker system prune -a
    WARNING! This will remove:
            - all stopped containers
            - all networks not used by at least one container
            - all images without at least one container associated to them
            - all build cache
    Are you sure you want to continue? [y/N] y
    Deleted Images:
    untagged: ubuntu:12.04
    untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
    deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
    deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
    deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
    deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
    deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
    deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
    untagged: osixia/openldap:1.2.1
    untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
    deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
    deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
    deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
    deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
    deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
    deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
    deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
    deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
    deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
    untagged: centos:centos7
    untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
    deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
    deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7

    Total reclaimed space: 533.3MB
    [root@jasontest volumes]# ls -alth
    total 32K
    -rw-------  1 root root  32K May 23 21:14 metadata.db
    drwx------  2 root root 4.0K May 23 21:14 .
    drwx--x--x 14 root root 4.0K May 21 20:26 ..