Sécurité et communication des agents

Les agents utilisent les protocoles sécurisés SSL JMS, HTTP et HTTPS pour communiquer avec le serveur.

Présentation des agents

Les agents se chargent du déploiement effectif, ce qui libère le serveur de cette tâche. Les agents apportent une contribution important à l'extensibilité d'IBM® UrbanCode Deploy.

Alors qu'un agent est généralement perçu comme étant un seul processus, il est constitué techniquement d'un processus de traitement et d'un processus de surveillance. Le processus de traitement est un processus à unités d'exécution multiples qui effectue le travail de déploiement après avoir reçu des commandes du serveur. Les commandes de travail émanent des étapes de plug-in, lesquelles permettent une intégration à de nombreux outils tiers. Le contrôle est assuré par un service qui gère le processus de traitement : démarrage et arrêt, gestion des redémarrages, mises à niveau et sécurité, par exemple. Une fois un agent installé, il peut être géré depuis l'interface Web d'IBM UrbanCode Deploy.

Sécurité des agents

Tous les processus, y compris le conditionnement, la configuration et le déploiement, que le serveur IBM UrbanCode Deploy demande s'exécutent sur le matériel affecté aux agents. Pour plus de sécurité, les agents ne sont pas à l'écoute de ports mais ouvrent à la place une communication directe avec le serveur. Après le démarrage d'un agent installé, l'agent ouvre une connexion de socket vers le serveur IBM UrbanCode Deploy en fonction des informations d'installation. La majorité de la communication entre un serveur et des agents utilise un protocole JMS (Java™ Message Service). La communication peut être sécurisée avec SSL et l'authentification mutuelle par clé facultative pour chaque noeud final. Ce protocole de communication est sans état et résilient aux pannes réseau.

Les agents sur d'autres réseaux que celui où est situé le serveur peuvent avoir besoin d'ouvrir un pare-feu pour établir la connexion. Une fois la communication établie, l'agent est visible dans l'application Web IBM UrbanCode Deploy où vous pouvez le configurer. Les agents actifs, quel que soit le système d'exploitation, peuvent être mis à niveau via l'application Web.

Communication des agents

Le canal JMS est le canal de contrôle principal pour IBM UrbanCode Deploy. Les agents l'utilisent pour extraire des commandes du serveur. Toutefois, certaines activités d'agent accèdent au niveau Web via HTTP et HTTPS. Par exemple, la publication de journaux, la transmission de résultats de test ou la publication de fichiers dans CodeStation utilisent HTTP et HTTPS.

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.

Diagramme des ports que les agents, les relais d'agent et les serveurs utilisent pour communiquer ; il s'agit des ports répertoriés dans les listes ci-dessus

Pour plus d'informations sur la configuration du pare-feu et l'utilisation des ports, voir Configuration système requise et remarques sur les performances et Configuration de pare-feu et de la communication.

Le service de surveillance d'agent utilise JMS pour toutes les communications avec le serveur et pour l'envoi de commandes, telles que la commande run step au processus de traitement. Le processus de traitement utilise JMS pour les communications système, et des services HTTP REST lorsqu'il exécute des étapes de plug-in ou extrait des informations depuis le serveur.

La communication serveur-agent sans état procure des avantages significatifs en termes de performances, sécurité, disponibilité et reprise après incident. Etant donné que chaque demande d'agent est autonome, une transaction est constituée d'un message indépendant qui peut être synchronisé avec le stockage auxiliaire lorsqu'elle se produit. Un noeud final, un serveur ou un agent, peuvent être arrêtés et redémarrés sans répercussion, autre que le temps perdu. Si les communications échouent au milieu d'une transaction, aucun message n'est perdu. Une fois reconnectés, le serveur et l'agent déterminent automatiquement quels messages ont déjà circulé et quels travaux ont déjà abouti. Après une indisponibilité, le système synchronise les noeuds finaux et rétablit les processus affectés. Les résultats du travail qu'un agent effectue pendant l'indisponibilité sont communiqués au serveur.


Retour d'informations