我这次想在测试机上放一个 Open WebUI,给团队内部连 Ollama 用。镜像本身不复杂,官方主镜像是 ghcr.io/open-webui/open-webui:main,但真正排查时发现问题一般分三层:镜像拉取、容器网络、数据卷。
先把镜像层单独过掉
GHCR 拉取不稳定时,先不要急着写 compose。单独拉镜像:
bash
docker pull ghcr.1ms.run/open-webui/open-webui:main
镜像层先过,后面再看 WebUI 和 Ollama。否则 docker compose up 里所有问题都会混在一起。
最小 Compose
我先写了一个最小版本:
yaml
services:
open-webui:
image: ghcr.1ms.run/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
ports:
- "3000:8080"
environment:
OLLAMA_BASE_URL: "http://host.docker.internal:11434"
volumes:
- open-webui:/app/backend/data
volumes:
open-webui:
启动:
bash
docker compose pull
docker compose up -d
docker compose logs -f open-webui
第一个坑:容器里的 localhost 不是宿主机
Ollama 跑在宿主机时,WebUI 容器里访问 127.0.0.1:11434,访问到的是容器自己。
所以这里用:
yaml
environment:
OLLAMA_BASE_URL: "http://host.docker.internal:11434"
如果 Linux 上这个地址不可用,可以考虑:
yaml
extra_hosts:
- "host.docker.internal:host-gateway"
或者直接把 Ollama 也放进同一个 compose 网络,让 Open WebUI 访问 http://ollama:11434。
第二个坑:数据卷必须提前想好
Open WebUI 的数据路径是:
text
/app/backend/data
所以 compose 里要有:
yaml
volumes:
- open-webui:/app/backend/data
没有这个卷,重建容器后配置可能丢。自托管服务最烦的不是第一次启动,而是升级后发现数据没按预期保留。
第三个坑:端口和安全组
容器启动不代表外部能访问。
bash
docker ps
ss -lntp | grep 3000
docker logs open-webui
如果是云服务器,还要看安全组有没有放开 3000。如果走反向代理,再看 Nginx upstream 指向的是宿主机端口还是容器网络。
排查表
| 问题 | 命令 |
|--------------|-------------------------------------------------------|-------------------|
| 镜像是否能拉 | docker pull ghcr.1ms.run/open-webui/open-webui:main |
| 容器是否在跑 | `docker ps | grep open-webui` |
| 日志是否异常 | docker logs -f open-webui |
| Ollama 是否可访问 | curl http://127.0.0.1:11434/api/tags |
| 数据卷是否存在 | docker volume inspect open-webui |
结论
Open WebUI 用 Docker 部署并不难,难的是把"镜像、端口、Ollama 地址、数据卷"这几层分开排。团队内网 AI 入口要长期用,Compose 文件、数据卷和升级路径要比第一次启动更重要。