Привет Хабр! Снова.
Docker уже давно стал стандартом, и базовые команды вроде docker run, docker build или docker compose up знакомы любому разработчику. Но экосистема и инструментарий контейнеризации гораздо глубже.
В этом материале мы отойдём от банальных инструкций и разберём шесть продвинутых инструментов и настроек. Думаю, вы узнаете для себя что-нибудь новое.
Читайте первую часть по ссылке.
Dive: Рентген для образов
Dive — это инструмент с текстовым интерфейсом, который позволяет визуально исследовать каждый слой вашего образа. Вы можете пощупать файловую систему контейнера на каждом этапе его сборки. Когда вы запускаете команду:
dive <тег-или-id-образа>
Перед вами открывается экран, разделённый на две основные части. Слева вы видите список слоёв. Справа отображается дерево файлов текущего выбранного слоя.
Очень полезная функция в Dive это подсветка изменений. Вы можете переключаться между слоями, и программа будет показывать, какие файлы были добавлены, изменены или удалены именно на этом шаге, как в Git. Dive автоматически анализирует эффективность образа и показывает метрику Wasted Space (потраченное впустую пространство). Это происходит, когда вы, например, копируете файлы в одном слое, а удаляете их в другом. Фактически файлы остаются в истории образа, занимая место, хотя в финальной файловой системе их нет.
Кроме интерактивного режима, Dive умеет работать в CI/CD пайплайнах. Вы можете настроить пороговые значения для мусора в образе, и если сборка превысит этот лимит, билд упадёт:
CI=true dive <image>
SlimToolkit: Автоматическая минимизация контейнеров
Если Dive помогает вам понять проблему, то SlimToolkit (ранее известный как DockerSlim) решает её, причём радикально. Это инструмент для автоматической минимизации размера образа и безопасности контейнеров. Идея SlimToolkit заключается в том, что стандартные образы (даже Alpine) часто содержат множество утилит и библиотек, которые вашему приложению никогда не понадобятся.
Работает SlimToolkit по принципу динамического анализа. Утилита поднимает временный контейнер с вашим приложением. Далее она начинает мониторить всё, что происходит внутри: какие файлы открываются, какие системные вызовы используются, какие порты слушаются.
Вы не меняете ничего в своём контейнере, а SlimToolkit автоматически уменьшает итоговый образ в десятки раз и одновременно усиливает его безопасность. Но оптимизация размера — не единственная задача. Инструмент также помогает лучше понимать структуру контейнеров и создавать более качественные образы.
Ничего менять не требуется: используйте любой базовый образ, любой пакетный менеджер, не думайте о ручной оптимизации Dockerfile.
Инструмент успешно применяют для приложений на Node.js, Python, Ruby, Java, Go, Rust, Elixir, PHP (для некоторых типов приложений), работающих на Ubuntu, Debian, CentOS, Alpine и даже на Distroless.
Примеры минимизации размера
Node.js application images:
from ubuntu:14.04 - 432MB => 14MB (уменьшение 30.85X)
from debian:jessie - 406MB => 25.1MB (уменьшение 16.21X)
from node:alpine - 66.7MB => 34.7MB (уменьшение 1.92X)
Python application images:
from ubuntu:14.04 - 438MB => 16.8MB (уменьшение 25.99X)
from python:2.7-alpine - 84.3MB => 23.1MB (уменьшение 3.65X)
from python: 2.7.15 - 916MB => 27.5MB (уменьшение 33.29X)
Go application images:
from golang:latest - 700MB => 1.56MB (уменьшение 448.76X)
from ubuntu:14.04 - 531MB => 1.87MB (уменьшение 284.10X)
Docker Events
Перейдём от работы с образами к мониторингу самого демона Docker. Часто разработчики используют docker psв цикле или сторонние GUI, чтобы узнать, что происходит с контейнерами. Однако у Docker есть нативный механизм стриминга событий в реальном времени — Docker Events.
Команда docker system events (алиас docker events) подключается к серверу Docker и начинает транслировать поток информации обо всех изменениях состояний. Похоже на чтение логов, но на уровне оркестратора. Вы видите события создания контейнеров, их запуска, остановки, уничтожения, подключения к сетям, монтирования томов и обновления образов.
Суперский инструмент для отладки. Если у вас есть сложная система из микросервисов, и один из контейнеров постоянно перезагружается, docker events покажет точную хронологию, когда и где он умер и с каким кодом выхода, и когда был перезапущен.
Можете использовать фильтры, например --filter 'event=die', чтобы следить только за падениями, или фильтровать по конкретному имени контейнера.
Вывод ивентов за последние 10 минут:
docker events --since '10m'
2017-01-05T00:35:41.241772953+08:00 volume create testVol (driver=local)
2017-01-05T00:35:58.859401177+08:00 container create d9cd...4d70 (image=alpine:latest, name=test)
2017-01-05T00:36:04.703631903+08:00 network connect e2e1...29e2 (container=0fdb...ff37, name=bridge, type=bridge)
2017-01-05T00:36:04.795031609+08:00 container start 0fdb...ff37 (image=alpine:latest, name=test)
2017-01-05T00:36:09.830268747+08:00 container kill 0fdb...ff37 (image=alpine:latest, name=test, signal=15)
2017-01-05T00:36:09.840186338+08:00 container die 0fdb...ff37
Вывод stop ивентов:
docker events --filter 'event=stop'
2017-01-05T00:40:22.880175420+08:00 container stop 0fdb...ff37 (image=alpine:latest, name=test)
2017-01-05T00:41:17.888104182+08:00 container stop 2a8f...4e78 (image=alpine, name=kickass_brattain)
Вывод ивентов по формату:
docker events --filter 'type=container' --format 'Type={{.Type}} Status={{.Status}} ID={{.ID}}'
Type=container Status=create ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=attach ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=start ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=resize ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=die ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=destroy ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Вывод ивентов по формату JSON:
docker events --format json
{"status":"create","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4"}
{"status":"attach","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4"}
{"Type":"network","Action":"connect","Actor":{"ID":"1b50a5bf755f6021dfa78e"}
{"status":"start","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f42"}
{"status":"resize","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4"}...
Docker Sandbox: Безопасная песочница для ИИ-агентов
С развитием генеративного искусственного интеллекта и LLM возникла проблема безопасности выполнения кода, написанного нейросетью. Когда вы просите ИИ написать и выполнить скрипт, запускать его на своей основной машине или даже в стандартном контейнере может быть рискованно.
Docker Sandboxes упрощает и делает безопасным запуск AI-агентов на вашей локальной машине. Это новый подход, ориентированный на создание безопасных сред код-агентов вроде Claude Code. Sandboxes изолируют таких агентов от вашей операционной системы, но при этом сохраняют привычный рабочий процесс разработки. Агент получает возможность выполнять команды, устанавливать зависимости и изменять файлы внутри контейнера, который повторяет вашу рабочую директорию. Это позволяет дать агенту полный контроль внутри ограниченной среды, не ставя под угрозу безопасность вашего компьютера. Среды запускаются мгновенно и уничтожаются сразу после выполнения задачи.
Появилась в Docker Desktop 4.50. В данный момент функция является экспериментальной. Чтобы её использовать, нужно разрешить экспериментальные функции в конфиге Докера.
В Linux добавьте или измените строку "experimental": true в конфигурационный файл /etc/docker/daemon.json. Перезапустите Docker Engine.
В Docker Desktop это делается через Настройки > Docker Engine, где можно отредактировать JSON.
Как работает процесс
Когда вы запускаете команду docker sandbox run <agent>:
Создаётся контейнер
Docker разворачивает контейнер из заранее подготовленного шаблонного образа и монтирует вашу текущую рабочую директорию внутрь контейнера в ту же самую файловую точку.Передаются Git-настройки пользователя
Docker считывает ваши параметрыgit configuser.nameиgit configuser.emailи автоматически добавляет их в контейнер. Благодаря этому любые коммиты, которые делает агент, корректно привязываются к вашему имени и почте.Первый запуск требует авторизации
При первом использовании появится запрос на вход. Данные для авторизации сохраняются в Docker volume (постоянное хранилище) и используются автоматически при следующих запусках агентами в песочнице.Агент запускается внутри контейнера
Агент стартует внутри созданной среды с разрешениями обхода ограничений, необходимыми для выполнения команд.
Docker обеспечивает правило один workspace — одна песочница. Если вы запускаете docker sandbox run <agent> в той же директории, Docker не создаёт новый контейнер, а использует существующий.
Из-за этого сохраняется весь накопленный контекст:
установленные пакеты,
временные файлы,
любые изменения, сделанные агентом ранее.
То есть состояние рабочей среды не пропадает между сеансами агента в этом каталоге.
В отличие от обычного долгоживущего контейнера, Sandbox оптимизирован под короткие сессии выполнения недоверенного кода. Он спроектирован так, чтобы минимизировать накладные расходы на старт, но при этом обеспечить более строгую изоляцию по умолчанию. Это решение позволяет разработчикам, создающим ИИ-ассистентов, не изобретать велосипед с виртуальными машинами, а использовать привычные Docker-механизмы для безопасного тест-драйва кода, который генерирует нейросеть.
Memory-swap: Тонкая настройка памяти
Управление ресурсами это важная часть эксплуатации контейнеров, про которую часто забывают до первого падения сервера по Out Of Memory. Большинство знает про флаг --memory, ограничивающий потребление RAM. Но есть второй, не менее важный параметр — memory-swap, который определяет, как контейнер может использовать файл подкачки.
Параметр --memory-swap задаёт общий лимит памяти (RAM + Swap). Если вы зададите --memory="300m" и --memory-swap="1g", контейнер сможет использовать 300 МБ памяти и 700 МБ (1ГБ - 300МБ) свопа.
Здесь есть важные нюансы. Если вы установите --memory-swap равным --memory, вы фактически запретите контейнеру использовать своп. Подойдет для приложений, чувствительных к задержкам, которым критично работать только в быстрой RAM. С другой стороны, если вы зададите --memory-swap="-1", контейнер получит право использовать своп хост-системы без ограничений, пока тот не кончится. Грамотная настройка этой пары параметров позволяет защитить хост-систему от деградации производительности и чётко контролировать поведение приложений под нагрузкой.
Docker Offload: Облачная мощь для локальной разработки
Docker Offload — это полностью управляемый облачный сервис, который позволяет переносить сборку и запуск контейнеров в облако, используя те же инструменты Docker, что и на локальной машине. Он помогает разработчикам работать без ограничений в средах VDI или на системах, где нет поддержки вложенной виртуализации.
Суть технологии заключается в переносе выполнения контейнеров с локальной машины на удалённый сервер или в облако, сохраняя при этом элементы локальной работы.
У Docker Offload есть свои фичи:
Временные облачные окружения — автоматическое создание и удаление облачных сред под каждую контейнерную сессию.
Гибридные рабочие процессы — плавное переключение между локальным и удалённым запуском через Docker Desktop или CLI.
Безопасная коммуникация — использование зашифрованных каналов между Docker Desktop и облаком, поддержка безопасных секретов и загрузки образов.
Проброс портов и bind-mount — сохранение локального опыта разработки даже при запуске контейнеров в облаке.
Работа в VDI — возможность использовать Docker Desktop в виртуальных рабочих столах или на системах без вложенной виртуализации.
Подробнее о том, как использовать Offload.
Надеюсь, эти материалы помогут вам глубже понять возможности Docker и начать использовать фичи, экономящее время, ресурсы.
© 2025 ООО «МТ ФИНАНС»