Docker

Docker оправдан практически в каждом современном проекте, но особенно ценен, когда нужны воспроизводимые окружения от dev до prod, когда в команде больше двух разработчиков с идентичными локальными сетапами, или когда планируется деплой на Kubernetes, ECS или другую платформу оркестрации. Прямой деплой на VM всё ещё имеет смысл для legacy-приложений со сложными OS-зависимостями, для специализированных серверов (например, выделенная СУБД), или для сверхчувствительных к латентности нагрузок, где сетевой слой контейнера вносит измеримую задержку (обычно менее 1 %, но не нулевую). Для новых проектов Docker — дефолт: он устраняет проблемы «у меня работает», создаёт консистентные CI/CD-артефакты и делает приложение переносимым между любым облаком и on-premises инфраструктурой.

Безопасность Docker в продакшене требует осознанной настройки на нескольких уровнях. Контейнеры запускаются от non-root пользователя (директива USER в Dockerfile), лишние Linux capabilities убираются, файловая система корня монтируется в read-only где возможно. Базовые образы привязываются к конкретным digest-версиям, а не к тегу «latest», чтобы предотвратить supply-chain атаки. Каждый образ сканируется на известные CVE через Trivy или Snyk в CI-пайплайне, сборка падает при обнаружении критических уязвимостей. Подпись образов Cosign или Docker Content Trust верифицирует происхождение перед деплоем. В рантайме мы применяем seccomp и AppArmor профили для ограничения системных вызовов, сетевые политики для изоляции трафика между контейнерами, а секреты монтируются из HashiCorp Vault или cloud-native secrets manager, а не запекаются в образ.

Оптимизация Docker-образов начинается с multi-stage builds: первая стадия устанавливает инструменты сборки, компилирует код и запускает тесты, финальная — копирует только рантайм-артефакты в минимальный базовый образ (alpine, distroless или scratch для Go). Это регулярно сокращает размер образа с 1+ ГБ до менее 100 МБ, а для Go-сервисов — до 20 МБ. Порядок слоёв имеет значение: часто меняющиеся инструкции (COPY кода) должны идти после редко меняющихся (COPY манифеста зависимостей, RUN install). BuildKit cache mounts (--mount=type=cache) сохраняют кэш пакетных менеджеров (npm, pip, composer) между сборками. .dockerignore исключает node_modules, .git и другие ненужные директории из контекста сборки. В CI мы используем inline cache или registry-based caching для переиспользования слоёв между запусками пайплайна, сокращая типичное время сборки с 5–10 минут до 1–2.

Docker Compose — инструмент для запуска многоконтейнерных приложений на одном хосте, идеальный для локальной разработки: приложение, база данных, кэш, брокер сообщений запускаются одной командой. Compose использует декларативный YAML и не предназначен для продакшен-оркестрации. Docker Swarm — встроенный в Docker режим кластеризации с балансировкой нагрузки и service discovery, проще в настройке, чем Kubernetes, но практически не развивается с 2020 года и редко выбирается для новых проектов. Kubernetes — индустриальный стандарт оркестрации: продвинутый планировщик, автоскейлинг, rolling deployments, self-healing и огромная экосистема операторов. Он сложнее в эксплуатации, но справляется с продакшен-нагрузками любого масштаба. Наша рекомендация: Docker Compose для разработки, Kubernetes (EKS, AKS, GKE) для продакшена. Swarm — только для небольших деплоев, где Kubernetes overhead не оправдан.

Экосистема Docker в 2026 году зрелая и глубоко встроена в каждый этап разработки. Docker Desktop остаётся основным инструментом на macOS и Windows, хотя OrbStack (нативный для macOS, быстрее I/O) и Podman (без демона, rootless) набрали серьёзную долю. BuildKit — дефолтный движок сборки с поддержкой параллельных multi-stage builds, cache mounts и кросс-платформенных сборок. Реестры образов: GHCR, AWS ECR, Azure ACR и Docker Hub — все поддерживают OCI-спецификацию и подпись артефактов. На стороне рантайма containerd заменил Docker daemon в большинстве дистрибутивов Kubernetes, но Docker CLI и Dockerfile остаются универсальным интерфейсом сборки. Testcontainers (Java, Go, Node.js, Python, .NET) стал стандартом интеграционного тестирования. Инструменты безопасности цепочки поставок — Cosign, Syft для SBOM, Trivy или Grype для сканирования — теперь стандартные этапы CI-пайплайна.