Discussion :

[sekaijin]

Bonjour

J'ai un gros système fait de plus de dix conteneur karaf (OSGI)
dans chacun d'eux plusieurs dizaines de composants déployés. une grande partie de ces composants sont des routes apache camel.

pour résumer de façon extrême une route camel reçois des "messages" par un point d'entré, lui fait subir toutes sorte de traitement pour le transmettre via un point de sortie.

cela reste très vague car en effet cela recouvre tout type de point d'entrée ou de sortie et si un moyen de communication n'est pas fournis en standard par camel il est très simple de l'ajouter.

parmi tous ces points d'entrée j'en ai un nombre certain qui exposent un port TCP (socket) ou HTTPS. dans la solution actuelle rien de plus simple
from("https://0.0.0.0:61010/mysService") le port est ouvert, et le service accessible. il suffit donc qu'un bundle(jar) implémente un tel code pour ouvrir un port. vu la quantité de composant que je gère les urls ne sont pas en dur mais paramétrable. du coup un chagement de ce paramètre et mon service change de port https://0.0.0.0:61030/mysService mieux encore mina2:tcp://0.0.0.0:61001 et il change de protocole. et tout ça sans arrêter quoi que ce soit. il est vrais que le changement dynamique de port est rare mais l'ouverture et la fermeture de services (ports) est la vie de tous les jours.


Voila qu'on me demande de passer sous docker. mais je ne parviens pas à trouver quoi que ce soit sur docker qui autorise ça. c'est à dire redéfinir l'url d'un point d'entrée dynamiquement. tout ce que je vois se fait toujours à froid avant de lancer l'exécutable.

si cela est vraiment le cas c'est une énorme restriction.

Je me suis souvent entendu répondre que je devais ne mettre qu'un seul composant par image docker pour déployer indépendamment chaque micro services. mais du coup cela signifie que tous les composant qui communiquent entre eux dans OSGI (en mémoire) devront le faire de process à process.
mais aussi que chaque micro service va devoir être déployé avec ses dépendances et sa JVM ce qui revient à multiplier par quelques centaines la taille de ce qui est déployer. car là ou 150 à 200 composant se partagent la même JVM les mêmes jars je vais avoir 150 à 200 JVM avec quasiment les deux tiers des jars chacun.

Autant je comprend docker dans le cadre d'une applications au périmètre bien défini, autant j'ai du mal à voir comment il peut être utilisé dans le cas de systèmes qui sont eux même déjà des conteneurs.

Merci à vous je suis preneur de tous commentaire qui m'aiderait à y voir plus clair.

A+JYT

[Dymmm]

Bonjour,

Les ports ouvrant vers l’extérieur doivent être défini au lancement du conteneur. En revanche il n'est pas nécessaire de définir de port pour une communication sur un même réseau interne à docker. Du coup, exposer l’ensemble les ports via un reverse proxy ou un load balancer transférant aux instances traitant les données peu permettre de limiter le downtime de façon généralement acceptable. Exposer un service par load-balancer est viable aussi car ils sont très légers.

Le principe préconisant une image par composant est vivement recommandé. Rien d'obligatoire la dedans, mais généralement on y vient naturellement à un moment ou à un autre.
La somme des consommations de mémoire des images produites en suivant ce principe peut être élevée. Il faut voir si le ratio prix du Go de RAM / gain de temps est favorable à cette approche.

J'utilisais Karaf également il y a quelques années, mais j'ai fini par l'abandonner et scinder petit à petit les services en services indépendant Sprint boot et Go. J'y ai gagner en simplicité et productivité car n'étant pas un expert Java je galérai régulièrement avec la gestion des versions de Spring et le reste des libs.