Образы, версии и вариант со встроенной Ollama

В уроке про установку через Docker Compose мы запускали проект со строкой image: ghcr.io/open-webui/open-webui:main. Тогда мы разбирали запуск контейнера и сохранение данных. Теперь выберем конфигурацию для новой установки: определим состав образа и выпуск Open WebUI, затем решим, где разместить сервер моделей Ollama.

Рабочие экземпляры Docker или Python оставим с прежними настройками. В этом уроке нужно научиться выбирать образ, фиксировать выпуск и объяснять, сколько будет контейнеров, как WebUI подключится к Ollama и где сохранятся их данные. Сохранять учебный файл на диск и запускать его необязательно.

Что задаёт строка image

Разберём знакомую запись ghcr.io/open-webui/open-webui:main как адрес образа. Менять её в рабочем файле сейчас не нужно.

В нашем примере двоеточие отделяет тег от адреса репозитория:

• До двоеточия указаны реестр (ghcr.io, GitHub Container Registry) и репозиторий проекта (open-webui/open-webui). Они говорят Docker, откуда забирать пакет.
• После двоеточия идёт тег (например, main или v0.12.3-ollama). Он уточняет, какой именно выпуск и какую разновидность сборки мы выбираем.

Адрес образа ещё не говорит, что уже запущено и есть ли модель для чата. Разделим три понятия:

1. Образ (image) — неизменяемый шаблон с файлами самого приложения Open WebUI и его системными зависимостями.
2. Контейнер (container) — изолированный процесс (или несколько процессов), который Docker запускает на основе выбранного образа. Постоянные пользовательские данные живут в подключённых томах, а не внутри самого образа.
3. Языковая модель (LLM) — отдельные файлы весов и настроек, которые использует сервер моделей (например, Ollama) для генерации ответов в чате.

Зная адрес образа, можно перейти к его составу и выпуску, на который указывает тег.

Выберем разновидность образа и выпуск

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

Состав образа: стандартный, slim, CUDA и ollama

В руководстве быстрого старта Open WebUI и сценариях сборки репозитория описаны следующие разновидности:

Состав виден в Dockerfile выпуска v0.12.3. Стандартный образ включает локальные библиотеки машинного обучения и вспомогательные модели для поиска по документам и работы с голосом, но не содержит готовой чатовой языковой модели.

В выпуске 0.12.3 вариант slim исключает локальный ML-стек, а не откладывает загрузку тяжёлых библиотек до первого обращения. Базовый чат через внешний API или отдельно стоящий сервер моделей в slim работает штатно, но для векторизации текста (embeddings), распознавания речи и части обработчиков документов ему понадобятся внешние сервисы. Кроме того, slim не комбинируется с суффиксами cuda или ollama.

Выбор slim не гарантирует автономную работу или отсутствие сетевых загрузок. Внешним провайдерам моделей нужно соединение, а браузерный интерпретатор кода при вызове подгружает пакеты с публичных CDN.

Фиксация выпуска: плавающие теги, версии и digest

Когда состав выбран, нужно определить версию. Теги вроде main, main-slim или ollama называют плавающими (rolling tags). По мере выхода новых сборок они указывают на разное содержимое. Тег latest в этом проекте тоже следует за веткой main, а не указывает специально на последний стабильный релиз.

Чтобы конфигурация оставалась предсказуемой, вместо плавающего имени указывают номер выпуска и, через дефис, нужную разновидность. По данным API релизов GitHub на 17 октября 2026 года актуальный выпуск Open WebUI имеет номер v0.12.3 и опубликован 16 октября 2026 года. Добавив к нему суффикс разновидности, мы получаем в реестре ghcr.io точные теги v0.12.3, v0.12.3-slim, v0.12.3-cuda и v0.12.3-ollama (в приведённых ссылках сохраняем начальную букву v). Список проверен на дату подготовки материала; позднее появятся новые выпуски.

Документация проекта описывает теги версий как неизменяемые, но технически любой текстовый тег в реестре можно переназначить. Для строгой фиксации содержимого Docker использует контрольную сумму (digest). Например, для выбранного образа проверена ссылка ghcr.io/open-webui/open-webui@sha256:5cfb154608cda2aab1f34db4be65fb0b0f3c82f5faaec91f7d12b114b2b7b486.

У мультиплатформенных сборок Open WebUI этот общий индексный digest фиксирует набор вариантов для linux/amd64 и linux/arm64. Docker выбирает вариант под архитектуру машины; байты его слоёв отличаются от варианта для другой архитектуры. У каждого платформенного манифеста есть отдельный digest. Для учебной конфигурации достаточно явного тега версии v0.12.3-ollama.

Для примера выберем образ ghcr.io/open-webui/open-webui:v0.12.3-ollama. Посмотрим, что именно добавляет суффикс ollama и достаточно ли одного скачивания образа, чтобы модель начала отвечать в чате.

Что входит в образ со встроенной Ollama

Суффикс -ollama означает, что в образ добавлена программа сервера моделей. Её установку и запуск описывают файлы сборки (Dockerfile и стартовый скрипт start.sh выпуска v0.12.3):

1. На этапе сборки образа внутри него выполняется скрипт установки программы Ollama.
2. При запуске контейнера стартовый скрипт сначала поднимает фоновый сервер командой ollama serve, а затем в том же контейнере запускает бэкенд самого Open WebUI.
3. Ни во время сборки образа, ни в момент первого запуска контейнера веса чатовой языковой модели автоматически не скачиваются.

Это значит, что в свежем образе и при подключении нового пустого тома список языковых моделей будет пустым. Сама программа-сервер уже ждёт команд, но конкретную модель для чата нужно будет загрузить отдельно (или подключить том, в котором модели уже сохранялись ранее). Как выбирать и загружать подходящие веса, мы разберём в уроке про подключение и настройку Ollama.

Номера версий этих программ тоже различаются. Тег v0.12.3-ollama фиксирует выпуск самого интерфейса Open WebUI (0.12.3), но номер версии встроенной программы Ollama с ним не совпадает и определяется тем, какой пакет установился при сборке образа.

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

Один контейнер или два сервиса Compose

Один и тот же файл compose.yaml позволяет организовать работу двумя способами: запустить совмещённый (bundled) образ в одном контейнере или описать два отдельных сервиса (например, на базе штатного docker-compose.yaml из репозитория), которые создадут два разных контейнера в общей виртуальной сети проекта.

Сравним число контейнеров, адрес подключения и управление программами:

Почему в этих двух схемах отличается сетевой адрес OLLAMA_BASE_URL? Адрес localhost (или 127.0.0.1) всегда указывает на ту сетевую среду, в которой работает вызывающая программа:

• Когда вы вводите http://127.0.0.1:3003 в браузере, браузер обращается к вашему собственному компьютеру (хосту).
• По адресу http://127.0.0.1:11434 процесс Open WebUI обращается внутрь своего контейнера. В совмещённом образе v0.12.3-ollama это срабатывает, потому что ollama serve запущен прямо там.
• Если же разнести программы по двум контейнерам, внутри контейнера WebUI на порту 11434 никого не будет. Для связи через внутренний DNS Docker Compose используют имя второго сервиса: http://ollama:11434.

При этом ни одна из двух схем не даёт автоматического прироста скорости генерации текста и не избавляет от необходимости хранить данные в двух разных местах: в рассматриваемых Docker-конфигурациях настройки и чаты WebUI хранятся в /app/backend/data, а файлы и модели самой Ollama (согласно документации Ollama по Docker) — в /root/.ollama.

Дальше разберём один учебный файл для совмещённой схемы с образом v0.12.3-ollama.

Разберём отдельный учебный compose.yaml

Посмотрим, как записать выбранный образ v0.12.3-ollama, адрес подключения и два хранилища в чистую конфигурацию.

Для примера нужны новое имя проекта и отдельные тома. Замена версии образа поверх существующей базы данных может запустить миграцию схемы, а возврат старого тега не откатит её назад. Об этом предупреждает руководство по обновлению Open WebUI. Кроме того, в уже работающей базе могут быть сохранены прежние настройки подключения администратора, которые переопределяют переменные окружения из файла. Новые тома отделяют данные примера от прежней установки.

Пример рассчитан на локальный Bash в Ubuntu 24.04 с уже подготовленными Docker Engine, плагином Compose и OpenSSL из прошлого урока. Сохраните прежний способ вызова Docker: docker или sudo docker.

Если захотите сохранить пример на диск для проверки, выделите для него новую отдельную папку ~/owui-images-lesson-0403. Если такой каталог, одноимённый проект owui-images-lesson-0403 или локальный порт 3003 у вас уже чем-то заняты, ничего поверх них не перезаписывайте.

В новом каталоге перед проверкой файла конфигурации нужно подготовить отдельный файл lesson.env с секретным ключом. Используем приём генерации из основного урока по Compose, изменив только имя файла. Старый ключ из другого проекта не копируем и на экран не выводим:

if [ ! -e lesson.env ]; then
  (
    umask 077
    webui_key=$(openssl rand -hex 32) &&
    printf 'WEBUI_SECRET_KEY=%s\n' "$webui_key" > lesson.env
  )
fi

В той же папке сохраним учебный файл compose.yaml:

name: owui-images-lesson-0403

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.12.3-ollama
    ports:
      - "127.0.0.1:3003:8080"
    environment:
      OLLAMA_BASE_URL: http://127.0.0.1:11434
    env_file:
      - ./lesson.env
    volumes:
      - webui-data:/app/backend/data
      - ollama-data:/root/.ollama
    restart: unless-stopped

volumes:
  webui-data:
  ollama-data:

Разберём назначение каждого элемента этой конфигурации:

• name: owui-images-lesson-0403 задаёт собственное пространство имён проекта, чтобы Docker Compose не смешивал его контейнеры и тома с вашей основной установкой.
• image: ghcr.io/open-webui/open-webui:v0.12.3-ollama выбирает проверенный выпуск v0.12.3 в варианте со встроенным сервером Ollama.
• ports: - "127.0.0.1:3003:8080" публикует веб-интерфейс на свободном локальном порту 3003 (вместо 3000), чтобы избежать пересечения с другими учебными сервисами. Порт самой Ollama (11434) наружу публиковать не требуется: обмен между WebUI и Ollama идёт внутри контейнера.
• environment: OLLAMA_BASE_URL: http://127.0.0.1:11434 явно указывает бэкенду Open WebUI (по логике config.py), что сервер моделей отвечает на внутреннем адресе того же контейнера. В новой базе эта переменная применится сразу, поскольку прежних сохранённых настроек в ней нет.
• env_file: - ./lesson.env подключает новый секретный ключ этого проекта.
• Две записи в volumes разделяют хранение постоянных данных. Поскольку Compose приставляет к именам томов префикс проекта, для /app/backend/data (база и чаты WebUI) будет использован том owui-images-lesson-0403_webui-data, а для /root/.ollama (ключи и будущие загруженные веса моделей Ollama) — отдельный том owui-images-lesson-0403_ollama-data. Оба тома переживают остановку и пересоздание контейнера.

Конфигурация выбрана. Теперь разберём проверки файла и работающего контейнера на случай, если вы решите его запустить.

Проверим выбор и границы результата

При подготовке материала контейнер не запускался. Ниже описано, что проверяет каждая команда; проверку файла и готовность работающих программ нужно различать.

Проверка конфигурации без запуска контейнеров

Если вы создали отдельную папку проекта, сохранили в ней compose.yaml и сгенерировали lesson.env, правильность синтаксиса и выбранный образ проверяются двумя командами docker compose config:

docker compose config --quiet
docker compose config --images

• Первая команда (--quiet) проверяет структуру YAML и наличие файла ./lesson.env, не выводя в терминал секретный ключ. Если в отступах или путях есть ошибка, нужно остановиться и исправить файл до любых попыток старта.
• Вторая команда (--images) выводит только итоговую ссылку на образ (ghcr.io/open-webui/open-webui:v0.12.3-ollama), подтверждая, что Compose прочитал ваш выбор.

Эти две команды работают исключительно с текстом конфигурации. Они не скачивают образ, не запускают контейнер и не проверяют наличие свободной памяти, видеокарты или языковых моделей.

Ни изменение строки image в compose.yaml, ни выполнение docker compose pull сами по себе не меняют уже работающий контейнер. Compose создаёт или пересоздаёт контейнер с новой конфигурацией при вызове docker compose up -d.

Проверки после необязательного запуска

Если вы решите самостоятельно запустить этот новый изолированный проект (убедившись, что папка, имя проекта и порт 3003 свободны, и следуя правилам доступа к Docker из прошлого урока по Compose), после docker compose pull и docker compose up -d состояние системы проверяется по слоям:

После проверки запущенного примера проект можно остановить командой docker compose stop: она освободит ресурсы, сохранив и контейнер, и оба новых тома (owui-images-lesson-0403_webui-data и owui-images-lesson-0403_ollama-data).

Проверим себя

Объясните пять настроек выбранной конфигурации:

1. Образ и выпуск: выбран тег ghcr.io/open-webui/open-webui:v0.12.3-ollama, который фиксирует релиз WebUI 0.12.3 со стандартным локальным ML-стеком и встроенной программой сервера Ollama (в отличие от плавающего :main и урезанного :v0.12.3-slim).
2. Число контейнеров: один контейнер, внутри которого работают сразу оба процесса (ollama serve и Open WebUI).
3. Адрес подключения: WebUI обращается к серверу моделей внутри того же контейнера по адресу http://127.0.0.1:11434 (тогда как в схеме из двух сервисов использовалось бы имя сервиса http://ollama:11434).
4. Два постоянных хранилища: данные самого интерфейса и пользователей монтируются в /app/backend/data, а каталог моделей Ollama — отдельно в /root/.ollama.
5. Граница готовности: сам образ приносит программу сервера, но не веса чатовой модели.

О том, как загрузить первую языковую модель и проверить связь с сервером в интерфейсе, читайте в уроке про подключение Ollama к Open WebUI.