Salut, oui whoami c'est juste une image qui sert d'exemple ! Inutile de la déployer du coup
NicCo Tu m'as perdu, pourquoi vouloir utiliser la configuration dynamique du coup ?
Je réitère qu'il n'y a pas de meilleur choix, ça dépend de ce que tu veux, de ton usage, tes besoins. Pour moi xataz a raison, si tu joues pas avec tes conteneurs toutes les semaines autant tout mettre dans la config statique. Si c'était le doublon le problème, quel était le souci d'utiliser la config statique avec exposeByDefault sur false (ou sans le provider Docker du tout) ?A mon avis tu te prends beaucoup trop la tête.
Maintenant, oui, le provider Docker/config dynamique avec socket-proxy c'est déjà bien mieux que monter le socket en nature.NicCo Oui ça revient exactement au même, si tu mets le exposedByDefault sur false il va s'en foutre du conteneur sauf si tu mets un label qui l'active "traefik.enable=true" ou qqchose du genre.
- Modifié
Il n'y a pas de "bonne" façon, avec Traefik il y a des façons de faire.
Ben du coup si tu n'utilises pas du tout Docker comme provider, désactive-le ou alors active désactive "exposedByDefault" comme indiqué dans la doc : https://doc.traefik.io/traefik/providers/docker/(Dis mois si ça marche, je serai curieux.)
Pour Portainer, si tu veux monitorer il y a de meilleurs outils pour ça. Netdata pour du temps-réel, cAdvisor + Prometheus si tu veux vraiment sortir les gros moyens.
Pour le moment ça a l'air de fonctionner
Avec les labels pour chaque réseau ? Cool du coup !
j'en profite aussi pour tester le proxy socket qui fonctionne aussi (par contre pour Portainer par exemple il faut activer plusieurs variables d'environnement, j'espère que niveau sécurité ça ne pose pas de souci mais pas le choix sinon à priori)
Non c'est normal, effectivement Portainer a besoin d'infos supplémentaires qui sont cachées par socket-proxy par défaut. Cependant n'oublie pas que socket-proxy empêche les requêtes POST, donc l'utilité de Portainer en dehors de visionner ses conteneurs est discutable. (Pour ma part je n'aime pas utiliser Portainer.)
A quoi sert l'utilisation du socket sur Traefik ?
Le provider comme son nom l'indique fournit à Traefik informations et configurations de ce qu'il doit faire. Le socket comme provider est parfait pour du plug & play avec les conteneurs, tu peux ajouter/retirer des conteneurs à la volée et Traefik le prendra en compte.
En soit, j'ai aussi des providers docker et file. Docker pour fournir les configurations de mes conteneurs, File pour les configurations style les headers HSTS que j'appelle dans le compose via "@file". Effectivement tu as l'air d'avoir du doublon par contre, si tu mix labels/config statique pour les conteneurs j'imagine que ça peut arriver, je sais pas trop comment tu t'y es pris au final
- Modifié
mcartaud Ouais, avec cette ligne tu écoutes sur IPv4 et IPv6.
Mais comme dit, tu n'as que de l'IPv4 NAT actuellement sur ton install Docker, et les solutions que je t'ai proposées. Si jamais tu optes pour la seconde :
- Modifie ton /etc/docker/daemon.json et ajoute "experimental: true" et "ip6tables: true"
- Redémarrer le Docker daemon
- Recréer ton réseau user-defined bridge pour ton reverse proxy avec "docker network create --ipv6 --subnet subnet mon_reseau" et si t'as pas d'idée pour un subnet go en faire un ici
- Vérifie que dans le compose tu utilises ce réseau, puis relance tout, enjoy l'IPv6 (et toujours l'IPv4 bien entendu)
(J'en profite pour faire la pub mais Traefik est le reverse proxy le plus agréable que tu peux utiliser si ton setup est Dockerisé.
)Déjà il faut en effet un enregistrement AAAA.
Le problème c'est juste que Docker n'a pas été pensé pour l'IPv6 et jusqu'à présent, il n'y a aucune solution parfaite pour avoir de la connectivité IPv6 en accès/connectivité.
Tu as deux solutions :
- Le proxying direct AKA une IPv6 = un conteneur : ça va demander de la bidouille, potentiellement avec NDP. Je n'aime pas cette solution car Docker est pensé pour de l'IPv4 NAT avant tout, les images sont conçues pour.
- La dualstack IPv4/IPv6 symétrique = IPv6 NAT à côté de l'IPv4 : c'est un sacrilège de parler d'IPv6 et de NAT (on utilise la solution à un problème sur une autre solution), mais la réalité c'est que ça "juste marche" si tu veux la connectivité IPv6 dans le paradigme Docker.
Pas de solution idéale du coup, j'aurais tendance à quand même préférer la seconde car la plus logique quand on utilise Docker (d'ailleurs Docker supporte désormais nativement ip6tables pour le calquer de son fonctionnement avec iptables).
Si tu ne veux pas choisir, tu peux déplacer ton reverse proxy hors de Docker, et l'utiliser pour pointer vers le conteneur.
- Modifié
Mais tu as essayé comme ça ? Tu ne devrais pourtant pas avoir à préciser de réseau pour le provider Docker. Pour moi ça devrait fonctionner si tu précises par app le label Traefik du réseau à utiliser.
Sinon c'est effectivement un cas très rare, d'habitude on fait un gros réseau frontend avec le provider Docker, rapide et simple mais isole moins les apps entre elles (ça pose problème si tu dépends par exemple d'une basicauth donc via le proxy pour sécuriser l'accès à une application).
Cependant sache qu'il n'y a aucun problème si utilises des configurations statiques, même sans forcément les IP statiques (c'est juste pour gVisor ça, t'embête pas comme moi) ; donc au pire des cas, fais de la configuration statique directement avec l'exemple que je t'avais fourni par mail (ou celui de xataz). Mais je suis persuadé qu'avec juste les labels de réseau ça devrait marcher, ça me semblait logique (mais si ce n'est pas le cas excuse-moi).
NicCo Un réseau external te donne la connectivité, mais à partir de là tu map Traefik aux ports de l’hôte directement. Le label que j’ai donné est à préciser pour chaque conteneur pour que Traefik sache sur quel réseau il doit trouver ce conteneur. Comme dit, moi j’ai juste pour le moment un gros réseau frontend.
Chez Traefik tu as différents backends (Docker, file, etc.) et types de configuration (dynamique/statique, labels/toml/yaml). Donc tout ce que tu peux faire en label tu peux le faire en statique yaml et vice versa. La documentation couvre vraiment beaucoup, n’hésite pas à la consulter !
NicCo Oui j'ai pas très bien compris, mais le 4ème réseau sera inutile du coup.
Traefik utilise ce label par app que tu veux exposer : traefik.docker.network=mon_reseauNicCo Non pas personnellement., j'attendais que ça mature un peu et de prendre le temps d'essayer un jour. Mais par rapport à Docker c'est plus propre, daemonless et rootless par défaut, ça résout pas mal de ses défauts. Mais Docker a plus de features encore pour l'instant, j'ai pas tout en tête, xataz sera l'expert dessus
- Modifié
NicCo Non je n'utilise ni Watchtower ni Diun. Peut-être je devrai mais pour l'instant je suis satisfait avec les RSS pour les mises à jour proprement dites et la "bonne pratique" de mettre à jour les images régulièrement (tout comme généralement on fait apt update/upgrade soi-même plutôt qu'automatique). Après c'est à chacun de voir ce qui lui va...
Pour les RSS sache que la page "releases" de chaque Github t'as un flux atom pour ça. Chez moi j'utilise Miniflux et Miniflux le récupère tout seul après un C/C. Pour les images, tu peux ajouter les flux RSS d'Alpine Linux (souvent utilisé) pour être au courant si y a un gros truc à mettre à jour et donc penser à mettre à jour toutes tes images. Et évidemment Debian, etc.
De façon générale faut se tenir au courant, il n'y a pas d'install & forget même avec Docker. Les flux RSS sont un outil souvent trop sous-estimé pour ça.
- Modifié
Perso ce que je fais j'ai des flux RSS pour chaque soft que j'utilise, et comme j'utlilise au maximum les versions officielles, je sais que c'est vite à jour. Après même sur un tag fixe tu dois idéalement refaire le conteneur avec une image fraîche de temps en temps histoire d'avoir des paquets à jour (là encore il faut que la maintenance de l'image soit présente, à moins de la construire toi-même) ; faut avoir ça à l'esprit (et on touche au gros point noir de Docker avec l'enfer des dépendances : si t'as une faille OpenSSL tu dois la corriger sur X conteneurs au lieu d'un simple apt update).
- Modifié
Je conseille pas tant que ça Watchtower, ça peut mener à des emmerdes. Enfin, pourquoi pas, mais ça dépend vraiment au cas par cas et il faut absolument prendre la bonne habitude de préciser les tags de ses images (exemple : nginx:1.19-alpine et pas juste nginx). Watchtower ou pas, tu auras moins de soucis comme ça.
Pour le monitoring tu peux jeter un coup d'oeil à Netdata : c'est surtout pour du monitoring en temps réel même s'il peut être personnalisé pour remonter un peu plus loin dans le temps. Si tu veux un truc plus complet (mais plus lourd), pourquoi pas s'intéresser à une stack Grafana/Prometheus/Node-exporter/Cadvisor. Attention c'est un peu lourd par contre, et y a trop de configurations pour que je te dise quoi faire (faut que je mette à jour la mienne d'ailleurs...), mais doit y avoir des tuto sur Internet.
NicCo C'est des capabilities, en gros des "morceaux de privilèges", c'est déjà bien plus propre que de tourner avec l'option
privileged.Parfois c'est nécessaire, et dans ce cas,
NET_ADMINpermet au conteneur d'administrer des règles iptables par exemple ce qui semble nécessaire pour un VPN. PourSYS_MODULEc'est à voir selon le besoin. Tu veux monter un serveur ou un client VPN (pour une seedbox par exemple) ? Si c'est pour un client et que tu veux passer par un conteneur, je te conseille cette image qui est bien documentée et à jour.Il n'y a pas de solution plus sécurisée, parfois il faut les privilèges. Mais il faut appliquer le concept du moindre privilège et adopter une façon granulaire quand tu dois en donner à un conteneur. RedHat en parle en détails.
Donc pour les réseaux type DB ou Redis, on est OK qu'un réseau internal suffit vu qu'il n'y a pas besoin d'accéder à l'extérieur.
Oui, c'est préférable.
Par contre pour tous les réseaux des apps auxquelles je vais accéder derrière traefik, je peux les créer en internal (vu que c'est traefik qui est en frontal) ou il faut quand même les créer en external ?
Le truc c'est que ton conteneur va quand même avoir besoin d'un réseau non-internal, sinon par exemple dans ton cas avec Jellyfin, il pourra pas récupérer des métadonnées pour tes bibliothèques. Ces réseaux-là je les laisserais comme ça.
Du coup pareil pour Traefik, il lui faut au moins un réseau connecté au monde extérieur. Pour ces réseaux-là ne t'embête donc pas à faire des réseaux internal.
NicCo Moi je pense toujours que tu peux utiliser bridge même pour les ports en local.
Précise l'IP du subnet local comme j'ai montré avant pour voir si ça marche. Et si ça marche pas, tu le fais écouter sur localhost et puis t'utilises nginx pour reverse proxy ça.Dans tous les cas, je vois difficilement l'intérêt du mode network host, tu peux juste publier les ports de la bonne façon. Et en dernier recours faire des règles iptables manuelles.
- Modifié
NicCo J'avoue que ça dépasse un peu mon utilisation donc je ne peux pas trop t'aider sur ce terrain.
Mais macvlan me semble être utilisé pour des besoins bien précis, ce réseau associe une adresse MAC à ton conteneur, j'ai du mal à voir pourquoi faire ça.
Sinon au pire tu publies le port 8096 et le reste normalement, mais tu filtres l'accès par iptables comme ça :
-A FILTERS -p tcp --dport PORT -s LOCAL_SUBNET -j ACCEPT
Avec la chaîne FILTERS à ajouter dans INPUT et DOCKER-USER. C'est une solution aussi je pense- Modifié
NicCo Ne fais pas ça, tu risques d'exposer publiquement Jellyfin en HTTP, c'est pas ce que tu veux. Ce qu'il faut faire, c'est lier les 2 conteneurs (Jellyfin et Traefik) avec un réseau, et créer un service qui écoute sur jellyfin:8096.
Si ton serveur est local, tu peux par contre modifier et préciser par sécurité 127.0.0.1:8096:8096 pour qu'en gros le port ne soit exposé que localement si tu veux y accéder sans Traefik. Pareil pour les autres, si c'est une utilisation spécifique (je doute que tu aies besoin les exposer sur Internet !).
Moi je ferais juste tout simplement passer par Traefik, et dans ce cas tu n'as pas besoin de publier les ports de Jellyfin.
- Modifié
NicCo La seule différence avec ton exemple c'est le to: qui pointe vers websecure au lieu de :443 mais ça doit revenir au même vu que websecure pointe vers :443 (et donc si jamais on venait à modifier, pour x raison, le 443 en 4443 on aurait juste à faire une modif sur websecure au lieu de 2 ?)
Oui c'est la même chose, moi j'ai précisé :443 car mon conteneur Traefik est rootless et écoute sur le port 4430 (et avec la magie de Docker et du NAT ça devient le port 443 exposé sur mon IP publique). Mais longue histoire
J'aurais juste à créer un app.yml dans le dossier conf.d de traefik avec les infos concernant ma nouvelle app et c'est tout ? Pas besoin de bind mount le dossier conf.d dans le docker-compose.yml de ma nouvelle app ?
Pas besoin non, l'app n'y ferait rien. Traefik communiquera avec ton app via le réseau docker, frontend dans ton cas. Après moi j'utilise encore la configuration dynamique, il faudra voir les exemples de xataz pour la configuration statique, mais c'est l'idée