Docker
Docker jest najłatwiejszym sposobem wdrożenia w stylu produkcyjnym na jednym serwerze.
Dla instalacji na jednym serwerze dostępnej z internetu zacznij od Prywatnego wdrożenia zdalnego. Jego szablon Compose nie publikuje portów aplikacji, domyślnie używa obrazu main i dodaje zewnętrzną granicę Cloudflare Access, kontrolę hosta, kopie zapasowe oraz limity kontenerów.
Dostępność Work
Work jest domyślnie włączony w plikach Compose repozytorium. Obraz zawiera Docker CLI, a Compose montuje /var/run/docker.sock, więc kontenery zadań Work są równorzędne z kontenerem Libre WebUI. Są widoczne w docker ps na hoście.
Proces z dostępem do tego gniazda ma kontrolę nad hostem Docker równoważną uprawnieniom roota. Domyślne włączenie Work jest świadomą decyzją: Work to funkcja podstawowa i nie może działać bez dostępu do demona. W konsekwencji każdy administrator Libre WebUI jest w praktyce administratorem hosta. Uwzględnij to:
- Utrzymuj stos na hoście, którego administratorom już ufasz.
- Nie wystawiaj opublikowanego portu w niezaufanej sieci.
- Usuń montowanie
/var/run/docker.sock, gdy Work nie jest potrzebny. Strona Work zgłosi wtedy Runtime unavailable.
W systemie Linux gniazdo należy do grupy docker, a nie do roota, dlatego użytkownik aplikacji bez uprawnień roota potrzebuje identyfikatora tej grupy. Ustaw go raz:
echo "DOCKER_GID=$(docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
alpine stat -c '%g' /var/run/docker.sock)" >> .env
Odczytaj wartość przez kontener, jak pokazano wyżej. Host macOS zgłasza inną wartość niż widzi kontener, ponieważ Docker Desktop przekazuje gniazdo przez maszynę wirtualną. Jeśli grupa jest błędna, strona Work nazwie problem zamiast zawieść bez komunikatu. Zobacz Work: izolowane obszary robocze.
Podglądy Work i Work Computer publikują losowe porty wyłącznie na prywatnym interfejsie hosta. Docker Desktop działa z domyślnymi ustawieniami Compose: pętla zwrotna hosta dla bindowania i host.docker.internal dla połączenia zaplecza. Natywny Docker Engine nie dosięgnie nasłuchu na pętli zwrotnej hosta z kontenera siostrzanego. Ustaw wtedy bindowanie na niepubliczną bramę mostka Docker:
echo "WORK_PREVIEW_BIND=$(docker network inspect bridge \
--format '{{(index .IPAM.Config 0).Gateway}}')" >> .env
echo "WORK_DOCKER_PUBLISHED_HOST=host.docker.internal" >> .env
docker compose up -d --force-recreate libre-webui
Pliki Compose mapują host.docker.internal przez host-gateway. Nigdy nie używaj WORK_PREVIEW_BIND=0.0.0.0; wystawiłoby to nieuwierzytelnione, tymczasowe porty zadań na każdym interfejsie hosta zamiast trzymać je za podpisanym proxy Libre WebUI.
Dołączona Ollama
Uruchamia Libre WebUI i Ollama w jednym stosie Compose:
docker compose up -d
Otwórz http://localhost:8080.
Port WebUI domyślnie wiąże się z interfejsem loopback hosta. Ustaw WEBUI_BIND_ADDRESS=0.0.0.0 wyłącznie wtedy, gdy dostęp jest potrzebny z zaufanej sieci LAN lub przez reverse proxy hosta, i ogranicz port zaporą hosta.
Ollama pozostaje prywatna w sieci Compose. Aby udostępnić ją aplikacjom hosta przez loopback, dodaj jawne nadpisanie hosta:
docker compose -f docker-compose.yml -f docker-compose.ollama-host.yml up -d
Ustaw OLLAMA_BIND_ADDRESS tylko wtedy, gdy inny komputer musi łączyć się z Ollama, i zabezpiecz port zaporą oraz proxy obsługującym uwierzytelnianie.
GPU NVIDIA
Użyj pliku Compose GPU, gdy Docker ma dostęp do środowiska NVIDIA:
docker compose -f docker-compose.gpu.yml up -d
Jeśli modele nadal działają na CPU, potwierdź dostęp do GPU z kontenera Ollama.
Zewnętrzna Ollama
Użyj tej opcji, gdy Ollama działa już na hoście lub innym serwerze:
docker compose -f docker-compose.external-ollama.yml up -d
W razie potrzeby nadpisz adres Ollama:
OLLAMA_BASE_URL=http://192.168.1.10:11434 docker compose -f docker-compose.external-ollama.yml up -d
Work z izolowanym gniazdem
Standardowe pliki Compose montują gniazdo Docker w kontenerze Libre WebUI, aby Work mógł uruchamiać kontenery zadań; takie montowanie daje kontrolę nad hostem Docker równoważną uprawnieniom roota. Aby zachować Work bez udostępniania gniazda aplikacji internetowej, użyj wariantu z proxy gniazda:
docker compose -f docker-compose.socket-proxy.yml up -d
Proxy gniazda w sieci wewnętrznej utrzymuje /var/run/docker.sock i przekazuje tylko sekcje API używane przez Work (kontenery, obrazy, woluminy, sieci, exec, info). Punkty końcowe Swarm, secrets, configs, build i system są blokowane. Libre WebUI łączy się przez DOCKER_HOST=tcp://docker-socket-proxy:2375 — bez montowania gniazda i bez DOCKER_GID, a interaktywny terminal i diagnostyka systemowa działają bez zmian. Dokumentacja obszarów roboczych wyjaśnia, co ta granica obejmuje, a czego nie.
Trwałość danych
Libre WebUI przechowuje dane backendu w /app/backend/data wewnątrz kontenera. Pliki Compose montują tę ścieżkę jako nazwany wolumin.
Obraz używa tej ścieżki również domyślnie przy bezpośrednim uruchomieniu przez docker run; tymczasowe dane wstępnej kontroli bazy pozostają osobno w /app/backend/temp. Montuj /app/backend/data zawsze, gdy kontener może zostać utworzony ponownie.
W środowisku produkcyjnym ustaw stabilne sekrety:
JWT_SECRET=replace-with-a-long-random-secret
ENCRYPTION_KEY=replace-with-64-hex-characters
Twórz kopię zapasową woluminu danych razem z kluczem szyfrowania.
Przed usunięciem bezpośrednio uruchomionego kontenera ze starszego obrazu potwierdź, że istnieje /app/backend/data/.encryption_key, albo zapisz skonfigurowany ENCRYPTION_KEY. Starsze obrazy mogły zapisać automatycznie wygenerowany klucz wyłącznie w warstwie kontenera; usunięcie kontenera usuwa też jedyny klucz zdolny odszyfrować trwałą bazę danych.
Jeśli korzystasz z niestandardowego środowiska obsługującego Work, jego pliki zadań znajdują się w osobnych nazwanych woluminach Docker i nie wchodzą do zwykłej kopii /app/backend/data.
Dostęp publiczny
Pliki Compose repozytorium wiążą WebUI z loopbackiem i ustawiają CORS_ORIGIN bezpośrednio. Wartość z powłoki lub pliku .env nie zastępuje tej wartości literalnej. Edytuj wpis libre-webui.environment albo zapisz jawne nadpisanie jako compose.origin.yml:
services:
libre-webui:
environment:
CORS_ORIGIN: https://your-domain.example
BASE_URL: https://your-domain.example
Zastosuj nadpisanie razem z wybranym plikiem Compose repozytorium:
docker compose -f docker-compose.yml -f compose.origin.yml up -d
Następnie umieść Libre WebUI za HTTPS przy użyciu reverse proxy lub modułu równoważenia obciążenia platformy. Ustaw WEBUI_BIND_ADDRESS na dokładny interfejs wymagany przez proxy; nie publikuj portu na wszystkich interfejsach, chyba że wymaga tego zapora.
Serwer już wydajnie dostarcza zbudowany frontend: pakiety z hashem w /js/ i /assets/ są wysyłane skompresowane brotli lub gzip z rocznym, immutable czasem życia w pamięci podręcznej, natomiast index.html i service worker są oznaczone jako no-cache, więc nowe wydanie zostaje pobrane przy następnym załadowaniu. Proxy nie musi ponownie kompresować ani buforować tych ścieżek; przepuszczaj nagłówek Accept-Encoding.
Przydatne polecenia
docker compose ps
docker compose logs -f libre-webui
docker compose logs -f ollama
docker compose pull
docker compose up -d