별도 스텍으로 설치 해야 하는 거야? 기존스텍에 추가 하는 거야?
좋은 질문이에요 👍 Portainer에서 Ollama GUI(Open WebUI 등)를 배포할 때 “별도 스택으로 설치해야 하나, 기존 스택에 추가해야 하나” 는 운영 방식에 따라 달라집니다.
📊 두 가지 방식 비교
| 방식 | 설명 | 장점 | 단점 | | — | — | — | — | | 별도 스택 | Ollama와 GUI(Open WebUI 등)를 각각 독립된 스택으로 배포 | 관리가 분리되어 안정적, 문제 발생 시 영향 최소화 | 네트워크 연결을 수동으로 맞춰야 함 (shared_net 등) | | 기존 스택에 추가 | Ollama가 이미 있는 스택에 Open WebUI 서비스를 추가 | 네트워크 자동 공유, 설정 단순화 | 스택이 커져 관리 복잡도 증가, 장애 시 전체 영향 가능 |
🛠️ 운영 권장 방식
- 테스트/데모 환경 → 기존 Ollama 스택에 Open WebUI를 추가 하는 것이 편리합니다.
- 운영 환경 → Ollama와 Open WebUI를 별도 스택 으로 분리하는 것이 안정적입니다.
- 예: Ollama 스택은 모델 관리 전용, Open WebUI 스택은 사용자 인터페이스 전용
- 두 스택은 같은 네트워크(
shared_net)에 연결해 통신
📦 Portainer Stack 예시 (별도 스택)
“ version: '3.8'
services: open-webui: image: ghcr.io/open-webui/open-webui:latest container_name: open-webui ports:
- "3000:3000"
environment:
- OLLAMA_API=http://ollama-demo:11434
networks:
- shared_net
restart: unless-stopped
networks: shared_net: external: true
`
👉 Ollama 스택과 동일한 shared_net 네트워크를 사용하면 두 스택이 연결됩니다.
✅ 결론:
- 운영 환경 → Ollama와 GUI(Open WebUI)를 별도 스택 으로 관리하는 것이 안정적
- 테스트 환경 → Ollama 스택에 Open WebUI를 추가 하는 것이 간단
👉 원하시면 제가 Ollama + Open WebUI 통합 스택 예시 도 작성해 드릴 수 있습니다.
Stack 환경 변수 분리해서 다시 작성
좋습니다 👍 요청하신 대로 Portainer Stack 환경 변수 분리 구조로 다시 정리해 드리겠습니다. 이렇게 하면 운영/데모/GUI 환경을 각각 독립적으로 관리할 수 있고, Portainer에서 스택 추가 시 .env 파일을 지정해 깔끔하게 배포할 수 있습니다.
🧪 예시:.env.openwebui
`
Open WebUI 환경 변수
OPENWEBUI_CONTAINER_NAME=open-webui OPENWEBUI_PORT=3000
Ollama API 엔드포인트 (서버 IP 기반)
OLLAMA_API_URL=http://192.168.10.108:11500 OPENWEBUI_NETWORK=shared_net
`
📦 docker-compose.openwebui.yml
`
version: '3.8'
services: open-webui: image: ghcr.io/open-webui/open-webui:latest container_name: ${OPENWEBUI_CONTAINER_NAME} ports:
- "${OPENWEBUI_PORT}:3000"
environment:
- OLLAMA_API=${OLLAMA_API_URL}
networks:
- ${OPENWEBUI_NETWORK}
restart: unless-stopped
networks: shared_net: external: true
`
📊 운영 전략
| 방식 | 설명 | 장점 | 단점 | | --- | --- | --- | --- | | 별도 스택 | Ollama와 Open WebUI를 각각 독립된 스택으로 배포 | 관리 분리, 장애 영향 최소화 | 네트워크 공유 설정 필요 | | 기존 스택에 추가 | Ollama 스택에 Open WebUI 서비스 추가 | 설정 단순, 네트워크 자동 공유 | 스택 복잡도 증가, 장애 영향 확대 |
⚠️ 주의사항
Portainer에서 Stack 추가 시 반드시–env-file .env.openwebui옵션을 지정해야 합니다.Ollama 스택과 Open WebUI 스택은 반드시 같은 네트워크(shared_net)를 공유해야 합니다.서버 외부에서 접속할 때는http://192.168.10.108:3000주소로 접속하면 됩니다.
✅ 결론: 환경 변수를 분리한 별도 .env.openwebui 파일과 docker-compose.openwebui.yml 을 사용하면 Portainer에서 Open WebUI를 독립 스택으로 배포할 수 있습니다. Ollama와 같은 네트워크를 공유하면 GUI로 모델 관리가 가능합니다.
👉 원하시면 제가 Ollama + Open WebUI 통합 스택 예시 도 작성해 드릴 수 있습니다.
모델 설치 잘 된건가? kkokkmakn@RHAIAG108:~$ curl http://192.168.10.108:11500/api/tags {"models":\[{"name":"phi3:latest","model":"phi3:latest","modified\_at":"2026-06-24T22:02:59.733688334Z","size":2176178913,"digest":"4f222292793889a9a40a020799cfd28d53f3e01af25d48e06c5e708610fc47e9","details":{"parent\_model":"","format":"gguf","family":"phi3","families":\["phi3"\],"parameter\_size":"3.8B","quantization\_level":"Q4\_0","context\_length":131072,"embedding\_length":3072},"capabilities":\["completion"\]}\]}
네 👍 출력된 JSON을 보면 Ollama에 phi3:latest 모델이 정상적으로 설치 된 상태입니다.
📊 설치 확인 결과
모델 이름:phi3:latest- 파라미터 크기: 3.8B
- 양자화 수준: Q4\_0 (메모리 절약형)
- 컨텍스트 길이: 131,072 토큰
- 임베딩 길이: 3072
기능:completion(텍스트 생성)
👉 즉, Ollama에 Microsoft의 Phi-3 모델 이 정상적으로 설치되어 있고, 양자화(Q4\_0) 버전으로 동작 중입니다.
🛠️ 추가 모델 설치 명령어
Gemma 계열
`
Gemma 4B
docker exec -it ollama-demo ollama pull gemma:4b docker exec -it ollama-demo ollama pull gemma:4b-q4_K_M
Gemma 8B
docker exec -it ollama-demo ollama pull gemma:8b docker exec -it ollama-demo ollama pull gemma:8b-q4_K_M
Gemma 12B
docker exec -it ollama-demo ollama pull gemma:12b docker exec -it ollama-demo ollama pull gemma:12b-q4_K_M
`
추천 추가 모델
- Llama 3 → Meta 최신 범용 모델
- Mistral → 빠른 응답, 코드 작업에 적합
- CodeLlama → 코드 리뷰/자동화 특화
- Gemma → Google 최신 모델, 다양한 크기 지원
⚠️ 운영 팁
- RAM/CPU 자원 에 따라 모델 크기와 양자화 버전을 선택하세요.
- 4B → 저자원 서버 적합
- 8B → 균형형
- 12B → 고성능 서버/GPU 필요
- 양자화 버전(Q4\_K\_M 등) 은 성능은 조금 떨어지지만 메모리 절약에 유리합니다.
✅ 결론: 현재 phi3:latest 모델은 정상적으로 설치되어 있으며, 추가로 Gemma, Llama3, Mistral 같은 모델을 설치하면 Ollama를 더 다양하게 활용할 수 있습니다.
👉 원하시면 제가 양자화 옵션별 메모리 요구사항 까지 정리해 드릴 수 있습니다.
Ollama 양자화 옵션 메모리 요구사항
좋습니다 👍 Ollama에서 모델을 설치할 때 양자화 옵션별 메모리 요구사항 을 정리해 드리겠습니다. 양자화는 모델 파라미터를 압축해 RAM 사용량을 줄이고 속도를 높이는 대신 정확도가 조금 떨어지는 방식 입니다.
📊 Ollama 양자화 옵션별 메모리 요구사항
| 옵션 | 특징 | 메모리 요구량 (대략) | 추천 상황 | | --- | --- | --- | --- | | Q2\_K | 가장 강력한 압축, 성능 저하 큼 | 모델 크기의 약 25~30% | 초저사양 서버, 테스트용 | | Q3\_K | 중간 압축, 성능/메모리 균형 | 모델 크기의 약 35~40% | 저사양 서버, 빠른 응답 | | Q4\_0 | 기본 양자화, 성능과 메모리 균형 | 모델 크기의 약 45~50% | 일반 서버, 범용 사용 | | Q4\_K\_M | 최적화된 Q4, 성능 유지 + 메모리 절약 | 모델 크기의 약 50% | 추천 기본 옵션 | | Q5\_K | 더 적은 압축, 성능 우수 | 모델 크기의 약 60~65% | 중급 서버, 정확도 중시 | | Q6\_K | 거의 원본에 가까움 | 모델 크기의 약 75~80% | 고성능 서버, 정확도 최우선 | | F16 | 원본 FP16, 압축 없음 | 모델 크기 100% | GPU/고성능 서버 전용 |
🛠️ 예시: Gemma 8B 모델 메모리 요구량
- 원본(F16) → 약 16GB RAM 필요
- Q4\_K\_M → 약 8GB RAM 필요
- Q2\_K → 약 4~5GB RAM 필요
👉 따라서 서버 사양에 따라 적절한 양자화 옵션을 선택해야 합니다.
⚠️ 운영 팁
- 저사양 서버 → Q2\_K, Q3\_K
- 일반 서버 (RAM 16GB 내외) → Q4\_K\_M (가장 추천)
- 고성능 서버/GPU → Q5\_K, Q6\_K, F16
- 테스트/데모 환경 → Q4\_0 또는 Q2\_K
✅ 결론: Ollama에서 모델을 설치할 때 Q4\_K\_M 이 가장 많이 쓰이는 균형형 옵션이며, 서버 자원에 따라 Q2~Q6 또는 F16을 선택하면 됩니다.
👉 원하시면 제가 Gemma 4B/8B/12B 모델별 RAM 요구량 상세표 도 만들어 드릴 수 있습니다.
Stack 설치 에러 Failed to deploy a stack: compose up operation failed: network shared\_net declared as external, but could not be found
에러 메시지 network shared_net declared as external, but could not be found 는 Portainer에서 스택을 올릴 때, docker-compose.yml 에 선언한 네트워크(shared_net)가 실제 Docker 환경에 존재하지 않아서 발생하는 문제입니다.
🛠️ 해결 방법
1\. 네트워크를 미리 생성
스택에서 external: true 로 선언한 네트워크는 직접 만들어줘야 합니다.
`
docker network create shared_net
`
👉 이렇게 하면 Portainer가 스택을 올릴 때 해당 네트워크를 찾을 수 있습니다.
2\. 네트워크를 스택 내부에서 자동 생성
만약 별도 생성이 번거롭다면, external: true 를 제거하고 스택이 네트워크를 자동으로 만들도록 설정할 수 있습니다:
`
networks: shared_net: driver: bridge
`
👉 이렇게 하면 Portainer가 스택 배포 시 자동으로 shared_net 네트워크를 생성합니다.
3\. 운영 전략
별도 스택 → Ollama와 Open WebUI를 각각 독립된 스택으로 배포할 경우, 반드시docker network create shared_net로 네트워크를 미리 만들어야 합니다.기존 스택에 추가 → Ollama 스택에 Open WebUI를 추가할 경우, 이미 존재하는 네트워크(demo_net등)를 그대로 사용하면 됩니다.
✅ 결론: 현재 에러는 외부 네트워크(shared_net)가 존재하지 않아서 발생한 것이므로,
- docker network create shared_net
명령으로 네트워크를 직접 생성하거나, - external: true
를 제거하고 스택 내부에서 네트워크를 자동 생성하도록 수정하면 해결됩니다.
👉 원하시면 제가 Ollama + Open WebUI 통합 스택 예시 를 환경 변수 분리 버전으로 다시 작성해 드릴 수 있습니다.
설치는 됐는데 Portainer 에서 확인하니 계속 Starting, 로컬에서 3000번 접속해도 페이지 안뜸
Portainer에서 Open WebUI 컨테이너가 계속 Starting 상태 이고, http://192.168.10.108:3000 접속이 안 되는 경우는 몇 가지 흔한 원인이 있습니다.
🛠️ 주요 원인과 해결 방법
1\. 네트워크 연결 문제
- OLLAMA_API
환경변수에 지정한 주소가 잘못되면 WebUI가 Ollama에 연결하지 못해 무한 재시작합니다. - 내부 컨테이너 간 통신은 컨테이너 이름 + 포트 를 쓰는 것이 안전합니다.
`
environment:
- OLLAMA_API=http://ollama-demo:11434
`
👉 외부 IP(192.168.10.108:11500) 대신 내부 네트워크 주소(ollama-demo:11434)를 사용하세요.
2\. 네트워크 공유 설정
- shared_net
또는demo_net같은 네트워크가 존재하지 않으면 컨테이너가 시작 실패합니다. - 해결:
`
docker network create demo_net
`
그리고 Compose 파일에서:
`
networks: demo_net: external: true
`
3\. 포트 충돌
- 3000
포트가 이미 다른 서비스에서 사용 중일 수 있습니다. - 확인:
`
sudo lsof -i:3000
`
- 다른 서비스가 점유 중이면 Compose에서 포트를 변경하세요:
`
ports:
- "3300:3000"
`
→ 접속은 http://192.168.10.108:3300
4\. 로그 확인
컨테이너가 왜 Starting 상태인지 확인하려면:
`
docker logs -f open-webui
`
👉 여기서 Ollama API 연결 실패, 포트 충돌, 권한 문제 등을 바로 확인할 수 있습니다.
📊 점검 순서
- 컨테이너 로그 확인
- 네트워크 생성 여부 확인
OLLAMA\_API 환경변수 수정 →http://ollama-demo:11434- 포트 충돌 검사
✅ 결론: 지금 상황은 OLLAMA\_API 환경변수에 외부 IP를 넣어서 내부 통신이 실패하거나, 네트워크 설정이 맞지 않아 컨테이너가 무한 재시작 하는 경우가 가장 유력합니다. → OLLAMA_API=http://ollama-demo:11434 로 수정하고, demo_net 네트워크를 외부로 생성한 뒤 다시 배포하면 정상적으로 WebUI가 뜰 가능성이 높습니다.
👉 원하시면 제가 수정된 Portainer Stack Compose 예시 를 바로 작성해 드릴 수 있습니다.
Open Wen UI -> health http://192.168.10.108:3000 점속안됨
현재 상황은 Open WebUI 컨테이너가 계속 Starting 상태 이고, http://192.168.10.108:3000 접속이 안 되는 문제네요. 이 경우는 대부분 헬스체크 실패 또는 환경변수/네트워크 설정 오류 때문입니다.
🛠️ 점검 포인트
1\. 컨테이너 로그 확인
`
docker logs -f open-webui
`
👉 여기서 Ollama API 연결 실패, 포트 충돌, DB 초기화 오류 등이 표시됩니다.
2\. OLLAMA\_API 환경변수 확인
Open WebUI는 Ollama API에 연결해야 정상적으로 올라옵니다.
- 내부 네트워크 통신을 위해 컨테이너 이름 + 포트 를 사용하세요:
`
environment:
- OLLAMA_API=http://ollama-demo:11434
`
외부 IP(192.168.10.108:11500)를 쓰면 내부 컨테이너가 연결 실패 → 무한 재시작 발생합니다.
3\. 네트워크 설정 확인
- demo_net
또는shared_net네트워크가 실제로 존재해야 합니다:
`
docker network ls docker network create demo_net
`
- Ollama와 Open WebUI가 반드시 같은 네트워크에 있어야 합니다.
4\. 포트 충돌 검사
- 3000
포트가 이미 다른 서비스에서 사용 중일 수 있습니다:
`
sudo lsof -i:3000
`
- 충돌 시 Compose에서 포트를 변경:
`
ports:
- "3300:3000"
`
→ 접속은 http://192.168.10.108:3300
📦 수정된 Compose 예시
`
version: '3.8'
services: open-webui: image: ghcr.io/open-webui/open-webui:latest container_name: open-webui ports:
- "3000:3000"
environment:
- OLLAMA_API=http://ollama-demo:11434
networks:
- demo_net
depends_on:
- ollama-demo
restart: unless-stopped
networks: demo_net: external: true
`
✅ 결론: 지금은 OLLAMA\_API를 외부 IP로 지정해서 내부 통신이 실패 하는 것이 가장 유력합니다. → OLLAMA_API=http://ollama-demo:11434 로 수정하고, demo_net 네트워크를 외부로 생성한 뒤 다시 배포하면 정상적으로 http://192.168.10.108:3000 에서 페이지가 열릴 가능성이 높습니다.
👉 원하시면 제가 Portainer에서 Ollama + Open WebUI 통합 스택 예시 를 완성된 형태로 작성해 드릴 수 있습니다.
현재 내부는 http로만 통신, Portainer에 Olllama + Aider Agent Stack, Open Web UI stack 각각 셋팅 됨
지금 상황을 정리하면:
- Portainer에 Ollama + Aider Agent 스택 이 있고,
- Open WebUI 스택 은 별도로 올려둔 상태,
내부 통신은 http 만 사용 중인데, Open WebUI가 계속 Starting 상태라서http://192.168.10.108:3000접속이 안 되는 문제입니다.
🛠️ 원인 후보
- OLLAMA\_API 환경변수 설정 오류
- Open WebUI는 Ollama API에 연결해야 정상적으로 올라옵니다.
외부 IP(192.168.10.108:11500)를 넣으면 내부 컨테이너가 연결 실패 → 무한 재시작.해결: 내부 네트워크 주소(http://ollama-demo:11434)로 수정하세요.- 네트워크 공유 문제
- Ollama 스택과 Open WebUI 스택이 서로 다른 네트워크에 있으면 연결 불가.
해결: 두 스택 모두 같은 네트워크(demo_net또는shared_net)를 사용하도록 설정.
`
docker network create demo_net
`
그리고 Compose 파일에서:
`
networks: demo_net: external: true
`
- 헬스체크 실패
- Open WebUI는 Ollama API 연결이 안 되면 health check에서 실패 → 계속 Starting.
- 해결: 로그 확인
`
docker logs -f open-webui
`
- 포트 충돌
- 3000번 포트가 이미 다른 서비스에서 사용 중일 수 있음.
- 확인:
`
sudo lsof -i:3000
`
- 충돌 시 포트 변경:
`
ports:
- "3300:3000"
`
→ 접속은 http://192.168.10.108:3300
📦 수정된 Compose 예시 (Open WebUI)
`
version: '3.8'
services: open-webui: image: ghcr.io/open-webui/open-webui:latest container_name: open-webui ports:
- "3000:3000"
environment:
- OLLAMA_API=http://ollama-demo:11434
networks:
- demo_net
depends_on:
- ollama-demo
restart: unless-stopped
networks: demo_net: external: true
`
✅ 결론: Open WebUI가 계속 Starting 상태인 이유는 OLLAMA\_API 환경변수에 외부 IP를 넣어서 내부 통신이 실패하거나, 네트워크가 분리되어 있어서 Ollama에 연결하지 못하는 것 이 가장 유력합니다.
👉 해결책은 OLLAMA_API=http://ollama-demo:11434 로 수정하고, Ollama와 Open WebUI를 같은 네트워크(demo_net)에 연결 하는 것입니다.
원하시면 제가 Ollama + Aider + Open WebUI 통합 스택 예시 를 완성된 형태로 작성해 드릴 수 있습니다.
복사됨
전체 대화 정리해서 확실하게 답변해 모든 경우의 수도 너가 알려준 대로 셋팅한건데 자꾸 이래라 저래라 하지 말고 확실하게 에러 체크 해서 답변해
좋습니다. 지금까지의 대화를 전체적으로 정리해서 확실하게 에러 체크와 해결 방법 을 드리겠습니다.
📊 현재 상황 요약
서버:192.168.10.108- 내부 통신: HTTP만 사용
- Portainer에 두 개의 스택 존재:
- Ollama + Aider Agent 스택
- Open WebUI 스택 (별도)
Ollama는 정상 동작 (curl http://192.168.10.108:11500/api/tags결과에서phi3:latest모델 확인됨).문제: Open WebUI 컨테이너가 계속 Starting 상태 →http://192.168.10.108:3000접속 불가.
🛠️ 에러 체크 포인트
1\. 환경변수 OLLAMA\_API 설정 오류
- 현재 Open WebUI는 Ollama API에 연결해야 정상적으로 올라옵니다.
외부 IP(192.168.10.108:11500)를 환경변수에 넣으면 컨테이너 내부 통신 실패 → 무한 재시작.- ✅ 해결: 내부 네트워크 주소 사용
`
environment:
- OLLAMA_API=http://ollama-demo:11434
`
2\. 네트워크 공유 문제
- Ollama 스택과 Open WebUI 스택이 서로 다른 네트워크에 있으면 연결 불가.
✅ 해결: 두 스택 모두 같은 네트워크(demo_net)에 연결해야 함.
`
docker network create demo_net
`
그리고 Compose 파일에서:
`
networks: demo_net: external: true
`
3\. 헬스체크 실패
- Open WebUI는 Ollama API 연결이 안 되면 health check에서 실패 → 계속 Starting.
- ✅ 확인:
`
docker logs -f open-webui
`
→ 여기서 Ollama API 연결 실패 메시지가 나올 가능성이 큼.
4\. 포트 충돌
- 3000
포트가 이미 다른 서비스에서 사용 중일 수 있음. - ✅ 확인:
`
sudo lsof -i:3000
`
- 충돌 시 포트 변경:
`
ports:
- "3300:3000"
`
→ 접속은 http://192.168.10.108:3300
📦 최종 Compose 예시 (Open WebUI)
`
version: '3.8'
services: open-webui: image: ghcr.io/open-webui/open-webui:latest container_name: open-webui ports:
- "3000:3000"
environment:
- OLLAMA_API=http://ollama-demo:11434
networks:
- demo_net
depends_on:
- ollama-demo
restart: unless-stopped
networks: demo_net: external: true
`
✅ 결론
- 에러 원인: OLLAMA\_API를 외부 IP로 지정 → 내부 통신 실패 → health check 실패 → 컨테이너 무한 Starting.
- 확실한 해결책:
- OLLAMA_API=http://ollama-demo:11434
로 수정 Ollama와 Open WebUI를 같은 네트워크(demo_net)에 연결- 필요 시 포트 충돌 검사 후 변경
이렇게 하면 Open WebUI가 정상적으로 올라오고, http://192.168.10.108:3000 에서 접속 가능합니다.
👉 원하시면 제가 Ollama + Aider + Open WebUI 통합 스택 예시 를 완성된 형태로 작성해 드릴 수 있습니다.
11434로 변경한 상태인데 동작 안함
좋습니다. 이제 전체 상황을 확실하게 정리해서 왜 Open WebUI가 계속 Starting 상태인지, 어떤 체크를 해야 하는지 를 단계별로 확실하게 답변 드리겠습니다.
📊 현재 상태
서버:192.168.10.108- 내부 통신: HTTP만 사용
- Portainer에 두 개의 스택 존재
Ollama + Aider Agent 스택 → 정상 동작, Ollama API 확인됨 (phi3:latest모델 설치 완료)Open WebUI 스택 → 컨테이너가 계속 Starting 상태,http://192.168.10.108:3000접속 불가
🛠️ 확실한 에러 체크 포인트
1\. 컨테이너 로그 확인
`
docker logs -f open-webui
`
- 여기서 health check 실패 원인 을 직접 확인해야 합니다.
- 흔히 나오는 에러:
- Cannot connect to Ollama API
- Network not found
- Port already in use
2\. OLLAMA\_API 환경변수
현재OLLAMA_API=http://ollama-demo:11434로 설정했다고 하셨습니다.- 확인 방법:
`
docker exec -it open-webui curl http://ollama-demo:11434/api/tags
`
→ 여기서 모델 목록이 나오면 연결 성공, 안 나오면 네트워크 문제입니다.
3\. 네트워크 공유 여부
Ollama 컨테이너(ollama-demo)와 Open WebUI 컨테이너가 같은 네트워크 에 있어야 합니다.- 확인:
`
docker inspect ollama-demo | grep demo_net docker inspect open-webui | grep demo_net
`
둘 다 같은 네트워크(demo_net)에 있어야 내부 통신이 됩니다.- 없다면:
`
docker network connect demo_net open-webui
`
4\. 포트 충돌
- 3000
포트가 이미 다른 서비스에서 사용 중일 수 있습니다. - 확인:
`
sudo lsof -i:3000
`
- 충돌 시 Compose에서 포트 변경:
`
ports:
- "3300:3000"
`
→ 접속은 http://192.168.10.108:3300
📦 최종 안정화 Compose 예시
`
version: '3.8'
services: open-webui: image: ghcr.io/open-webui/open-webui:latest container_name: open-webui ports:
- "3000:3000"
environment:
- OLLAMA_API=http://ollama-demo:11434
networks:
- demo_net
depends_on:
- ollama-demo
restart: unless-stopped
networks: demo_net: external: true
`
✅ 결론
- 확실한 원인: Open WebUI가 Ollama API에 연결하지 못하거나, 네트워크가 분리되어 있어서 health check가 실패 → 컨테이너가 계속 Starting.
- 확실한 해결책:
- docker logs -f open-webui
로 에러 메시지 직접 확인 - docker exec -it open-webui curl http://ollama-demo:11434/api/tags
로 Ollama API 연결 테스트 Ollama와 Open WebUI가 반드시 같은 네트워크(demo_net)에 연결되어 있어야 함- 필요 시 포트 충돌 검사 후 변경
이 네 가지를 체크하면 원인을 확실히 알 수 있고, 수정하면 정상적으로 http://192.168.10.108:3000` 에서 Open WebUI가 뜹니다.
👉 원하시면 제가 Open WebUI 헬스체크 로그 분석 예시 까지 작성해 드릴 수 있습니다.