Bonjour à tous,
J'étudie Docker en vue de le mettre en production au boulot. Il va y avoir des appli web, des services réseaux et le futur en ajoutera probablement.
Tout est bien, beau, propre sauf un point : la gestion des ports.
Chaque container possède son ou ses ports et j'ai beau avoir défini une règle de nommage et d'attribution je trouve ça olé olé encore plus pour des services dont la résolution de l'ip se fait par dns pour le reste du réseau.
Par exemple, mon serveur docker est sur l'ip 192.168.0.250.
J'ai 2 appli web déployé dans 2 container différent : glpi et akeneo
Glpi est accessible par le port 192.168.0.250:8080 --> 80 et Akeneo par le port 192.168.0.250:8081 --> 80. Pour GLPI pas de problème mais pour Akeneo je dois passer par un vhost apache du coups je renseigne comment le dns de mon réseau ?
Avant Docker il était simple de faire du vhost dynamique mais avec Docker et les ports je vois pas trop comment faire. Avez-vous une idée ou une piste ?
Merci d'avance.
# Traefik ?
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 3.
https://traefik.io/
[^] # Re: Traefik ?
Posté par Philippe M (site web personnel) . Évalué à 1. Dernière modification le 12 avril 2018 à 12:28.
J'ai commencé à regardé du côté du reverse proxy mais tout est basé sur le nom de domaine et un préfixe du coups c'est très orienté appli web (http) mais pour le cas d'une appli qui utilise pas le nom de domaine et qui n'utilise pas http, comment faire ?
Born to Kill EndUser !
# Docker fait du DNS
Posté par Michaël (site web personnel) . Évalué à 5. Dernière modification le 10 avril 2018 à 18:46.
Depuis quelques temps la stack docker implémente aussi un DNS sur son réseau interne.
Une architecture typique qui tire parti de ça consiste à avoir un reverse proxy global, commun à toutes tes applications, qui fait le routage entre les microservices. Il y a un exemple rikiki ici, qui consiste à déployer un trac et un jenkins dans le même environnement docker: https://github.com/michipili/cid.
Le fichier docker-copose te donne une idée de ce qui se passe il définit notamment deux services
trac
etjenkins
qui sont appelés par le haproxy.Si par exemple j'avais aussi un service qui nécessite d'être redimensionné je pourrais compter sur le DNS-Round-Robin implémenté par docker pour répartir la charge entre ces services, ou utiliser une autre stratégie de répartition de charge.
De façon plus réaliste dans ton cas, un fichier docker stack (staging, production) définirait plusieurs réseaux, comme:
Un service
loadbalancer
implémenté par exemple par haproxy ou nginx s'occupe de terminer SSL et rediriger les requêtes HTTP entrantes en fonction du Header host et de la “route“ (ou api endpoint) vers le service adéquat. Ces programmes supportent le changement à chaud de la configuration.On peut imaginer ensuite que glpi est une application web typique implémentée par plusieurs services comme
frontend
qui sert la partie statique (CSS, JS et autres ressources), unbackend
qui implémente l'API, éventuellement fractionné en plusieurs microservices. Tous ces services sont sur le réseau interface-layer et internal-layer-glpi. Enfin sur le réseau internal-layer-glpi on doit trouver tes bases de données, caches, etc. qui n'ont pas besoin d'être visibles depuis le point d'entrée.Donc tout ce dont tu as besoin comme entrée DNS c'est de résoudre tous tes noms (comme glpi.macompanie.net et akeneo.macompanie.net) vers l'höte docker.
Si ça te semble aller dans la bonne direction n'hésite pas à donner plus de détails sur ton environnement et à poser des questions!
PS: Pour la découverte de services, le consul de hashicorp était très populaire mais il me semble comprendre que la stack docker implémente une partie significative des fonctions du consul. Ce logiciel peut cependant t'intéresser.
# reponse bourin, mais qui peut s averer utile a terme
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
Coucou a tous :)
peut etre faudrait il regarder du cotes de kubernetes :)
si c est juste pour 2 services au boulot, mais si après 1 ans tu en as 15 ça peut valoir le coup
c est assez simple a prendre en main, c'est assez élégant, et en moins de 1 jour de lecture de la doc officiel tu arrive a faire qq chose de sympa et qui marche pour de vrai.
cela par exemple qui correspond a peu près a ton besoin avec des fonctionalités (gratuites) en bonus
https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/
[^] # Re: reponse bourin, mais qui peut s averer utile a terme
Posté par Michaël (site web personnel) . Évalué à 2.
Kubernetes est bien plus puissant – ce qui concrètement se traduit par beaucoup plus de choses paramétrisables – que la docker stack en revanche c'est plus ardu à prendre en main. Un point important à relever est que kubernetes devient peu à peu le standard de facto pour les infrastructures cloud qui “proposent du docker” (google compute, forcément, et AWS depuis peu).
Chouette, merci pour le lien!
[^] # Re: reponse bourin, mais qui peut s averer utile a terme
Posté par SauronDeMordor (site web personnel) . Évalué à 2.
de rien,
sinon il y a une version plus facile a prendre en main avec openshift origin
ca simplifie grandement la stack, et aussi des lien de prosélytismes pour le plaisir learn.openshift.com
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.