Оригинал: https://timofei-ermolaev.ru/courses/open-webui/install/podgotovka-docker-dlya-linux/

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

Подготовим Ubuntu 24.04 LTS к запуску Open WebUI: установим Docker Engine с плагином Compose и проверим, как команды в терминале обращаются к локальному движку. Затем проверим OpenSSL и подготовим папку для файлов проекта.

[![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_Z1x8STQ.webp)](<https://timofei-ermolaev.ru/ob-avtore/>)

[Тимофей Ермолаев](<https://timofei-ermolaev.ru/ob-avtore/>) Директор по информационным технологиям (CIO)

**Опубликовано**

15 октября 2026 г.

**Обновлено**

15 октября 2026 г.

**На урок**

30 мин

**Тема**

[Установка Open WebUI](<https://timofei-ermolaev.ru/courses/open-webui/install/>)

## После урока вы сможете

- Понять, как Docker Engine работает в Ubuntu без Docker Desktop
- Установить Docker Engine и плагин Compose из официального репозитория
- Проверить локальную службу, права доступа, OpenSSL и рабочую папку

Этот материал продолжает шаг с [выбором способа установки](<https://timofei-ermolaev.ru/courses/open-webui/install/choose/>) для пользователей Linux. Здесь мы работаем в обычном терминале полноценной системы Ubuntu 24.04 (установленной на компьютер, сервер или в обычную виртуальную машину) под обычной пользовательской учётной записью с доступом к `sudo`. Для загрузки пакетов и образов понадобится интернет. Если вы запускаете Ubuntu внутри Windows через WSL2, вернитесь к ветке подготовки для Windows: там настройка устроена иначе.

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

Docker Engine в этом маршруте использует ядро Ubuntu и работает как фоновая служба. Устанавливать Docker Desktop для запуска контейнеров не требуется. Подготовим три компонента, которые мы установим из [официального репозитория Docker для Ubuntu](<https://docs.docker.com/engine/install/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](<https://ubuntu.com/server/docs/how-to/software/package-management/>) , чтобы все компоненты 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](<https://docs.docker.com/compose/install/linux/>) :

```
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`](<https://docs.docker.com/engine/daemon/start/>) и обычно запускается и добавляется в автозагрузку автоматически сразу после установки пакетов. Вам не нужно запускать демон `dockerd` вручную в отдельном окне, держать терминал постоянно открытым или перезагружать компьютер.

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

```
systemctl  is-active  docker  
systemctl  is-enabled  docker  
```

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

Теперь проверим связь клиента с серверной частью с помощью [`docker version`](<https://docs.docker.com/reference/cli/docker/version/>) , доступность плагина Compose и текущий контекст подключения [`docker context ls`](<https://docs.docker.com/reference/cli/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](<https://docs.docker.com/engine/install/linux-postinstall/>) и добавить свою учётную запись в системную группу `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`](<https://docs.openssl.org/3.0/man1/openssl-rand/>) . Создадим ключ на этапе запуска новой установки. При последующих обновлениях сохраним прежнее значение. Сейчас нам нужно лишь убедиться, что утилита [`openssl`](<https://docs.openssl.org/3.0/man1/openssl-version/>) установлена в 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](<https://docs.docker.com/engine/storage/>) . Рабочая папка нужна для конфигурации запуска.

Создадим каталог и перейдём в него **от имени обычного пользователя, без `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](<https://timofei-ermolaev.ru/courses/open-webui/install/docker-compose/>) . Продолжим работу в терминале Ubuntu 24.04. Если доступ к движку вы проверяли через `sudo docker`, в следующем уроке этот префикс сохраняется. Конфигурацию и файл ключа будем создавать от обычного пользователя.

Этот маршрут рассчитан на открытие браузера на том же компьютере. Для удалённого Linux-сервера понадобится отдельно настроить доступ; серверная ветка остаётся в [программе курса](<https://timofei-ermolaev.ru/courses/open-webui/#roadmap-title>) .

## Отметить прохождение

Отметьте урок, когда закончите чтение.

Урок пройден

![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_2r7Nkv.webp)

## Об авторе

### Тимофей Ермолаев

Директор по информационным технологиям (CIO)

Пишу о больших языковых моделях, автоматизации и применении ИИ в бизнесе. В статьях разделяю личный опыт, выводы исследований и практические рекомендации.

[Подробнее об авторе](<https://timofei-ermolaev.ru/ob-avtore/>)
