Контейнеры
Docker: контейнерный движок, который копируют все
Docker сделал контейнеры общеупотребительными: образы, реестры и CLI превратили «работает у меня» в вопрос упаковки. Он остаётся движком по умолчанию в большинстве хостингов, а гигиена образов, безопасность демона и Compose определяют, снижают ли контейнеры риск или просто меняют его форму.
Главное
- Модель — образы и слои: каждый образ состоит из кешированных слоёв, каждая инструкция Dockerfile создаёт слой, порядок сборки управляет попаданиями в кеш; multi-stage сборки уменьшают финальный образ и не тащат инструменты в прод.
- Демон — привилегированная поверхность: Docker daemon с root и API-сокетом эквивалентен root на хосте; проброс сокета в контейнер (-v /var/run/docker.sock) отдаёт всю машину. Современная практика — rootless, user namespaces и аудит сокета.
- Compose — стандарт для небольших хозяйств: многокомпонентные стеки с volumes, networks и healthchecks как код; большинству хостингов не нужен оркестратор, а дисциплина Compose — зависимости, healthchecks и restart policies — делает их стабильными.
- Управление ресурсами уходит в cgroups: лимиты памяти и CPU на контейнер обязательны на общих хостах, иначе утечка в сборке или сбежавший cron съест хост; логи по умолчанию пишутся огромными JSON-файлами, поэтому нужна ротация.
- Гигиена образов — это гигиена цепочки поставок: сканирование CVE (например, Trivy), закрепление по digest вместо изменяемых тегов, секреты не в слоях (build args утекают, mounts нет) и приватный реестр с проверкой подписей.
- Честные границы: Docker Swarm существует, но отраслевой импульс у Kubernetes; реестры, storage drivers и сетевые модели добавляют поверхность обучения. Оптимум для хостинга — Compose-стеки на нескольких хорошо наблюдаемых хостах.
Заметка из практики
Инцидент на Docker-хосте, из-за которого появилось правило лимитов: один безлимитный build-контейнер съел память хоста и уронил базы рядом. На той неделе лимиты получило всё, и с тех пор мы пережили ещё три сбежавших сборки без страницы.
Частые вопросы
Docker умер с появлением Podman?
Нет. Docker остаётся движком по умолчанию, который поддерживают почти все, а Podman явно стремится к совместимости CLI. Выбор — между daemon и no-daemon, а также между ОС (RHEL несёт Podman, Ubuntu чаще остаётся на Docker).
Какие первые пять шагов безопасности на Docker-хосте?
Rootless или userns-remap; не пробрасывать сокет в контейнеры; лимиты ресурсов везде; автоматическое сканирование образов в CI; настроить ротацию логов до первого переполнения диска.
Контейнеры отменяют необходимость патчить хост?
Абсолютно нет: ядро, движок и хранилище всё ещё патчатся; контейнеры лишь переносят патчи приложения на пересборку образов, и это выигрыш только если пересборка действительно запускается.
Когда Docker — избыточен?
Для машин с одним сервисом и одним runtime (один PostgreSQL, один основной WordPress) хорошо пропатченная нативная установка имеет меньшую поверхность и проще в мониторинге; контейнеры окупаются переносимостью образов или изоляцией сервисов.
Как мы берём на себя контейнеры
Договорились: Управление, оркестрация и безопасность контейнеров в производственной среде. Передайте это нашей услуге Администрирование серверов и Безопасность серверов Linux — вопрос будет закрыт, оценён по делу, внедрён без лишних движений и под наблюдением круглосуточно.