Oui, le reverse proxy est possible sur ZimaOS. La véritable limitation dans cette source ne vient pas du réseau Docker lui-même, mais de la couche de simplification qui entoure les applications installées via l’interface graphique. Traefik fonctionne mieux lorsque chaque service dispose de labels définis volontairement, de noms de services Compose prévisibles et de réseaux Docker partagés. Ces paramètres sont bien plus faciles à contrôler lorsque la stack est créée avec Compose que lorsqu’une application est installée à l’aide d’un formulaire graphique simplifié.
La réponse source recommande donc Nginx Proxy Manager à la plupart des utilisateurs de ZimaOS qui privilégient l’interface graphique, et Traefik aux utilisateurs prêts à déployer les applications concernées avec Compose. Il s’agit de recommandations de la communauté, et non d’une architecture officielle de reverse proxy d’IceWhale.
Pourquoi Traefik semble peu pratique avec les applications installées via l’interface graphique
Le principal atout de Traefik est la détection automatique des conteneurs Docker grâce à des labels tels que les routeurs, les services, les points d’entrée et les règles TLS. Si l’interface de l’application n’autorise pas l’ajout de labels arbitraires, ou si les noms des conteneurs sont générés automatiquement ou peu pratiques, Traefik perd une grande partie de son automatisation.
Compose rétablit un contrôle total
ZimaOS 1.7 App Store 2.0 prend actuellement en charge le format YAML natif, et la documentation destinée aux développeurs de ZimaOS considère Docker Compose standard comme le modèle de configuration d’exécution. Compose vous permet de définir :
- des noms de services stables ;
- des réseaux personnalisés ;
- des labels Traefik ;
- des ports hôte/conteneur explicites ;
- des volumes et une politique de redémarrage.
Utilisez le modèle Compose actuel de ZimaOS.
Pourquoi Nginx Proxy Manager est plus simple
Nginx Proxy Manager n’exige pas que chaque application d’arrière-plan possède des labels de détection. Vous pouvez créer manuellement des hôtes proxy et les diriger vers un nom de conteneur ou une adresse IP stable, ou vers l’hôte ZimaOS et le port publié par l’application.
Cette configuration manuelle est moins élégante à grande échelle, mais plus simple dans un environnement mixte comprenant des applications de l’App Store et des stacks Compose personnalisées.
Planifiez les ports 80 et 443 avant de démarrer le proxy
La WebUI de ZimaOS et sa configuration HTTPS peuvent utiliser les ports web standard. Un reverse proxy ne peut pas s’attacher à la même adresse IP et au même port hôte déjà utilisés par un autre processus.
Vous pouvez déplacer la WebUI de ZimaOS vers un autre port, utiliser une autre interface ou adresse IP, ou publier volontairement le proxy sur d’autres ports externes.
Les réseaux Docker partagés évitent le hairpinning inutile via l’hôte
Si le proxy et l’application cible partagent un réseau Docker défini par l’utilisateur, acheminez directement les requêtes vers le nom du service ou du conteneur et son port interne. Le trafic reste ainsi dans Docker et ne dépend pas des ports publiés sur l’hôte.
Pour les applications graphiques dont le réseau ne peut pas être contrôlé proprement, l’utilisation de l’adresse IP de l’hôte et du port publié peut tout de même fonctionner.
Le reverse proxy du tableau de bord ZimaOS est un choix distinct
Ne redirigez pas automatiquement chaque hôte proxy vers l’adresse IP de ZimaOS. N’utilisez cette cible que si vous souhaitez délibérément placer la WebUI de ZimaOS derrière un reverse proxy.
Un reverse proxy ne rend pas automatiquement une application sûre à exposer
Un certificat HTTPS public ne chiffre que le transport. Les applications sensibles peuvent toujours nécessiter une authentification, une MFA, un middleware de contrôle d’accès, des restrictions d’adresse IP ou un accès limité au VPN.
FAQ sur le reverse proxy de ZimaOS
Le reverse proxy est-il impossible sur ZimaOS ?
Non. La réponse de la communauté citée dans la source indique que c’est possible ; les difficultés concernent principalement les métadonnées des applications graphiques, les réseaux et les ports occupés.
Quelle solution est la plus simple pour des applications graphiques variées ?
Nginx Proxy Manager est généralement plus simple, car il peut être configuré manuellement sans avoir à ajouter des labels Traefik à chaque application.
Quand Traefik est-il le plus pertinent ?
Lorsque la stack d’applications est déployée avec Compose, de sorte que les labels, les noms de services et les réseaux restent sous votre contrôle.
