Docker на Astra Linux: что не заводится сразу и как это чинить

MAATRIX

Если вы ставили Docker десятки раз на Ubuntu или Debian и привыкли, что после apt install docker.io и systemctl enable --now docker всё просто работает — на Astra Linux этот сценарий сбоит чаще, чем хотелось бы. Пакет устанавливается, демон стартует, docker ps отвечает пустым списком — а первый же docker run падает с невнятным отказом в доступе или контейнер вовсе не поднимается. Причина почти всегда одна и та же: защищённая конфигурация Astra не «ломает» Docker, а честно применяет к его процессам те же ограничения, что и ко всей остальной системе — просто Docker по умолчанию на это не рассчитан. Разберём, какие категории проблем стоит ожидать и как их диагностировать без паники и без отключения защиты целиком.

Почему на Astra Linux Docker ведёт себя иначе

Docker изначально проектировался под модель, где ядро линейно применяет дискреционные unix-права и несколько специфичных для контейнеров механизмов — пространства имён, cgroups, seccomp, capabilities. На «ванильных» Debian и Ubuntu этого обычно достаточно: демон работает от root, дергает нужные системные вызовы, ядро не задаёт лишних вопросов.

Astra Linux Special Edition поверх этого добавляет ещё один слой решений, который принимается не на уровне отдельного процесса или файла, а централизованно, для всей системы: мандатный контроль целостности и доступа проверяет метки субъектов и объектов на каждое действие, а замкнутая программная среда контролирует, какие исполняемые файлы и модули вообще имеют право запуститься. Мы разбирали эти механизмы по отдельности — как работает мандатное разграничение доступа и на чём на нём спотыкаются в первый день и что нужно учесть при включении замкнутой программной среды. Docker — процесс, который активно создаёт новые процессы, монтирует файловые системы, работает с сетевыми интерфейсами и cgroups — задевает оба механизма практически сразу, просто потому что делает необычно много системных действий для одного демона.

Важно понимать: это не значит, что Docker на Astra «не поддерживается» или работает принципиально хуже. Это значит, что часть настройки, которая на Ubuntu была неявной (ядро молча разрешает всё, что не запрещено), на Astra становится явной — систему нужно научить доверять процессам Docker и контейнеров ровно в том объёме, который вам действительно нужен.

Категория первая: демон не стартует или падает сразу после запуска

Первый класс проблем — сам dockerd не поднимается или завершается вскоре после старта. Симптомы разные: systemctl status docker показывает failed, в выводе journalctl -u docker — обрывы на монтировании overlay-файловой системы, ошибки создания сетевого моста, отказы при инициализации хранилища.

Типичные причины на защищённой конфигурации:

• Модуль ядра или функциональность заблокированы политикой. Часть возможностей, на которые опирается Docker (сетевые пространства имён, определённые cgroup-контроллеры), может быть недоступна процессу демона, если для него не настроены соответствующие разрешения — даже если модуль формально загружен в ядро.
• Замкнутая программная среда не пропускает бинарники Docker или containerd. Если ЗПС включена в блокирующем режиме, а исполняемые файлы демона, containerd, runc не прошли контроль целостности или не внесены в список разрешённых — процесс не запустится вовсе, часто без развёрнутого объяснения причины в стандартном выводе systemd.
• Конфликт с параметрами загрузки ядра, специфичными для защищённых сборок. Некоторые опции, влияющие на изоляцию процессов, могут быть выставлены строже, чем ожидает Docker по умолчанию.

Порядок действий здесь — не «выключить всё и посмотреть, заработает ли», а последовательно исключить причины:

# статус самого демона и последние события
systemctl status docker
journalctl -u docker -n 200 --no-pager

# то же для containerd, если используется отдельно
systemctl status containerd
journalctl -u containerd -n 200 --no-pager

Если в логе явно фигурирует отказ в духе «operation not permitted» на конкретном системном вызове или пути — это почти наверняка след мандатного контроля или ЗПС, а не проблема самого Docker. Если ошибка про недоступный ресурс ядра (сеть, cgroup) — это, скорее, вопрос загруженных модулей и их конфигурации.

Категория вторая: контейнеры не стартуют при работающем демоне

Второй, более частый случай: docker ps показывает, что демон жив, docker images работает, но docker run завершается ошибкой — либо сразу, либо контейнер стартует и тут же падает. Здесь причины обычно ближе к процессам самих контейнеров, а не к демону:

• Процессу внутри контейнера не хватает разрешений на действия, которые сам Docker формально ему выдал через capabilities — потому что поверх стандартных unix-capabilities лежит ещё и мандатная проверка, а она про capabilities ничего не знает.
• Точка монтирования (volume, bind mount) недоступна процессу контейнера из-за несовпадения меток на хостовом каталоге и на процессе, даже если владелец и unix-права выставлены верно.
• Сетевой стек контейнера не поднимается, потому что процессу Docker не хватает разрешений на операции с сетевыми пространствами имён или интерфейсами.

Диагностика здесь двухступенчатая. Сначала — обычный Docker-инструментарий:

docker logs <container_id>
docker inspect <container_id> --format '{{.State.Error}}'
docker events --since 10m

Если в логах контейнера — «Permission denied» на действие, которое явно разрешено правами файла (владелец совпадает, права есть), это сигнал смотреть на уровень мандатных меток и разрешений подсистемы безопасности, а не на Docker. Здесь та же логика, что и с обычными файлами и процессами вне контейнеров: ls -l и stat мандатные метки не показывают, нужны отдельные средства просмотра меток субъекта и объекта — без них причина физически не видна.

Категория третья: тома, bind mount'ы и права на файлы хоста

Отдельная и очень частая головная боль — том или каталог хоста, примонтированный в контейнер, недоступен процессу внутри контейнера на запись, а иногда и на чтение, при том что на хосте с этим же каталогом всё в порядке.

Механика та же, что и в целом на Astra: мандатная проверка идёт поверх дискреционной, и несовпадение меток «глушит» доступ независимо от того, что показывают unix-права. Для Docker это осложняется тем, что процесс внутри контейнера физически работает от имени того же ядра хоста (в отличие от полноценной виртуальной машины), и метка, с которой стартовал демон Docker, наследуется его дочерними процессами — включая процессы контейнеров.

Практический подход:

1. Убедиться, что проблема действительно мандатная, а не дискреционная — временно проверить доступ от имени той же учётной записи, что и демон Docker, вне контейнера, к тому же каталогу.
2. Если проблема воспроизводится и вне контейнера — искать решение на уровне разрешений и меток для каталога и для процесса, а не менять права chmod на каталоге хоста. Второе часто «помогает» на вид, но на деле маскирует настоящую причину и создаёт слепое пятно на будущее.
3. Если проблема пропадает вне контейнера, но остаётся внутри — смотреть на то, как именно Docker создаёт процесс контейнера и какая метка ему присваивается: несовпадение может быть именно на этом шаге, а не в правах самого каталога.

Категория четвёртая: сеть контейнеров и порты

Сетевая часть — источник проблем, которые часто путают с чем-то другим, потому что симптом («контейнер поднялся, но недоступен по порту») одинаков для десятка разных причин. На защищённой конфигурации к обычному списку подозреваемых (firewall, DNS, конфликт портов) добавляются ещё два пункта:

• Демону Docker может не хватать разрешений на создание виртуальных сетевых интерфейсов и мостов — тогда сеть контейнера либо не создаётся вовсе, либо создаётся, но пакеты не проходят.
• Если на сервере уже настроен маршрутизатор или дополнительный сетевой стек (актуально для сценариев с WireGuard и подобными туннелями), правила фильтрации, добавленные Docker автоматически, могут конфликтовать с уже существующими политиками — на защищённой системе такие конфликты чаще фиксируются явным отказом, а не тихо игнорируются.

Проверочный минимум:

# видит ли Docker сетевые ресурсы
docker network ls
docker network inspect bridge

# что реально происходит на уровне ядра
ip a
ip route

Если мост и интерфейсы контейнера в выводе ip a присутствуют, а трафик всё равно не идёт — проблема, скорее всего, в правилах фильтрации или в разрешениях на конкретные сетевые операции для процесса демона, а не в самой сетевой конфигурации контейнера.

Общий подход: диагностика вместо отключения защиты

Соблазн после второй-третьей необъяснимой ошибки — временно выключить мандатный контроль и замкнутую программную среду целиком, чтобы «просто заработало», а потом разобраться. Это рабочий способ быстро подтвердить гипотезу («дело в защите, а не в Docker»), но плохой способ решить проблему в проде: вы теряете именно ту защиту, ради которой Astra Linux вообще выбирают для таких серверов, и рискуете забыть включить её обратно.

Более правильный порядок:

1. Локализовать проблему — определить, демон это, контейнер, том или сеть, по логам конкретного компонента, а не по общему ощущению «что-то не работает».
2. Проверить гипотезу точечно, а не глобально. Если подозрение падает на мандатный контроль — временно (в тестовом окружении, не на боевом сервере) проверить гипотезу минимальным изменением на конкретном объекте, а не отключением подсистемы целиком.
3. Дать процессам Docker и контейнеров ровно те разрешения, которые им реально нужны, а не максимально широкие. Это медленнее, чем один раз всё выключить, но результат — рабочий Docker, который не открывает дыру в остальной защите сервера.
4. Задокументировать, какие разрешения были добавлены и зачем — на защищённых системах это не факультативно: при следующем обновлении Docker или самой Astra список нужных разрешений может измениться, и без записи придётся заново проходить весь путь проб и ошибок.

Если вы только присматриваетесь к Astra Linux после Ubuntu или Debian, полезно заранее знать, какие вещи в принципе меняются в первый день — мы отдельно разбирали, что реально ломается при переезде с Ubuntu на Astra Linux, и контейнеризация — лишь один пункт из этого списка, хоть и заметный.

Когда проще пересмотреть архитектуру, а не бороться с настройками

Иногда точечная настройка разрешений занимает больше времени и риска, чем того стоит конкретная задача. Если вам нужен Docker для изолированной служебной нагрузки, а не для чего-то, что обязано жить именно на защищённом контуре с мандатным контролем — рассмотрите вариант вынести контейнеризацию на отдельный сервер с более стандартной конфигурацией, а Astra Linux оставить там, где её защитные механизмы реально нужны и оправданы регуляторными требованиями.

Это не «сдаться» — это трезвая оценка того, что усложнение конфигурации имеет смысл только тогда, когда даёт что-то взамен. Если проект не требует именно защищённого контура для контейнерной нагрузки, отдельный сервер под Docker с более предсказуемым поведением экономит часы отладки, которые иначе уйдут на подбор точных разрешений под каждый новый образ и том.

Частые вопросы