Оригинал: https://timofei-ermolaev.ru/courses/open-webui/drugie-sposoby/obrazy-i-vstroennaya-ollama/ # Образы, версии и вариант со встроенной Ollama Поможем выбрать образ и версию Open WebUI, понять ограничения slim и отличить встроенную Ollama от двух отдельных сервисов в Docker Compose. [![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_Z1x8STQ.webp)]() [Тимофей Ермолаев]() Директор по информационным технологиям (CIO) **Опубликовано** 17 октября 2026 г. **Обновлено** 17 октября 2026 г. **На урок** 18 мин **Тема** [Другие способы развёртывания]() ## После урока вы сможете - Различать образ приложения, контейнер и файлы модели - Выбирать подходящий вариант образа Open WebUI - Фиксировать версию и понимать ограничение тегов - Отличать встроенную Ollama от отдельных сервисов **Проверяемый результат:** Выбран подходящий образ и способ размещения 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]() и сценариях сборки репозитория описаны следующие разновидности: | Разновидность тега | Что входит в образ | Когда выбирать | | --- | --- | --- | | Стандартный (`main`, `v0.12.3`) | Open WebUI, локальный ML-стек и предварительно загруженные вспомогательные кеши для векторизации (embeddings) и речи | Универсальный вариант для работы на процессоре (CPU), когда сервер чатовых моделей подключён отдельно | | Облегчённый (`slim`, `main-slim`, `v0.12.3-slim`) | Open WebUI с урезанным списком зависимостей (`requirements-slim.txt`) без локального ML-стека | Работа через внешние API или отдельный сервер моделей, когда локальная обработка документов и речи внутри WebUI не нужна | | С поддержкой GPU (`cuda`, `cuda126`, `v0.12.3-cuda`) | Стандартный состав плюс библиотеки для ускорения внутренних задач WebUI на видеокартах NVIDIA (ориентир — CUDA 12.8 для `cuda` и CUDA 12.6 для `cuda126`) | Системы с подготовленным драйвером NVIDIA и пробросом GPU в контейнер (настройка видеокарты рассматривается отдельно) | | Со встроенной Ollama (`ollama`, `main-ollama`, `v0.12.3-ollama`) | Стандартный состав Open WebUI плюс установленная программа сервера Ollama внутри того же образа | Учебные и одиночные установки, где веб-интерфейс и сервер моделей решено держать в одном контейнере | Состав виден в [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 из репозитория]() ), которые создадут два разных контейнера в общей виртуальной сети проекта. Сравним число контейнеров, адрес подключения и управление программами: | Параметр сравнения | Совмещённый вариант (Bundled) | Два сервиса в одном Compose | | --- | --- | --- | | **Число контейнеров** | Один контейнер (внутри работают и процесс WebUI, и процесс `ollama serve`) | Два отдельных контейнера: один для Open WebUI (например, `v0.12.3`), другой для официального образа `ollama/ollama` | | **Адрес Ollama для WebUI** | `http://127.0.0.1:11434` (обращение внутри того же контейнера) | `http://ollama:11434` (обращение к соседнему контейнеру по имени сервиса в [сети Compose]() ) | | **Управление версиями и перезапуск** | При обычном управлении контейнером оба процесса перезапускаются вместе; состав обеих программ обновляется через общий образ | Независимые: можно отдельно перезапустить или обновить контейнер Ollama, не трогая WebUI, и наоборот | | **Постоянные хранилища (тома)** | Два пути монтирования в один контейнер: `/app/backend/data` и `/root/.ollama` | Два пути монтирования, разнесённые по своим контейнерам: `/app/backend/data` у WebUI и `/root/.ollama` у сервиса Ollama | Почему в этих двух схемах отличается сетевой адрес `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 ps -a` | Показывает, создан ли контейнер проекта и в каком он состоянии | Что веб-сервер внутри уже завершил инициализацию базы данных | | Готовность бэкенда WebUI | `curl --fail --silent --show-error http://127.0.0.1:3003/ready` (и открытие `http://127.0.0.1:3003` в браузере) | При успешном ответе приложение завершило стартовую процедуру и проверило доступность БД и Redis, если он используется (согласно маршруту `/ready` в [`main.py`]() ) | Что сервер Ollama работает или что в него загружена хотя бы одна модель | | Наличие программы Ollama | `docker compose exec open-webui ollama --version` | Исполняемый файл Ollama установлен внутри контейнера и откликается | Что в хранилище есть веса моделей или что хватит ресурсов для генерации ответа | | Список установленных моделей | `docker compose exec open-webui ollama list` | Показывает инвентаризацию моделей в томе `/root/.ollama` (в новой чистой установке пустой список — это норма) | Успешную генерацию ответа, даже если модели присутствуют в списке | После проверки запущенного примера проект можно остановить командой `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]() . ## Материалы урока - [Установка Open WebUI через Docker Compose timofei-ermolaev.ru]() - [Подключаем локальную модель через Ollama timofei-ermolaev.ru]() - [Официальное руководство Open WebUI docs.openwebui.com]() ## Отметить прохождение Отметьте урок после того, как получили проверяемый результат из практической части. Урок пройден ![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_2r7Nkv.webp) ## Об авторе ### Тимофей Ермолаев Директор по информационным технологиям (CIO) Пишу о больших языковых моделях, автоматизации и применении ИИ в бизнесе. В статьях разделяю личный опыт, выводы исследований и практические рекомендации. [Подробнее об авторе]()