Съвети за Docker: Почистете машината си от ненужни файлове

Здравей, Хабр! Представям ви превода на статията "Съвети за Docker: Почистете локалната си машина" автора Люк Жегери.

Днес ще говорим за това как Docker използва дисковото пространство на хост машината и как да освободим това пространство от излишни образи и контейнери.

Общо потребление

Docker е страхотен инструмент, вероятно днес малко хора се съмняват в това. Само преди няколко години, този продукт ни предостави изцяло нов начин за изграждане, доставка и стартиране на всякакви среди, спестявайки значително ресурси от процесора и оперативната памет. В допълнение (а за някои това ще е дори най-важното), Docker ни позволи да опростим и стандартизираме управлението на жизнения цикъл на използваните работни среди.

Въпреки това, за всички тези предимства на съвременния живот трябва да платим. Когато стартираме контейнери, изтегляме или създаваме собствени образи, развиваме сложни екосистеми, ние наистина плащаме. И плащаме в частност с дисково пространство.

Ако никога не сте се замисляли за това колко място всъщност е заето от Docker на вашата машина, може да останете неприятно изненадани от резултата на тази команда:

$ docker system df

Тук е показано използването на диска от Docker в различни аспекти:

• образи (images) – общият размер на образите, които са изтеглени от хранилищата на образи и изградени в системата ви;
• контейнери (containers) – общият обем дисково пространство, използван от стартираните контейнери (включва се общият обем на слоевете за четене и запис на всички контейнери);
• локални тома (local volumes) – обем на локалните хранилища, монтирани на контейнери;
• кеш за изграждане (build cache) – временни файлове, генерирани от процеса на изграждане на образи (при използване на инструмента BuildKit, наличен от Docker версия 18.09).

Готов съм да се съглася, че вече след това просто изброяване, вие горите от желание да почистите диска от боклука и да върнете обратно ценните гигабайти (забележка: особено ако за тези гигабайти плащате наем всеки месец).

Използване на диска от контейнери

Всеки път, когато създавате контейнер на хост машината, в директорията /var/lib/docker се създават няколко файла и директории, сред които си струва да споменем следните:

• Каталог /var/lib/docker/containers/ID_контейнера – при използване на стандартния драйвер за логгинг именно тук се запазват журналите на събитията в JSON формат. Твърде подробните логове, както и логовете, които никой не чете и не обработва по други начини, често стават причина за пренапълване на дисковете.
• Каталог /var/lib/docker/overlay2 – съдържа слоеве с достъп за запис на контейнерите (overlay2 – предпочитаният драйвер в повечето дистрибуции на Linux). Ако контейнерът съхранява данни в своята файлова система, именно в този каталог те ще бъдат разположени.

Нека си представим система, на която е инсталиран девствено чист Docker, никога неучаствал в стартирането на контейнерите и изграждането на образи. Неговият отчет за използването на дисковото пространство ще изглежда така:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         0          0          0B         0B
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Нека стартираме някой контейнер, например, NGINX:

$ docker container run --name www -d -p 8000:80 nginx:1.16

Какво става с диска:

• образите (images) заемат 126 Мб, това е именно NGINX, който стартирахме в контейнера;
• контейнерите (containers) заемат смешни 2 байта.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          2B         0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Съдя по изхода, нямаме още пространство, което можем да освободим. Тъй като 2 байта са съвсем незначителни, нека си представим, че нашият NGINX изненадващо е записал 100 Мегабайта данни и е създал файл test.img точно с този размер.

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

Отново изследваме използването на дисковото пространство на хоста. Ще видим, че контейнерът (containers) заема там 100 Мегабайта.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          104.9MB    0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Мисля, че вашият любопитен ум вече си задава въпроса, къде се намира нашият файл test.img. Нека го потърсим:

$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177...630078/merged/test.img
/var/lib/docker/overlay2/83f177...630078/diff/test.img

Без да навлизаме в детайли, можем да отбележим, че файлът test.img е удобно разположен на ниво за четене-запис, управлявано от драйвера overlay2. Ако обаче спрем нашия контейнер, хостът ще ни подсказа, че това място всъщност може да бъде освободено:

# Stopping the www container
$ docker stop www

# Visualizing the impact on the disk usage
$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          0          104.9MB    104.9MB (100%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Как можем да го направим? С изтриването на контейнера, което ще доведе до освобождаване на съответното пространство на ниво за четене-запис.

С помощта на следната команда можете да изтриете всички инсталирани контейнери наведнъж и да почистите диска си от всички файлове, създадени от тях на ниво за четене-запис:

$ docker container prune
WARNING! Това ще изтрие всички спряни контейнери.
Сигурни ли сте, че искате да продължите? [y/N] y
Изтрити контейнери:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Общо освободено пространство: 104.9MB

И така, освободихме 104.9 Мегабайта с изтриването на контейнера. Но тъй като вече не използваме изтегления по-рано образ, той също става кандидат за изтриване и освобождаване на нашите ресурси:

$ docker system df
ТИП           ОБЩО      АКТИВЕН     РАЗМЕР     МОЖЕ ДА БЪДЕ ОСВОБОДЕН
Образи       1          0          126M       126M (100%)
Контейнери    0          0          0B         0B
Локални обеми 0          0          0B         0B
Кеш за строеж 0          0          0B         0B

Внимание: докато образът се използва поне от един контейнер, няма да можете да използвате този трик.

Подкомандата prune, която използвахме по-горе, има ефект само върху спрени контейнери. Ако искаме да изтрием не само спрени, но и активни контейнери, трябва да използваме една от тези команди:

# Historical command
$ docker rm -f $(docker ps –aq)

# More recent command
$ docker container rm -f $(docker container ls -aq)

Забележки на полето: ако при стартиране на контейнера се използва параметър —rm, то при спирането му ще бъде освободено всичкото дисково пространство, което е заемал.

Използване на диска от образи

Преди няколко години размерът на образа от няколкостотин мегабайта беше напълно нормален: образът на Ubuntu тежеше 600 мегабайта, а образът на Microsoft .Net – няколко гигабайта. В онези времена изтеглянето дори само на един образ можеше да нанесе голяма вреда на свободното ви дисково пространство, дори и да споделяхте слоеве между образите. Днес – слава на великите – образите тежат значително по-малко, но дори и в този случай можете бързо да запълните наличните ресурси, ако не предприемете някои предпазни мерки.

Има няколко типа образи, които не са директно видими на крайните потребители:

• междинни образи, на основата на които са събрани други образи – те не могат да бъдат изтрити, ако използвате контейнери, базирани на тези "други" образи;
• висящи образи – това са такива междинни образи, на които не се позовава нито един от активните контейнери – те могат да бъдат изтрити.
• С помощта на следната команда можете да проверите наличието на висящи образи в системата си:

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     12 minutes ago      71.3MB

Можете да ги изтриете по следния начин:

$ docker image rm $(docker image ls -f dangling=true -q)

Можем да използваме и подкомандата prune:

$ docker image prune
WARNING! Това ще премахне всички висящи образи.
Сигурни ли сте, че искате да продължите? [y/N] y
Изтрити образи:
deleted: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
deleted: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
deleted: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
deleted: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
deleted: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Общо възстановено пространство: 12.9kB

Ако изведнъж искаме да изтрием всички образи (а не само висящи) с една команда, можем да направим следното:

$ docker image rm $(docker image ls -q)

Използване на дискове с томове

Томовете (volumes) се използват за съхранение на данни извън файловата система на контейнера. Например, ако искаме да запазим резултатите от работата на някакво приложение, за да ги използваме по друг начин. Чест пример са базите данни.

Нека стартираме контейнер MongoDB, да монтираме към него външен том, и да възстановим от него резервно копие на базата данни (което имаме на разположение в файла bck.json):

# Running a mongo container
$ docker run --name db -v $PWD:/tmp -p 27017:27017 -d mongo:4.0

# Importing an existing backup (from a huge bck.json file)
$ docker exec -ti db mongoimport 
  --db 'test' 
  --collection 'demo' 
  --file /tmp/bck.json 
  --jsonArray

Данните ще се намират на хост машината в каталога /var/lib/docker/volumes. Но защо не на ниво четене-запис на контейнера? Защото в Dockerfile на образа MongoDB каталогът /data/db (в който MongoDB по подразбиране съхранява своите данни) е определен като том (volume).

Забележки на полета: много образи, в резултат на работа на които трябва да се създават данни, използват томове (volumes) за запазване на тези данни.

Когато се наситим на MongoDB и спрем (или дори изтрием) контейнера, томът няма да бъде изтрит. Той ще продължи да заема нашето ценно дисково пространство, докато не го изтрием явно с такава команда:

$ docker volume rm $(docker volume ls -q)

Или можем да използваме вече познатата подкоманда prune:

$ docker volume prune
ВНИМАНИЕ! Това ще премахне всички локални обеми, които не се използват от поне един контейнер.
Сигурни ли сте, че искате да продължите? [y/N] y
Изтритите обеми:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Обща възстановена площ: 25.82GB
luc@saturn:~$

Използване на диска за кеш на изграждане на образи

В Docker 18.09 процесът на създаване на образи претърпя някои промени благодарение на инструмента BuildKit. С него се увеличава скоростта на процеса, оптимизира се управлението на данните и сигурността. Тук няма да разглеждаме всички детайли на този прекрасен инструмент, а само как той влияе на въпросите за използването на дисковото пространство.

Да предположим, че имаме съвсем простo приложение Node.js:

• файлът index.js стартира прост HTTP сървър, който отговаря с низ на всеки получен запит:
• файлът package.json определя зависимостите, от които се използва само expressjs за стартиране на HTTP сървъра:

$ cat index.js
var express = require('express');
var util    = require('util');
var app = express();
app.get('\\', function(req, res) {
  res.setHeader('Content-Type', 'text/plain');
  res.end(util.format("%s - %s", new Date(), 'Got Request'));
});
app.listen(process.env.PORT || 80);

$ cat package.json
    {
      "name": "testnode",
      "version": "0.0.1",
      "main": "index.js",
      "scripts": {
        "start": "node index.js"
      },
      "dependencies": {
        "express": "^4.14.0"
      }
    }

Dockerfile за изграждане на образа изглежда така:

FROM node:13-alpine
COPY package.json \/app\/package.json
RUN cd \/app && npm install
COPY . \/app\/
WORKDIR \/app
EXPOSE 80
CMD ["npm", "start"]

Нека изградим образа по обичайния начин, без да използваме BuildKit:

$ docker build -t app:1.0 .

Ако проверим използването на дисковото пространство, ще видим, че мястото заемат само базовият образ (node:13-alpine) и крайният образ (app:1.0):

TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

Да изградим втора версия на нашето приложение, вече с използване на BuildKit. За целта просто трябва да зададем променливата DOCKER_BUILDKIT на стойност 1:

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

Ако сега проверим използването на диска, ще видим, че сега участва и кеш за изграждане (build-cache):

$ docker system df
ТИП           ОБЩО      АКТИВЕН     РАЗМЕР       ВЪЗСТАНОВИМ
Образи       2          0          109.3MB    109.3MB (100%)
Контейнери    0          0          0B         0B
Локални обеми 0          0          0B         0B
Кеш за изграждане 11         0          8.949kB    8.949kB

За да го изчистим, ще използваме следната команда:

$ docker builder prune
ПРЕДУПРЕЖДЕНИЕ! Това ще премахне всички висящи кешове за изграждане.
Сигурни ли сте, че искате да продължите? [y/N] y
Изтрити обекти на кеша за изграждане:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Общо възстановено пространство: 8.949kB

Изчистване на всичко!

И така, разгледахме как да изчистим дисковото пространство, заето от контейнери, образи и томове. В това ни помага подкомандата prune. Но тя може да се използва и на системно ниво на docker и ще изчисти всичко, което само може:

$ docker system prune
ПРЕДУПРЕЖДЕНИЕ! Това ще премахне:
  - всички спряни контейнери
  - всички мрежи, които не се използват поне от един контейнер
  - всички висящи образи
  - всички висящи кешове за изграждане

Сигурни ли сте, че искате да продължите? [y/N]

Ако по някакви причини пестите дисково пространство на машина с Docker, периодичното стартиране на тази команда е добра практика.

Източник: habr.com