Bonjour à tous, Pour les plus avertis, vous êtes pas sans savoir que Wonderfall a arrêté ses projets Docker. Utilisant son image "boring-nginx" en reverse proxy pour toutes mes autres images et "rtorrent-flood" comme seedbox, les mises à jours ne verront plus le jour 💯 Je commence donc à penser au futur.... Voici mon docker-compose.yml : https://paste.mondedie.fr/?27c9dbdddd5d3c85#q6Sh+8rK48W8ryC/DfVGLV1ihrqmu2SdeeznzeSuihY= Je voudrais donc changer les deux images de Wonderfall par celle de Xataz. "docker-reverse-nginx" pour le proxy et "docker-rtorrent-rutorrent" pour la seedbox vu que Xataz ne fait pas avec Flood. Comme sur l'image proxy de Xataz il est possible d'utiliser ses propres VirtualHost d'après mes sources, j'aimerais faire comme ça plutôt que d'utiliser les labels mais j'aurais besoin d'un exemple de ce fichier pour le proxy, de savoir dans quel dossier le mettre pour l'activer car j'ai fait quelques essais mais ça se terminé toujours par des échecs. Concernant le changement de Flood à ruTorrent, comment puis-je faire pour que tout ce remettent en place après les changements ? Merci beaucoup pour votre aide

Si tu mount le folder .session avec le même chemin d'une image à l'autre, pareil avec les torrents, ça devrait pouvoir faire un recheck de tes torrents 😉

BXT Ok donc pour la seedbox c'est une très bonne chose si on remet simplement les mêmes répertoires et que le recheck ce fait tout seul. Me reste plus que quelques explications sur l'utilisation du proxy de Xataz et je serais prêt pour des tests 🙂 Merci

Celui de xataz je connais pas. Perso' j'utilise le jwilder/nginx-proxy avec letsencrypt-companion. Il te suffit de mettre 2 variables d'env (VIRTUAL_HOST et VIRTUAL_PRORT) pour ton reverse proxy et 2 autres pour générer les crt (LETSENCRYPT_MAIL et LETSENCRYPT_HOST)

J'aurais une préférence tout de même pour celui de Xataz, je trouve la doc simple à comprendre, pareil pour l'utilisation des certificats, je pèche juste sur les vhosts... Mais merci pour toutes tes infos

letsencrypt companion n'est plus maintenu depuis quelques temps. Franchement, je vous encourage fortement à arrêter avec le bricolage (oui, nginx en reverse proxy pour docker, c'est du bricolage :p ) et à migrer sous traefik qui lui, est prévu pour ça. Il est plus efficace et facile à mettre en place. La migration ce fait très facilement et ça gère les certificats let's encrypt de manière transparente. Pour rtorrent+flood, je n'ai pas d'alternative non plus. Si tu trouves, je suis preneur 😉 z.

Euh nginx en reverse-proxy est parfaitement prévu pour ça... Pour ton traefik, regarde les benchs, tu verras qu'il est moins rapide qu'un bon vieux nginx

zer Avec Traefik, on peut ajouter/modifier les vhosts pour des modifications HSTS / OCSP etc..... ?

Bonjour, Avez-vous essayé de build les images Wonderfall avec ses Dockerfile ? Même s'il arrête de maintenir ses images, rien ne vous empêche de continuer à les utiliser en les créant vous même.

BXT nginx est prévu pour fonctionner en temps que reverse proxy, oui. Bien sûr même, mais il n'est pas prévu pour gérer des containers. Preuve en est qu'il faut soit bidouiller pour le faire fonctionner avec (= avoir un container développé en parallèle pour regénérer la conf à partir de variables d'environnements), soit refaire la conf à la main pour chaque nouveau container... Sans compter qu'il ne génère pas les certificats automatiquement. Traefik a été dév spécialement pour travailler avec des containers. Quelques labels suffisent et il map le container avec le ou les fqdns voulus tout en générant le(s) certificats en direct. Après, que les benchs soient en faveur de l'un ou l'autre, c'est une autre histoire, mais la différence ne ce voit pas à un niveau d'auto-hébergement en tout cas. Sur un site brassant 10k visiteurs jours, c'est une autre histoire, certes 😃

Rathorian Il me semble que oui, mais je n'ai pas testé.

Changement de plusieurs images Docker : Page 2

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Changement de plusieurs images Docker

Rathorian

BXT Je comprends pas tout désolé. Je pensais pas qu'il fallait des links quand on utilise des réseaux spécifique comme j'ai fait. Il me semble avoir vu sur la doc que les links était déprécié, je sais pas si ça fait la même chose mais j'ai essayé d'ajouter dans le docker-compose de nginx :

depends_on : - adminer

Mais le problème reste le même

EDIT: Le plus étonnant quand je regarde "/nginx/www/adminer.rathorian.fr" dans le conteneur nginx, j'ai absolument rien .... Est-ce normal ? Il devrait y avoir le site adminer....

BXT

Je t'ai dit link pas depends_on xD

Tu as spécifié le nom de la machine, sans link, ton autre Host peut la joindre mais via son IP, pas son nom

Rathorian

BXT Je sais que tu m'as pas dit "depends_on" 😂
Je voudrais pas être lourd mais je comprend pas trop ou tu veux en venir, loin d'être un pro 😐

zer

Pour faire simple, le link, c'est comme si tu rajoutais l'autre container dans le /ets/hosts du premier container.
Ainsi ils peuvent ce parler en utilisant leurs noms.

Sans ça, tu est obligé de taper les ips des containers.

Rathorian

zer Donc en gros si je comprends bien, pour ne pas utiliser de link et que tout ça fonctionne, je dois changer dans mon vhost la ligne :

location / { proxy_pass http://adminer:8888; proxy_cookie_path / "/; secure"; include /nginx/conf.d/proxy.conf; client_max_body_size 200M; }

par

location / { proxy_pass http://IP.DU.CONTENEUR:8888; proxy_cookie_path / "/; secure"; include /nginx/conf.d/proxy.conf; client_max_body_size 200M; }

zer

Rathorian C'est l'idée, sauf que dans ce cas, tu as intérêt à spécifier une ip fixe à ton container... Bien plus lourd à mettre en place qu'un simple link 😉

xataz

zer Pas vraiment en fait, puisque en utilisant des networks, cela crée un serveur mDNS, donc la résolution nom -> IP est dynamique et automatique, donc c'est encore plus simple, et cela permets la communication bilatéral.

Rathorian J'ai cru voir que tu avais utiliser l'option com.docker.network.bridge.enable_icc sur tes réseaux, ce qui empêche la communication entre les conteneurs.
Donc si tu fais le test, docker exec -ti nginx ping adminer, cela ne devrait même pas fonctionner. Faudrait recréé tes réseaux sans cette option.

zer

xataz Tu as raison, cependant, tu ne parles pas de la même chose.
le mDNS dont tu parles résoudra le hostname interne du container.
Le link lui, associe le nom que tu veux au container quelque soit son hostname, puisqu'il travaille au niveau du service.

Certes, la finalité est la même et ça fait un peu "jouer sur les mots", mais ça montre bien qu'il y a plusieurs approches !

xataz

zer Tu peux le faire avec un network aussi :

services:
  adminer:
    image: hardware/adminer
    container_name: adminer
    restart: always
    environment:
      - UID=1000
      - GID=1000
    networks:
      frontend:
        aliases:
          - "reverse"
          - "labiteadudule"
      backend:
        aliases:
          - "reverse"

Et la le conteneur pourra être appelé par nginx ou reverse, ou même labiteadudule (depuis le réseau frontend seulement)

zer

xataz Effectivement, je ne connaissais pas cette manière !

Rathorian

Vous parlez tellement technique que j'ai rien compris, la vache 😂

@xataz Pour l'option "com.docker.network.bridge.enable_icc" j'avais lu un truc qu'il était conseillé de le désactiver pour éviter que des conteneurs qui ont pas besoin de communiquer entre eux puisse ne pas le faire, genre par exemple le reverse proxy nginx et mariadb. Je fais juste ça pour avoir un peu plus de sécurité, pareil pour mes deux réseaux, le front et le back.

Pour le coup, d'une utilisation perso, je me demande bien si ça en vaut la peine que je m'embête autant !

BXT

Discussion intéressante

@Rathorian l'option que tu as mis est intéressante oui. Mais comme je t'ai dit, tu es obligé de links tous tes containers afin qu'ils communiquent entre eux.

Sans link, grace/à cause de l'option que tu as mis, ce sera impossible de communiquer.

xataz

Oui c'est la seul solution, mais link est limité.

Perso j'ai un réseau avec l'option ICC, il me sers seulement pour mettre des conteneurs qui n'auront jamais besoin de communiqué avec un autre, comme actuellement j'ai un mineur de monero.

Autrement dans ton exemple, nginx n'aura jamais accès à la bdd, puisqu'il n'est pas sur le même réseau.

Hardware

J'hésite à passer hardware/mailserver sous Træfik, il y a quelqu'un qui a fait une PR pour commencer la transition : https://github.com/hardware/mailserver/pull/201

Alors certes, Træfik est plus lent que Nginx mais ça on s'en fout un peu, je pense que la plupart des gens sur ce forum ne s'occupent pas à héberger des applications à forte charge, on fait surtout de l'auto-hébergement, Træfik est parfait dans ce cas là. Moi ce qui me pose problème c'est plus là personnalisation, j'avais l'habitude de l'image de Wonderfall qu'on pouvait customiser sans problème, Træfik est encore jeune, et n'implémente pas encore tout ce que peut faire Nginx.

Donc je sais pas, soit je reprends l'image de Wonderfall, soit je passe sur Træfik 🤔

xataz

Hardware C'est justement ce qui m'a fait créer mon propre reverse proxy, c'est que traefik n'inclus pas certaines fonctionnalités que j'utilise.
Après niveau perfs, c'est effectivement négligeable.

zer

Hardware C'est moi la PR 😉
Après, rien ne t'empêche ce proposer les deux. Après tout, ce ne sont que des docker-compose, rien n'empêche d'avoir les deux et de laisser le choix aux utilisateurs !

Au passage, félicitation pour ton image mailserver. Pour en avoir testé pas mal, c'est de loin la plus fonctionnelle et efficace 😉
Tant que je te tiens, dans ton image, postfix est compilée avec le support ldap ou non ? Je n'ai pas trouvé l'info sur github.
z.

Hardware

Après l'avantage de Træfik, c'est qu'il est simple à déployer, il marche out-of-box et intègre déjà Let's Encrypt. Donc je pense que je vais mettre à jour le readme de mailserver pour intégrer cette solution, comme ça l'image docker sera plus simple à déployer et "standard" pour tout le monde. Mais de mon côté (mondedie.fr et perso), je garde nginx en reverse proxy.

Par contre je sais pas si je vais avoir le temps de maintenir l'image de Wonderfall, il a ajouté quand même pas mal de petits patch en tout genre dedans. @xataz tu utilises quoi comme reverse proxy toi ?

xataz

Hardware J'utilise le mien, xataz/reverse-nginx, j'ai encore des petits bugs, mais c'est aussi simple que traefik à mettre en place.
J'ai pas mal repris des features de wonderfall, sauf pour boring-ssl, je suis passé à openssl.

Rathorian

xataz Et j'adore ton image

Hardware

Le reverse de xataz me tente bien pour le coup. J'avais pas vu que tu avais ajouté la génération automatique des certificats Let's Encrypt, c'est très pratique.

Je vais faire quelques tests aujourd'hui, si tout fonctionne bien je passe le forum et mon image mail sous xataz/reverse-nginx.

zer non pas de support ldap pour le moment.

BXT

Si traefik intègre correctement le wildcard Lets Encrypt, je passerais sur traefik je pense.

Nebukad

BXT Bonjour, d'ailleurs, on a des nouvelles de quand seront dispo les wildcard ?

« Page précédente Page suivante »