Docker Engine, Desktop и рабочий context

В предыдущем уроке отделили образ от контейнера и настроек запуска. Теперь подготовим рабочее окружение, в котором эти объекты появятся. Результатом будет паспорт Docker: выбранный context, версии клиента и сервера, версия Compose и платформа. Установка зависит от операционной системы, поэтому не будем переносить команды для одного компьютера на все остальные.

Все команды ниже предназначены для самостоятельного выполнения читателем. При написании серии Docker не устанавливался и не запускался. В исходных файлах значения паспорта оставлены пустыми, а ожидаемые результаты описаны словами. Такое состояние позволяет сохранить честную границу между инструкцией и уже проверенным окружением.

Клиент и сервер выполняют разные задачи

Команда docker относится к клиенту. Клиент передаёт запрос Docker Engine, а Engine создаёт контейнеры, читает образы и работает с хранилищем. Наличие исполняемого файла docker ещё не означает, что сервер доступен. Можно установить клиент, но не запустить daemon; можно направить клиент на другую машину и видеть её ресурсы.

На обычном Linux возможна установка Docker Engine по инструкции для конкретного дистрибутива. Docker Desktop предоставляет связанный рабочий набор для поддерживаемых систем, включая управление окружением через интерфейс. На macOS Linux-контейнеры требуют Linux-среду Desktop. На Windows выбор зависит от поддерживаемой конфигурации, в том числе WSL 2. Начинать следует с официального выбора способа установки и страницы Docker Desktop, поскольку требования и установщики меняются.

Старые инструкции иногда предлагают вручную выполнять фиксированный набор системных команд для настройки WSL. Следовать им вслепую неудобно: текущая версия Windows, включённые компоненты и состояние обновления отличаются. Выберите инструкцию своей платформы, проверьте системные требования и только затем устанавливайте. В учебный проект не включаем универсальный скрипт, который меняет настройки компьютера.

Сначала определим адрес назначения

Docker context связывает имя с параметрами подключения к Engine. Обычно читатель использует локальное окружение, однако на рабочей машине могут остаться context для сервера или другого Desktop. Перед командой, которая создаёт или удаляет ресурс, нужно понимать, где именно этот ресурс находится.

docker context show
docker context ls
docker version
docker compose version

Выполняйте строки отдельно, читая результат каждой. Context show должен назвать активный context, а список — помочь связать его с endpoint. Docker version обычно показывает части Client и Server. Если есть только данные клиента и ошибка подключения, переходить к сборке API рано: проблема ещё в соединении с Engine.

Проверяем именно docker compose, с пробелом. Серия использует Compose v2. Команда с дефисом может относиться к другой установке и старому интерфейсу; наличие такого файла само по себе не подтверждает требуемый профиль. Конкретный номер версии Compose читатель запишет из своего результата, а не возьмёт из скриншота или текста курса.

Какие сведения записываем

Сведение	Зачем оно нужно	Как трактовать отсутствие
Активный context	Понимать, на каком Engine появятся ресурсы	Не выполнять операции с неясным адресом
Client и Server	Различать CLI и доступный daemon	Ошибка Server требует настройки подключения
Compose v2	Использовать compose.yaml и текущую команду	Установить подходящий Compose по документации
ОС и архитектура	Выбрать совместимые образы и mounts	Не обещать совместимость без уточнения
Способ запуска Engine	Повторить окружение после перезагрузки	Записать Desktop или установленный Engine

Создайте environment-record.json рядом с model.json. Ниже полный начальный файл. После самостоятельной подготовки заменяйте null собственными наблюдаемыми значениями. Execution меняйте только вместе с записью того, что действительно было выполнено: паспорт окружения не означает успешного запуска всего учебного проекта.

{
  "execution": "not_run",
  "context": null,
  "cli_version": null,
  "server_version": null,
  "compose_version": null,
  "platform": null,
  "cpu_architecture": null
}

Такой паспорт пригодится для обсуждения ошибки. Сообщение «у меня Docker установлен» мало что говорит о daemon, Compose и платформе. Несколько точных строк помогают отделить проблему команды от проблемы сетевого соединения и дают возможность повторить окружение позднее. Пароли, токены registry и приватные endpoint с секретами в этот файл не записываем.

Проверим список, не создавая приложение

Когда выбран понятный Engine, читатель может посмотреть существующие ресурсы. Эти команды читают состояние и ещё не запускают наш API:

docker image ls
docker container ls --all

Пустой список образов не является ошибкой. Он означает, что на выбранном Engine пока нечего показывать. Непустой список также не подтверждает происхождение ресурсов: могли остаться другие проекты. В дальнейшем будем давать собственные имена контейнерам и тегам, чтобы случайный похожий образ не стал частью курса.

Если строки Docker Desktop и вывод CLI отличаются, сначала сравните context и выбранное окружение. Интерфейс может показывать другую категорию ресурсов; остановленные контейнеры не обязаны появляться в списке запущенных. В контейнерном списке флаг all расширяет наблюдение, но ничего не удаляет. Он нужен для понимания состояния, а не для очистки машины.

Разберём типичные отказы

Ошибка соединения с daemon требует проверить, запущен ли выбранный Engine и доступен ли его endpoint. Для Desktop это может быть ещё запускающееся окружение. Для установленного Linux Engine — состояние службы и выбранная конфигурация. Не пытайтесь исправить любую такую ошибку скачиванием другого образа: до образов запрос пока не дошёл.

Отказ доступа к Docker socket относится к правам подключения. Не делайте socket доступным всем пользователям через произвольное изменение разрешений. Docker Engine предоставляет сильные возможности управления системой, поэтому способ выдачи доступа выбирают по официальной инструкции и правилам компьютера. Для некоторых случаев подходит rootless-конфигурация; это отдельный профиль, который также следует зафиксировать.

На Desktop доступность локального каталога для bind mount может зависеть от настроек и файловой системы. Сейчас каталог ещё не подключаем, но заранее полезно держать проект в понятной пользовательской папке. Сетевой диск, необычные символические ссылки и ограничения доступа способны усложнить последующие занятия. Перенос проекта в другую папку не должен сопровождаться удалением неизвестных Docker volumes.

Что будет входом следующего урока

Продолжать можно, когда читатель понимает выбранный context, получает сведения Server и знает, что команда Compose соответствует v2. Это конкретный ожидаемый критерий, а не требование совпадения с чужим номером patch-релиза. Команды могут вернуть новые версии — запишите их, затем сверяйте особенности с текущей документацией.

Далее выберем базовый образ Node.js и создадим собственный API. В образе не будет установленного редактора, браузера или всего компьютера разработчика. Только нужное окружение процесса и явные файлы приложения. Поэтому паспорт нужен сейчас: он описывает внешнюю часть условий, которую Dockerfile сам внутри себя не фиксирует.

Оглавление серии