blog.bressure.net

En passant à Traefik pour router les flux vers mes conteneurs sans exposition de leur port d’écoute HTTP, je ne suis plus contraint par l’unicité du port d’exposition sur un même en noeud. Cela va me permettre de me débarrasser de ma VM de staging qui n’est utilisée que temporairement et en conséquence de libérer de la ressource pour la VM de production.

VM par environnement

L’utilisation d’une VM par environnement permet d’avoir une préproduction identique à la production du point de vue des services exposés. La partie amont constituée des reverse proxy TLS et de répartition doit être dupliquée afin d’isoler les environnements.

L’accès à l’environnement staging se fait par un VirtualHost dédié du reverse proxy TLS rôle joué par un apache et qui n’est pas accessible depuis l’extérieur. Les briques intermédiaires avant d’atteindre le service final sont spécifiques (ici un haproxy) afin d’isoler la préprod de la prod. Par ailleurs les nom de domaines sont égalements identiques entre production et staging afin de pouvoir tester toute la partie TLS sans avoir à adapter quoi que ce soit.

Traefik pour supprimer le port

La migration des VM vers des conteneurs il y a un an m’a permis d’économiser des ressources. J’ai plus de services en ligne et seulement 2 VM: une pour la production et une autre pour la préproduction (ou staging). Actuellement cette VM staging occupe des ressources dont j’aurais bien besoin car la VM de production est à bout de souffle au niveu mémoire et l’agrandir n’est plus possible. Il faut bien garder un peu de mémoire l’hôte qui me sert également de station de travail et en conséquence il faut faire la chasse au gaspillage de RAM. Or l’environnement de staging n’est pas utilisée en continue il devient superflue d’avoir une VM de staging de même taille que la production.

Mon objectif est de ne plus avoir de VM staging en déplaçant les conteneurs sur le docker d’infrastructure (hôte principal). Or sur l’hôte principale j’ai des conteneurs qui sont une extension de la production (comme mon serveur Gitlab) que je préfère faire tourner sur un docker natif local car ils traitent des données plus importantes que je veux mettre à l’abri d’une éventuelle corruption des applications (comme les blog) accessibles depuis internet de manière publique. Alors on voit sur le schéma précédent où la VM staging est identique à la prod (et d’infra), que dans le cas des conteneur sur l’infra, leurs jumeaux sur staging ne peuvent pas aller sur l’infra car cela va poser un problème au niveau des ports exposées sur l’hôte. Le schéma suivant l’illustre:

C’est là que Traefik va me permettre de m’affranchir des ports des services. Chaque service sera défini par un nom de domaine. L’aiguillage entre production et staging pour un nom de domaine donnée se fera depuis le reverse proxy TLS comme sur le premier schéma. Cet aiguillage par port sera réalisé une fois pour toute et il ne sera pas nécessaire d’y revenir lors de l’ajout d’un service. Le schéma suivant montre la situation intermédiaire qu’il faut atteindre:

On voir que pour mettre sur le docker d’infra les conteneurs de staging on n’a qu’a doubler 2 ports: 7070 et 88 en disons 7171 et 99.

Environnement staging par réseau dédié

Comme sur un même hôte docker on va avoir des applications en double : prod/infra et staging. Je les isole par environnement en autorisant les accès par le répartiteur/routeur dédié. En bout de chaîne c’est Traefik qui effectuera le routage sur le critère du nom de domaine et afin d’assurer l’isolation (car prod et staging partage les mêmes noms de domaine) je place ces conteneur dans des réseaux distincts comme illustré ci-contre:

Garder la production sur une VM permet de contraindre les applications publiquement accessibles dans une enveloppe mémoire/disque fini. Si on accepte de lever ce verrou on peut facilement déplacer les services de la VM de production sur l’hôte d’infra et ainsi supprimer toutes les VM !