Если команде нужен общий локальный сервер моделей, Ollama в Docker запускается одним контейнером с примонтированным томом для весов и открытым портом API. Контейнер отделяет сервер от рабочей системы, а том сохраняет скачанные модели при обновлении образа. Схема подходит для небольшой команды на одной машине, а для кластера и строгих требований к доступности её придётся дорабатывать.
Контейнер и том
Запустите официальный образ ollama/ollama, примонтируйте том в каталог /root/.ollama и опубликуйте порт 11434. Веса моделей лягут в том, поэтому пересоздание контейнера оставит их нетронутыми.
Базовая команда выглядит так: docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama. Именованный том ollama хранит модели, ключи и служебные файлы сервера. Если том забыть, веса окажутся внутри слоя контейнера и исчезнут вместе с ним, а повторная загрузка крупных моделей займёт время и трафик.
Для команды удобнее описать то же самое в файле compose: имя контейнера, том, порт и политика перезапуска лежат в репозитории и воспроизводятся на другой машине одной командой. Если нужна видеокарта NVIDIA, на хосте ставят NVIDIA Container Toolkit и запускают контейнер с флагом --gpus=all, для AMD у образа есть отдельный тег rocm, а как проверить, что ускорение включилось, мы разбираем отдельно. Общую картину запуска локальной модели в компании описывает статья про Ollama для компании, здесь нас интересует именно контейнерная часть.
В compose-файле обычно оказываются четыре строки по делу: образ с зафиксированным тегом, список томов, порт и политика перезапуска unless-stopped. Последняя нужна, чтобы сервер поднимался сам после перезагрузки машины, и сотрудникам утром был доступен тот же адрес, что вчера. Переменные окружения, например адрес привязки сервера, тоже записывают в этот файл: так настройки видны в репозитории, а устная договорённость о том, как запускали в прошлый раз, перестаёт быть единственным источником знаний.
Модель загружают командой внутри контейнера: docker exec -it ollama ollama pull имя-модели. Название и размер выбирайте по карточке модели в библиотеке Ollama, точные требования к памяти там указаны для каждого варианта.
Где лежат веса
Веса занимают основную часть диска, и решение о месте хранения принимают заранее. Именованный том Docker живёт в каталоге служебных данных на хосте, а привязанный каталог (bind mount) лежит там, где вы его указали. Для сервера команды второй вариант чаще удобнее: путь известен, права настраиваются обычными средствами, резервные копии делает привычный скрипт.
| Вариант хранения | Плюс | Минус | Когда выбирать |
|---|---|---|---|
| Именованный том Docker | Простая команда, Docker управляет правами | Путь на диске приходится искать | Пробный запуск на одной машине |
| Каталог хоста (bind mount) | Понятный путь, лёгкое резервирование | Нужно следить за правами пользователя | Сервер команды с регулярными копиями |
| Отдельный диск или сетевое хранилище | Много места, общий доступ к весам | Скорость загрузки модели зависит от канала | Несколько серверов с общим набором моделей |
Резервная копия весов нужна реже, чем копия конфигурации: модели можно загрузить заново, а вот compose-файл, переменные и список используемых моделей восстанавливать по памяти тяжело. Храните их в репозитории, а копию тома делайте перед крупными изменениями. Так потеря тома стоит вам времени на повторную загрузку, а рабочие настройки остаются целыми.
Определите заранее, какие модели команда реально использует, и удаляйте остальные: забытые варианты разных размеров быстро занимают диск. Список установленных моделей показывает ollama list, удаляются они командой ollama rm.
Сеть и доступ
В базовой настройке Ollama отдаёт API без проверки доступа, поэтому любой, кто достучался до порта, может запускать модели и нагружать видеокарту. Команда из документации публикует порт на всех интерфейсах хоста, так что открывать его в интернет напрямую нельзя. Рабочая схема строится на трёх слоях.
- Привязка порта к закрытому интерфейсу:
127.0.0.1:11434:11434для доступа только с самой машины либо адрес внутренней сети. - Защитный шлюз перед контейнером с проверкой токена или входом через корпоративную учётную запись, если сервисы стоят на других машинах.
- Правила межсетевого экрана: порт открыт только адресам, которым нужен доступ, остальные получают отказ.
Для сотрудников удобно поставить поверх сервера готовый интерфейс вроде корпоративного чата на Open WebUI. Сервисы компании обращаются к API напрямую, подробности подключения собраны в статье про Ollama API.
Если приложение работает в соседнем контейнере, объедините их в одну сеть compose и обращайтесь к серверу по имени сервиса. Тогда порт на хост можно оставить закрытым вовсе, и поверхность атаки сокращается.
Обновление образа
Обновление сводится к загрузке нового образа и пересозданию контейнера. Данные лежат в томе, поэтому модели остаются на месте. Перед обновлением заглядывайте в заметки к выпуску на странице проекта: возможны изменения в поддерживаемых форматах и настройках.
| Шаг | Команда или действие | Что проверить |
|---|---|---|
| Загрузка образа | docker pull ollama/ollama | Образ скачался, тег нужный |
| Остановка старого контейнера | docker stop ollama и docker rm ollama | Том остался в списке docker volume ls |
| Запуск нового | Та же команда или docker compose up -d | Контейнер в статусе работающего, в логах нет ошибок |
| Проверка моделей | docker exec ollama ollama list | Все рабочие модели на месте |
Фиксируйте тег образа в compose-файле, а ссылку latest оставьте для экспериментов: так обновление происходит по вашему решению, а контейнер меняется на новую версию только после проверки на тестовой машине. Перед первым обновлением сохраните копию каталога с весами или хотя бы список используемых моделей.
Где у вас сейчас запускаются локальные модели?
Пробный вызов
После запуска проверьте цепочку целиком: контейнер, сеть, модель, ответ. Минимальная проверка занимает несколько минут и снимает основную часть вопросов.
- Убедитесь, что контейнер работает:
docker psпоказывает ollama, аdocker logs ollamaвыводит запуск сервера без ошибок. - Проверьте, что сервер отвечает: запрос на адрес
http://localhost:11434возвращает короткое сообщение о работе Ollama. - Загрузите небольшую модель командой pull и дождитесь завершения.
- Отправьте запрос к API: POST на
/api/generateс именем модели, текстом запроса и параметром stream со значением false, чтобы получить ответ одним JSON. - Повторите вызов с соседней машины или из соседнего контейнера, чтобы проверить сетевые правила, и запишите время ответа как точку отсчёта.
Отдельно проверьте поведение после перезагрузки хоста. Остановите машину, запустите заново и убедитесь, что контейнер поднялся сам, модели видны в списке, а первый запрос получает ответ. Первый вызов после старта идёт медленнее обычного, потому что модель загружается в память, а по умолчанию Ollama выгружает её после пяти минут простоя, так что та же задержка повторится утром. Лучше увидеть её самим, чем услышать от сотрудников.
Один контейнер на одной машине обслуживает небольшую команду. Для нескольких серверов, балансировки и контроля доступа по пользователям нужна отдельная архитектура. Решение о ней принимайте по замерам на реальной нагрузке, а пока оно преждевременно.
Если задача шире пробного запуска и охватывает безопасность, интеграции и поддержку, соберите требования и обсудите проект на странице про внедрение ИИ в компанию.