Pour améliorer les performances et réduire l'effort de maintenance, IBM UrbanCode Deploy peut utiliser des relais d'agent afin de communiquer avec les agents distants. Au lieu de se connecter directement au serveur de façon individuelle, les agents se connectent à des relais d'agent, qui se connectent à leur tour directement au serveur. L'utilisation de relais d'agent réduit la charge sur le serveur car celui-ci présente moins de connexions directes.
Les relais d'agent simplifient également la communication sur les réseaux et à travers les pare-feux. Si plusieurs agents se trouvent sur un réseau distant sans relais d'agent, chaque agent doit se connecter au serveur individuellement. Dans ce cas, chaque agent doit disposer du droit sur le réseau de se connecter au serveur, ainsi que des droits sur le pare-feu. Avec un relais d'agent, les agents se connectent au relais seulement, et le relais est le seul système qui prend contact avec le serveur directement, comme avec un réseau privé virtuel ou un tunnel.
Généralement, les relais d'agent sont pratiques lorsque les agents se trouvent sur des systèmes cloud, car ces derniers sont souvent séparés du serveur IBM UrbanCode Deploy par un pare-feu et requièrent un réseau privé virtuel ou un tunnel pour atteindre le serveur.
La figure ci-après est un diagramme simple de la communication entre des agents, un relais d'agent et le serveur, à travers un pare-feu. Les agents se connectent directement au relais d'agent, et le relais d'agent est le seul système qui se connecte au serveur à travers le pare-feu.
Le relais d'agent communique avec le serveur et les agents à l'aide de la même combinaison de protocoles de communication JMS, HTTP et HTTPS que les agents utilisent. S'il existe au moins une connexion de réseau étendu à bande passante faible entre le serveur et le relais d'agent, le serveur IBM UrbanCode Deploy peut envoyer du travail aux agents qui se trouvent à d'autres emplacements.
- 7918 pour les connexions JMS directes au serveur
- 8080 et 8443 pour les connexions HTTP et HTTPS au serveur
- 7916 pour les connexions JMS à partir d'agents
- 20080 pour les connexions proxy HTTP à partir d'agents
- 20081 pour les demandes relatives au cache des artefacts émanant d'agents
Le diagramme ci-dessous représente les ports par défaut principaux qui sont impliqués dans la communication entre les agents, les relais d'agent et le serveur.
Vous pouvez également mettre en cache des artefacts sur des relais d'agent afin d'améliorer les performances du système. Voir Mise en cache des artefacts sur les relais d'agent.
Exemple
Le simple déplacement d'artefact suivant illustre le mécanisme des communications distantes :
- Un agent distant démarre et établit une connexion au relais d'agent via JMS.
- Le relais d'agent signale au serveur IBM UrbanCode Deploy via JMS que l'agent distant est connecté.
- Le serveur envoie une commande de téléchargement d'artefact au relais via JMS, et le relais distribue le message à l'agent distant, également via JMS.
- Le serveur localise les artefacts. Si les artefacts ne se trouvent pas dans le cache CodeStation du relais, le serveur les envoie au relais via HTTP ou HTTPS.
- Le relais d'agent envoie les artefacts directement à l'agent sur la connexion HTTP ou HTTPS du relais de serveur.
- Une fois son travail terminé, l'agent distant en informe le serveur via la connexion JMS du relais d'agent.