Docker / overlay2 / temizlemek güvenli midir

AWS EC2 üzerinde çalışan bazı docker container'larım var, / var / lib / docker / overlay2 klasörü disk boyutunda çok hızlı büyüyor.

İçeriğini silmenin güvenli olup olmadığını merak ediyorum. veya docker, disk kullanımının bir kısmını boşaltmak için bir tür komuta sahipse.

GÜNCELLEME:

Aslında docker system prune -azaten denedim , bu da 0Kb'yi geri aldı.

Ayrıca / docker / overlay2 disk boyutum, docker system df

Docker belgelerini ve BMitch'in cevabını okuduktan sonra, bu klasöre dokunmanın aptalca bir fikir olduğuna inanıyorum ve disk alanımı geri kazanmak için başka yollar deneyeceğim.

Docker, görüntülerinizi, kapsayıcılarınızı ve yerel adlandırılmış birimlerinizi depolamak için / var / lib / docker kullanır. Bunu silmek veri kaybına neden olabilir ve muhtemelen motorun çalışmasını durdurabilir. Overlay2 alt dizini özellikle görüntüler ve kaplar için çeşitli dosya sistemi katmanlarını içerir .

Kullanılmayan kapları ve görüntüleri temizlemek için bkz docker system prune. Birimleri ve hatta etiketli görüntüleri kaldırma seçenekleri de vardır, ancak bunlar veri kaybı olasılığı nedeniyle varsayılan olarak etkinleştirilmez.

Bunun benim için en iyi şekilde çalıştığını buldum:

docker image prune --all

Varsayılan olarak Docker, kullanılmamış olsalar bile adlandırılmış görüntüleri kaldırmaz. Bu komut, kullanılmayan resimleri kaldıracaktır.

Bir görüntüdeki her katmanın, klasörün içindeki bir klasör olduğunu unutmayın /usr/lib/docker/overlay2/.

Bu sorunu yaşadım ... Çok büyük olan kütüktü. Günlükler burada:

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

Bunu çalıştır komut satırında veya oluşturma dosyasında yönetebilirsiniz. Oraya bakın: Günlük sürücülerini yapılandırın

Bu 3 satırı kişisel olarak docker-compose.yml dosyama ekledim:

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

ayrıca hızla büyüyen sorunları vardı overlay2

/var/lib/docker/overlay2- docker'ın konteyneriniz için yazılabilir katmanları depoladığı bir klasördür. docker system prune -a- yalnızca konteyner durdurulduğunda ve çıkarıldığında çalışabilir.

benimde, içine overlay2girip araştırarak neyin alanı tükettiğini anlayabildim .

bu klasör diğer hash isimli klasörleri içerir. her birinin klasör dahil birkaç diffklasörü vardır.

diff klasör - kapsayıcınız olarak tam klasör yapısına sahip bir kap tarafından yazılan gerçek farkı içerir (en azından benim durumumda - ubuntu 18 ...)

bu yüzden konteynerimin içinde kirlenen klasör du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpolduğunu anlamaya /tmpalıştım .

Bu nedenle, geçici bir çözüm olarak, iç klasörü ana bilgisayarla eşleştirmek ve bu klasörü temizlemek için ana bilgisayarda bir cron kurmak -v /tmp/container-data/tmp:/tmpiçin docker runkomut parametresini kullandım /tmp.

cron görevi basitti:

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

NOT: overlay2sistem docker klasörüdür ve yapısını istedikleri zaman değiştirebilirler. Yukarıdaki her şey, orada gördüklerime dayanıyor. Docker klasör yapısına girmem gerekiyordu çünkü sistem tamamen boştu ve hatta docker konteynerine ssh yapmama izin vermiyordu.

UYARI: ÜRETİM SİSTEMİNDE KULLANMAYIN

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

Tamam, önce sistem budamayı deneyelim

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

Pek iyi değil, birkaç megabaytı temizlemiş gibi görünüyor. Şimdi delirelim:

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

Güzel! Bunun bir atma sunucusu dışında hiçbir şey için ÖNERİLMEZ. Bu noktada Docker'ın dahili veritabanı bu kaplamaların hiçbirini bulamayacak ve istenmeyen sonuçlara neden olabilir.

Backgroud

Sorunun suçu, konteyner birimlerinin yanlış yapılandırılması ile bu birimlere yazılan geçici verilerin docker sızıntısı (serbest bırakılamaması) ile ilgili bir sorun arasında bölünebilir. Uygulamalarımızın sık ve / veya yoğun bir şekilde yazdığı, kapsayıcının tüm geçici / günlükleri / sıfırdan klasörlerini eşlemeliyiz (klasörleri veya diğer kalıcı depolama taleplerini barındırmak için). Docker, varsayılan olarak /var/lib/docker/overlay2/*/diff/*. Bu "kalıcı olmayan" klasörlerin içeriği, konteyner durdurulduktan sonra docker tarafından otomatik olarak temizlenmelidir, ancak görünüşe göre değildir (konteyner hala çalışıyorsa ana bilgisayar tarafından temizlemek bile imkansız olabilir - ve aylarca çalışabilir. zamanında).

Geçici çözüm

Bir geçici çözüm, dikkatli bir manuel temizlik gerektirir ve başka bir yerde zaten açıklanmış olsa da, mümkün olduğunca öğretici ve genelleştirilebilir yapmaya çalıştığım vaka çalışmamdan bazı ipuçları bulabilirsiniz.

Suçlu uygulama (benim durumumda clair-scanner) /diff/tmpliman işçilerinin alt klasörüne birkaç ay boyunca yüzlerce konser veri yazmayı başardı.overlay2

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

271G total

Bu nedenle, içindeki tüm alt klasörler /diff/tmpoldukça açıklayıcı olduğundan (tümü clair-scanner-*biçimdeydi ve eski oluşturulma tarihlerine sahipti), ilişkili kapsayıcıyı ( docker stop clair) durdurdum ve bu eski alt klasörleri dikkatlice kaldırdım diff/tmp, tek bir (en eski) klasörle ihtiyatlı bir şekilde başlayarak ve docker motoru üzerindeki etkiyi test etmek ( systemctl restart dockerdisk alanını geri kazanmak için [ ] yeniden başlatmayı gerektiriyordu ):

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'ı yeniden kurmaya veya tüm klasörlerini temizlemeye gerek kalmadan yüzlerce disk alanını geri kazandım. Disk alanını geri kazanmak için docker daemon yeniden başlatılması gerektiğinden, çalışan tüm kapsayıcıların bir noktada durdurulması gerekiyordu, bu nedenle önce yük devretme kapsayıcılarınızın bir / diğer düğümde / düğümlerde doğru şekilde çalıştığından emin olun. Keşke docker prunekomut eski /diff/tmp(veya hatta /diff/*) verileri de (başka bir anahtar aracılığıyla) kapsayabilir .

Bu 3 yıllık bir sorun, zengin ve renkli geçmişini Docker forumlarında okuyabilirsiniz, burada yukarıdaki çözümün uygulama günlüklerini hedefleyen bir varyant 2019'da önerildi ve birkaç kurulumda işe yaradığı görülüyor: https: // forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

ÜRETİMDE YAPMAYIN

@ Ravi-luthra tarafından verilen cevap teknik olarak işe yarıyor ama bazı sorunları var!

Benim durumumda, sadece disk alanını kurtarmaya çalışıyordum. lib/docker/overlayKlasör alanı 30GB alıyordu ve sadece düzenli bir kaç konteyner çalıştırın. Görünüşe göre docker veri sızıntısı ile ilgili bazı sorunlar yaşıyor ve konteyner durduğunda bazı geçici veriler temizlenmiyor.

Ben de devam ettim ve lib/docker/overlayklasörün tüm içeriğini sildim . Bundan sonra docker örneğim kullanılamaz hale geldi. Herhangi bir konteyneri çalıştırmayı veya oluşturmayı denediğimde, bana şu hatayı verdi:

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

Sonra biraz deneme yanılma ile bu sorunu şu şekilde çözdüm:

(UYARI: Bu, docker birimlerindeki tüm verilerinizi silecektir)

docker system prune --volumes -a

Bu nedenle, sistemin nasıl çalıştığını tamamen anlamadığınız sürece bu tür kirli temizliklerin yapılması önerilmez.

/ Var / lib / docker'daki her şey, konteynerlerin dosya sistemleridir. Tüm kaplarınızı durdurursanız ve budarsanız, klasörün boş olması gerekir. Muhtemelen bunu gerçekten istemiyorsunuzdur, bu yüzden oradaki şeyleri rastgele silmeye gitmeyin. / Var / lib / docker içindeki şeyleri doğrudan silmeyin. Bazen bundan kurtulabilirsiniz, ancak birçok nedenden dolayı bu tavsiye edilmez.

Bunun yerine şunu yapın:

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

Altta gösterilen en büyük dosyalardır. İsterseniz, bu dosyaların hangi kaplarda olduğunu bulun, bu kaplara girin docker exec -ti containername -- /bin/shve bazı dosyaları silin.

Ayrıca, docker system prune -a -filgilendiğiniz etrafında durdurulmuş kaplar ve hacimler bırakmadığınız sürece günlük / haftalık bir cron işi de koyabilirsiniz . Neden büyüdüğünü anlamak ve bunları kapsayıcı düzeyinde düzeltmek daha iyidir.

Yakın zamanda benzer bir sorun yaşadım, overlay2 gittikçe büyüdü, ancak alanın büyük bir kısmını neyin tükettiğini anlayamadım.

df overlay2'nin yaklaşık 24GB boyutunda olduğunu gösterdi.

Bununla birlikte dualanı neyin işgal ettiğini anlamaya çalıştım… ve başarısız oldum.

Fark, silinen dosyaların (benim durumumda çoğunlukla günlük dosyaları) hala bir işlem tarafından (Docker) kullanıldığı gerçeğinden kaynaklanıyor. Böylece dosya birlikte görünmez, duancak kapladığı alanla birlikte gösterilir df.

Ana makinenin yeniden başlatılması yardımcı oldu. Docker konteynerini yeniden başlatmak muhtemelen yardımcı olabilirdi… linuxquestions.org'daki bu makale bunu anlamama yardımcı oldu.

İnsanların net sarkan hacimler, resimler, çıkış kapları vb. gibi sistemi budamasını önerdiği yukarıdaki yoruma ek olarak, Bazen uygulamanız suçlu hale gelir, kısa sürede çok fazla günlük oluşturdu ve boş doğrudan hacim (yerel hacimler) kullanıyorsanız ) bu / var bölümlerini doldurur. Bu durumda, / var bölüm diskimde neyin yer kapladığını anlamak için aşağıdaki komutu çok ilginç buldum.

du -ahx / var / lib | sırala -rh | kafa -n 30

Bu komut, tek bir diskte en çok yer kaplayan ilk 30'u listeleyecektir. Konteynırlarınızla harici depolama kullanıyorsanız, du command çalıştırmak için çok zaman harcanması anlamına gelir. Bu komut bağlama birimlerini saymaz. Ve çok daha hızlı. Yer kaplayan tam dizinleri / dosyaları alacaksınız. Sonra bu dizinlere gidebilir ve hangi dosyaların yararlı olup olmadığını kontrol edebilirsiniz. Bu dosyalar gerekliyse, o konum için kalıcı depolamayı kullanmak veya o dosyaların konumunu değiştirmek için uygulamada değişiklik yaparak bunları kalıcı bir depolamaya taşıyabilirsiniz. Ve dinlenmek için onları temizleyebilirsiniz.

"Docker system prune -a" kullandım, ciltler ve overlay2 altındaki tüm dosyaları temizledi

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