Bonjour,
Je viens vers vous afin d’échanger et obtenir des informations/solutions sur la mise en place de la disponibilité entre 1 home worker et 2 doc worker au sein d’un environnement Docker.
Voici quelques lignes pour présenter notre environnement :
→ 1 Home Worker & 2 Doc Worker
→ OIDC / REDIS / MINIO / …
→ Reverse Proxy Traefik pour la communication entre nos workers
Problématique rencontrée :
Suite à la mise en place du reverse proxy TRAEFIK dans notre environnement de Dev afin d’assurer la communication entre nos Worker des problèmes ont vu le jour.
(Nous nous sommes inspirés de la configuration traefik présente sur votre GitLab.)
Il semblerait à l’heure actuel, que bien que la communication entre notre OIDC, GRIST et traefik soit opérationnel cette dernière n’est pas fonctionnelle, les cookies de session bien que renseigner ne sont pas fournit à GRIST et par ce biais empêche la connexion à ce dernier. Il semblerait que le reverse proxy Traefik supprime le contenu du cookie bien que nous ayons fournit des headers et configuration pour favoriser le maintien du contenu du cookie de session.
Nous n’avons pas non plus l’impression que l’interaction entre nos workers se fassent bien.
Auriez-vous des informations/documentations sur la mise en place de ce type d’environnement ?
Dans l’attente d’échanger avec vous sur ce sujet épineux.
Je me permets de mettre à jour directement ce ticket car je viens de me rendre compte que mon problème d’Authentification était lié au navigateur qui me forcer l’utilisation du HTTPS alors que ma config était en HTTP ce qui avait pour cause de rendre mon cookie de session vierge.
Cependant le problème de communication entre mon Home worker et mes Docs Workers persiste toujours. Il semblerait que la redirection vers le doc worker concerné lors de la création/ouverture des documents sur grist ne fonctionnent pas et retourne une erreur.
Je n’ai pas l’impression non plus que mon home worker et mes docs worker arrievnt à bien communiquer.
Cordialement
Bonjour !
Merci pour ces précisions sur le setup d’infra, c’est intéressant d’avoir des retours de mises en place différentes.
C’est sur quel repo Gitlab que tu as trouvé la configuration Traefik en exemple ? Il me semble qu’on l’avait utilisé il y a quelques temps pour un PoC mais on ne l’a jamais utilisé en production. Les mêmes concepts peuvent s’appliquer à un autre reverse proxy cependant.
Pour reprendre ce qu’il faut retrouver dans les flux, l’essentiel est le suivant :
- les requêtes entrantes avec le chemin /dw/<id> doivent aller sur le doc worker ayant cet ID
- toutes les autres requêtes entrantes doivent finir sur un home worker
- les home workers doivent pouvoir communiquer avec les doc workers via leur APP_DOC_URL ou APP_DOC_INTERNAL_URL . L’URL interne est préférée
Un problème que nous avions rencontré avec les requêtes entre home et doc worker échouant était que le doc worker refusait les requêtes avec le mauvais Host. Il détermine les Host valides à partir de APP_DOC_URL et APP_DOC_INTERNAL_URL.
Est-ce que tu as un exemple minimal pour reproduire le problème avec un docker compose par exemple ?
J’ai retrouvé cet exemple qu’on avait mis en place à un moment, d’un docker compose avec 3 doc workers + keycloak + minio + postgresql. Traefik est utilisé dans cet exemple pour gérer l’authentification via un header « X-Forward-Auth » et un middleware, mais Grist peut désormais gérer l’OIDC nativement donc le middleware n’est plus nécessaire. La configuration Traefik reflête bien le routage nécessaire cependant.
Bonjour,
Tous d’abord merci pour la prise en compte de ce sujet.
Je me suis inspiré de votre dépôt numérique-gouv/helmcharts, le même que tu viens de me montrer.
Pour être transparent, j’essaye de mettre en place cette disponibilité avec Traefik car M. Fayolle me l’avais communiquer et je souhaitais comprendre le fonctionnement avant de le mettre en place sous apache.
De ce que je comprends a ton message le reverse proxy n’est plus nécessaire pour que mon Home worker et mes Docs worker communique c’est bien cela ?
Nous sommes dans un environnement avec 1 docker compose avec 2 doc worker + OIDC arobas + minio + postgresql + redis
L’interaction entre Home et Doc se fait maintenant seulement par variable d’environnement ?
C’est ça, si les workers peuvent communiquer directement ils n’ont pas besoin de proxy. Il faut quand même un reverse proxy devant tout ça pour rediriger les flux des clients vers le home ou les docs.
Au démarrage, les doc workers s’inscrivent dans Redis avec leur URL. Au moment de l’ouverture d’un document, le home worker choisit un doc worker à partir de ceux qu’il trouve dans Redis. Il fait ensuite une première requête vers celui-ci via l’URL interne du doc worker, puis redirige le client vers l’URL publique du doc worker.
Pour le déploiement sur Kubernetes, les ID/URLs des workers sont définis dynamiquement, donc nous avons un second proxy qui permet de redonner des URLs distinctes à chacun, mais pour un setup fixe ce n’est pas nécessaire.
D’accord, le reverse proxy est donc quand même nécessaire en frontal pour la redirection. Afin de voir si j’ai bien compris dans le cas de votre configuration présente sur GitLab helmcharts est-ce que le routing de traefik est présent seulement pour la redirection frontal ou bien dans ce cas il est aussi utilisé pour la connexion entre les Workers ?
Effectivement, j’ai pu bien voir l’enregistrement de mes Docs Workers au sein de REDIS mais mon Home workers n’arrivent pas a les contacters.
Je suppose que c’est l’adresse internal qui est mal configurer je vais explorer cette pistes pour le moment.
Merci pour ton aide jusqu’à maintenant
Dans notre déploiement Helm, on a un premier proxy via l’ingress controller qui sépare les flux du client vers home worker et doc worker. Les flux client doc worker vont vers un second proxy qui peut gérer les workers dynamiquement.
On y a rajouté des règles spécifiques pour pouvoir identifier un worker qui n’existe plus et le révoquer par exemple. Ça se passe quand le home worker contacte le doc worker, via l’URL interne qui passe donc via le second proxy.
Tu peux voir la config de ce second proxy ici si ça t’intéresse. On manipule les IP des pods pour les utiliser comme IDs de doc worker, et il y a une page d’erreur spécifique renvoyée si le worker apparaît comme absent.
Dans un setup où les workers sont « statiques » ça ne me semble pas nécessaire. Si un worker est en panne j’imagine que tu vas surtout chercher à le redémarrer ou le débloquer au lieu de provisionner un nouveau worker avec une nouvelle URL.