Мы уверенны что среди наших клиентов, есть много профессионалов IT, работающих над интересными проектами. Если у Вас возникает желание рассказать о них, Вы можете разместить статью в нашем блоге. А чтоб было интересней, мы сделали конкурс статей, каждый месяц три победителя будут получать призы.
Статья также доступна на украинском (перейти к просмотру).
Содержание:
- Где Docker хранит данные
- Как проверить, что именно занимает место
- Удаление контейнеров
- Удаление шаблонов
- Удаление volume
- Очистка build cache
- Полная очистка Docker
- Docker Compose
- Логи контейнеров
- Рекомендации для VPS
- Выводы
Многим знакома ситуация, когда на сервере вдруг заканчивается свободное место за счет того, что Docker занимает десятки гигабайт и постоянно расширяется. Проверка системы с помощью команд docker system df и df -h при этом дает противоречивые результаты, и поэтому пользователь не понимает, что именно нужно удалять. Сущность проблемы заключается в сложном строении файловой системы (layered filesystem) и особенностях организации хранения данных в Docker. Владея базовой информацией по механизмам хранения данных в Docker, можно предотвратить возникновение критической ситуации и повысить производительность системы. Рассмотрим базовые понятия, а также методы анализа и очищения Docker от лишних и/или неиспользованных данных.
Рекомендуем ознакомиться со статьей "Заканчивается место на VPS: как найти, что занимает диск в Ubuntu".
Где Docker хранит данные
В среде Linux стандартным местом хранения всех данных является корневой каталог /var/lib/docker/. Каталог содержит ряд подкаталогов для разных типов данных. Рассмотрим ключевые из них:
Overlay2 – стандартный драйвер хранилища в Linux или storage driver, управляющий хранением контейнеров и шаблонов на Docker-узле.
Containers – контейнеры представляют собой автономные приложения или сервисы, временно созданные на базе шаблонов image. В контексте Linux они являются изолированными процессами, которые можно создать в любой момент времени, запустить, остановить или удалить.
Volumes – тома определяют место хранения данных (локальное или внешнее), независимо от файловой системы контейнера.
Image – шаблоны содержат функциональные зависимости, библиотеки и другие данные, необходимые для обеспечения автономной работы контейнеров. Они многослойные, где каждый уровень фиксирует определенные изменения файловой системы контейнера.
Buildkit – кэш сборки или Build Cache, который генерируется во время сборки шаблона.
Исходя из приведенных определений, в частности, можно сделать следующие выводы:
Удаление контейнера не удаляет шаблон, на основе которого он создан, а только ликвидирует временно созданный изолированный процесс;
-
Удаление шаблона не удаляет объем, а только ликвидирует данные и контекст сборки определенной контейнерной среды;
-
При работе контейнеров, как и любых других процессов, выполняется логирование, и, соответственно, логи контейнеров также занимают на диске место.
Как проверить, что именно занимает место
Для демонстрации и лучшего понимания процесса обнаружения и удаления лишних данных нам понадобится собственный Docker-шаблон. Создадим его с помощью приведенных ниже команд.
Создадим каталог, который в дальнейшем станет контекстом сборки для нашего шаблона:
$ mkdir dock $ cd dock
В каталоге dock создадим файл с именем dockerfile и разместим в нем следующий код:
$ sudo nano dockerfile
FROM python:latest //Определение данных шаблона
RUN mkdir -p /usr/myproject///Создание директории
WORKDIR /usr/myproject/ //Установление рабочей директории проекта
CMD ["python", "main.py"]//Определение команды на старте контейнера
После сохранения внесенных изменений соберем шаблон с именем my_app:v1с помощью команды:
$ sudo docker build . -t my_app:v1
Здесь опция -t позволяет указать имя шаблона, а символ «.» перед ней указывает текущий каталог в качестве контекста сборки. .
Сокращенный выход команды:
[+] Building 79.9s (7/7) FINISHED docker:default => [internal] load build definition from dockerfile 0.7s => => transferring dockerfile: 137B 0.0s => [internal] load metadata for docker.io/library/python:latest 3.4s => [internal] load .dockerignore 0.6s => => transferring context: 2B 0.0s => [1/3] FROM docker.io/library/python:latest@sha256:151ab3571dad616bb031052e86411e2165295c7f67ef27206852203e854bcd12 67.3s => => resolve ..................................................................................................................................... .................................................................................................................................... sha256:48adf976412b12c3683dd37d9d0ccd7e8dc20a70e8a80f20d35ddd70bc088838 0.1s => => naming to docker.io/library/my_app:v1 0.0s => => unpacking to docker.io/library/my_app:v1 0.4 Переглянути список шаблонів, котрі є у нашій системі можна за допомогою команди: $ sudo docker image ls IMAGE ID DISK USAGE CONTENT SIZEEXTRA hello-world:latest05813aedc15f 25.9kB 9.52kB U my_app:v1 48adf976412b 1.61GB 414MB
Кроме созданного нами my_app:v1 здесь также присутствует шаблон hello-world:latest.
Столбцы DISK USAGE и CONTENT SIZE предоставляют информацию о местоположении на диске в целом и по размеру контента.
Нередко может оказаться полезной подробная информация по каждому из слоев шаблона, в частности, для определения занимаемых ими мест. Провести такой анализ можно с помощью команд docker history и docker inspect..
Продемонстрируем это:
$ sudo docker history my_app:v1 IMAGE CREATED CREATED BY SIZE COMMENT 48adf976412b 41 hours ago CMD ["python" "main.py"] 0B buildkit.dockerfile.v0 <missing> 41 hours ago WORKDIR /usr/myproject/ 4.1kB buildkit.dockerfile.v0 <missing> 41 hours ago RUN /bin/sh -c mkdir -p /usr/myproject/ # bu… 12.3kBbuildkit.dockerfile.v0 <missing> 11 days agoCMD ["python3"] 0B buildkit.dockerfile.v0 <missing> 11 days agoRUN /bin/sh -c set -eux; for src in idle3 p… 16.4kB buildkit.dockerfile.v0 <missing> 11 days agoRUN /bin/sh -c set -eux; savedAptMark="$(a… 82.2MB buildkit.dockerfile.v0 <missing> 11 days agoENV PYTHON_SHA256=a97d5549e9ad81fe17159ed02c… 0B buildkit.dockerfile.v0 <missing> 11 days agoENV PYTHON_VERSION=3.14.3 0B buildkit.dockerfile.v0 <missing> 11 days agoRUN /bin/sh -c set -eux; apt-get update; a… 19.9MBbuildkit.dockerfile.v0 <missing> 11 days agoENV PATH=/usr/local/bin:/usr/local/sbin:/usr… 0B buildkit.dockerfile.v0 <missing> 13 days agoRUN /bin/sh -c set -ex; apt-get update; ap… 694MB buildkit.dockerfile.v0 <missing> 13 days agoRUN /bin/sh -c set -eux; apt-get update; a… 202MB buildkit.dockerfile.v0 <missing> 13 days agoRUN /bin/sh -c set -eux; apt-get update; a… 65MB buildkit.dockerfile.v0 <missing> 2 weeks ago# debian.sh --arch 'amd64' out/ 'trixie' '@1… 134MB debuerreotype 0.17
С помощью команды history можно получить информацию об идентификаторе шаблона; время его создания; команды, которые использовались для каждого слоя; размер; сообщение от драйвера кэша.
Другую информацию можно получить с помощью команды проверить:
$ sudo docker inspect --format '{{json .RootFS.Layers}}' my_app:v1
Здесь мы форматировали выход команды с помощью пользовательского шаблона json. Результаты выполнения приведены ниже.
["sha256:d16566b6c5a6bd5c45da221a2fc94937d8d503c920c8627f154a2f8a57537da4","sha256:3dc84f17a3999c0ab5fc2ef9c360dde19a663f4c22cbcec9e1b507fa3ca4222d","sha256:222b6d2e7e9f54c3f0013d281f37408ecd1c690fba9b7230138187da42415cf6","sha256:05f2b78449c812b7301720f11a1a2e4c2b8fc0229e2433b9aa0b619f2cade10a","sha256:96fc0777a58100b18b903a7e88704df66e8e9272647a732271287def69586a9a","sha256:5b1da75dbec265d08f3518d63dc6ec9317d4196024302d4724ce775648b5b362","sha256:c2bc34f33e3a3d9fc75b76bc4bf8c29b62e7c9ccc26f0ce610487f7efa0eb1bc","sha256:d990813ef0375de95e633fc39b5ec62185a4594b42dcf4b3306c8e58e12ebe08","sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"]
Мы получили девять слоев шаблона my_app:v1 в виде хешей SHA256. Каждый шаблон имеет криптографический хэш или дайджест, основанный на содержании его слоев. При отправке или загрузке шаблона дайджест используется для контроля его целостности.
Просмотр потребления памяти Docker в файловой системе хоста можно так:
$ sudo docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 2 1 1.611GB 104.6kB (0%) Containers 1 0 4.096kB 4.096kB (100%) Local Volumes 0 0 0B 0B Build Cache 11 0 1.611GB 12.29kB
Команда предоставляет информацию об использовании диска Docker в нескольких категориях: шаблоны, контейнеры, локальные тома и кэш сборки.
По результатам можно понять, что большая часть дискового пространства может быть восстановлена ??и возвращена хост-компьютеру, поскольку не все эти данные нужны Docker. Особенно это касается содержимого Создать кэш, который занимает столько же места, сколько все шаблоны вместе.
Та же команда с опцией -в дает результаты в более расширенном формате:
$ sudo docker system df -v Images space usage: REPOSITORYTAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS my_app v1 48adf976412b 42 hours ago 1.61GB 0B 1.611GB 0 hello-world latest05813aedc15f 6 months ago 25.9kB 0B 25.9kB 1 Containers space usage: CONTAINER ID IMAGE COMMANDLOCAL VOLUMES SIZE CREATED STATUS NAMES e9420d894d77 hello-world "/hello" 0 4.1kB 12 days ago Exited (0) 12 days ago cool_cray Local Volumes space usage: VOLUME NAME LINKS SIZE Build cache usage: 1.611GB CACHE ID CACHE TYPE SIZE CREATED LAST USED USAGE SHARED ocbvf7mtbt5v regular 183MB 42 hours ago 42 hours ago 1 true h0ybalxd04nz regular 90.6MB42 hours ago 42 hours ago 1 true s7vqc0xwa076 regular 270MB 42 hours ago 42 hours ago 1 true 3264z8l74jf5regular 930MB 42 hours ago 42 hours ago 1 true y73i1rof03sxregular 26MB 42 hours ago 42 hours ago 1 true v6j7jnhvxxa2 regular 112MB 42 hours ago 42 hours ago 1 true som9zatjipwv regular 16.5kB 42 hours ago 42 hours ago 1 true a7bkawsvjwdh regular 4.13kB 42 hours ago 42 hours ago 1 true u2hirnr07j61 source.local 8.19kB 42 hours ago 42 hours ago 1 false xa5bfnuj4lpg source.local 4.1kB 42 hours ago 42 hours ago 1 false dfyl3902roiu regular 16.6kB 42 hours ago 42 hours ago 1 true
Также может быть полезна команда, которая выводит информацию об использовании дискового пространства стандартными и монтируемыми каталогами. Linux:
$ sudo df -h Filesystem Size UsedAvail Use% Mounted on udev 2.4G 0 2.4G 0% /dev tmpfs 480M1.8M 478M 1% /run /dev/vda2 38G 7.7G 29G 22% / tmpfs 2.4G 0 2.4G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 480M 0 480M 0% /run/user/
Удаление контейнеров
При использовании Docker следует удалять ненужные контейнеры, чтобы они не загрязняли среду и не занимали место на диске.
В этом можно просто убедиться. К примеру, после создания нами двух контейнеров на базе имеющихся шаблонов, места на диске для них стало тратиться больше. Проверить это можно с помощью уже известной нам команды:
$ sudo docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 2 2 1.611GB 1.611(100%) Containers 3 0 86.02kB 86.02kB (100%) Local Volumes 0 0 0B 0B Build Cache 11 0 1.611GB 12.29kB
Первый раз контейнеры занимали только 4,096 kB, а теперь 86,02 kB, то есть, в 20 раз больше. Удалив лишние, мы освободим место на диске. Но для этого мы должны знать ID или имя контейнера.
Вывести список всех имеющихся в системе контейнеров (активных и остановленных) можно с помощью команды:
$ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 074b6bc4f4a0my_app:v1 "python main.py" 17 minutes ago Exited (2) 17 minutes ago focused_jemison bd59f1999239 hello-world "/hello" 24 minutes ago Exited (0) 24 minutes ago hardcore_shirley e9420d894d77 hello-world "/hello" 12 days ago Exited (0) 4 minutes ago cool_cray
exited (выполнен выход). В таком случае команда ps будет выглядеть следующим образом:
$ sudo docker ps -a -f status=exited
Здесь мы использовали опцию -f для выполнения операции фильтрации.
Теперь мы сможем контролировать ситуацию.
К примеру, удалим контейнер со статусом вздохнул, созданный на базе шаблона my_app:v1.
Останавливаем его:
$ sudo docker stop 074b6bc4f4a0
В случае успешного выполнения на выходе получим его идентификатор:
074b6bc4f4a0
Удаляем:
$ sudo docker rm 074b6bc4f4a0 074b6bc4f4a0
Удалить все остановленные контейнеры можно с помощью команды:
$ sudo docker container prune WARNING! This will remove all stopped containers. Are you sure you want to continue? [y/N] y Deleted Containers: 5e34c067f59c27fe8eb196ee3d5fba09d87b246ebcf00368db51c7f62d749602 6e3f084c1f8097afe82e5241f11811476b7a488f3b1059d1d644ee9e87ad0a8a 00a688034a328c410cb02ea2ee48e800d97e5251aed221c465bb663c9414a3f3 bd59f19992393c4365f3514adc86a657ea940e7618412061616e3d7fb46aaca6 e9420d894d775e01ae0a041d2f11a083987d2f93256fecc458916db1977c7725 Total reclaimed space: 94.21kB
Одним из путей оптимизации расхода дискового пространства может стать использование опции –rm при запуске контейнеров, обеспечивающей их автоматическое удаление на выходе.
Пример команды:
$ docker run --rm <имя шаблона>
Удаление шаблонов
Со временем в процессе работы накапливается немало неиспользуемых шаблонов. (unused) и тех, кто находится во взвешенном состоянии или, как говорится, зависшие шаблоны (dangling).
Первые из них не используются ни одним контейнером (активным или остановленным). У других нет тега и имени репозитория и в списках шаблонов отображаются как <none>:<none>. Все они вместе могут занимать значительный объем дискового пространства и поэтому нуждаются в удалении.
Следует отметить, что удаление любых шаблонов должно происходить только после удаления используемых контейнеров. В противном случае операция не будет исполнена.
Приведем примеры некоторых команд.
Удаление dangling-шаблонов:
$ docker images -f dangling=true $ docker image prune
Удаление определенного шаблона по его ID:
$ docker rmi <image id>
Удаление всех шаблонов, к которым не привязан ни один контейнер (dangling + unused):
$ docker image prune –a
При этом команда выдаст следующее сообщение:
WARNING! This will remove all images without at least one container associated to them. Are you sure you want to continue? [y/N]
После подтверждения своего согласия на удаление операция будет исполнена.
Поиск и удаление по определенному шаблону с помощью оператора схватить:
$ docker images -a | grep "pattern"
Удаление volume
Томы являются местом хранения данных и могут быть нескольких типов: анонимные, именуемые и Bind Mounts (связаны с хостом). Приведем главные команды для работы с томами.
Вывести список всех зарегистрированных в системе томов.
$ sudo docker volume ls Результат может быть следующим: #DRIVER VOLUME NAME #local b45436c7f8bab37c0bfe998f
Удаление одного или нескольких томов по их имени, при условии, что они не используются ни одним контейнером:
$ docker volume rm [OPTIONS] VOLUME [VOLUME...]
Удаление всех неиспользуемых локальных томов (Unused):
$ docker volume prune
Следует отметить, что тома содержат реальные данные и поэтому их удаление означает удаление данных проекта. В частности, они могут содержать БД.
Очистка build cache
Просматривая результаты выполнения команды docker system df , мы уже обращали внимание, что содержимое Создать кэш занимает на диске не меньше места, чем все имеющиеся в системе шаблоны (Build cache usage: 1.611GB). И это понятно, поскольку кэш используется для оптимизации производительности. Docker за счет кэширования данных шаблонов. С другой стороны это может перезагрузить диск, что особенно ощутимо при частом выполнении операций сборки. Для этого необходимо периодически выполнять его очищение.
Рассмотрим использование нескольких команд.
Первая команда:
$ sudo docker builder prune WARNING! This will remove all dangling build cache. Are you sure you want to continue? [y/N]
Команда предлагает удалить все dangling-данные кэша, которые не привязаны ни к одному шаблону с тегом. Для их удаления достаточно подтвердить операцию.
Вторая команда:
$ sudo docker builder prune
WARNING! This will remove all dangling build cache. Are you sure you want to continue? [y/N]
Команда выполняет полную очистку кэша при подтверждении операции.
Полная очистка Docker
Продемонстрируем использование нескольких команд для полной очистки системы.
$ sudo docker system prune WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all dangling images - unused build cache Are you sure you want to continue? [y/N]
Команда удаляет все остановленные контейнеры; взвешенные шаблоны; сети, не привязанные ни к одному контейнеру; данные кэша, которые не используются.
$ sudo docker system prune -a WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all anonymous volumes 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]
Команда удаляет все остановленные контейнеры; все сети и шаблоны, которые не привязаны ни к одному контейнеру; весь кэш сборника.
$ sudo docker system prune -a --volumes WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all anonymous volumes 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]
Команда удаляет все остановленные контейнеры; все сети, анонимные тома и шаблоны, которые не привязаны ни к одному контейнеру; весь кэш сборника.
Обращаем внимание, что указанные команды, особенно последнюю, можно использовать только при условии ясного понимания последствий их выполнения.
Docker Compose
Рассмотрим эффективный инструмент для корректного завершения работы и очистки сетей, контейнеров, томов и шаблонов Docker. Это команда docker Compose Down. В отличие от нее, команда docker Compose Stop только останавливает контейнеры, не трогая их содержимое.
При применении команды на практике можно получить следующий результат:
$ docker-compose down Stopping docker-compose-mydemo_cont ... done Removing docker-compose-mydemo_cont ... done Removing network docker-compose-mydemo_def Network testnet is external, skipping
Network testnet is external, skipping
По результатам ее выполнения можно сделать следующие выводы:
-
Останавливаются и удаляются все контейнеры, указанные в файле Docker Compose;
-
Удаляются все внутренние сети, созданные Docker Compose;
-
Том с данными не удаляются.
Теперь применим ее с опцией --volumes (-v):
$ docker-compose down --volumes Stopping docker-compose-mydemo_cont ... done Removing docker-compose-mydemo_cont ... done Removing network docker-compose-mydemo_def Network testnet is external, skipping Removing volume docker-compose-mydemo_data
В отличие от предыдущего варианта, теперь также удаляются тома volume с данными, что делает команду более кардинальной, и поэтому применять ее можно только с большой осторожностью.
Логи контейнеров
Как уже отмечалось, осуществляется логирование каждого контейнера, причем, как внутри, так и снаружи.VPS-хосты. Стандартный путь для их хранения: /var/lib/docker/containers/.log.
С течением времени файлы логов могут значительно увеличиваться в размерах. Docker не имеет устроенного механизма для их очистки, а только предоставляет инструменты для их просмотра, поэтому необходимо применять вспомогательные механизмы. Рассмотрим некоторые из них.
Вывести логи из определенного контейнера можно с помощью команды:
$ docker logs -f <container ID>
При этом контейнер может быть как активным, так и остановленным.
Найти файл логов на хосте можно с помощью команды:
$ docker container inspect <container ID> | grep LogPath
Вывести его содержимое:
$ cat $(docker inspect --format "{{.LogPath}}" <container ID>)
Выполнить очистку журнала логов без его удаления можно с помощью команды:
$ sudo sh -c 'echo "" > $(docker inspect --format="{{.LogPath}}" <container ID>)'
Большинство драйверов логирования Docker поддерживают ротацию логов. Ее можно включить глобально или отдельно для каждого контейнера. Стандартно ее глобальное включение и настройку можно выполнить в файле /etc/docker/daemon.json. Пример кода приведен ниже.
{
"log-opts": {
"max-size": "7m",
"max-file": "3"
}
}
Здесь логи контейнеров ротируются сразу по достижении ими размера 7 МБ. В каждый момент времени может храниться до трех файлов.
После сохранения внесенных изменений следует перезапустить главный процесс Docker:
$ systemctl restart docker
Рекомендации для VPS
Предоставим основные рекомендации по предотвращению загрязнения Docker-среды вашего хоста:
-
Регулярно проверять docker system df;
-
Включить лог-ротацию;
-
Использовать --rm для временных контейнеров;
-
Выносить данные на отдельный диск;
-
Не удалять вручную каталог /var/lib/docker
Выводы
Основные выводы по теме:
-
Docker хранит данные слоями;
-
Контейнеры, шаблоны и volumes – разные сущности;
-
Очистка должна быть осознанной;
-
Важно понимать, что именно удаляется.
Подписывайтесь на наш Telegram-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов
Смотрите наш канал YouTube на https://www.youtube.com/freehostua.
Мы в чем ошиблись, или что-то пропустили?
Напишите об этом в комментариях, мы с удовольствием ответим и обсуждим Ваши замечания и предложения.
|
Дата: 20.02.2026 Автор: Александр Ровник
|
|
Авторам статьи важно Ваше мнение. Будем рады его обсудить с Вами:
comments powered by Disqus