Documentation de l'architecture de votre environnement
Il est recommandé de créer des diagrammes d'architecture pour vos applications. Ces diagrammes peuvent être utilisés dans le cadre du travail de conception initial, de la formation de nouveaux membres d'équipe ou de l'éducation de membres d'équipe nouveaux et existants. La mise à jour des diagrammes de ce type permet de gagner du temps lorsque des problèmes doivent être examinés rapidement.
En documentant l'architecture de votre application, vous vous assurez que votre équipe et vous-même comprenez parfaitement tous les composants qui la constituent.
Vous pouvez créer un diagramme d'architecture dans le cadre de la planification initiale de votre environnement ou une fois que votre environnement est opérationnel. Passez en revue les étapes suivantes pour documenter votre environnement. Les exemples fournis sont basés sur des applications réelles.
Etape 1: Comprendre votre application et votre architecture
Le traitement des incidents liés aux applications dans les clusters Red Hat OpenShift on IBM Cloud peut être compliqué, en particulier si le problème concerne un flux réseau qui s'étend sur différents clusters, composants, pods ou services. La documentation de votre architecture d'application peut aider votre équipe à bien comprendre tous les composants de votre configuration.
Pour une application avec un flux réseau simple, l'architecture peut être décrite dans le texte. Pour les scénarios plus complexes, un diagramme d'architecture détaillé est utile afin que les différentes équipes impliquées dans le traitement des incidents puissent comprendre le flux. Il est également important de vous assurer que la documentation de votre architecture reste à jour si votre configuration est modifiée.
Le traitement des incidents liés aux applications dans les clusters Red Hat OpenShift on IBM Cloud peut être difficile, en particulier si une ou plusieurs des conditions suivantes sont remplies.
- L'application n'est pas bien comprise ou n'est pas correctement journalisée.
- Le problème est intermittent ou ne se produit pas souvent.
- Le problème implique un flux de réseau qui s'étend sur différents clusters, composants, pods ou services.
Les exemples de diagrammes d'architecture suivants sont tirés de scénarios réels. Vous pouvez utiliser ces exemples comme guide lors de la création de vos propres diagrammes d'architecture.
Exemple 1: Application de base s'exécutant dans un cluster OpenShift unique
Dans cet exemple, l'ensemble de l'application s'exécute dans un cluster OpenShift unique. Il s'agit d'une application simple dans laquelle un pod client unique envoie une demande à un service en cluster, qui se connecte ensuite à une instance etcd gérée par trois pods.
Client Application Service Etcd Instance
|------> [Etcd Pod 1]
|---> [Application Pod 1] ---|
| |
[Client pod] ---| |------> [Etcd Pod 2]
| |
|---> [Application Pod 2] ---|
|------> [Etcd Pod 3]
Exemple 2: Architecture multicluster avec un équilibreur de charge global et un service Cloudant
Dans le diagramme suivant, la connexion est initiée par l'un des trois pods client d'un cluster dans la région eu-de. Les pods client se connectent à un équilibreur de charge global (GLB) qui équilibre ensuite la charge de la
connexion à l'un des deux équilibreurs de charge d'application VPC publics (ALB) dans eu-de et eu-gb.
Chacun de ces ALB VPC fait partie d'un cluster distinct dans sa région. Ces équilibreurs de charge d'application acheminent le trafic vers les pods de routeur OpenShift, qui acheminent ensuite ce trafic vers les pods de back end du cluster. Ces pods de back end se connectent à une base de données Cloudant pour traiter la demande.
Notez que certaines de ces connexions se trouvent sur le réseau public. Certains sont sur un réseau privé dans le même VPC et d'autres utilisent le réseau privé dans IBM Cloud entre des composants dans un VPC et un service dans IBM Cloud.
Exemple 3: Un client VSI contactant un équilibreur de charge de réseau VPC avec un système de back end de service externe
Dans l'exemple suivant, le client est une instance de serveur virtuel classique dans IBM Cloud. La VSI se connecte via le réseau privé à un équilibreur de charge de réseau VPC privé (NLB) créé pour un cluster VPC. Cet équilibreur de charge de réseau équilibre le trafic vers l'un des trois noeuds worker VPC via le NodePort pour le service d'équilibreur de charge de cluster. Le service d'équilibreur de charge de cluster envoie ensuite le trafic à l'un des pods d'application qui se connectent à un service de cloud externe en dehors de IBM Cloud sur le réseau public.
Etape 2: Choisissez un outil
Vous pouvez utiliser l'un des outils suivants pour créer votre diagramme d'architecture.
De nombreux outils de création de diagrammes sont disponibles. Choisissez l'outil qui vous convient le mieux.
Étape 3 : Créer le schéma
Vous pouvez utiliser l'un des exemples mentionnés précédemment comme référence ou créer un diagramme à partir de zéro.
Pour plus d'informations sur les architectures de référence, voir IBM Architectures.