Tilda Publishing
Привет, любопытный друг. Да, это Tilda. Потому что мы хотим быстро внедрять и управлять решением, а не ждать
в очереди разработчика. Контроль, предсказуемость и отказоустойчивость — наша главная идея.
в очереди разработчика. Контроль, предсказуемость и отказоустойчивость — наша главная идея.
Заказать обратный звонок
Оставьте номер телефона — мы свяжемся с вами в ближайшее время, ответим на вопросы и подберём оптимальное решение.
Для запросов и ТЗ
с 9:30 до 18:00
Подберём типовое или произведем на заказ серверное оборудование, предоставим расчёт и поможем интегрировать в систему.
Заполните форму запроса слева или отправьте описание вашей задачи на почту get@work-system.ru
При отправке письма на почту укажите номер телефона вашего специалиста для обсуждения аналогов оборудования в случае необходимости
Заполните форму запроса слева или отправьте описание вашей задачи на почту get@work-system.ru
При отправке письма на почту укажите номер телефона вашего специалиста для обсуждения аналогов оборудования в случае необходимости
Docker: что это такое и зачем нужен
Разбираем Docker последовательно: от определения и архитектуры платформы — к тому, как контейнеризация меняет требования к серверу, когда вместо самого Docker нужен оркестратор вроде Kubernetes и стоит ли контейнеризировать высоконагруженные базы 1С и ERP. Отдельно — какую лицензию Docker выбрать для корпоративной инфраструктуры и как избежать типичных ошибок в проде.
Содержание
Что такое Docker: определение и суть контейнеризации
Docker — открытая программная платформа для разработки, доставки и запуска приложений в контейнерах. В официальной документации Docker Engine компания Docker Inc. определяет платформу как инструмент, который отделяет приложение от инфраструктуры и позволяет управлять ею теми же методами, что и кодом.
Контейнер — не виртуальная машина и не облегчённый процесс ОС в привычном понимании. Это изолированный набор процессов, который использует общее ядро хостовой системы, но имеет собственное пространство пользователя: свою файловую систему, сеть, список процессов. Изоляция достигается механизмами ядра Linux — namespaces и cgroups (подробнее — в разделе о принципе работы контейнеризации), поэтому контейнер легче и быстрее виртуальной машины: он не эмулирует железо и не поднимает отдельное ядро.
Первая версия Docker Engine вышла в 2013 году как открытый инструмент на основе возможностей ядра Linux (изначально — обёртка над LXC, с 2015 года — собственная библиотека libcontainer). С тех пор Docker стал синонимом контейнеризации в индустрии.
Практический вывод для IT-директора: Docker — это инструмент упаковки приложения со всеми зависимостями в переносимый артефакт, а не отдельная виртуализация оборудования. Выбор между Docker-контейнерами и виртуальными машинами определяется требуемым уровнем изоляции и типом нагрузки — к этому вопросу мы ещё вернёмся.
Контейнер — не виртуальная машина и не облегчённый процесс ОС в привычном понимании. Это изолированный набор процессов, который использует общее ядро хостовой системы, но имеет собственное пространство пользователя: свою файловую систему, сеть, список процессов. Изоляция достигается механизмами ядра Linux — namespaces и cgroups (подробнее — в разделе о принципе работы контейнеризации), поэтому контейнер легче и быстрее виртуальной машины: он не эмулирует железо и не поднимает отдельное ядро.
Первая версия Docker Engine вышла в 2013 году как открытый инструмент на основе возможностей ядра Linux (изначально — обёртка над LXC, с 2015 года — собственная библиотека libcontainer). С тех пор Docker стал синонимом контейнеризации в индустрии.
Практический вывод для IT-директора: Docker — это инструмент упаковки приложения со всеми зависимостями в переносимый артефакт, а не отдельная виртуализация оборудования. Выбор между Docker-контейнерами и виртуальными машинами определяется требуемым уровнем изоляции и типом нагрузки — к этому вопросу мы ещё вернёмся.
Зачем нужен Docker: какие задачи он решает для разработки и IT-инфраструктуры
Главная практическая польза Docker — устранение проблемы «у меня на машине работает, а на сервере нет». Приложение со всеми зависимостями упаковывается в неизменяемый Docker-образ (read-only шаблон, собранный слоями по инструкциям Dockerfile) и запускается идентично на любом хосте с Docker — на Linux, Windows и macOS, — что устраняет конфликты зависимостей между средами разработки, тестирования и продакшена.
Использовать Docker имеет смысл там, где команда регулярно переносит приложение между средами, работает с несколькими сервисами одновременно или хочет ускорить цикл релизов.
Использовать Docker имеет смысл там, где команда регулярно переносит приложение между средами, работает с несколькими сервисами одновременно или хочет ускорить цикл релизов.
Ускорение разработки, тестирования и CI/CD
Контейнеризация ускоряет три этапа цикла разработки одновременно. Сборка ускоряется за счёт слоистой файловой системы образа: неизменённые слои переиспользуются и не пересобираются заново. Тестирование ускоряется благодаря идентичности окружений на любой рабочей станции команды. Деплой ускоряется, поскольку конвейер CI/CD доставляет в продакшен готовый к развёртыванию образ, а не разворачивает приложение внутри уже существующей среды.
По данным отчёта Datadog, использование Docker в CI/CD снижает время развёртывания на 40–50% — выигрыш даёт не сам факт контейнеризации, а связка Docker и автоматизированного конвейера сборки.
По данным отчёта Datadog, использование Docker в CI/CD снижает время развёртывания на 40–50% — выигрыш даёт не сам факт контейнеризации, а связка Docker и автоматизированного конвейера сборки.
Упрощение развёртывания и переноса приложений между средами
При переносе между хостами неизменным остаётся образ — его слои с кодом, библиотеками и зависимостями. Команда docker push загружает образ в реестр, docker pull — забирает его на новый хост; данные приложения хранятся отдельно от образа, в именованных томах (volumes) или через bind mounts — прямое монтирование папки хоста внутрь контейнера.
Контейнеры работают на общем ядре ОС хоста, поэтому зависимости приложения — конкретные версии библиотек, интерпретаторов — упакованы внутри образа и не привязаны к версии ОС хоста. Это снимает с разработчика необходимость вручную настраивать окружение при каждом развёртывании.
Контейнеры работают на общем ядре ОС хоста, поэтому зависимости приложения — конкретные версии библиотек, интерпретаторов — упакованы внутри образа и не привязаны к версии ОС хоста. Это снимает с разработчика необходимость вручную настраивать окружение при каждом развёртывании.
Изоляция сервисов в микросервисной архитектуре
Принцип «один контейнер — один процесс/сервис» — общепринятая индустриальная практика: сбой одного компонента не должен приводить к падению всей системы, а отдельные сервисы можно обновлять и масштабировать независимо. На практике это реализует оркестратор поверх Docker: Kubernetes использует Horizontal Pod Autoscaler для изменения числа экземпляров сервиса под нагрузкой и Rolling Update для обновления без простоя — подробнее в разделе про Kubernetes ниже.
Как устроен Docker: архитектура и ключевые компоненты
Docker построен на клиент-серверной архитектуре: пользователь работает с клиентом (CLI-командой docker), клиент передаёт команды демону через API, а демон выполняет реальную работу — собирает образы, запускает контейнеры, управляет сетями и томами. Все эти компоненты работают на Docker Host — системе, где установлен демон.
Клиент может взаимодействовать с несколькими демонами одновременно, в том числе удалёнными. Отдельно от хоста существует Docker Registry — репозиторий для хранения и распространения образов: оттуда демон подтягивает образы командой docker pull и туда же публикует их командой docker push.
Клиент может взаимодействовать с несколькими демонами одновременно, в том числе удалёнными. Отдельно от хоста существует Docker Registry — репозиторий для хранения и распространения образов: оттуда демон подтягивает образы командой docker pull и туда же публикует их командой docker push.
Docker Engine: демон, клиент и API
Docker Daemon (dockerd) — постоянный фоновый процесс, управляющий образами, контейнерами, сетями и томами. Docker CLI передаёт команды в демон через REST API — по умолчанию локально через Unix-сокет, а не через TCP; включать удалённый доступ без дополнительной защиты на продакшен-хостах не стоит.
Образ, контейнер, Registry и Dockerfile
Docker Image — неизменяемый шаблон только для чтения: набор инструкций и файлов, состоящий из слоёв. Dockerfile — текстовый файл с инструкциями, по которым Docker строит образ: каждая команда (RUN, COPY, ADD) создаёт новый слой. Docker Container — исполняемый экземпляр образа с добавленным верхним слоем для записи: контейнер отличается от образа именно возможностью модификации файлов во время работы, тогда как сам образ неизменяем. Docker Registry — серверное приложение для хранения и распространения образов, Docker Hub — крупнейший публичный реестр такого рода.
Слоистая структура образа реализована через union-файловую систему — в Docker по умолчанию это overlay2. Слои дедуплицируются: если несколько образов используют один и тот же базовый слой, на диске он хранится однократно, а изменения применяются через copy-on-write к отдельной writable-копии, не затрагивая исходный образ. Согласно документации Docker Inc., именно такое разделение на клиент, демон, слоистые образы и реестр делает платформу пригодной для промышленной эксплуатации.
Слоистая структура образа реализована через union-файловую систему — в Docker по умолчанию это overlay2. Слои дедуплицируются: если несколько образов используют один и тот же базовый слой, на диске он хранится однократно, а изменения применяются через copy-on-write к отдельной writable-копии, не затрагивая исходный образ. Согласно документации Docker Inc., именно такое разделение на клиент, демон, слоистые образы и реестр делает платформу пригодной для промышленной эксплуатации.
Docker Compose для многоконтейнерных приложений
Docker Compose — инструмент для декларативного запуска и управления многоконтейнерными приложениями через один файл docker-compose.yml, командой docker-compose up. Файл состоит из трёх секций: services описывает список контейнеров и их настройки, volumes объявляет тома, networks создаёт изолированную сеть проекта. Compose удобен для локальной разработки и небольших продакшен-сценариев на одном хосте — ограничения при росте инфраструктуры разберём в разделе про оркестрацию.
Принцип работы контейнеризации: изоляция ядра ОС и слои образов
Как контейнер добивается изоляции, если ядро у него общее с хостом? За счёт двух независимых механизмов ядра Linux. Namespaces изолируют видимость ресурсов — создают для процессов внутри контейнера иллюзию собственной системы: свою нумерацию процессов (PID), сетевой стек (NET), файловую систему (MNT), идентификаторы пользователей (USER) и другие. Cgroups, в отличие от namespaces, отвечают не за изоляцию видимости, а за ограничение потребления ресурсов: сколько CPU, памяти и пропускной способности ввода-вывода может использовать контейнер.
Все контейнеры на одном хосте используют общее ядро ОС — это ключевое архитектурное отличие от виртуализации оборудования. Файловая система образов работает через инкрементную модель copy-on-write поверх overlayfs: базовые слои монтируются в режиме read-only, а поверх них при запуске добавляется тонкий writable-слой контейнера, куда копируются только изменяемые файлы. Такая дедупликация общих базовых слоёв напрямую снижает требования к дисковому пространству хоста при высокой плотности контейнеров.
Все контейнеры на одном хосте используют общее ядро ОС — это ключевое архитектурное отличие от виртуализации оборудования. Файловая система образов работает через инкрементную модель copy-on-write поверх overlayfs: базовые слои монтируются в режиме read-only, а поверх них при запуске добавляется тонкий writable-слой контейнера, куда копируются только изменяемые файлы. Такая дедупликация общих базовых слоёв напрямую снижает требования к дисковому пространству хоста при высокой плотности контейнеров.
Чем Docker-контейнеры отличаются от виртуальных машин
Ключевое отличие — уровень, на котором происходит виртуализация. Гипервизор при аппаратной виртуализации эмулирует полный набор виртуального оборудования и создаёт для гостевой ОС иллюзию отдельного физического компьютера. Контейнерный движок не эмулирует железо и не поднимает виртуальную ОС — он использует единое ядро хоста, изолируя только пользовательское пространство: процессы, файловые системы, сетевые интерфейсы.
Отсюда и разница в глубине изоляции: виртуальная машина обеспечивает полную изоляцию за счёт собственной виртуальной версии оборудования, контейнер — ограниченную изоляцию средствами ОС. Практическое следствие: уязвимость в общем ядре потенциально затрагивает все контейнеры на хосте одновременно, тогда как у ВМ ядра изолированы друг от друга — это стоит учитывать при выборе архитектуры для мультитенантных или регулируемых сред.
Отсюда и разница в глубине изоляции: виртуальная машина обеспечивает полную изоляцию за счёт собственной виртуальной версии оборудования, контейнер — ограниченную изоляцию средствами ОС. Практическое следствие: уязвимость в общем ядре потенциально затрагивает все контейнеры на хосте одновременно, тогда как у ВМ ядра изолированы друг от друга — это стоит учитывать при выборе архитектуры для мультитенантных или регулируемых сред.
Сравнение по изоляции, ресурсам и скорости запуска
Параметр
Docker-контейнер
Виртуальная машина
Уровень изоляции
Пользовательское пространство поверх общего ядра хоста
Собственное ядро и полный стек ОС поверх гипервизора
Ресурсоёмкость
Оверхед минимален, близок к нативной производительности
Оверхед виртуализации — по общим оценкам порядка 10–15%
Время запуска
Обычно 0,1–1 секунда
Загрузка ядра ВМ — порядка 10–60 секунд, полная инициализация может занимать минуты
Размер артефакта
Образ — единицы-десятки мегабайт
Образ ВМ — единицы-десятки гигабайт с полной гостевой ОС
Плотность на хосте
Высокая — благодаря отсутствию дублирования ядра и системных служб
Ниже — каждая ВМ требует собственного ядра и памяти под ОС
По материалам сравнения контейнеров и виртуальных машин Red Hat, эта разница в глубине изоляции определяет область применения каждой технологии: контейнеры — для высокоплотных сред и динамического масштабирования; виртуальные машины — там, где нужна жёсткая изоляция на уровне ядра или строгая мультитенантная безопасность. Реальный коэффициент выигрыша в плотности зависит от профиля нагрузки и его стоит проверять на пилотном стенде, а не брать усреднённую цифру из общих источников.
Как контейнеризация влияет на требования к серверной инфраструктуре
Переход с виртуальных машин на контейнеры меняет не только программный стек, но и то, под какую нагрузку проектируется сервер. Если для виртуализации ключевым параметром был объём памяти и число физических ядер под ограниченное количество тяжёлых ВМ, то для контейнеризации важен баланс вычислительной мощности, скорости дисковой подсистемы и пропускной способности сети под большое число мелких, но активных по I/O контейнеров.
Коэффициент консолидации нагрузки на хост в контейнерной среде растёт за счёт отсутствия дублирования ядра ОС и системных библиотек — каждый дополнительный контейнер не тянет за собой отдельное ядро и набор системных служб, как это происходит с виртуальной машиной. Это прямо влияет на то, сколько сервисов реально разместить на одном физическом сервере при заданном объёме CPU и RAM.
Коэффициент консолидации нагрузки на хост в контейнерной среде растёт за счёт отсутствия дублирования ядра ОС и системных библиотек — каждый дополнительный контейнер не тянет за собой отдельное ядро и набор системных служб, как это происходит с виртуальной машиной. Это прямо влияет на то, сколько сервисов реально разместить на одном физическом сервере при заданном объёме CPU и RAM.
Плотность контейнеров на хосте: CPU, RAM, диск и сеть
Память для контейнеров ограничивается через cgroup-параметр memory.max — это жёсткий лимит: при его достижении срабатывает OOM killer и завершает процессы контейнера. Отсюда прямое следствие для проектирования сервера: сумма лимитов памяти всех запланированных контейнеров должна быть меньше физического объёма RAM хоста, с запасом на ядро и системные буферы.
С процессором ситуация двухслойная. CPU shares (в терминах cgroups v2 — cpu.weight) задают только относительный приоритет доступа к CPU при конкуренции за него и не ограничивают максимум — если процессор свободен, контейнер использует всё доступное время. Это позволяет закладывать overcommit по CPU при проектировании сервера. Жёсткий лимит CPU (cpu.max, в Docker — параметр CPUQuota) — другое дело: он прямо диктует минимальное число ядер сервера, если сумма лимитов всех контейнеров превышает 100% от одного ядра.
Открытых отраслевых бенчмарков с конкретными цифрами IOPS под контейнерные нагрузки немного — точные требования к дисковой подсистеме лучше проверять нагрузочным тестированием под профиль конкретного приложения, а не ориентироваться на усреднённые рекомендации.
Два типичных профиля нагрузки на практике требуют разных приоритетов при подборе сервера. Первый — 10–20 контейнеров с активным логированием и частым обращением к конфигурационным файлам: здесь узким местом обычно становится дисковая подсистема и объём RAM под буферы, а не число ядер CPU. Второй — 100+ преимущественно stateless-микросервисов с редкими обращениями к диску: здесь важнее число ядер и пропускная способность сети между узлами кластера, а дисковая нагрузка второстепенна. Эти профили нельзя усреднять — конфигурация сервера под них будет разной даже при сопоставимом суммарном числе контейнеров.
В наших проектах при подборе серверных конфигураций под виртуализированные и контейнеризированные нагрузки мы в первую очередь считаем не количество ядер CPU, а сумму жёстких лимитов памяти и дисковую подсистему — именно они чаще становятся узким местом раньше процессора, особенно при большом числе мелких контейнеров с активным логированием и обращением к конфигурационным данным. Подбор конкретной конфигурации сервера всегда идёт от профиля реальной нагрузки заказчика, а не от абстрактного числа контейнеров на хост. Экономика перехода считается по той же логике: сравнить число физических серверов, необходимое для одной и той же нагрузки на виртуальных машинах и на контейнерах, вычесть разницу в стоимости лицензий гостевых ОС и энергопотреблении, добавить затраты на оркестрацию и поддержку кластера — только такой расчёт даёт реалистичный ориентир TCO, а не усреднённый процент экономии без привязки к профилю нагрузки.
С процессором ситуация двухслойная. CPU shares (в терминах cgroups v2 — cpu.weight) задают только относительный приоритет доступа к CPU при конкуренции за него и не ограничивают максимум — если процессор свободен, контейнер использует всё доступное время. Это позволяет закладывать overcommit по CPU при проектировании сервера. Жёсткий лимит CPU (cpu.max, в Docker — параметр CPUQuota) — другое дело: он прямо диктует минимальное число ядер сервера, если сумма лимитов всех контейнеров превышает 100% от одного ядра.
Открытых отраслевых бенчмарков с конкретными цифрами IOPS под контейнерные нагрузки немного — точные требования к дисковой подсистеме лучше проверять нагрузочным тестированием под профиль конкретного приложения, а не ориентироваться на усреднённые рекомендации.
Два типичных профиля нагрузки на практике требуют разных приоритетов при подборе сервера. Первый — 10–20 контейнеров с активным логированием и частым обращением к конфигурационным файлам: здесь узким местом обычно становится дисковая подсистема и объём RAM под буферы, а не число ядер CPU. Второй — 100+ преимущественно stateless-микросервисов с редкими обращениями к диску: здесь важнее число ядер и пропускная способность сети между узлами кластера, а дисковая нагрузка второстепенна. Эти профили нельзя усреднять — конфигурация сервера под них будет разной даже при сопоставимом суммарном числе контейнеров.
В наших проектах при подборе серверных конфигураций под виртуализированные и контейнеризированные нагрузки мы в первую очередь считаем не количество ядер CPU, а сумму жёстких лимитов памяти и дисковую подсистему — именно они чаще становятся узким местом раньше процессора, особенно при большом числе мелких контейнеров с активным логированием и обращением к конфигурационным данным. Подбор конкретной конфигурации сервера всегда идёт от профиля реальной нагрузки заказчика, а не от абстрактного числа контейнеров на хост. Экономика перехода считается по той же логике: сравнить число физических серверов, необходимое для одной и той же нагрузки на виртуальных машинах и на контейнерах, вычесть разницу в стоимости лицензий гостевых ОС и энергопотреблении, добавить затраты на оркестрацию и поддержку кластера — только такой расчёт даёт реалистичный ориентир TCO, а не усреднённый процент экономии без привязки к профилю нагрузки.
Когда одного Docker недостаточно: оркестрация и Kubernetes
Docker Compose закрывает задачу многоконтейнерного приложения только на одном хосте: у него нет встроенного балансировщика нагрузки между репликами, автомасштабирования по метрикам CPU, а при падении хоста контейнеры не перезапускаются на других узлах — Compose не управляет кластером и не решает задачу service discovery между хостами.
Эти ограничения снимает оркестратор — подробнее о том, чем Docker и Kubernetes отличаются друг от друга, мы разбирали отдельно в материале «Docker и Kubernetes: в чём разница». Kubernetes был разработан инженерами Google в 2014 году и передан в Cloud Native Computing Foundation в 2015 году как первый проект фонда. Его базовые объекты — Pod (минимальная единица развёртывания), Deployment (управляет обновлениями через Rolling Update) и Service (балансировка нагрузки и сетевая связь между подами); Horizontal Pod Autoscaler автоматически меняет число реплик под нагрузкой. OpenShift — коммерческий дистрибутив Kubernetes от Red Hat для промышленной эксплуатации в корпоративной среде.
Согласно ежегодному отчёту Cloud Native Computing Foundation (CNCF Annual Survey, 2024), внедрение облачных нативных технологий в индустрии достигло 89%, а 82% пользователей контейнеров уже запускают Kubernetes в продакшене — оркестрация стала для контейнерной инфраструктуры фактическим стандартом при масштабировании за пределы одного хоста.
Эти ограничения снимает оркестратор — подробнее о том, чем Docker и Kubernetes отличаются друг от друга, мы разбирали отдельно в материале «Docker и Kubernetes: в чём разница». Kubernetes был разработан инженерами Google в 2014 году и передан в Cloud Native Computing Foundation в 2015 году как первый проект фонда. Его базовые объекты — Pod (минимальная единица развёртывания), Deployment (управляет обновлениями через Rolling Update) и Service (балансировка нагрузки и сетевая связь между подами); Horizontal Pod Autoscaler автоматически меняет число реплик под нагрузкой. OpenShift — коммерческий дистрибутив Kubernetes от Red Hat для промышленной эксплуатации в корпоративной среде.
Согласно ежегодному отчёту Cloud Native Computing Foundation (CNCF Annual Survey, 2024), внедрение облачных нативных технологий в индустрии достигло 89%, а 82% пользователей контейнеров уже запускают Kubernetes в продакшене — оркестрация стала для контейнерной инфраструктуры фактическим стандартом при масштабировании за пределы одного хоста.
Преимущества и ограничения Docker
Взвешенная картина важнее маркетинговых формулировок: у Docker есть конкретные сильные стороны и конкретные ограничения, и решение о внедрении стоит принимать с учётом обеих сторон.
Что даёт Docker бизнесу и разработке
Главный экономический эффект — скорость и портируемость. Контейнер запускается менее чем за секунду благодаря отсутствию времени на загрузку отдельной ОС, что сокращает цикл разработки и время выхода изменений в продакшен. Контейнеры используют общее ядро хоста и занимают заметно меньше памяти на экземпляр, чем ВМ с полной гостевой ОС, — это позволяет одному серверу поддерживать в разы больше нагрузок по сравнению с виртуализацией.
Ограничения и риски, которые нужно учитывать
По данным исследования контейнеров в edge-вычислениях, оверхед Docker относительно нативного исполнения не превышает 1,3% — производительность остаётся близкой к нативной. Заметные задержки возникают при сетевых нагрузках, критичных к микросекундам, и при запуске Docker на Windows или macOS через прослойку виртуализации.
По умолчанию контейнеры запускаются от имени root — в продакшене стоит запускать процессы от непривилегированного пользователя. Без явных лимитов ресурсов контейнер способен занять всю доступную память хоста и спровоцировать Linux OOM killer, который убьёт не только сам контейнер, но и другие сервисы на хосте. Флаг --privileged даёт контейнеру почти все права хоста и противоречит модели безопасности — вместо него стоит использовать --cap-drop=ALL и --security-opt=no-new-privileges.
Отдельная категория рисков — supply chain security: публичные реестры, включая Docker Hub, содержат и уязвимые, и заведомо вредоносные образы, поэтому безопасная практика — работать с проверенными официальными образами и переносить критичные образы в собственный реестр.
На Windows и macOS Docker Desktop работает через прослойку виртуализации (WSL 2 на Windows, HyperKit на macOS), поскольку платформа изначально рассчитана на нативное Linux-ядро — производительность близка к нативной, но по разным оценкам может быть на 10–30% медленнее, что стоит учитывать при разработке на Windows-станциях с продакшеном на Linux-серверах.
По умолчанию контейнеры запускаются от имени root — в продакшене стоит запускать процессы от непривилегированного пользователя. Без явных лимитов ресурсов контейнер способен занять всю доступную память хоста и спровоцировать Linux OOM killer, который убьёт не только сам контейнер, но и другие сервисы на хосте. Флаг --privileged даёт контейнеру почти все права хоста и противоречит модели безопасности — вместо него стоит использовать --cap-drop=ALL и --security-opt=no-new-privileges.
Отдельная категория рисков — supply chain security: публичные реестры, включая Docker Hub, содержат и уязвимые, и заведомо вредоносные образы, поэтому безопасная практика — работать с проверенными официальными образами и переносить критичные образы в собственный реестр.
На Windows и macOS Docker Desktop работает через прослойку виртуализации (WSL 2 на Windows, HyperKit на macOS), поскольку платформа изначально рассчитана на нативное Linux-ядро — производительность близка к нативной, но по разным оценкам может быть на 10–30% медленнее, что стоит учитывать при разработке на Windows-станциях с продакшеном на Linux-серверах.
Типичные ошибки при внедрении Docker в инфраструктуру компании
Первая типичная ошибка — бесконтрольный рост «подвешенных» образов (dangling images) и остановленных контейнеров, которые продолжают хранить файловую систему и метаданные на диске. Решение — регулярная очистка через docker system prune и настройка CI/CD на уборку после каждой сборки.
Вторая — отсутствие лимитов ресурсов на контейнер: без CPU- и memory-лимитов сама идея изоляции частично теряет смысл, один контейнер способен вытеснить остальные по ресурсам, что на проде оборачивается деградацией всех совместно размещённых сервисов.
Третья — использование образов из непроверенных источников или устаревших тегов вроде FROM ubuntu:latest. Официальные образы с фиксированными тегами регулярно обновляются вендором и минимизируют поверхность атаки.
Четвёртая — отсутствие мониторинга и логирования контейнерной инфраструктуры. Практика DevSecOps строится на трёх опорах: статическое сканирование образов на уязвимости в CI/CD, запуск контейнеров с политикой наименьших привилегий и постоянный runtime-мониторинг аномального поведения. Без этого компрометация контейнера обнаруживается постфактум, а не в момент атаки.
Вторая — отсутствие лимитов ресурсов на контейнер: без CPU- и memory-лимитов сама идея изоляции частично теряет смысл, один контейнер способен вытеснить остальные по ресурсам, что на проде оборачивается деградацией всех совместно размещённых сервисов.
Третья — использование образов из непроверенных источников или устаревших тегов вроде FROM ubuntu:latest. Официальные образы с фиксированными тегами регулярно обновляются вендором и минимизируют поверхность атаки.
Четвёртая — отсутствие мониторинга и логирования контейнерной инфраструктуры. Практика DevSecOps строится на трёх опорах: статическое сканирование образов на уязвимости в CI/CD, запуск контейнеров с политикой наименьших привилегий и постоянный runtime-мониторинг аномального поведения. Без этого компрометация контейнера обнаруживается постфактум, а не в момент атаки.
Как начать работу с Docker: первые шаги
Для установки нужна 64-битная система с поддержкой аппаратной виртуализации и минимум 2–4 ГБ ОЗУ — на Windows бэкендом служит WSL 2 или Hyper-V, на macOS Docker Desktop поддерживает и Intel, и Apple Silicon.
После установки первый контейнер запускается командой docker run [OPTIONS] IMAGE — она создаёт и запускает контейнер из указанного образа, автоматически подтягивая его из реестра, если нет локально. docker ps показывает запущенные контейнеры (флаг -a — и остановленные), docker images — список локальных образов, docker stop останавливает контейнер сигналом SIGTERM с принудительным SIGKILL по таймауту.
Dockerfile обычно состоит из инструкций FROM (базовый образ), COPY (копирование файлов), RUN (установка зависимостей) и CMD (команда запуска) — из него собирается образ командой docker build. Для логов работающего контейнера используется docker logs, для команды внутри него — docker exec. Для продакшен-развёртывания дальше потребуется настройка лимитов ресурсов, сети, томов и, при росте числа сервисов, — оркестратор.
После установки первый контейнер запускается командой docker run [OPTIONS] IMAGE — она создаёт и запускает контейнер из указанного образа, автоматически подтягивая его из реестра, если нет локально. docker ps показывает запущенные контейнеры (флаг -a — и остановленные), docker images — список локальных образов, docker stop останавливает контейнер сигналом SIGTERM с принудительным SIGKILL по таймауту.
Dockerfile обычно состоит из инструкций FROM (базовый образ), COPY (копирование файлов), RUN (установка зависимостей) и CMD (команда запуска) — из него собирается образ командой docker build. Для логов работающего контейнера используется docker logs, для команды внутри него — docker exec. Для продакшен-развёртывания дальше потребуется настройка лимитов ресурсов, сети, томов и, при росте числа сервисов, — оркестратор.
Часто задаваемые вопросы о Docker
Это разные уровни задачи, а не конкурирующие инструменты. Docker упаковывает приложение в образ и запускает контейнеры на одном хосте; Kubernetes управляет кластером из множества хостов и решает, на каком узле запустить контейнер, сколько реплик держать и как балансировать трафик между ними.
На практике Kubernetes работает поверх контейнеров, а не вместо Docker — большинство кластеров Kubernetes используют containerd, компонент, изначально выделенный из Docker Engine.
- Единица управления. У Docker это контейнер, у Kubernetes — под (Pod), группа контейнеров с общими сетевыми ресурсами.
- Масштабирование. Docker Compose масштабирует stateless-сервисы вручную флагом --scale; Kubernetes — автоматически через Horizontal Pod Autoscaler.
- Отказоустойчивость. При падении хоста с Compose контейнеры не переезжают на другой узел; Kubernetes перезапускает под на исправном узле кластера сам.
На практике Kubernetes работает поверх контейнеров, а не вместо Docker — большинство кластеров Kubernetes используют containerd, компонент, изначально выделенный из Docker Engine.
Docker CE (сейчас официально называется Docker Engine) распространяется бесплатно по лицензии Apache 2.0, но без поддержки от вендора — только силами сообщества; условия платной подписки на Docker Desktop для крупных организаций стоит сверять в актуальном соглашении Docker Inc., поскольку пороги лицензирования периодически пересматриваются.
Полноценное enterprise-предложение для промышленной эксплуатации — Mirantis Kubernetes Engine (MKE), продукт Mirantis, купившей коммерческую часть Docker Enterprise: распространяется по подписке и включает поддержку вендора, SLA и обновления безопасности. Для инфраструктуры с требованиями к SLA практический выбор — управляемая платформа с контрактной поддержкой; для внутренней разработки бесплатного Docker Engine, как правило, достаточно.
Полноценное enterprise-предложение для промышленной эксплуатации — Mirantis Kubernetes Engine (MKE), продукт Mirantis, купившей коммерческую часть Docker Enterprise: распространяется по подписке и включает поддержку вендора, SLA и обновления безопасности. Для инфраструктуры с требованиями к SLA практический выбор — управляемая платформа с контрактной поддержкой; для внутренней разработки бесплатного Docker Engine, как правило, достаточно.
Для СУБД с интенсивным мелкоблочным вводом-выводом — а это типичный профиль баз 1С и ERP-систем — контейнеризация несёт специфические ограничения, о которых стоит знать до принятия решения. Контейнер без лимита CPU начинает троттлиться при конкуренции за ресурсы, что напрямую бьёт по производительности stateful-нагрузок с интенсивным I/O. Контейнер без лимита памяти рано или поздно получает OOMKilled, что для СУБД означает не просто перезапуск процесса, а риск потери незафиксированных транзакций.
По распространённой в индустрии практике для production-приложений лимит CPU задают в 1,5–2 раза выше запроса, а лимит памяти — в 1,2–1,5 раза выше запроса, чтобы избежать троттлинга и внезапного OOM; точные коэффициенты стоит уточнять нагрузочным тестированием под конкретное приложение, а не брать как жёсткий норматив. Для критичных stateful-нагрузок рекомендуется класс QoS Guaranteed в оркестраторе. Документация Kubernetes определяет его как приоритетный при нехватке ресурсов узла: под с этим классом вытесняется в последнюю очередь, в отличие от классов Burstable и BestEffort. Дополнительная сложность в том, что stateful-нагрузки нельзя свободно перезагружать, удалять или масштабировать в контейнерных группах без сохранения состояния во внешнем хранилище, а storage-драйверы и слои оркестрации добавляют накладные расходы, критичные именно при мелкоблочном I/O баз 1С и ERP.
По совокупности этих ограничений индустриальная практика для СУБД с интенсивным I/O — bare-metal или выделенные виртуальные машины без жёстких лимитов ресурсов, а не контейнеризация в оркестраторе общего назначения. Контейнеризация СУБД оправдана скорее в непроизводственных контурах — разработке, тестировании, staging, — где предсказуемость производительности не критична, а скорость поднятия окружения важнее. Итоговое решение по каждому конкретному контуру 1С или ERP стоит принимать после нагрузочного тестирования на профиле реальных данных заказчика, а не по общей рекомендации.
В наших проектах кластеризации 1С и СУБД для заказчиков такого профиля — например, при построении отказоустойчивого кластера 1С и СУБД для логистической компании с жёстким сроком запуска — мы закладывали bare-metal или выделенные ВМ именно по этой причине: задача была сократить издержки и повысить отказоустойчивость, а не выиграть в скорости поднятия окружения. Для регулируемых отраслей — банков, госструктур, промышленных предприятий с требованиями по 152-ФЗ и импортозамещению — решение по контейнеризации 1С и ERP всегда стоит сверять с актуальным статусом используемого ПО и доступностью отечественных аналогов: уход части зарубежных вендоров с российского рынка уже заставлял нас пересматривать типовые архитектуры под конкретного заказчика.
Итоговое архитектурное решение — как для отдельного контейнера, так и для кластера 1С или ERP — стоит принимать вместе с нагрузочным тестированием и подбором конкретной серверной конфигурации под профиль заказчика; именно с этого наша команда обычно и начинает работу над проектом.
По распространённой в индустрии практике для production-приложений лимит CPU задают в 1,5–2 раза выше запроса, а лимит памяти — в 1,2–1,5 раза выше запроса, чтобы избежать троттлинга и внезапного OOM; точные коэффициенты стоит уточнять нагрузочным тестированием под конкретное приложение, а не брать как жёсткий норматив. Для критичных stateful-нагрузок рекомендуется класс QoS Guaranteed в оркестраторе. Документация Kubernetes определяет его как приоритетный при нехватке ресурсов узла: под с этим классом вытесняется в последнюю очередь, в отличие от классов Burstable и BestEffort. Дополнительная сложность в том, что stateful-нагрузки нельзя свободно перезагружать, удалять или масштабировать в контейнерных группах без сохранения состояния во внешнем хранилище, а storage-драйверы и слои оркестрации добавляют накладные расходы, критичные именно при мелкоблочном I/O баз 1С и ERP.
По совокупности этих ограничений индустриальная практика для СУБД с интенсивным I/O — bare-metal или выделенные виртуальные машины без жёстких лимитов ресурсов, а не контейнеризация в оркестраторе общего назначения. Контейнеризация СУБД оправдана скорее в непроизводственных контурах — разработке, тестировании, staging, — где предсказуемость производительности не критична, а скорость поднятия окружения важнее. Итоговое решение по каждому конкретному контуру 1С или ERP стоит принимать после нагрузочного тестирования на профиле реальных данных заказчика, а не по общей рекомендации.
В наших проектах кластеризации 1С и СУБД для заказчиков такого профиля — например, при построении отказоустойчивого кластера 1С и СУБД для логистической компании с жёстким сроком запуска — мы закладывали bare-metal или выделенные ВМ именно по этой причине: задача была сократить издержки и повысить отказоустойчивость, а не выиграть в скорости поднятия окружения. Для регулируемых отраслей — банков, госструктур, промышленных предприятий с требованиями по 152-ФЗ и импортозамещению — решение по контейнеризации 1С и ERP всегда стоит сверять с актуальным статусом используемого ПО и доступностью отечественных аналогов: уход части зарубежных вендоров с российского рынка уже заставлял нас пересматривать типовые архитектуры под конкретного заказчика.
Итоговое архитектурное решение — как для отдельного контейнера, так и для кластера 1С или ERP — стоит принимать вместе с нагрузочным тестированием и подбором конкретной серверной конфигурации под профиль заказчика; именно с этого наша команда обычно и начинает работу над проектом.