Docker Съвети: Почистете вашата машина от боклуци

Хей Хабр! Представям на вашето внимание превода на статията „Съвети за Docker: Почистете вашата локална машина“ автор Люк Джагери.

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

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

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

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

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

$ docker system df

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

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

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

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

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

• Директория /var/lib/docker/containers/container_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

Какво се случва с диска:

• изображенията заемат 126 MB, това е същият NGINX, който стартирахме в контейнера;
• контейнерите заемат смешните 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]

Нека отново разгледаме използването на дисково пространство на хоста. Ще видим, че контейнерът (контейнерите) заема 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! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Total reclaimed space: 104.9MB

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

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          0          126M       126M (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    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! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
deleted: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
deleted: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
deleted: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
deleted: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Total reclaimed space: 12.9kB

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

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

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

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

Нека стартираме 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 съхранява своите данни по подразбиране) е дефинирана като том.

Странична бележка: много изображения, които трябва да произвеждат данни, използват обеми за съхраняване на тези данни.

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

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

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

$ docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Total reclaimed space: 25.82GB
luc@saturn:~$

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

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

Да приемем, че имаме напълно просто приложение 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 .

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

$ docker system df
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    11         0          8.949kB    8.949kB

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

$ docker builder prune
WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N] y
Deleted build cache objects:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Total reclaimed space: 8.949kB

Изчисти всичко!

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

$ docker system prune
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N]

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

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