1С в Docker: почему удалённый установщик остаётся в образе

🚨 Проблема: куда исчезают гигабайты в образе 1С

В практике контейнеризации 1С регулярно встречается классический Dockerfile:

FROM debian:12
COPY ./dist /tmp/dist
RUN dpkg -i /tmp/dist/*.deb && rm -rf /tmp/dist

Логика автора кажется прозрачной: дистрибутив скопировали, пакеты сервера и клиента платформы установили, а затем удалили временную папку командой rm -rf, рассчитывая, что итоговый образ уменьшится.

Но на практике происходит неприятный сюрприз: образ сервера 1С весит 2.5–3.0 ГБ вместо ожидаемых 1.2–1.5 ГБ. Заглядывая внутрь запущенного контейнера через docker exec, администратор видит, что каталога /tmp/dist действительно нет. Куда же делись сотни мегабайт?

Причина кроется в базовой архитектуре Docker: слои неизменяемы (immutable, Copy-on-Write). Инструкция COPY создала отдельный read-only слой, куда намертво записала 800 МБ дистрибутива. Следующая инструкция RUN при удалении файла не может переписать нижний слой — она лишь создает специальную whiteout-запись в новом слое оверлея, помечая файлы удаленными для видимой файловой системы.

Цена этой иллюзии в продакшене высока:

• Раздутый CI/CD трафик: при каждой сборке и доставке раннеры выгружают и скачивают лишний почти гигабайт неизвлекаемого балласта;
• Забитый реестр образов: хранилища Harbor / Nexus быстро переполняются мертвыми слоями;
• Медленный холодный старт: развертывание новых подов в Kubernetes или нод в Swarm задерживается на время передачи неиспользуемых байтов.

💡 Шпаргалка инженера: как правильно собирать образ

Прежде чем погружаться в детальные побайтовые замеры, зафиксируем практическую матрицу выбора архитектуры сборки:

Чтобы доказать эти выводы математически точно и исключить погрешности закрытого коммерческого кода, мы построили детерминированный микро-стенд.

📂 Антипаттерн на практике: COPY и удаление в следующем RUN

Первый вариант моделирует ту самую распространенную ошибку: установщик копируется в образ отдельной инструкцией, а затем удаляется в шаге установки.

1
2
3
4
5

FROM debian:12-base
COPY payload.dat /tmp/payload.dat
RUN mkdir -p /opt/demo     && head -c 4096 /tmp/payload.dat > /opt/demo/artifact.bin     && rm -f /tmp/payload.dat

После сборки проверяем запущенный контейнер: команда test ! -e /tmp/payload.dat возвращает успех — файла в файловой системе нет. Однако команда инспекции истории образа docker image history вскрывает реальную картину:

IMAGE          CREATED BY                                      SIZE
<missing>      RUN /bin/sh -c mkdir -p /opt/demo && head -c... 20.5kB
<missing>      COPY payload.dat /tmp/payload.dat # buildkit    16.8MB
<missing>      /bin/sh -c #(nop) ADD file:... in /             133MB

💻 Решение 1 (Рекомендуемое): Временный дистрибутив через BuildKit bind mount

Чтобы файл дистрибутива вообще не попадал в слои, современный сборщик BuildKit предоставляет механизм монтирования контекста сборки: RUN --mount=type=bind. Дистрибутив становится доступен контейнеру исключительно на время выполнения команды и только для чтения.

1
2
3
4

FROM debian:12-base
RUN --mount=type=bind,source=payload.dat,target=/tmp/payload.dat     mkdir -p /opt/demo     && head -c 4096 /tmp/payload.dat > /opt/demo/artifact.bin

Обратите внимание: здесь даже нет команды rm. Источник подключен временно. Всё, что прочитано из /tmp/payload.dat, используется процессом установки, а в итоговый слой попадает только созданный файл /opt/demo/artifact.bin.

История образа docker image history:

IMAGE          CREATED BY                                      SIZE
<missing>      RUN --mount=type=bind,source=payload.dat,tar... 16.4kB
<missing>      /bin/sh -c #(nop) ADD file:... in /             133MB

Готовый пример для сервера 1С:Предприятие 8.3

В реальном проекте с дистрибутивом платформы 1С это решение выглядит так:

# syntax=docker/dockerfile:1
FROM debian:12-slim

# Установка системных зависимостей платформы
RUN apt-get update && apt-get install -y --no-install-recommends     ca-certificates fontconfig locales libglib2.0-0     && rm -rf /var/lib/apt/lists/*

# Монтируем локальную папку с deb-пакетами 1С без копирования в образ
RUN --mount=type=bind,source=./dist_1c,target=/tmp/dist     dpkg -i /tmp/dist/1c-enterprise-8.3.*.deb     && rm -rf /var/lib/apt/lists/*

# Установщик исчезнет сразу после завершения RUN, в слое останется только /opt/1cv8

💻 Решение 2: Отдельный завершающий этап (Multi-stage)

Второй классический паттерн — многоэтапная сборка. Все грязные операции (копирование дистрибутива, распаковка, компиляция) выполняются на промежуточном этапе, а в финальный образ забирается только итоговый каталог через COPY --from=build.

1
2
3
4
5
6
7
8

FROM debian:12-base AS build
COPY payload.dat /tmp/payload.dat
RUN mkdir -p /opt/demo     && head -c 4096 /tmp/payload.dat > /opt/demo/artifact.bin     && rm -f /tmp/payload.dat

FROM debian:12-base
COPY --from=build /opt/demo/artifact.bin /opt/demo/artifact.bin

В истории итогового образа снова остаются ровно два слоя: базовый образ и слой COPY --from=build размером 16 384 байта. Слой с установщиком остался на этапе build и в финальный образ не попал.

📊 Парадокс размеров: почему history.Size и inspect.Size не совпадают

Сравним первичные данные всех трех сборок, зафиксированные тестовым раннером:

Здесь внимательный инженер сразу обратит внимание на два момента:

1. Разница в history.Size строго равна размеру файла: разница сумм между Вариантом 1 и оптимизированными вариантами составила ровно 16 789 504 байта (16 МиБ установщика + 4 КБ служебного оверхеда слоя). Чистая математика.
2. Разница в inspect.Size внезапно составила 33 572 534 байта (33.5 МБ) — вдвое больше! Почему?

Разгадка парадокса: на современных версиях Docker Desktop и серверных движках по умолчанию активирован containerd image store (io.containerd.snapshotter.v1). В отличие от старого драйвера overlay2, containerd хранит в метаданных inspect.Size суммарное дисковое пространство: и сжатые tar-архивы слоев, и их распакованные снапшоты. Поэтому «забытый» в слое файл на диске сборщика раздувает потребление пространства в двойном размере.

🔍 Как проверить свой образ и воспроизвести эксперимент

1. Экспресс-аудит рабочего образа 1С

Чтобы прямо сейчас узнать, не прячутся ли в вашем образе старые дистрибутивы, выполните две команды:

# Посмотреть все слои и команды сборщика без обрезания
docker image history --no-trunc --human=true YOUR_IMAGE_NAME

# Найти подозрительно тяжелые промежуточные слои COPY
docker image history --format "{{.CreatedBy}}: {{.Size}}" YOUR_IMAGE_NAME | grep -E "COPY|ADD"

Если среди строк вы видите COPY dist или ADD server64.tar.gz с размером в сотни мегабайт — ваш образ страдает от антипаттерна, и перевод сборки на bind mount моментально сбросит лишний вес.

2. Воспроизведение лабораторного эксперимента (архив-компаньон)

Для автономной проверки без необходимости скачивать гигабайты 1С в архиве за 1 SM приложен воспроизводимый раннер:

# Запуск сквозного прогона трех сборок (требует Docker с BuildKit):
python reproduce_lab.py --base debian:12 --prefix my-lab --out my-run

# Запуск анализатора первичных JSON-логов (работает автономно без Docker):
python image_report.py examples/split.inspect.json examples/bind.inspect.json examples/staged.inspect.json   --history examples/split.history.jsonl examples/bind.history.jsonl examples/staged.history.jsonl

🔒 Приёмка платформы и лицензирования после оптимизации

Успешная оптимизация веса образа — это только половина задачи. В экосистеме «1С:Предприятие» ключевым барьером контейнеризации остается программное лицензирование.

Иногда в погоне за компактностью инженеры вырезают зависимости или переходят на alpine/минималистичные дистрибутивы, после чего ломается механизм формирования аппаратного хэша (.lic) или перестает запускаться служба лицензирования. Важно помнить:

• Официальный список ОС: на текущий момент вендор официально поддерживает сервер x86-64 на дистрибутивах Debian 12 и Ubuntu 22.04 LTS. Сборка на их slim-версиях безопасна с точки зрения ядра и библиотек glibc;
• Программные лицензии привязаны к окружению: одного монтирования каталога с файлами .lic недостаточно. Изменение MAC-адреса, hostname, параметров виртуализации или состава оборудования хоста аннулирует программную лицензию;
• Разделение контуров проверки: проверка веса образа и проверка привязки лицензий должны идти раздельными этапами.

🏁 Итог и чек-лист для production

Проведенное исследование дает однозначный ответ: попытка удалить установщик через rm после COPY не работает. На синтетическом тесте в 16 МиБ мы увидели ровно 16 МиБ балласта, а на реальном дистрибутиве 1С это выливается в 500–900 МБ паразитного веса.

Для производственных конвейеров доставки 1С держите под рукой краткий чек-лист:

1. Включите BuildKit: экспортируйте DOCKER_BUILDKIT=1 в CI/CD пайплайнах;
2. Используйте RUN --mount=type=bind для тяжелых deb/rpm пакетов: это защищает слои от попадания дистрибутивов без усложнения Dockerfile;
3. Контролируйте историю перед публикацией: проверяйте docker image history на наличие случайных слоев COPY размером более нескольких мегабайт;
4. Разделяйте сервер и вспомогательные сервисы: многоэтапную сборку используйте для независимых утилит, а для сервера 1С сохраняйте целостность системных пакетов ОС.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S