đ FAQ
đĄ Pourquoi Docker ?â
Nous comprenons que Docker ne soit pas la prĂ©fĂ©rence de tout le monde ; cependant, cette approche est au cĆur de la conception et de l'efficacitĂ© opĂ©rationnelle de notre projet. Nous considĂ©rons l'engagement du projet envers Docker comme un aspect fondamental et encourageons ceux qui recherchent d'autres mĂ©thodes de dĂ©ploiement Ă explorer les alternatives proposĂ©es par la communautĂ©.
Q : Comment puis-je personnaliser le logo et la marque ?â
R : Vous pouvez personnaliser le thÚme, le logo et la marque avec notre Licence Entreprise, qui débloque des fonctionnalités exclusives pour les entreprises.
Pour plus de dĂ©tails sur les solutions pour entreprises et les personnalisations de marque, veuillez contacter notre Ă©quipe commerciale Ă : đ§ [email protected]
Q : Pourquoi dois-je m'inscrire ? OĂč mes donnĂ©es sont-elles envoyĂ©es ?â
R : Nous demandons votre inscription pour vous permettre de devenir l'utilisateur administrateur, renforçant ainsi la sécurité. Cela garantit que, si l'Open WebUI est un jour accessible depuis l'extérieur, vos données restent sécurisées. Il est important de noter que tout est conservé localement. Nous ne collectons pas vos données. Lorsque vous vous inscrivez, toutes les informations restent sur votre serveur et ne quittent jamais votre appareil. Votre confidentialité et votre sécurité sont nos priorités absolues, garantissant que vos données restent sous votre contrÎle en permanence.
Q : Pourquoi mon conteneur Docker ne peut-il pas se connecter aux services sur l'hĂŽte en utilisant localhost
?â
R : à l'intérieur d'un conteneur Docker, localhost
fait rĂ©fĂ©rence au conteneur lui-mĂȘme et non Ă la machine hĂŽte. Cette distinction est cruciale pour le rĂ©seau. Pour Ă©tablir une connexion entre votre conteneur et les services exĂ©cutĂ©s sur l'hĂŽte, vous devez utiliser le nom DNS host.docker.internal
Ă la place de localhost
. Ce nom DNS est spécialement reconnu par Docker pour faciliter ces connexions, traitant efficacement l'hÎte comme une entité accessible depuis le conteneur, contournant ainsi la limitation habituelle du domaine localhost
.
Q : Comment rendre les services de mon hĂŽte accessibles aux conteneurs Docker ?â
R : Pour rendre les services exécutés sur l'hÎte accessibles aux conteneurs Docker, configurez ces services pour qu'ils écoutent sur toutes les interfaces réseau, en utilisant l'adresse IP 0.0.0.0
au lieu de 127.0.0.1
qui est limité à localhost
uniquement. Cette configuration permet aux services de recevoir des connexions depuis n'importe quelle adresse IP, y compris les conteneurs Docker. Il est important d'ĂȘtre conscient des implications sĂ©curitaires de cette configuration, notamment dans des environnements avec un accĂšs externe potentiel. La mise en Ćuvre de mesures de sĂ©curitĂ© appropriĂ©es, telles que des pare-feu et l'authentification, peut aider Ă attĂ©nuer les risques.
Q : Pourquoi mon Open WebUI ne se met-il pas Ă jour ? J'ai re-tĂ©lĂ©chargĂ©/re-dĂ©marrĂ© le conteneur, mais rien n'a changĂ©.â
R : La mise Ă jour d'Open WebUI nĂ©cessite plus que de simplement tĂ©lĂ©charger la nouvelle image Docker. Voici pourquoi vos mises Ă jour peuvent ne pas ĂȘtre visibles et comment vous assurer qu'elles le soient :
- Mise Ă jour de l'image Docker : La commande
docker pull ghcr.io/open-webui/open-webui:main
met à jour l'image Docker mais pas le conteneur en cours d'exécution ni ses données. - Données persistantes dans les volumes Docker : Les volumes Docker stockent les données indépendamment des cycles de vie des conteneurs, préservant vos données (comme les historiques de chat) lors des mises à jour.
- Application de la mise à jour : Assurez-vous que la mise à jour prenne effet en supprimant le conteneur existant (qui ne supprime pas le volume) et en créant un nouveau conteneur avec l'image mise à jour et le volume existant attaché.
Ce processus met à jour l'application tout en protégeant vos données.
Q : Attendez, pourquoi devrais-je supprimer mon conteneur ? Ne vais-je pas perdre mes donnĂ©es ?â
R : C'est une préoccupation courante, mais supprimer un conteneur ne signifie pas perdre vos données, à condition que vous utilisiez correctement les volumes Docker. Voici pourquoi :
- Les volumes préservent les données : Les volumes Docker sont conçus pour conserver les données en dehors des cycles de vie des conteneurs. Tant que vos données sont stockées dans un volume, elles restent intactes, quel que soit le sort du conteneur.
- Processus de mise à jour sécurisé : Lors de la mise à jour d'Open WebUI, la suppression de l'ancien conteneur et la création d'un nouveau avec l'image mise à jour n'affecte pas les données stockées dans les volumes. La clé est de ne pas supprimer explicitement le volume avec des commandes telles que
docker volume rm
.
En suivant les Ă©tapes correctes de mise Ă jour â tĂ©lĂ©charger la nouvelle image, supprimer l'ancien conteneur sans supprimer le volume et crĂ©er un nouveau conteneur avec l'image mise Ă jour et le volume existant â votre code d'application est mis Ă jour tandis que vos donnĂ©es restent intactes et sĂ©curisĂ©es.
Q : Devrais-je utiliser Docker fourni par ma distribution ou le package Docker officiel ?â
A: Nous recommandons d'utiliser le package officiel Docker plutÎt que les versions packagées par les distributions pour exécuter Open WebUI. Le package officiel Docker est fréquemment mis à jour avec les derniÚres fonctionnalités, correctifs de bugs et patchs de sécurité, assurant des performances optimales et une sécurité accrue. En outre, il prend en charge des fonctionnalités importantes comme host.docker.internal
, qui peuvent ne pas ĂȘtre disponibles dans les versions packagĂ©es par les distributions. Cette fonctionnalitĂ© est essentielle pour une configuration rĂ©seau et une connectivitĂ© appropriĂ©es au sein des conteneurs Docker.
En choisissant le package officiel Docker, vous bénéficiez d'un comportement cohérent dans différents environnements, d'un support de dépannage plus fiable et d'un accÚs aux derniÚres avancées de Docker. La communauté Docker élargie et ses ressources sont également mieux alignées avec le package officiel, vous offrant une richesse d'informations et de soutien pour tout problÚme que vous pourriez rencontrer.
Tout ce dont vous avez besoin pour exécuter Open WebUI, y compris vos données, reste sous votre contrÎle et dans votre environnement de serveur, soulignant notre engagement envers votre confidentialité et sécurité. Pour obtenir des instructions sur l'installation du package officiel Docker, veuillez consulter le guide Installer Docker Engine sur le site officiel de documentation Docker.
Q : La prise en charge du GPU est-elle disponible dans Docker ?â
A: La prise en charge du GPU dans Docker est disponible mais varie selon la plateforme. Officiellement, la prise en charge du GPU est fournie dans Docker pour Windows et Docker Engine sur Linux. D'autres plateformes, telles que Docker Desktop pour Linux et MacOS, ne proposent actuellement pas de prise en charge du GPU. Cette limitation est importante à considérer pour les applications nécessitant une accélération GPU. Pour une expérience optimale et pour utiliser les capacités GPU, nous recommandons d'utiliser Docker sur des plateformes qui prennent officiellement en charge l'intégration GPU.
Q : Pourquoi Open WebUI met-il l'accent sur l'utilisation de Docker ?â
A: La dĂ©cision d'utiliser Docker dĂ©coule de sa capacitĂ© Ă garantir la cohĂ©rence, isoler les dĂ©pendances et simplifier le dĂ©ploiement dans diffĂ©rents environnements. Docker minimise les problĂšmes de compatibilitĂ© et rationalise le processus de mise en route de l'interface WebUI, indĂ©pendamment du systĂšme sous-jacent. C'est un choix stratĂ©gique des mainteneurs du projet pour tirer parti de ces avantages, tout en reconnaissant que Docker peut avoir une courbe d'apprentissage. Cependant, les avantages en termes de dĂ©ploiement et de maintenance sont significatifs. Nous comprenons que Docker peut ne pas ĂȘtre la prĂ©fĂ©rence de tout le monde ; toutefois, cette approche est centrale Ă la conception et Ă l'efficacitĂ© opĂ©rationnelle de notre projet. Nous considĂ©rons l'engagement du projet envers Docker comme un aspect fondamental et encourageons ceux qui recherchent des mĂ©thodes de dĂ©ploiement diffĂ©rentes Ă explorer les alternatives dĂ©veloppĂ©es par la communautĂ©.
Q : Pourquoi les fonctions de reconnaissance vocale (STT) et de synthĂšse vocale (TTS) ne fonctionnent-elles pas dans mon dĂ©ploiement ?â
A: Le fonctionnement des services de reconnaissance vocale (STT) et de synthÚse vocale (TTS) dans votre déploiement peut nécessiter HTTPS pour fonctionner correctement. Les navigateurs modernes appliquent des mesures de sécurité qui limitent certaines fonctionnalités, y compris STT et TTS, à fonctionner uniquement sous des connexions HTTPS sécurisées. Si votre déploiement n'est pas configuré pour utiliser HTTPS, ces services pourraient ne pas fonctionner comme prévu. Assurer que votre déploiement est accessible via HTTPS peut résoudre ces problÚmes et permettre une fonctionnalité complÚte des caractéristiques STT/TTS.
Q : Pourquoi Open WebUI n'inclut-il pas un support intĂ©grĂ© pour HTTPS ?â
A: Bien que nous comprenions le désir d'une solution tout-en-un incluant le support HTTPS, nous pensons qu'une telle approche ne servirait pas adéquatement la diversité des besoins de nos utilisateurs. Implémenter HTTPS directement dans le projet pourrait limiter la flexibilité et ne pas correspondre aux exigences ou préférences spécifiques de tous les utilisateurs. Pour garantir que chaque utilisateur puisse adapter son installation à son environnement unique, nous laissons l'implémentation de la terminaison HTTPS aux utilisateurs pour leurs déploiements en production. Cette décision permet une plus grande adaptabilité et personnalisation. Bien que nous ne proposions pas de documentation officielle sur la configuration de HTTPS, les membres de la communauté peuvent fournir des conseils sur demande, partageant leurs idées et suggestions basées sur leur expérience.
Q : J'ai mis Ă jour/redĂ©marrĂ©/implĂ©mentĂ© un nouveau logiciel et maintenant Open WebUI ne fonctionne plus du tout !â
A: Si votre Open WebUI ne se lance pas aprĂšs une mise Ă jour ou une installation d'un nouveau logiciel, cela est probablement liĂ© Ă une approche d'installation directe, particuliĂšrement si vous n'avez pas utilisĂ© un environnement virtuel pour les dĂ©pendances backend. Les installations directes peuvent ĂȘtre sensibles aux modifications de l'environnement systĂšme, telles que les mises Ă jour ou les nouvelles installations qui modifient les dĂ©pendances existantes. Pour Ă©viter les conflits et assurer la stabilitĂ©, nous vous recommandons d'utiliser un environnement virtuel pour gĂ©rer les dĂ©pendances listĂ©es dans le fichier requirements.txt
de votre backend. Cela isole vos dépendances Open WebUI des autres packages systÚme, minimisant le risque de ce type de problÚme.
Q : J'ai mis Ă jour/redĂ©marrĂ© et maintenant ma connexion ne fonctionne plus, j'ai dĂ» crĂ©er un nouveau compte et toutes mes discussions ont disparu.â
A: Ce problĂšme survient gĂ©nĂ©ralement lorsquâun conteneur Docker est créé sans monter un volume pour /app/backend/data
ou lorsque le volume désigné pour Open WebUI (généralement nommé open-webui
dans nos exemples) a Ă©tĂ© supprimĂ© par inadvertance. Les volumes Docker sont essentiels pour conserver vos donnĂ©es entre les cycles de vie des conteneurs. Si vous vous trouvez obligĂ© de crĂ©er un nouveau compte aprĂšs un redĂ©marrage, il est probable que vous ayez initiĂ© un nouveau conteneur sans attacher le volume existant oĂč vos donnĂ©es rĂ©sident. Assurez-vous que votre commande Docker run inclut une monture de volume pointant vers lâemplacement correct des donnĂ©es pour Ă©viter toute perte de donnĂ©es.
Q: Jâai essayĂ© de me connecter et je nâai pas rĂ©ussi, jâai créé un nouveau compte et maintenant on me dit que mon compte doit ĂȘtre activĂ© par un administrateur.â
A: Cette situation se produit lorsque vous oubliez le mot de passe du compte administrateur initial créé lors de la premiĂšre configuration. Le premier compte est automatiquement dĂ©signĂ© comme compte administrateur. La crĂ©ation dâun nouveau compte sans accĂšs au compte administrateur entraĂźnera la nĂ©cessitĂ© dâune activation par lâadministrateur. Ăviter de perdre les identifiants du compte administrateur initial est crucial pour un accĂšs fluide Ă Open WebUI et une gestion sans compromis. Consultez le guide RĂ©initialisation du mot de passe administrateur pour obtenir des instructions sur la rĂ©cupĂ©ration du compte administrateur.
Q: Pourquoi Open WebUI ne peut-il pas dĂ©marrer avec une erreur SSL ?â
A: Lâerreur SSL rencontrĂ©e au dĂ©marrage dâOpen WebUI est probablement due Ă lâabsence de certificats SSL ou Ă une configuration incorrecte de huggingface.co. Pour rĂ©soudre ce problĂšme, vous pourriez configurer un miroir pour HuggingFace, comme hf-mirror.com, et le spĂ©cifier comme point dâaccĂšs lors du dĂ©marrage du conteneur Docker. Utilisez le paramĂštre -e HF_ENDPOINT=https://hf-mirror.com/
afin de dĂ©finir lâadresse miroir de HuggingFace dans la commande Docker run. Par exemple, vous pouvez modifier la commande Docker run comme suit :
docker run -d -p 3000:8080 -e HF_ENDPOINT=https://hf-mirror.com/ --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
Q: Le RAG avec Open WebUI est trĂšs mauvais ou ne fonctionne pas du tout. Pourquoi ?â
A: Si vous utilisez Ollama, sachez que Ollama fixe par dĂ©faut la longueur du contexte Ă 2048 tokens. Cela signifie que les donnĂ©es rĂ©cupĂ©rĂ©es pourraient ne pas ĂȘtre utilisĂ©es car elles ne rentrent pas dans la fenĂȘtre de contexte disponible.
Pour améliorer les performances de la génération augmentée par récupération (RAG) avec Open WebUI, vous devez augmenter la longueur du contexte à une valeur nettement plus grande (8192+ tokens) afin de garantir que les documents récupérés puissent contribuer efficacement aux réponses du modÚle.
Pour ce faire, configurez les paramĂštres du modĂšle Ollama pour permettre une fenĂȘtre de contexte plus grande. Vous pouvez vĂ©rifier et modifier ce paramĂštre directement dans votre chat ou depuis la page dâĂ©dition du modĂšle pour amĂ©liorer significativement lâexpĂ©rience RAG.
Q: Le MCP (ModĂšle de protocole de contexte) est-il pris en charge dans Open WebUI ?â
A: Oui, Open WebUI prend officiellement en charge les serveurs dâoutils MCP â mais uniquement via un proxy compatible OpenAPI (openapi-servers) pour une compatibilitĂ©, une sĂ©curitĂ© et une maintenabilitĂ© optimales.
Pour connecter MCP (et dâautres protocoles backend), nous fournissons une implĂ©mentation de proxy spĂ©cialement conçue disponible ici : đ https://github.com/open-webui/mcpo
Ce choix de conception se fond sur plusieurs principes fondamentaux :
- đ Standards avant tout : OpenAPI est la norme de facto pour les dĂ©finitions de services RESTful et lâinteropĂ©rabilitĂ© des services basĂ©es sur des contrats. En alignant les intĂ©grations via OpenAPI, nous permettons un comportement reproductible et basĂ© sur des schĂ©mas Ă travers les mises Ă jour et les dĂ©ploiements.
- đ Isolation du modĂšle de sĂ©curitĂ© : IntĂ©grer MCP via un proxy nous permet de sandboxer et dâisoler le comportement du protocole backend, rĂ©duisant la surface dâattaque et permettant un audit, une authentification et une observabilitĂ© au niveau des limites.
- âïž Abstraction des protocoles : Prendre en charge les backend hĂ©tĂ©rogĂšnes (par exemple : MCP) via un schĂ©ma OpenAPI unifiĂ© permet Ă Open WebUI de rester indĂ©pendant du backend tout en maintenant un comportement prĂ©visible Ă lâexĂ©cution.
- âïž Topologie de dĂ©ploiement dĂ©couplĂ©e : Lâarchitecture basĂ©e sur des proxy permet aux serveurs dâoutils (comme MCP) dâĂ©voluer indĂ©pendamment de la prĂ©sentation frontend, facilitant des environnements de production hautement modulaires ou des charges de travail distribuĂ©es.
En rĂ©sumĂ© : MCP est pris en charge â Ă condition que le serveur dâoutils MCP soit derriĂšre un proxy compatible OpenAPI. Cette dĂ©cision architecturale est dĂ©libĂ©rĂ©e et garantit quâOpen WebUI reste Ă©volutif, sĂ©curisĂ© et maintenable.
Besoin dâune aide supplĂ©mentaire ?â
Si vous avez dâautres questions ou prĂ©occupations, veuillez consulter notre page GitHub Issues ou notre canal Discord pour obtenir davantage dâaide et dâinformations.