ปลอดภัยหรือไม่ที่จะทำความสะอาดนักเทียบท่า / โอเวอร์เลย์ 2 /

ฉันมีคอนเทนเนอร์นักเทียบท่าที่ทำงานบน AWS EC2 โฟลเดอร์ / var / lib / docker / overlay2 มีขนาดดิสก์เติบโตเร็วมาก

ฉันสงสัยว่าการลบเนื้อหานั้นปลอดภัยหรือไม่? หรือถ้านักเทียบท่ามีคำสั่งบางอย่างเพื่อเพิ่มการใช้งานดิสก์บางอย่าง

อัพเดท:

ฉันได้ลองdocker system prune -aแล้วซึ่งเรียกคืน 0Kb

นอกจากนี้ขนาดดิสก์ / docker / overlay2 ของฉันยังใหญ่กว่าเอาต์พุตจากไฟล์ docker system df

หลังจากอ่านเอกสารนักเทียบท่าและคำตอบของ BMitch ฉันเชื่อว่าเป็นความคิดที่โง่เขลาที่จะแตะโฟลเดอร์นี้และฉันจะลองวิธีอื่นในการเรียกคืนพื้นที่ดิสก์ของฉัน

นักเทียบท่าใช้ / var / lib / docker เพื่อจัดเก็บอิมเมจคอนเทนเนอร์และไดรฟ์ข้อมูลที่มีชื่อในเครื่องของคุณ การลบสิ่งนี้อาจทำให้ข้อมูลสูญหายและอาจทำให้เครื่องยนต์หยุดทำงาน ไดเร็กทอรีย่อย overlay2 มีเลเยอร์ระบบไฟล์ต่างๆสำหรับอิมเมจและคอนเทนเนอร์โดยเฉพาะ

docker system pruneภาชนะที่ไม่ได้ใช้ทำความสะอาดและภาพให้ดู นอกจากนี้ยังมีตัวเลือกในการลบไดรฟ์ข้อมูลและแม้แต่รูปภาพที่ติดแท็ก แต่ไม่ได้เปิดใช้งานโดยค่าเริ่มต้นเนื่องจากข้อมูลอาจสูญหายได้

ฉันพบว่าสิ่งนี้ได้ผลดีที่สุดสำหรับฉัน:

docker image prune --all

โดยค่าเริ่มต้น Docker จะไม่ลบภาพที่ระบุชื่อแม้ว่าจะไม่ได้ใช้ก็ตาม คำสั่งนี้จะลบภาพที่ไม่ได้ใช้

สังเกตว่าแต่ละเลเยอร์ในรูปภาพคือโฟลเดอร์ภายใน/usr/lib/docker/overlay2/โฟลเดอร์

ฉันมีปัญหานี้ ... มันเป็นบันทึกที่ใหญ่มาก บันทึกอยู่ที่นี่:

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

คุณสามารถจัดการสิ่งนี้ได้ในบรรทัดคำสั่ง run หรือในไฟล์เขียน ดูที่นั่น: กำหนดค่าไดรเวอร์การบันทึก

ฉันได้เพิ่ม 3 บรรทัดนี้ลงในไฟล์ docker-compose.yml ของฉันเป็นการส่วนตัว:

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

ยังมีปัญหากับการเติบโตอย่างรวดเร็ว overlay2

/var/lib/docker/overlay2- เป็นโฟลเดอร์ที่นักเทียบท่าเก็บเลเยอร์ที่เขียนได้สำหรับคอนเทนเนอร์ของคุณ docker system prune -a- อาจทำงานได้เฉพาะเมื่อหยุดและนำคอนเทนเนอร์ออก

ในตัวฉันฉันสามารถคิดออกว่าอะไรกินพื้นที่โดยเข้าไปoverlay2และตรวจสอบ

โฟลเดอร์นั้นมีโฟลเดอร์ชื่อแฮชอื่น ๆ แต่ละโฟลเดอร์มีหลายโฟลเดอร์รวมถึงdiffโฟลเดอร์

diff โฟลเดอร์ - มีความแตกต่างที่แท้จริงที่เขียนโดยคอนเทนเนอร์ที่มีโครงสร้างโฟลเดอร์ที่แน่นอนเป็นคอนเทนเนอร์ของคุณ (อย่างน้อยก็ในกรณีของฉัน - ubuntu 18 ... )

ดังนั้นผมจึงได้นำมาใช้du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpจะคิดออกว่า/tmpภายในของภาชนะของฉันคือโฟลเดอร์ที่ได้รับการปนเปื้อน

ดังนั้นเพื่อเป็นวิธีแก้ปัญหาฉันได้ใช้-v /tmp/container-data/tmp:/tmpพารามิเตอร์สำหรับdocker runคำสั่งเพื่อแมป/tmpโฟลเดอร์ภายในเพื่อโฮสต์และตั้งค่า cron บนโฮสต์เพื่อล้างโฟลเดอร์นั้น

งาน cron นั้นง่ายมาก:

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

หมายเหตุ: overlay2เป็นโฟลเดอร์ System Docker และอาจเปลี่ยนแปลงโครงสร้างได้ตลอดเวลา ทุกอย่างข้างต้นขึ้นอยู่กับสิ่งที่ฉันเห็นในนั้น ต้องไปในโครงสร้างโฟลเดอร์นักเทียบท่าเท่านั้นเพราะระบบไม่มีพื้นที่ว่างอย่างสมบูรณ์และยังไม่อนุญาตให้ฉัน ssh ในคอนเทนเนอร์นักเทียบท่า

พื้นหลัง

ข้อตำหนิสำหรับปัญหานี้สามารถแบ่งออกได้ระหว่างการกำหนดค่าปริมาณคอนเทนเนอร์ที่ไม่ถูกต้องและปัญหาเกี่ยวกับนักเทียบท่าที่รั่วไหล (ไม่สามารถปล่อย) ข้อมูลชั่วคราวที่เขียนลงในไดรฟ์ข้อมูลเหล่านี้ เราควรทำแผนที่ (ไม่ว่าจะเป็นโฮสต์โฟลเดอร์หรือการอ้างสิทธิ์พื้นที่เก็บข้อมูลถาวรอื่น ๆ ) โฟลเดอร์ชั่วคราว / บันทึก / รอยขีดข่วนของคอนเทนเนอร์ทั้งหมดที่แอปของเราเขียนบ่อยและ / หรือหนักมาก นักเทียบท่าไม่รับผิดชอบต่อการล้างข้อมูลทั้งหมดที่สร้างขึ้นโดยอัตโนมัติที่เรียกว่า EmptyDirs ซึ่งอยู่ตามค่าเริ่มต้นใน/var/lib/docker/overlay2/*/diff/*. เนื้อหาของโฟลเดอร์ที่ "ไม่ถาวร" เหล่านี้ควรถูกล้างโดยอัตโนมัติโดยนักเทียบท่าหลังจากที่คอนเทนเนอร์หยุดทำงาน แต่ดูเหมือนว่าจะไม่ใช่ (อาจเป็นไปไม่ได้ที่จะล้างออกจากฝั่งโฮสต์หากคอนเทนเนอร์ยังคงทำงานอยู่ - และสามารถทำงานได้เป็นเวลาหลายเดือน ขณะนั้น).

วิธีแก้ปัญหา

วิธีแก้ปัญหาต้องใช้การล้างข้อมูลด้วยตนเองอย่างรอบคอบและในขณะที่อธิบายไว้แล้วในที่อื่นคุณอาจพบคำแนะนำบางอย่างจากกรณีศึกษาของฉันซึ่งฉันพยายามทำให้เป็นคำแนะนำและเข้าใจได้โดยทั่วไปมากที่สุด

สิ่งที่เกิดขึ้นคือแอปผู้ร้าย (ในกรณีของฉันclair-scanner) สามารถเขียนข้อมูลหลายร้อยกิ๊กในช่วงสองสามเดือนไปยัง/diff/tmpโฟลเดอร์ย่อยของนักเทียบท่าoverlay2

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

271G total

ดังนั้นเนื่องจากโฟลเดอร์ย่อยเหล่านี้ทั้งหมดใน/diff/tmpนั้นค่อนข้างอธิบายตัวเองได้ดี (ทั้งหมดอยู่ในรูปแบบclair-scanner-*และมีวันที่สร้างที่ล้าสมัย) ฉันจึงหยุดคอนเทนเนอร์ที่เกี่ยวข้อง ( docker stop clair) และลบโฟลเดอร์ย่อยที่ล้าสมัยเหล่านี้ออกอย่างระมัดระวังdiff/tmpโดยเริ่มต้นอย่างรอบคอบด้วยโฟลเดอร์เดียว (เก่าที่สุด) และ การทดสอบผลกระทบต่อ Docker Engine (ซึ่งต้องรีสตาร์ท [ systemctl restart docker] เพื่อเรียกคืนพื้นที่ดิสก์):

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)

ฉันเรียกคืนพื้นที่ดิสก์หลายร้อยกิ๊กโดยไม่จำเป็นต้องติดตั้งนักเทียบท่าใหม่หรือล้างโฟลเดอร์ทั้งหมด คอนเทนเนอร์ที่กำลังรันทั้งหมดต้องหยุดทำงานในจุดเดียวเนื่องจากต้องรีสตาร์ท Docker daemon เพื่อเรียกคืนพื้นที่ดิสก์ดังนั้นโปรดตรวจสอบให้แน่ใจก่อนอื่นคอนเทนเนอร์เฟลโอเวอร์ของคุณกำลังรันอย่างถูกต้องบน / other node / s) ฉันหวังว่าdocker pruneคำสั่งจะครอบคลุมข้อมูลที่ล้าสมัย/diff/tmp(หรือแม้กระทั่ง/diff/*) ด้วย (ผ่านสวิตช์อื่น)

ตอนนี้เป็นปัญหาอายุ 3 ปีคุณสามารถอ่านประวัติอันยาวนานและมีสีสันได้ในฟอรัม Docker ซึ่งมีการเสนอตัวแปรที่มุ่งเป้าไปที่บันทึกแอปพลิเคชันของโซลูชันข้างต้นในปี 2019 และดูเหมือนว่าจะทำงานในการตั้งค่าหลายอย่าง: https: // forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

คำเตือน: ห้ามใช้ในระบบการผลิต

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

โอเคเรามาลองใช้ระบบพรุนกันก่อน

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

ไม่ค่อยดีเท่าไหร่ดูเหมือนว่ามันจะสะอาดขึ้นไม่กี่เมกะไบต์ ไปบ้ากันเถอะ:

/# 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% /
...

ดี! เพียงจำไว้ว่าสิ่งนี้ไม่แนะนำให้ใช้กับเซิร์ฟเวอร์แบบโยนทิ้ง ณ จุดนี้ฐานข้อมูลภายในของ Docker จะไม่สามารถค้นหาภาพซ้อนทับเหล่านี้ได้และอาจทำให้เกิดผลที่ไม่คาดคิด

อย่าทำสิ่งนี้ในการผลิต

คำตอบที่ได้รับจาก @ ravi-luthra ใช้งานได้จริง แต่มีปัญหาบางอย่าง!

ในกรณีของฉันฉันแค่พยายามกู้คืนพื้นที่ดิสก์ lib/docker/overlayโฟลเดอร์กำลัง 30GB ของพื้นที่และฉันเพียงเรียกใช้ภาชนะบรรจุไม่กี่อย่างสม่ำเสมอ ดูเหมือนว่านักเทียบท่าจะมีปัญหาเกี่ยวกับการรั่วไหลของข้อมูลและข้อมูลชั่วคราวบางส่วนจะไม่ถูกล้างเมื่อคอนเทนเนอร์หยุดทำงาน

ดังนั้นฉันจึงลบเนื้อหาทั้งหมดของlib/docker/overlayโฟลเดอร์ หลังจากนั้นอินสแตนซ์นักเทียบท่าของฉันก็ไม่สามารถใช้งานได้ เมื่อฉันพยายามเรียกใช้หรือสร้างคอนเทนเนอร์ใด ๆ มันทำให้ฉันเกิดข้อผิดพลาดนี้:

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

จากนั้นด้วยการลองผิดลองถูกฉันจึงแก้ไขปัญหานี้ด้วยการเรียกใช้

(คำเตือน: การดำเนินการนี้จะลบข้อมูลทั้งหมดของคุณในวอลุ่มนักเทียบท่า)

docker system prune --volumes -a

ดังนั้นจึงไม่แนะนำให้ทำความสะอาดสิ่งสกปรกเช่นนี้เว้นแต่คุณจะเข้าใจวิธีการทำงานของระบบอย่างสมบูรณ์

ทุกอย่างใน / var / lib / docker เป็นระบบไฟล์ของคอนเทนเนอร์ หากคุณหยุดคอนเทนเนอร์ทั้งหมดและตัดออกคุณควรจบลงด้วยการที่โฟลเดอร์ว่างเปล่า คุณอาจไม่ต้องการสิ่งนั้นจริงๆดังนั้นอย่าไปสุ่มลบข้อมูลในนั้น อย่าลบสิ่งต่างๆใน / var / lib / docker โดยตรง คุณอาจจะหนีไปบ้างในบางครั้ง แต่ก็มองไม่เห็นด้วยเหตุผลหลายประการ

ทำสิ่งนี้แทน:

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

สิ่งที่คุณจะเห็นคือไฟล์ที่ใหญ่ที่สุดที่แสดงที่ด้านล่าง หากคุณต้องการให้ค้นหาว่าไฟล์เหล่านั้นอยู่ในคอนเทนเนอร์ใดป้อนคอนเทนเนอร์เหล่านั้นด้วยdocker exec -ti containername -- /bin/shและลบไฟล์บางไฟล์

นอกจากนี้คุณยังสามารถdocker system prune -a -fทำงาน cron รายวัน / รายสัปดาห์ได้ตราบเท่าที่คุณไม่ได้ออกจากคอนเทนเนอร์ที่หยุดทำงานและปริมาณรอบ ๆ ที่คุณสนใจ จะดีกว่าที่จะหาสาเหตุที่ทำให้มันเติบโตและแก้ไขในระดับคอนเทนเนอร์

เมื่อเร็ว ๆ นี้ฉันมีปัญหาที่คล้ายกันโอเวอร์เลย์ 2 ขยายใหญ่ขึ้นเรื่อย ๆ แต่ฉันคิดไม่ออกว่าอะไรกินเนื้อที่ส่วนใหญ่

df แสดงให้ฉันเห็นว่าโอเวอร์เลย์ 2 มีขนาดประมาณ 24GB

ด้วยความที่duฉันพยายามคิดหาสิ่งที่ครอบครองพื้นที่ ... และล้มเหลว

ความแตกต่างมาจากข้อเท็จจริงที่ว่าไฟล์ที่ถูกลบ (ส่วนใหญ่เป็นไฟล์บันทึกในกรณีของฉัน) ซึ่งยังคงถูกใช้โดยกระบวนการ (Docker) ดังนั้นไฟล์ไม่แสดงขึ้นด้วยแต่พื้นที่ที่หมกมุ่นอยู่กับมันจะแสดงพร้อมกับdudf

การรีบูตเครื่องโฮสต์ช่วยได้ การรีสตาร์ทคอนเทนเนอร์นักเทียบท่าอาจช่วยได้แล้ว… บทความใน linuxquestions.org นี้ช่วยให้ฉันเข้าใจได้

เพิ่มในความคิดเห็นด้านบนซึ่งมีคนแนะนำให้ตัดระบบเช่นไดรฟ์ข้อมูลห้อยที่ชัดเจนรูปภาพออกจากตู้คอนเทนเนอร์เป็นต้นบางครั้งแอปของคุณกลายเป็นผู้ร้ายแอปจะสร้างบันทึกมากเกินไปในเวลาอันสั้นและหากคุณใช้ไดรฟ์ข้อมูลโดยตรงที่ว่างเปล่า (ไดรฟ์ข้อมูลในเครื่อง ) สิ่งนี้เติมพาร์ติชัน / var ในกรณีนั้นฉันพบว่าคำสั่งด้านล่างน่าสนใจมากที่จะหาว่าอะไรกินเนื้อที่บนดิสก์ / var พาร์ติชันของฉัน

du -ahx / var / lib | เรียง -rh | หัว -n 30

คำสั่งนี้จะแสดงรายการ 30 อันดับแรกซึ่งใช้พื้นที่มากที่สุดในดิสก์เดียว หมายความว่าหากคุณใช้ที่เก็บข้อมูลภายนอกกับคอนเทนเนอร์ของคุณจะใช้เวลามากในการรันคำสั่ง du คำสั่งนี้จะไม่นับปริมาณการเมาท์ และเร็วกว่ามาก คุณจะได้รับไดเร็กทอรี / ไฟล์ที่แน่นอนซึ่งใช้พื้นที่มาก จากนั้นคุณสามารถไปที่ไดเรกทอรีเหล่านั้นและตรวจสอบว่าไฟล์ใดมีประโยชน์หรือไม่ หากจำเป็นต้องใช้ไฟล์เหล่านี้คุณสามารถย้ายไฟล์เหล่านี้ไปยังที่เก็บข้อมูลถาวรได้โดยทำการเปลี่ยนแปลงในแอพเพื่อใช้ที่เก็บข้อมูลถาวรสำหรับตำแหน่งนั้นหรือเปลี่ยนตำแหน่งของไฟล์นั้น และสำหรับการพักผ่อนคุณสามารถล้างมันได้

ฉันใช้ "docker system prune -a" มันล้างไฟล์ทั้งหมดภายใต้ไดรฟ์ข้อมูลและโอเวอร์เลย์ 2

    [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 ..