Impossible d'accéder au service REST déployé dans Docker Swarm sur AWS

Question

J'ai utilisé le modèle de formation cloud fourni par Docker pour la configuration et les prérequis AWS pour mettre en place un essaim Docker.

J'ai créé un service REST en utilisant Tibco BusinessWorks Container Edition et je l'ai déployé dans l'essaim en créant un service Docker.
docker service create --name aka-swarm-demo --publish 8087:8085 akamatibco/docker_swarm_demo:part1
Le service démarre avec succès mais les journaux CloudWatch montrent l'exception suivante :

J'ai essayé de passer la variable d'environnement JVM dans le Dockerfile comme ceci :
ENV JAVA_OPTS= "-Dbw.rest.docApi.port=7778"
mais cela ne fonctionne pas.

Le fait intéressant est qu'à la fin, le journal indique :
com.tibco.thor.frwk.Application - TIBCO-THOR-FRWK-300006: BW Application démarrée [SFDemo:1.0]
Alors j'ai essayé d'accéder à l'application en utilisant CURL -
curl -X GET --header 'Accept: application/json' 'URL du répartiteur de charge AWS : port que j'ai exposé lors de la création du service/URI de la ressource'
Mais je reçois le message suivant :

Le service REST fonctionne bien lorsque je lance docker run.
J'ai vérifié les groupes de sécurité du gestionnaire et du répartiteur de charge. Le répartiteur de charge a un trafic entrant ouvert à tous et pour le gestionnaire j'ai ouvert des connexions HTTP.

Je n'arrive pas à comprendre si j'ai manqué quelque chose. Est-ce que quelqu'un peut m'aider s'il vous plaît ?

Answer 1

Comme mentionné dans Déployer des services dans Swarm, si vous lisez le long, vous trouverez ce qui suit :

PUBLIER LES PORTS D'UN SERVICE DIRECTEMENT SUR LE NŒUD SWARM
Utiliser le maillage de routage peut ne pas être le bon choix pour votre application si vous avez besoin de prendre des décisions de routage basées sur l'état de l'application ou si vous avez besoin d'un contrôle total du processus pour router les demandes vers les tâches de votre service. Pour publier le port d'un service directement sur le nœud où il s'exécute, utilisez l'option mode=host pour le drapeau --publish.

Remarque : Si vous publiez les ports d'un service directement sur le nœud swarm en utilisant mode=host et que vous définissez également published= cela crée une limitation implicite selon laquelle vous ne pouvez exécuter qu'une seule tâche pour ce service sur un nœud swarm donné. De plus, si vous utilisez mode=host et que vous n'utilisez pas le drapeau --mode=global sur docker service create, il sera difficile de savoir quels nœuds exécutent le service afin de router le travail vers eux.

Publier des ports pour les services fonctionne différemment que pour les conteneurs réguliers. Le problème était ; l'image n'expose pas le port après l'exécution de service create --publish et donc la couche de routage du swarm ne peut pas accéder au service REST. Pour résoudre cela, utilisez mode = host.

J'ai donc utilisé la commande suivante pour créer un service :
docker service create --name mardi --publish mode=host,target=8085,published=8087 akamatibco/docker_swarm_demo:part1

Ce qui a finalement supprimé l'exception.

Assurez-vous également de configurer les paramètres du pare-feu de votre équilibreur de charge de manière à autoriser les communications via les protocoles désirés pour accéder à vos applications déployées à l'intérieur du conteneur.
Dans mon cas, il s'agissait du protocole HTTP, en activant le port 8087 sur l'équilibreur de charge qui a servi le but.