Gérer deux NDD sur un seul serveur

McFlyPartages

Apprenti
31 Décembre 2022
35
7
8
Salut à tous,

Est-il possible d'avoir deux ndd avec chacun leur NPM sur docker ?

Actuellement, j'ai un NPM avec deux NDD dessus dont un redirigé vers un Swag et l'autre sous NPM seul, car ce n'est que de la redirection.
J'aimerais pouvoir séparer la gestion de ce deuxième NDD sans donner accès a mon NDD principal à des personnes tierces (deuxième ndd pour une association).
J'ai essayé de rediriger le *.ndd2 vers NPM2 mais quand je crée une redirection du ndd2, il affiche une erreur nginx 404 je crois alors que si je crée la redirection sur NPM1 ça marche.
Quelle serait votre démarche ?
Merci à tous

EDIT : Problème résolu via les accès NPM, même si ce n'est pas 100% satisfaisant.
 
Dernière édition:
Salut,
Pourquoi vouloir utiliser deux reverse proxy ??
Tu en configures un seul qui gère tes deux noms de domaines.
Et puis dans ce que tu veux faire, tu vas avoir des problèmes de ports. Le port 443 ne pourra être routé que sur une seule machine. Pas deux.
Je pense que ce que tu veux faire n'est pas possible au sein d'une seule boucle LAN et surtout avec la même connexion internet.

Si tu veux vraiment déléguer la gestion/configuration du ndd2 à ton association, je pense que tu vas devoir investir dans une serveur dédié sur le net chez un prestataire (aucune idée de ce qu'il faut ;)) ou bien délocaliser la machine gérant le ndd2 sur une autre connexion internet, donc chez quelqu'un d'autre.
 
  • J'aime
Réactions: McFlyPartages
J'utiliserais deux ports distinct et/ou un reverse proxy
Utiliser deux ports distincts va être pénible...
Il faudra toujours spécifier le port sur le nom de domaine : mon-service.ndd1.tld:12345 ; mon-service2.ndd2.tld:12346...

Utiliser un reverse proxy est la solution pour ne pas avoir besoin de préciser le port de connexion.
Mais il faudrait que tu détailles ceci :
J'aimerais pouvoir séparer la gestion de ce deuxième NDD sans donner accès a mon NDD principal à des personnes tierces (deuxième ndd pour une association).
Car ce n'est pas clair.
C'est quoi que tu veux déléguer ? La gestion du service derrière le nom de domaine ? ou bien la gestion de ce nom de domaine ?
Et dans la gestion du ndd, il y a le fournisseur (DNS etc...), et aussi la configuration du reverse proxy.
Bref, développe un peu s'il te plait.
 
Salut merci pour la réponse.

Ben finalement, avec la gestion des comptes sur NPM ca va le faire, ca m'embête de devoir générer des certificats SSL au lieu d'utiliser le Wildcard quand je suis avec un compte non admin, mais ben ca va le faire sans prise de tête.

Merci encore à vous.

Pour info le but sur le NPM 1 de rediriger le NDD1 ver un swag (pour mon utilisation) et de passer tout ce qui touche au NDD2 au NPM 2.

Mais ca bloque.
 
Utiliser deux ports distincts va être pénible...
Il faudra toujours spécifier le port sur le nom de domaine : mon-service.ndd1.tld:12345 ; mon-service2.ndd2.tld:12346...

Utiliser un reverse proxy est la solution pour ne pas avoir besoin de préciser le port de connexion.
Mais il faudrait que tu détailles ceci :

Car ce n'est pas clair.
C'est quoi que tu veux déléguer ? La gestion du service derrière le nom de domaine ? ou bien la gestion de ce nom de domaine ?
Et dans la gestion du ndd, il y a le fournisseur (DNS etc...), et aussi la configuration du reverse proxy.
Bref, développe un peu s'il te plait.
Tu déclares les redirection des domaine sur leur ports au niveau de la déclaration DNS des machines. C'est pénible comme tu dis si tu as plusieurs services derrières, et pas élégant, mais ça marche tres bien si tu dois taper un simple domaine .
D'où le reverse proxy ;)
 
  • J'aime
Réactions: McFlyPartages
Pour moi c'est ajouter une complexité potentiellement problématique...
Ça fait 3 reverses proxy à maintenir, à mettre à jour, à configurer...
Vous faites comme vous voulez, mais je n'opterais pas pour cette solution...
(Je n'ai ce cas de figure qu'une fois dans mon utilisation : c'est le conteneur Nextcloud qui vient avec un Nginx intégré, malgré que j'ai un Nginx en RP dédiée (via SWAG) pour gérer mes domaines sur mon réseau. Mais là je n'ai pas le choix. Et quand il y a des mises à jour, c'est quand même bien pénible d'aller modifier le .conf de mon RP Swag et en plus celui du Nginx du conteneur...).
 
Pour moi c'est ajouter une complexité potentiellement problématique...
Ça fait 3 reverses proxy à maintenir, à mettre à jour, à configurer...
Vous faites comme vous voulez, mais je n'opterais pas pour cette solution...
(Je n'ai ce cas de figure qu'une fois dans mon utilisation : c'est le conteneur Nextcloud qui vient avec un Nginx intégré, malgré que j'ai un Nginx en RP dédiée (via SWAG) pour gérer mes domaines sur mon réseau. Mais là je n'ai pas le choix. Et quand il y a des mises à jour, c'est quand même bien pénible d'aller modifier le .conf de mon RP Swag et en plus celui du Nginx du conteneur...).
Oui j'ai laissé tombé, la gestion des comptes dans NPM n'est pas parfaite mais suffit

Pourquoi tu as le container nginx sur nextcloud avec Swag tu n'a pas besoin ?
 
Dernière édition:
Oui j'ak laissé tombé la gestion des compte dans NPM n'est pas parfaite mais suffira.

Pourquoi tu as le container nginx sur nextcloud avec Swag tu n'a pas besoin ?
J'ai du mal à saisir le sens de tes phrases... 😅
Pour Nextcloud, l'image que j'utilise vient avec son nginx intégré. Pas le choix.
 
J'ai du mal à saisir le sens de tes phrases... 😅
Pour Nextcloud, l'image que j'utilise vient avec son nginx intégré. Pas le choix.
J'ai mis la ponctuation, désolé j'étais sur mobile et j'ai des gros doigts lol.

Pour Nextcloud, même l'image officielle bénéficie d'une version sans NGinx ? J'utilise celle de LS.io car j'aime bien l'ajout du puid pgid permettant de ne pas mettre tous les dossiers en root.
 
Pour Nextcloud, même l'image officielle bénéficie d'une version sans NGinx ? J'utilise celle de LS.io car j'aime bien l'ajout du puid pgid permettant de ne pas mettre tous les dossiers en root.
J'utilise aussi l'image LS.io :) pour la même raison, et aussi parce que leur images sont toutes sur le même moule, ça facilite la rédaction des docker-compose.yml.