Подготовка Docker для Linux

Этот материал продолжает шаг с выбором способа установки для пользователей Linux. Здесь мы работаем в обычном терминале полноценной системы Ubuntu 24.04 (установленной на компьютер, сервер или в обычную виртуальную машину) под обычной пользовательской учётной записью с доступом к sudo. Для загрузки пакетов и образов понадобится интернет. Если вы запускаете Ubuntu внутри Windows через WSL2, вернитесь к ветке подготовки для Windows: там настройка устроена иначе.

Разберём, как устроен нативный Docker в Ubuntu

Docker Engine в этом маршруте использует ядро Ubuntu и работает как фоновая служба. Устанавливать Docker Desktop для запуска контейнеров не требуется. Подготовим три компонента, которые мы установим из официального репозитория Docker для Ubuntu:

• Docker Engine (dockerd) работает в фоне как системная служба под управлением systemd. Именно этот демон создаёт, запускает и останавливает контейнеры и использует среду выполнения containerd, которую предоставляет пакет containerd.io.
• Docker CLI (docker) служит клиентом командной строки. Когда вы вводите команды в терминале Ubuntu, клиент отправляет запросы фоновой службе Docker Engine через локальный системный сокет /var/run/docker.sock.
• Плагин Docker Compose (docker-compose-plugin) устанавливается вместе с основным движком и добавляет команду docker compose (через пробел, без дефиса). Она пригодится, когда мы будем описывать запуск контейнера в конфигурационном файле.

Поскольку фоновая служба Docker Engine по умолчанию работает с правами суперпользователя (root), доступ к её локальному сокету тоже защищён системными правами. В основном маршруте этого урока мы будем выполнять команды управления контейнерами через sudo docker .... После проверки установки разберём необязательный вариант работы без sudo через группу docker.

Все команды в этом уроке выполняются в вашей штатной рабочей среде «Терминал Ubuntu». Установочные команды выполняем по очереди: если одна из них завершилась с ошибкой, сначала разбираемся с ней. Для диагностических команд ниже отдельно указано, что означает отсутствие вывода.

Проверим выпуск Ubuntu и существующие пакеты

Официальная инструкция Docker поддерживает несколько выпусков Ubuntu с длительным сроком поддержки (включая 22.04 LTS, 24.04 LTS и 26.04 LTS). Этот урок рассчитан на 64-битную Ubuntu 24.04 LTS (Noble). Мы не пишем универсальную инструкцию для всех дистрибутивов Linux сразу, поскольку в системах вроде Debian, Fedora, RHEL или производных сборках вроде Linux Mint настройка репозиториев отличается.

Убедимся, что мы находимся в Ubuntu 24.04, проверим архитектуру процессора и посмотрим, не установлены ли в системе пакеты контейнеризации из других источников. Выполните в среде «Терминал Ubuntu»:

cat /etc/os-release
dpkg --print-architecture
apt list --installed 2>/dev/null | grep -E '^(docker|containerd|runc|podman-docker)'
command -v docker

Сверим результаты первых двух команд с ожидаемыми параметрами системы:

• В выводе cat /etc/os-release должны присутствовать строки ID=ubuntu, VERSION_ID="24.04" и VERSION_CODENAME=noble.
• Команда dpkg --print-architecture покажет одну из поддерживаемых 64-битных архитектур, например amd64 или arm64.

Теперь посмотрим на две оставшиеся команды. Они только показывают сведения о текущей установке: фильтр выводит установленные пакеты, а command -v docker показывает путь к доступному клиенту.

• Если список пакетов пуст и command -v docker не показывает путь, проверенные признаки существующей установки не обнаружены. Фильтр grep при отсутствии совпадений возвращает ненулевой код завершения; это ожидаемый результат диагностики. Дальше проверим, не подключался ли репозиторий Docker раньше.
• Если в списке уже видны docker-ce, docker-ce-cli, containerd.io и docker-compose-plugin, пакеты Docker Engine и Compose уже установлены. Их названия не показывают, из какого источника они были получены. Повторную установку пока пропустим и проверим службу, версии и локальное подключение в разделе ниже.
• Если набор компонентов Docker неполный, например уже есть docker-ce, docker-ce-cli и containerd.io, но нет docker-compose-plugin, это тоже существующая установка. Такой компьютер не считаем чистым: сначала отдельно проверим её источник и недостающие компоненты. Повторять настройку репозитория или устанавливать весь набор поверх неё автоматически не нужно.
• Если команда показала пакеты из репозиториев самого дистрибутива или альтернативные среды (например, docker.io, docker-compose, docker-compose-v2, podman-docker, а также системные containerd или runc), пока не переходите к новой установке. Официальные пакеты Docker конфликтуют с этими компонентами, но автоматически удалять их командами apt remove или apt purge вслепую нельзя: от уже установленного containerd или runc могут зависеть существующие контейнеры, локальные кластеры Kubernetes или другие рабочие сервисы на вашем хосте. Аналогично, если в системе уже откликается команда docker, установленная через пакет snap или подключённая к удалённому демону, не ставьте поверх неё второй экземпляр Docker. В такой ситуации сначала отдельно проверьте, какие проекты уже используют текущую контейнерную среду, и при необходимости спланируйте перенос до перехода к чистой установке.

Подключим официальный репозиторий и установим Docker Engine

На чистой системе Ubuntu 24.04 подключим официальный репозиторий APT от разработчиков Docker и установим актуальные пакеты движка и плагина Compose. Мы используем штатный пакетный менеджер APT в Ubuntu, чтобы все компоненты Docker в дальнейшем обновлялись стандартным системным способом, и не используем сторонние скрипты быстрой установки.

Пакеты могут быть ещё не установлены, а источник APT уже настроен. Проверим, нет ли файла docker.sources и упоминаний репозитория в других настройках APT:

ls -l /etc/apt/sources.list.d/docker.sources 2>/dev/null
grep -R -F 'download.docker.com/linux/ubuntu' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

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

Сначала обновим индекс доступных пакетов, установим утилиты для загрузки ключа по HTTPS, создадим системный каталог /etc/apt/keyrings и скачаем туда официальный GPG-ключ Docker.

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Команда sudo apt update только обновляет списки доступных пакетов и не запускает полное обновление всей операционной системы. Последняя строка sudo chmod a+r /etc/apt/keyrings/docker.asc делает публичный ключ доступным для чтения APT. Она меняет права только на этот файл.

Теперь создадим файл описания репозитория /etc/apt/sources.list.d/docker.sources в современном формате deb822. Подстановка внутри блока автоматически возьмёт кодовое имя выпуска (noble) из /etc/os-release и архитектуру вашей системы из dpkg --print-architecture.

Скопируйте и выполните в терминале весь следующий блок целиком, включая завершающую строку EOF:

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Здесь используется конструкция многострочного ввода (here-document) и команда sudo tee: она позволяет записать текст от имени администратора в защищённый системный каталог /etc/apt/sources.list.d/, куда обычное перенаправление > без прав суперпользователя не сработает. Закрывающая строка EOF отмечает конец многострочного ввода. Её нужно вставить отдельной строкой, без пробелов перед буквами. В ответ команда tee выведет в терминал записанный текст с уже подставленными значениями Suites: noble и вашей архитектурой, после чего вернётся обычное приглашение оболочки.

Теперь ещё раз обновим индекс пакетов, чтобы APT прочитал новый источник, и одной командой установим сам движок, интерфейс командной строки, пакет containerd.io и официальные плагины, включая Docker Compose:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

В выводе sudo apt update вы увидите строки обращения к https://download.docker.com/linux/ubuntu. Если пакетный менеджер при установке пакетов запросит подтверждение, введите Y и нажмите Enter. Устанавливать отдельно старый пакет docker-compose (через дефис) или загружать бинарные файлы вручную не нужно: плагин docker-compose-plugin уже входит в этот набор.

Проверим службу systemd, локальный контекст и тестовый контейнер

В Ubuntu фоновая служба Docker Engine управляется через systemd и обычно запускается и добавляется в автозагрузку автоматически сразу после установки пакетов. Вам не нужно запускать демон dockerd вручную в отдельном окне, держать терминал постоянно открытым или перезагружать компьютер.

Проверим статус службы и её автозапуск:

systemctl is-active docker
systemctl is-enabled docker

Первая команда должна вывести active (служба работает сейчас), а вторая должна вывести enabled (служба автоматически стартует при включении системы). Только в том случае, если первая команда показала, что служба не запущена, запустите её вручную командой sudo systemctl start docker. Аналогично, если автозагрузка оказалась отключена, но вы хотите, чтобы Docker стартовал вместе с системой, включите её командой sudo systemctl enable docker.service.

Теперь проверим связь клиента с серверной частью с помощью docker version, доступность плагина Compose и текущий контекст подключения docker context ls:

sudo docker version
sudo docker compose version
sudo docker context ls

Разберём результаты этих трёх проверок:

• В отличие от короткого флага --version, который показывает только версию самого клиента, команда sudo docker version опрашивает и клиент, и работающий демон. В выводе должны без ошибок отобразиться оба блока: Client: Docker Engine - Community и Server: Docker Engine - Community. Номера версий могут различаться. Для этой проверки нужны оба раздела без ошибки подключения.
• Команда sudo docker compose version должна вернуть строку с версией, начинающуюся с Docker Compose version.
• В таблице sudo docker context ls звёздочкой (*) отмечен активный контекст. На стандартной локальной установке в Ubuntu активным должен быть контекст default с адресом сокета unix:///var/run/docker.sock в колонке DOCKER ENDPOINT. Такое подключение соответствует локальному сокету Docker. Если выбран другой адрес, сначала выясним, к какому движку он ведёт; переключать старые контексты или сбрасывать переменные окружения наугад не будем.

Когда служба и локальный контекст проверены, выполним контрольный пробный запуск официального тестового образа hello-world:

sudo docker run --rm hello-world

Если образа ещё нет локально, Docker загрузит его из Docker Hub. Затем он создаст тестовый контейнер, который выведет Hello from Docker! и завершит работу. Флаг --rm удалит этот контейнер после остановки. Скачанный образ останется в Docker; существующие контейнеры и тома эта команда не удаляет.

Сообщение Hello from Docker! подтверждает успешный запуск тестового контейнера. Если образ загружался именно при этой проверке, мы также проверили доступ Docker к Docker Hub. Запуск уже сохранённого образа сам по себе не проверяет интернет-соединение. Сам Open WebUI и языковые модели на этом шаге ещё не устанавливаются: мы перейдём к ним в следующих уроках.

Разберём работу через sudo и необязательную группу docker

По умолчанию демон Docker в Linux подключается через системный сокет /var/run/docker.sock, который принадлежит пользователю root и группе docker. Поэтому обычный пользователь без sudo не может отправлять команды напрямую в демон.

Для этого маршрута подготовки можно оставить sudo docker .... Менять членство пользователя в группах для работы с Docker необязательно.

Если же вы хотите вводить команды docker и docker compose без постоянного указания sudo, можно воспользоваться штатным механизмом из официального руководства по послеустановочной настройке Linux и добавить свою учётную запись в системную группу docker. У этой настройки есть существенное следствие:

• Членство в группе docker даёт права, эквивалентные правам root на хосте. Это доступ к управлению системой, а не только возможность открыть интерфейс Open WebUI.
• Добавление пользователя в группу docker лишь убирает ввод sudo перед командами, но сам демон остаётся работать от имени root (это не то же самое, что режим Rootless Docker, в котором сам демон работает без прав root).
• Для доступа используем sudo или выбранную группу. Команда chmod 666 /var/run/docker.sock дала бы доступ к Docker всем локальным пользователям; для этой настройки она не подходит.

Если вы решили настроить работу без sudo (необязательно)

Если вы работаете на собственной машине и осознанно хотите добавить своего текущего обычного пользователя в группу docker, сначала проверим, существует ли эта группа в системе (обычно пакет установки создаёт её автоматически):

getent group docker

Если команда вывела строку вида docker:x:..., группа уже есть. Только в том случае, если команда ничего не вернула, создайте группу вручную: sudo groupadd docker.

Теперь добавим вашего текущего пользователя (переменная $USER автоматически подставит имя вашей учётной записи, под которой вы вошли в терминал) в группу docker:

sudo usermod -aG docker "$USER"

Чтобы система применила обновлённый список групп к вашей учётной записи, просто открыть новую вкладку или новое окно терминала недостаточно. В Ubuntu Desktop выйдите из учётной записи через меню Log Out и войдите снова. В Ubuntu Server завершите сеанс под этой учётной записью и начните новый.

После повторного входа в систему проверьте, что команды теперь работают без sudo и обращаются к тому же локальному сокету (поскольку у обычного пользователя и у root настройки клиентского контекста хранятся раздельно):

docker version
docker compose version
docker context ls

Первая команда должна показать Client и Server без ошибки доступа, вторая версию Compose, а третья локальный контекст default со звёздочкой и сокетом unix:///var/run/docker.sock. Если же вы решили остаться на стандартном варианте с sudo, просто пропускайте эту настройку и в следующих уроках выполняйте команды Docker с префиксом sudo.

Проверим OpenSSL и создадим рабочую папку проекта

При новой установке Open WebUI нам понадобится случайный секретный ключ WEBUI_SECRET_KEY для защиты пользовательских сессий с помощью команды openssl rand -hex 32. Создадим ключ на этапе запуска новой установки. При последующих обновлениях сохраним прежнее значение. Сейчас нам нужно лишь убедиться, что утилита openssl установлена в Ubuntu.

Выполните проверку от имени вашего обычного пользователя (без sudo):

openssl version

В Ubuntu 24.04 пакет OpenSSL обычно уже предустановлен в системе, и команда сразу выводит строку вида OpenSSL 3.... В этом случае ничего дополнительно устанавливать не нужно.

Только если терминал сообщил об отсутствии команды (command not found), установите её через штатный пакетный менеджер APT и проверьте версию ещё раз:

sudo apt update
sudo apt install openssl
openssl version

Теперь подготовим в домашнем каталоге вашего обычного пользователя рабочую папку ~/projects. В следующих уроках мы будем хранить в ней конфигурационные файлы запуска (например, compose.yaml и файл окружения с параметрами). Внутренние данные Open WebUI при контейнерной установке будем хранить в отдельном постоянном томе под управлением Docker. Рабочая папка нужна для конфигурации запуска.

Создадим каталог и перейдём в него от имени обычного пользователя, без sudo. Тогда папка будет принадлежать вашей учётной записи:

mkdir -p ~/projects && cd ~/projects
pwd

Команда pwd покажет полный путь к созданному каталогу. Для стандартной учётной записи в Ubuntu это путь вида /home/<ваше_имя_пользователя>/projects. Если домашний каталог настроен иначе, ориентируемся на вывод pwd.

Разберём частые заминки и проверим готовность к запуску

Если на каком-то этапе проверка показала ошибку, не спешите переустанавливать пакеты, удалять системные каталоги или запускать разрушительные команды очистки вроде docker system prune или rm -rf ~/.docker. Разберём, что проверить при основных сообщениях об ошибках:

• При вводе docker version без sudo появляется ошибка permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock. Это штатное поведение системы, если вы не настраивали группу docker или ещё не вышли из системы после команды usermod. Используйте sudo docker version (основной способ) либо завершите сеанс пользователя в Ubuntu и войдите в систему заново, если вы уже добавили учётную запись в группу docker. Менять права на файл /var/run/docker.sock через chmod нельзя.
• Команда sudo docker version показывает раздел Client, но вместо Server сообщает Cannot connect to the Docker daemon.... Клиенту не удалось связаться с выбранным демоном. Проверим systemctl is-active docker и sudo docker context ls: служба могла остановиться, а клиент мог обращаться к другому адресу. Если локальная служба остановлена (inactive), запустим её через sudo systemctl start docker и повторим проверку.
• Команда docker выдаёт предупреждение об ошибке чтения конфигурационного файла в ~/.docker (permission denied на файлах внутри домашней папки). Такое случается, если ранее какие-то команды настройки клиентского профиля запускались с некорректным сочетанием прав и папка ~/.docker в домашнем каталоге оказалась записана на пользователя root. Не удаляйте эту папку вслепую, особенно если в ней уже сохранены контексты или авторизации в реестрах: сначала проверьте владельца файлов командой ls -la ~/.docker.
• Команда sudo docker version и systemctl is-active docker работают отлично, но sudo docker run --rm hello-world завершается ошибкой сети или таймаутом загрузки. Демон отвечает на запрос версии, а ошибка возникла при получении образа. Она может быть связана с подключением к интернету, настройками DNS, корпоративным прокси, межсетевым экраном или ограничениями доступа к внешнему реестру образов. Проверьте соединение с сетью и доступность внешних адресов перед переходом к загрузке более крупного образа Open WebUI.

Сверим результаты. Подготовка Docker в Ubuntu 24.04 завершена, когда выполняются пять условий:

1. Системная служба Docker работает: systemctl is-active docker выводит active.
2. Команды sudo docker version и sudo docker compose version (или они же без sudo, если вы настроили группу docker и перезашли в сессию) выводят версии клиента, работающего сервера Docker Engine и плагина Docker Compose без ошибок.
3. Команда sudo docker context ls (и docker context ls при работе без sudo) показывает активный локальный контекст default, отмеченный звёздочкой с сокетом unix:///var/run/docker.sock.
4. Проверочный запуск sudo docker run --rm hello-world успешно выводит сообщение Hello from Docker!.
5. Команда openssl version возвращает версию утилиты, а в домашнем каталоге пользователя создана папка ~/projects, путь к которой проверен через pwd.

Дальше перейдём к установке Open WebUI через Docker Compose. Продолжим работу в терминале Ubuntu 24.04. Если доступ к движку вы проверяли через sudo docker, в следующем уроке этот префикс сохраняется. Конфигурацию и файл ключа будем создавать от обычного пользователя.

Этот маршрут рассчитан на открытие браузера на том же компьютере. Для удалённого Linux-сервера понадобится отдельно настроить доступ; серверная ветка остаётся в программе курса.