Не удаётся подключиться к Docker daemon

TL;DR

Если команда docker сообщает «Cannot connect to the Docker daemon», проверьте, что сервис docker работает, что ваш CLI использует правильный endpoint (контекст/DOCKER_HOST) и что у вашей учётной записи есть права доступа к сокету /var/run/docker.sock. Откройте системный журнал и используйте systemctl, dockerd и docker context для диагностики.

Быстрые ссылки

• Признаки проблемы
• Проверить, запущен ли сервис Docker daemon
• Запуск демона вручную
• Убедиться, что CLI обращается к правильному демону
• Проблемы с правами доступа
• Дополнительные сценарии и методики
• Критерии приёмки
• Резюме

Признаки проблемы

Docker CLI зависит от соединения с демоном (daemon). CLI общается с демоном по API через Unix-сокет или TCP. Если настроенный демон недоступен, команды такие как:

docker ps

docker run

docker build

будут выдавать ошибку вида:

$ docker run hello-world:latest

Cannot connect to the Docker daemon at unix:///var/run/docker.sock

Is the docker daemon running?

Это говорит о том, что CLI пытался использовать Unix-сокет /var/run/docker.sock, но сокет был недоступен — соединение не удалось.

Иногда в ошибке указан TCP-адрес, например:

Cannot connect to the Docker daemon at tcp:///0.0.0.0:2375

В этом случае CLI пытается подключиться по сети к удалённому демону, а не к локальному сокету.

1. Проверить, запущен ли сервис Docker daemon

На большинстве систем Docker управляется systemd-сервисом. Сначала проверьте состояние сервиса:

$ sudo systemctl status docker

Ожидаемое состояние:

Active: active (running)

Если вы видите inactive (dead) или failed, демон не запущен или завершился с ошибкой. Запустите сервис:

$ sudo systemctl start docker

Чтобы автозапускать Docker после перезагрузки хоста:

$ sudo systemctl enable docker
$ sudo systemctl daemon-reload

Команда daemon-reload обновляет конфигурацию systemd.

Важно: если systemctl сообщает, что daemon завершился с ошибкой, посмотрите логи:

$ sudo journalctl -u docker --no-pager

Логи помогут выявить причины — нехватка места, проблемы с драйвером хранения, конфликт портов и т. п.

2. Запуск демона вручную

На системах без systemd или если сервис отсутствует, можно запустить демон напрямую:

$ sudo dockerd

Пример вывода запуска:

INFO[2022-06-29T15:12:49.303428726+01:00] Starting up

Dockerd будет работать в текущем терминале до тех пор, пока вы не нажмёте Ctrl+C или не завершите процесс. Этот способ полезен для отладки: вы увидите поток логов в реальном времени.

Советы при ручном запуске:

• Запускайте dockerd с ключом -D для включения дебага.
• Если требуется отличная конфигурация (например, задать другой socket или TLS), используйте опции командной строки или файл конфигурации /etc/docker/daemon.json.

3. Убедиться, что CLI обращается к правильному демону

Проблема часто возникает, когда CLI направлен к удалённому демону. Ошибка с TCP-адресом сигнализирует, что используется сетевой endpoint:

Cannot connect to the Docker daemon at tcp:///0.0.0.0:2375

Проверьте текущие контексты Docker и активный endpoint:

$ docker context ls

Вывод может выглядеть так:

NAME   DESCRIPTION                         DOCKER ENDPOINT
default * Current DOCKER_HOST based configuration unix:///var/run/docker.sock

Если в колонке DOCKER ENDPOINT вы видите tcp://… — значит CLI направлен на удалённый хост. Частая причина — установлена переменная окружения DOCKER_HOST. Пример:

$ export DOCKER_HOST=1.2.3.4
$ docker context ls

NAME   DESCRIPTION                         DOCKER ENDPOINT
default * Current DOCKER_HOST based configuration tcp://1.2.3.4:2375

Warning: DOCKER_HOST environment variable overrides the active context. To use a context, either set the global --context flag, or unset DOCKER_HOST environment variable.

Если DOCKER_HOST установлен, он переопределяет выбранный контекст. Очистите переменную, чтобы вернуться к контексту:

$ export DOCKER_HOST=

Или явно выберите контекст:

$ docker context use default

После этого docker будет по умолчанию обращаться к unix:///var/run/docker.sock, если вы не настраивали кастомный контекст.

4. Проблемы с правами доступа

Если демон работает, но у вас нет прав на сокет, команда выдаст ошибку вида:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Unix-сокет имеет владельца и права доступа. Лучшая практика — добавить пользователя в группу docker:

$ sudo usermod -aG docker $USER

После изменения групповой принадлежности откройте новый терминал или выполните выход и повторный вход в сессию; изменения вступят в силу только в новой сессии.

Альтернатива (менее рекомендуемая) — запускать команды с sudo:

$ sudo docker ps

Но постоянный запуск Docker от root не рекомендуется по соображениям безопасности.

Дополнительные сценарии и методики

Ниже — набор практических приёмов для редких или сложных случаев.

Проверка состояния сокета

Посмотрите, существует ли сокет и какие у него права:

$ ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 Jun 29 15:12 /var/run/docker.sock

Если сокета нет — демон не запущен. Если сокет есть, убедитесь, что ваша учётная запись в группе docker или права позволяют доступ.

Диагностика сетевых попыток

Если CLI пытается подключиться по TCP, проверьте доступность порта:

$ nc -vz 1.2.3.4 2375

Если порт закрыт — соединение будет недоступно. Также проверьте брандмауэр и сетевые правила между вашей машиной и хостом демона.

Проверка конфигурации daemon.json

Файл /etc/docker/daemon.json содержит параметры демона. Ошибки в JSON приведут к тому, что systemd не сможет запустить сервис. Валидируйте файл перед перезапуском:

$ sudo cat /etc/docker/daemon.json | jq .

Если jq отсутствует, используйте любой JSON-валидатор.

Логи контейнерного движка и драйверов

При ошибках драйверов хранения или сети демон может падать. Изучите journalctl -u docker и системные логи ядра.

Методика быстрого устранения неполадок (минимальный чек-лист)

1. Проверить, работает ли systemd-сервис: sudo systemctl status docker.
2. Если нет — запустить: sudo systemctl start docker и проверить логи: sudo journalctl -u docker.
3. Проверить, к какому endpoint обращается CLI: docker context ls и echo $DOCKER_HOST.
4. Убедиться в правах доступа к /var/run/docker.sock: ls -l /var/run/docker.sock и id.
5. При необходимости перезапустить демон и/или пересоздать socket: sudo systemctl restart docker.
6. Проверить конфигурацию /etc/docker/daemon.json на валидность.

Decision flowchart

flowchart TD
  A[Команда docker выдала ошибку подключения] --> B{systemd?}
  B -- Да --> C[Проверить status: sudo systemctl status docker]
  C --> D{Active?}
  D -- Да --> E[Проверить DOCKER_HOST и context]
  D -- Нет --> F[Запустить sudo systemctl start docker и посмотреть логи]
  B -- Нет --> G[Запустить sudo dockerd вручную для отладки]
  E --> H{Права на /var/run/docker.sock}
  H -- Нет --> I[Добавить в группу docker: sudo usermod -aG docker $USER]
  H -- Да --> J[Проверить сеть/порт для TCP и firewall]

(Диаграмма на языке Mermaid; визуализируется в поддерживающих рендер.)

Ролевые чек-листы

Администратор хоста:

• Проверить systemd и логи (journalctl).
• Перезапустить сервис и изучить причину падения демона.
• Проверить диск, inode, SELinux/AppArmor.
• Обновить daemon.json, если конфигурация изменилась.

DevOps/инженер CI:

• Проверить, не поменялся ли DOCKER_HOST в CI-скриптах.
• Убедиться, что сборщики направлены на корректный контекст.
• Проверить workspace на недостаток прав к сокету.

Разработчик:

• Проверить локальную переменную окружения DOCKER_HOST.
• Добавить себя в группу docker или использовать sudo для краткосрочной проверки.
• Попробовать docker context use default.

SOP: быстрое восстановление доступа (шаги)

1. В терминале выполнить sudo systemctl status docker.
2. Если сервис не активен, выполнить sudo systemctl start docker.
3. Если после старта демон падает — посмотреть sudo journalctl -u docker --no-pager и исправить причину.
4. Проверить контексты: docker context ls и очистить переменную DOCKER_HOST, если нужно: export DOCKER_HOST=.
5. Проверить права на сокет: ls -l /var/run/docker.sock и добавить пользователя в группу: sudo usermod -aG docker $USER.
6. Открыть новый терминал, повторить команду docker run hello-world:latest.

Критерии приёмки

• docker ps возвращает список контейнеров (или пустой список) без ошибок подключения.
• docker info выполняется и показывает статус демона и endpoint.
• Пользователь может запустить docker run hello-world без sudo, если добавлен в группу docker.
• Для CI-систем — все сборочные агенты успешно подключаются к ожидаемому демону.

Когда стандартные подходы не помогут

• Демон запускается, но падает сразу из-за ошибок драйвера хранения — проверьте драйверы и сообщения ядра.
• Сетевая политика в облаке блокирует доступ к удалённому демону — проверьте правила Security Group/Firewall.
• SELinux/AppArmor может блокировать доступ к сокету — исследуйте AVC-логи и профиль безопасности.

Альтернативные подходы

• Использовать Docker-in-Docker (dind) в CI, если нет прямого доступа к демону.
• Перейти на rootless mode, чтобы запускать docker daemon от непривилегированного пользователя (требует настройки).
• Перейти на контейнерную платформу типа Podman, если политика безопасности запрещает демон Docker.

Факты и полезные константы

• Unix-сокет по умолчанию: /var/run/docker.sock
• TCP-порт по умолчанию для неконфигурированного демона: 2375 (обычно небезопасен без TLS)
• Файл конфигурации демона: /etc/docker/daemon.json

Риски и рекомендации по безопасности

• Открытие TCP-порта 2375 без TLS даёт полный доступ к демону и потенциально к хосту — избегайте этого в продакшене.
• Добавление пользователя в группу docker даёт ему привилегии, эквивалентные root в контексте управления контейнерами. Управляйте членством в группе осторожно.

Резюме

Ошибка «Cannot connect to the Docker daemon» означает, что CLI не может связаться с демоном по текущей конфигурации. Чаще всего это простые причины: сервис Docker не запущен, CLI направлен не на тот endpoint (DOCKER_HOST/контекст) или у пользователя нет прав на сокет. Следуйте чек-листам в статье для быстрой диагностики и используйте логи демона для поиска корневой причины.

Важно: при работе с удалёнными демонами всегда проверяйте безопасность соединения (TLS) и сетевые правила.