Что такое Docker Daemon?

Docker Daemon (dockerd) — это основной фоновый сервис (демон), который управляет жизненным циклом Docker-объектов: образами, контейнерами, сетями и томами. В DevOps-практике мы взаимодействуем с ним через Docker CLI или API, чтобы автоматизировать развёртывание.

Его роль в CI/CD-пайплайне:

1. Сборка образов: Когда Jenkins-агент выполняет docker build, он отправляет контекст сборки и Dockerfile демону, который создаёт образ.
2. Запуск тестовых контейнеров: В пайплайне мы часто запускаем изолированные контейнеры для юнит-тестов или интеграционного тестирования (docker run --rm test-image).
3. Пуш образов в registry: Команда docker push инструктирует демону отправить собранный образ в реестр вроде Docker Hub или GitLab Container Registry.

Пример взаимодействия в скрипте развёртывания:

#!/bin/bash
# Типичный скрипт деплоя на staging-сервер
IMAGE_TAG="myapp:$CI_COMMIT_SHA"

# 1. Демон на CI-сервере собирает образ
sudo docker build -t $IMAGE_TAG .

# 2. Демон пушит образ в приватный registry
sudo docker push $REGISTRY/$IMAGE_TAG

# 3. По SSH на целевом хосте: демон стягивает и запускает новый контейнер
ssh deploy@staging "
  sudo docker pull $REGISTRY/$IMAGE_TAG && 
  sudo docker stop myapp_container || true && 
  sudo docker rm myapp_container || true && 
  sudo docker run -d --name myapp_container --restart unless-stopped $REGISTRY/$IMAGE_TAG
"

Критические аспекты для продакшена:

• Безопасность: Демон по умолчанию слушает UNIX-сокет /var/run/docker.sock. Предоставление к нему доступа равносильно правам root. В продакшене мы настраиваем TLS-аутентификацию для удалённого API или используем его только через доверенные инструменты (например, Portainer).
• Производительность и стабильность: Демон может стать единой точкой отказа. В высоконагруженных системах мы переходим на оркестраторы вроде Kubernetes, где его роль распределена между kubelet и containerd/cri-o, что повышает отказоустойчивость.
• Логирование: Все действия демона логируются (часто в journald). Мы настраиваем сбор этих логов в центральную систему (например, Loki или ELK) для аудита и отладки инцидентов.