Open WebUI, Ollama und SearXNG: Private KI mit Websuche
Ollama, Open WebUI, SearXNG und Redis auf einem Ubuntu-GPU-Server bereitstellen und lokale Modelle mit kontrollierter Websuche, TLS, Sicherheit und Tests ergänzen.
Was läuft am Ende dieser Anleitung?
Ollama, Open WebUI, SearXNG und Redis auf einem Ubuntu-GPU-Server bereitstellen und lokale Modelle mit kontrollierter Websuche, TLS, Sicherheit und Tests ergänzen. Beispiel-Domains, Passwörter und Secrets müssen vor der Ausführung durch eigene Werte ersetzt werden.
Architektur und Anforderungen vor der Installation
Ubuntu 24.04 LTS mit sudo-Zugriff und eigener IPv4-Adresse
Docker Engine und Compose v2 für containerbasierte Bereitstellungen
DNS-A-Record vom Anwendungsnamen auf den Server
NVMe-Kapazität für Daten, Logs, temporäre Dateien und Backups
CPU- und RAM-Reserve anhand gemessener Gleichzeitigkeit
DNS- und Portplan
80/443 TCP: Open WebUI dış erişim
11434/TCP: Ollama yalnız özel ağ/localhost
8080/TCP: SearXNG yalnız Docker ağı
6379/TCP: Redis yalnız Docker ağı
Praktische Installationsschritte
1. GPU doğrulama
nvidia-smi
lspci -nn | grep -Ei "3d|display|vga"
docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi
2. Dizin ve sırlar
sudo mkdir -p /opt/eka-ai/searxng
cd /opt/eka-ai
openssl rand -hex 32
Open WebUI, Ollama und SearXNG muss hinter HTTPS isoliert werden; Datenbank, Queue und interne APIs dürfen nicht direkt im Internet veröffentlicht werden.
Produktionshinweis
Vor Produktion getestete Image-Versionen fixieren. Vor Migrationen Release Notes lesen und ein konsistentes Backup erstellen.
Produktionshinweis
Ein Datenbank-Dump allein kann unvollständig sein. Persistente Dateien, Konfiguration, Schlüssel und exakte Version gemeinsam sichern.
Produktionshinweis
Eine echte Transaktion testen, den Host neu starten und die automatische Wiederherstellung prüfen, bevor produktiver Traffic zugelassen wird.
Häufige Fehler und Ursachen
Belirti / Symptom
Kök neden ve çözüm / Root cause and fix
Dienst oder Container startet nicht
Compose-Konfiguration, Abhängigkeiten, Dateirechte und die erste fatale Logzeile prüfen statt wiederholt neu zu starten.
Domain erreichbar, HTTPS fehlerhaft
A/AAAA, Ports 80/443, Proxy-Modus, Zertifikatsprüfung und konkurrierende Reverse Proxies prüfen.
Datenbank oder Queue nicht erreichbar
Internen Servicenamen und Credentials prüfen; Datenbankports nicht öffentlich freigeben.
Unter Last instabil
RAM-Spitzen, Disk-Latenz, Connection Pools und Worker-Concurrency messen und den Engpass gezielt beheben.
Validierung nach der Installation
Alle Dienste laufen und Healthchecks sind erfolgreich
Hostname liefert ein gültiges HTTPS-Zertifikat
Nur erforderliche Ports sind erreichbar
MFA und Notfallzugriff für Administratoren sind eingerichtet
Backup-Prüfsummen wurden gespeichert
Restore in isolierter Umgebung wurde getestet
Keine wiederkehrenden kritischen Fehler in Logs
Dienste starten nach einem Host-Neustart automatisch
Ja, nachdem Secrets ersetzt, Zugriffe begrenzt und ein vollständiger Restore erfolgreich getestet wurde.
Reichen Mindestressourcen?
Mindestwerte zeigen nur, dass Software startet. CPU, RAM, IOPS und Speicher anhand echter Last dimensionieren.
Kann Cloudflare verwendet werden?
Ja. Full (strict) TLS sowie Origin-Zertifikat, WebSockets und echte Client-IP korrekt konfigurieren.
Updates automatisch installieren?
Major Releases nicht automatisch installieren. Migrationen prüfen, Backup erstellen und altes Image bereithalten.
Was muss gesichert werden?
Datenbank, Uploads, Volumes, Konfiguration, Schlüssel und genaue Version gemeinsam sichern.
VPS oder GPU-Server?
NVMe-VPS passt für Web-Workloads; Inferenz, OCR-Beschleunigung und Transcoding können eine GPU benötigen.
Kontakt für die Bereitstellung
Ollama, Open WebUI, SearXNG und Redis auf einem Ubuntu-GPU-Server bereitstellen und lokale Modelle mit kontrollierter Websuche, TLS, Sicherheit und Tests ergänzen.