Les topologies du système ci-dessous sont représentées avec des diagrammes. Pour des explications relatives aux composants du système, voir Description des systèmes.
Topologie de base
L'installation de base d'IBM UrbanCode Deploy comprend un serveur, des agents, et un serveur de licences. Les clients accèdent au serveur via les navigateurs Web, l'API REST, ou le client de ligne de commande. Des agents peuvent être installés dans des environnements cloud, dans des conteneurs de machines virtuelles ou sur des systèmes physiques ; ils apparaissent dans des systèmes cloud dans les diagrammes ci-après, mais peuvent être installés sur de nombreux systèmes différents.Dans cette topologie, le serveur peut créer des environnements dans des clouds qui utilisent des patterns de système virtuel, comme IBM Cloud Orchestrator et IBM PureApplication System. Pour plus d'informations sur les clouds pris en charge qui utilisent des patterns de système virtuel, voir Modélisation d'environnements pour les clouds qui utilisent des patterns de système virtuel. Pour créer des environnements dans d'autres clouds, tels que des clouds reposant sur OpenStack, Amazon Web Services, SoftLayer, VMware vCenter et Microsoft Azure, vous devez installer le serveur de conception de plans directeurs et au moins un moteur, comme décrit dans les topologies de conception de plans directeurs.
Pour installer les composants centraux, voir Installation d'IBM UrbanCode Deploy.
Topologies de conception de plans directeurs
Pour pouvoir utiliser des plans directeurs dans des clouds via OpenStack Heat, notamment dans des clouds reposant sur OpenStack, Amazon Web Services, SoftLayer, VMware vCenter et Microsoft Azure, vous devez appliquer une topologie incluant le serveur de conception de plans directeurs et un moteur. (Dans les versions précédentes, ces systèmes faisaient partie d'IBM UrbanCode Deploy with Patterns.)Le schéma suivant illustre une topologie simple qui inclut le serveur de conception de plans directeurs et un moteur.
Pour installer les composants centraux et Blueprint Designer, voir l'étape 10 de la procédure Installation d'IBM UrbanCode Deploy.
D'autres topologies sont également possibles. Par exemple, au lieu d'installer un moteur distinct, vous pouvez étendre un moteur Heat existant. Dans ce cas, la topologie est le diagramme suivant. Dans ce cas, le moteur Heat comprend des extensions pour travailler avec IBM UrbanCode Deploy. Si vous utilisez un cloud OpenStack, vous devez étendre le moteur Heat fourni avec le cloud.
Topologie à plusieurs régions
Si votre environnement comporte plusieurs zones de sécurité qui sont divisées par des pare-feux, vous pouvez utiliser des relais d'agent pour connecter des agents au serveur via les pare-feux. Par exemple, si votre serveur IBM UrbanCode Deploy se trouve dans un pare-feu mais que vos environnements cible sont hors du pare-feu, les agents dans ces environnements cible ne peuvent pas se connecter directement au serveur. Dans ce cas, vous installez un relais d'agent hors du pare-feu afin de permettre aux agents de se connecter au serveur via le pare-feu, conformément au diagramme ci-dessous.
Pour installer et configurer un relais d'agent, voir Installation de relais d'agent.
Topologies en cluster à haute disponibilité
Les topologies à haute disponibilité utilisent plusieurs serveurs. Ces serveurs peuvent tous être en cours d'exécution simultanément pour partager la charge (comme dans une topologie en cluster), ou ils peuvent attendre qu'un autre serveur s'arrête (comme dans une topologie de secours (cold standby)). Le schéma suivant illustre une topologie en cluster dans laquelle un équilibreur de charge répartit des connexions sur trois serveurs. Les utilisateurs se connectent directement à l'équilibreur de charge, qui les envoie à un serveur actif. Les agents se connectent via HTTP et HTTPS à l'équilibreur de charge ; cependant, les agents se connectent via JMS directement aux serveurs. Les serveurs stockent leurs fichiers sur une base de données et un système de fichiers partagés.
Pour configurer un cluster de serveurs, voir Configuration de clusters de serveurs.
Vous pouvez aussi mettre en cluster des serveurs de conception de plans directeurs et des moteurs. Dans ce cas, vous installez un ou plusieurs serveurs de conception de plans directeurs et un ou plusieurs moteurs et les définissez pour qu'ils puissent accéder à la même base de données et au même système de fichiers partagé. De même, un équilibreur de charge distribue le trafic aux serveurs de conception de plans directeurs et aux moteurs. Le diagramme ci-dessous représente une topologie en cluster composée de trois moteurs et de trois serveurs de conception de plans directeurs.
Pour configurer un cluster de serveurs de conception de plans directeurs et de moteurs, voir Configuration de clusters de serveurs de conception de plans directeurs et Configuration de clusters de moteurs.
Topologies de reprise après incident
L'un des façons de préparer la reprise après incident consiste à utiliser un système de serveur de secours (cold standby), qui comprend un serveur arrêté et une copie répliquée de la base de données et du système de fichiers. Le diagramme ci-dessous représente une topologie simple comprenant un serveur de secours (cold standby) et les ressources liées de secours.
Afin de configurer un système de secours (cold standby) pour le serveur, voir Ajout de serveurs de secours (cold standby).
Vous pouvez aussi configurer un système de reprise après incident pour le serveur de conception de plans directeurs et le moteur. Le diagramme ci-dessous représente une topologie de reprise après incident pour le serveur de conception de plans directeurs et le moteur Heat, où les serveurs de secours (cold standby) se trouvent dans un centre de données différent. Dans ce diagramme, les services et les systèmes partagés doivent être configurés pour la haute disponibilité.
Pour configurer la reprise après incident de Blueprint Designer, voir Configuration de la reprise après incident pour le serveur de conception de plans directeurs.
Ports par défaut
Le diagramme ci-dessous représente les numéros de port par défaut qu'IBM UrbanCode Deploy utilise pour la communication. La plupart de ces ports peut changer selon les choix que vous effectuez lors de l'installation. Le diagramme ci-dessous est un récapitulatif des valeurs par défaut.
Pour plus d'informations sur les ports, voir Configuration système requise et remarques sur les performances.
Description des systèmes
- Serveur IBM UrbanCode Deploy
- Le serveur IBM UrbanCode Deploy stocke les composants, les processus, et d'autres éléments avec lesquels vous modélisez les déploiements d'applications automatisés. Vous exécutez des déploiements automatisés à partir du serveur.
- Navigateurs Web
- Les navigateurs Web sont le principal moyen par lequel les utilisateurs interagissent avec le serveur et Blueprint Designer. L'interface graphique basée sur un navigateur d'IBM UrbanCode Deploy est une application Internet enrichie qui conserve la plupart de ses fonctionnalités dans le navigateur. Les clients interagissent avec des services RESTful (Representational State Transfer) sur le serveur comme nécessaire.
- Client de ligne de commande
- Le client de ligne de commande permet d'accéder au serveur via la ligne de commande. Il peut automatiser des fonctions sur le serveur, comme la création de composants et d'applications, et fournit la plupart des fonctionnalités qui existent dans l'interface utilisateur reposant sur le navigateur. Le client de ligne de commande recourt lui aussi à des services RESTful. Voir Référence pour le client de ligne de commande (CLI).
- API REST
- L'API REST fournit l'accès au serveur via HTTP. Comme le client de ligne de commande, il peut automatiser des fonctions sur le serveur, comme la création de composants et d'applications.
- Le serveur et le serveur de conception de plans directeurs ont des API REST distinctes. Chaque commande dans l'API REST de serveur a une commande équivalente dans le client de ligne de commande ; toutefois, les commandes dans l'API du serveur de conception de plans directeurs ne disposent pas d'équivalents en ligne de commande. Voir Extension des fonctionnalités du produit.
- Agents
- Les agents exécutent des processus sur des systèmes cibles. Les agents peuvent fonctionner sur des ordinateurs physiques, des systèmes virtuels, ou des systèmes cloud. Voir Agents.
- Relais d'agent
- Un relais d'agent est un proxy de communication pour les agents qui se trouvent derrière un pare-feu ou à un autre emplacement réseau. Voir Relais d'agent.
- Serveur de conception de plans directeurs
- Ce serveur héberge Blueprint Designer et contrôle l'accès aux plans directeurs, les fichiers qui décrivent la topologie de réseau pour les applications que vous mettez à disposition dans différents clouds. Il héberge également le service de reconnaissance de cloud qui fournit des informations sur les ressources de cloud à la disposition de Blueprint Designer. (Dans les versions précédentes, ce système était le serveur de conception IBM UrbanCode Deploy with Patterns.) Pour plus d'informations sur l'utilisation de Blueprint Designer, voir Modélisation d'environnements pour des clouds à l'aide d'OpenStack Heat.
- Moteur
- Le moteur Heat est une installation du moteur d'orchestration OpenStack Heat avec des extensions IBM. Il gère l'infrastructure de cloud en mettant à disposition des ressources depuis des clouds, en actualisant ces ressources, et en les supprimant. Si vous utilisez un moteur Heat livré avec IBM UrbanCode Deploy, les extensions sont fournies pour vous. Vous pouvez également étendre un moteur Heat existant en lui ajoutant des extensions. (Dans les versions précédentes, ce système était le moteur Heat d'IBM UrbanCode Deploy with Patterns.)
- Serveur de licences Rational Common Licensing
- Le serveur de licences fournit des licences au serveur. Pour plus d'informations sur le serveur de licences, voir IBM Rational Common Licensing.
- Service d'identité de Keystone
- Ce service fournit des jetons d'authentification au système OpenStack. Le serveur de conception de plans directeurs l'exige. Si vous ne disposez pas d'un serveur Keystone, vous pouvez utiliser celui qui est fourni avec le moteur Heat.
- Clouds
- Les clouds hébergent des ressources virtuelles. Lorsque vous créez des environnements avec des plans directeurs, le serveur ou le moteur met à disposition des ressources sur les clouds cibles. Pour des informations sur les clouds pris en charge, voir Intégration avec des systèmes cloud.
- CodeStation
- CodeStation stocke les versions de composant et les artefacts. Il fait partie du serveur IBM UrbanCode Deploy.