Unité 8.3 : Laboratoire de synthèse - Construire le cœur d'entreprise de bout en bout

Introduction

Chaque module précédent a construit une composante de l'environnement de FinCorp de manière isolée et a volontairement maintenu cette construction au minimum. Cette unité est le lieu où les composants deviennent un système. Vous allez mettre en place le cœur de production dans un seul centre de données virtuel : la topologie à trois niveaux du Module 3, les équilibreurs de charge publics de couche 7 et privés de couche 4, le cluster PostgreSQL et le cache In-Memory DB sur le niveau de données privé du Module 5, un cluster Managed Kubernetes du Module 6, ainsi que les passerelles VPN hybride et NAT qui assurent la bascule.

Le projet de synthèse ne réenseigne pas chaque construction ; il fait référence à l'unité qui l'a réalisée. Ce qu'il ajoute est ce qu'aucune unité isolée ne pouvait montrer : l'ordre d'assemblage et les dépendances entre les ressources. L'échec récurrent lorsque ces constructions convergent n'est pas une valeur de champ incorrecte, mais une séquence erronée, un équilibreur de charge créé avant l'existence de ses cibles, une passerelle créée avant la réservation de son IP publique, une base de données à laquelle on attribue une adresse qui entre en conflit avec le DHCP. Si l'ordre est correct, l'architecture de l'Unité 8.2 devient réalité.

1. L'ordre de construction est un graphe de dépendances, pas une liste de contrôle

La décision la plus déterminante dans une construction intégrée est la séquence. Plusieurs ressources IONOS CLOUD ne peuvent pas être créées, ou ne peuvent pas fonctionner, tant qu'une autre ressource n'existe pas d'abord, et la plateforme ne réordonne pas toujours le travail à votre place. Traitez la construction comme un graphe de dépendances et résolvez-le de bas en haut.

Quatre règles d'ordre concentrent la majeure partie du risque, et chacune a été établie dans une unité antérieure :

• Réservez d'abord les IP publiques. Un ALB public a besoin d'au moins une IP d'écoute, le VPN Gateway et le NAT Gateway sélectionnent chacun des adresses réservées, et l'IP d'entrée d'un ingress Kubernetes LoadBalancer doit être réservée afin que la suppression d'un Service ne la libère pas. L'IPv4 réservé est lié à une région, il faut donc le réserver dans la région du VDC. C'est la règle derrière les erreurs courantes des unités 3.1, 3.3 et 3.6.
• Le VDC et ses LAN précèdent tout le reste. La topologie à trois LAN de l'unité 3.1 constitue le substrat. Les serveurs, bases de données, équilibreurs de charge et passerelles sont tous rattachés à des LAN qui doivent déjà exister, avec des adresses réservées afin que les services gérés et les passerelles disposent d'une marge (la plage de .2 à .9 est laissée libre, la couche de données est sur une adresse statique stable).
• Un équilibreur de charge a besoin de ses cibles d'abord. Le NLB de couche 4 privé de l'unité 3.4 répartit le trafic vers les serveurs de la couche de données qui doivent déjà être provisionnés sur leur LAN privé ; un NLB pointé vers des cibles qui n'existent pas n'a rien à acheminer. La même logique s'applique aux cibles d'application derrière l'ALB de couche 7.
• Le réseau hybride précède les charges de travail qui en dépendent. Le NAT Gateway doit exister et la route par défaut du LAN doit pointer vers lui avant que les charges de travail privées puissent accéder à Internet pour l'installation de paquets ou les appels API sortants ; la modification du routage est l'étape que les équipes oublient.

Ces règles produisent un ordre naturel : le substrat réseau, puis le calcul, puis la couche de données, puis les équilibreurs de charge qui la frontent, puis la plateforme de conteneurs, puis le bord hybride. Le tutoriel ci-dessous suit exactement cet ordre.

2. L'architecture intégrée que FinCorp est en train de construire

L'objectif est la forme en couches canonique de l'Unité 1.2, désormais remplie avec les produits spécifiques choisis tout au long du cours. Le tableau suivant associe chaque niveau à son produit, à l'unité qui l'a construit et à la décision de conception derrière le choix, afin que la présentation puisse y faire référence plutôt que de la répéter.

Tout cela se trouve dans un seul VDC, dans une seule région choisie dans l'Unité 1.4 pour satisfaire au RGPD et à la résidence BSI. Le niveau de données ne touche jamais un LAN public ; les seules surfaces exposées à Internet sont le ALB public et les adresses IP réservées des deux passerelles.

Déroulement de la mise en œuvre de DCD

Vous allez assembler le cœur FinCorp complet dans le VDC créé dans l'Unité 2.1, en reliant les constructions des Modules 3, 5 et 6 dans l'ordre des dépendances. Plutôt que de redécrire chaque champ, chaque étape indique l'unité qui documente la construction détaillée et ne précise que ce que l'intégration ajoute : ce qui doit déjà exister, où il s'attache, et la décision unique qui le lie à ses voisins. Considérez les déroulements par unité comme la référence au niveau des champs et celui-ci comme la séquence d'assemblage.

Objectif de construction : Construire le cœur d'entreprise FinCorp de bout en bout dans Data Center Designer, en reliant les déroulements des modules.

Prérequis : Le VDC FinCorp de l'Unité 2.1 avec sa région fixée ; les privilèges Reserve IP Blocks et Create Kubernetes Clusters ; un certificat PEM importé (une seule feuille RSA et une clé correspondante) dans Certificate Manager pour l'écouteur HTTPS de l'ALB ; et les détails de connexion pour le pair IKEv2 du centre de données d'entreprise.

Étapes (dans Data Center Designer) :

1. Réserver les IP publiques (à faire en premier). Dans Menu > Network Services > IP Management, réservez des adresses IPv4 publiques dans la région du VDC pour : l'écouteur ALB public, la VPN Gateway, la NAT Gateway et le point d'entrée d'ingress Kubernetes. Vous recevez des adresses depuis le pool plutôt que de les choisir, et chacune est liée à une région. Cette étape unique préalable élimine l'échec d'ordonnancement le plus courant entre les Unités 3.1, 3.3 et 3.6.

2. Construire la topologie à trois LAN (comme dans l'Unité 3.1). Dans le VDC FinCorp, créez le LAN public d'extrémité (le seul LAN attaché à Internet Access), le LAN privé d'application et le LAN privé de données. Conservez chaque sous-réseau par défaut /24, laissez les adresses .2 à .9 libres pour les services gérés et les passerelles, et ne connectez aucun LAN privé à Internet. Cette segmentation est ce qui permet aux équilibreurs gérés et à la base de données de rester sécurisés sans NSG.

3. Provisionner les serveurs de la couche application (comme dans l'Unité 4.1). Placez les serveurs d'application sans état sur le LAN privé d'application en tant que serveurs Dedicated Core. Dedicated Core est le choix délibéré pour une garantie de performance prévisible sous charge ; la couche est maintenue sans état afin que les données de session résident dans le cache, et non sur le serveur, et afin que VM Auto Scaling puisse ajouter et supprimer des répliques librement (Unité 4.3).

4. Provisionner les serveurs ou points d'accès de la couche de données sur le LAN privé de données. L'équilibreur de couche 4 de l'étape 7 a besoin de cibles qui existent déjà, donc les cibles de la couche de données doivent être présentes avant la création du NLB. Attribuez aux interfaces réseau de la couche de données des adresses statiques stables hors de la plage DHCP.

5. Construire le cluster PostgreSQL (comme dans l'Unité 5.3). Sous Menu > Databases > PostgreSQL, créez un cluster multi-nœuds sur le LAN privé de données. Pour le grand livre de FinCorp, sélectionnez la réplication Strictly Synchronous avec trois instances ou plus, définissez une fenêtre de maintenance réelle en dehors des heures de pointe, et attribuez une IP privée se terminant entre .3 et .10 afin qu'elle ne entre jamais en collision avec le DHCP. Il n'y a ni point d'accès public ni réplique en lecture ; cette lacune est comblée à l'étape suivante.

6. Construire le cache In-Memory DB (comme dans l'Unité 5.5). Sous Menu > Databases > In-Memory DB, créez le cache sur le même LAN privé de données avec une seule connexion privée. C'est la moitié de mise à l'échelle en lecture du schéma sans réplique de lecture et le magasin d'état externalisé qui rend la couche application sûre pour la mise à l'échelle automatique. Dimensionnez-le par RAM selon le jeu de travail ; capturez les identifiants à la création car ils ne peuvent pas être modifiés ultérieurement.

7. Construire le NLB privé de couche 4 devant la couche de données (comme dans l'Unité 3.4). Placez un Network Load Balancer avec ses deux interfaces sur des LAN privés : l'écouteur sur le LAN d'application, l'arrière-plan sur le LAN de données. Ajoutez les serveurs de la couche de données, maintenant existants, en tant que cibles avec une règle de transfert TCP et une vérification d'intégrité TCP. Le NLB ne termine pas TLS, donc le certificat reste sur l'arrière-plan ; c'est l'extrémité privée du chemin en couches.

8. Construire l'ALB public de couche 7 à l'extrémité (comme dans l'Unité 3.3). Créez d'abord le groupe de cibles de serveurs d'application, puis placez un Application Load Balancer avec son interface nord sur Internet Access et son interface sud sur le LAN d'application. Configurez l'écouteur HTTPS sur l'IP publique réservée de l'étape 1 avec le certificat PEM importé, ajoutez une règle de transfert basée sur le chemin pointant vers le groupe de cibles, et placez les règles spécifiques au-dessus de la règle par défaut. L'ALB termine TLS et donne sa moitié d'extrémité à la substitution de passerelle API ; il n'a ni liste d'autorisation ni NSG, donc le filtrage reste sur les interfaces réseau des cibles.

9. Construire le cluster Managed Kubernetes (comme dans l'Unité 6.2). Sous Menu > Containers > Managed Kubernetes, créez un cluster public avec un plan de contrôle adossé à Francfort pour garder les données du plan de contrôle en Allemagne, puis ajoutez un pool de nœuds Dedicated Core. Attachez le LAN du pool de nœuds du cluster au sein du même VDC. Réservez l'IP d'ingress de l'étape 1, déployez un contrôleur d'ingress intra-cluster exposé en tant que Service LoadBalancer unique épinglé à cette IP, et rappelez-vous qu'un Service LoadBalancer est une IP statique à nœud unique, et non un équilibreur géré ; la vraie couche 7 devant le cluster est l'ALB de l'étape 8.

10. Construire la NAT Gateway pour l'émission privée (comme dans l'Unité 3.6). Ajoutez une NAT Gateway, connectez-la au LAN privé d'application, attribuez-lui une IP publique réservée de l'étape 1, et créez une règle SNAT pour le sous-réseau d'application. Ensuite, définissez la route par défaut du LAN privé (0.0.0.0/0) vers la passerelle ; sans ce changement de routage, l'émission ne se produit jamais silencieusement. La NAT est uniquement SNAT, donc elle ne fournit aucun chemin entrant. Ajoutez une règle SNAT UDP afin que le DNS se résolve toujours pour les VM utilisant la route par défaut NAT.

11. Construire la VPN Gateway et le tunnel vers le centre de données d'entreprise (comme dans l'Unité 3.6). Créez une VPN Gateway IKEv2 sur son IP publique réservée, attachez-la au LAN privé avec une adresse de passerelle dans la plage .2 à .9, puis créez un tunnel vers le pair d'entreprise avec une PSK robuste et des paramètres de phase 1 et de phase 2 correspondants. Listez les CIDR du réseau cloud et du pair comme contrat de routage statique ; il n'y a pas de BGP. Sélectionnez la variante de niveau Haute Disponibilité afin que la paire actif-passif partage l'IP de passerelle unique.

12. Provisionner et valider l'ensemble du VDC. Provisionnez les modifications accumulées. Validez le chemin en couches de bout en bout : un client atteint l'ALB sur son IP publique via HTTPS, la couche application lit à travers le cache et bascule sur PostgreSQL en cas de manqué, le NLB distribue les connexions chiffrées vers la couche de données, les charges de travail privées atteignent Internet uniquement via la NAT Gateway, et le centre de données d'entreprise atteint les LAN privés uniquement à travers le tunnel VPN. La couche de données est inaccessible depuis n'importe quel endroit public.

Erreurs courantes :

• Construire un consommateur avant que son IP réservée n'existe. L'écouteur ALB, les deux passerelles et l'ingress Kubernetes attendent tous une adresse réservée ; réservez-les tous à l'étape 1, dans la région correcte, avant que quoi que ce soit n'en consomme une.
• Créer le NLB avant que les cibles de la couche de données n'existent. Un équilibreur pointé vers des cibles absentes ne route nulle part ; provisionnez la couche de données (étape 4) avant le NLB (étape 7).
• Pointer la NAT Gateway vers la mauvaise chose, ou oublier la route par défaut. La NAT est uniquement SNAT sans chemin entrant, et la passerelle ne fait rien tant que la route par défaut du LAN privé n'est pas redirigée vers elle. Ajoutez aussi la règle SNAT UDP, sinon le DNS se rompt pour ces VM.
• Traiter le Service LoadBalancer Kubernetes comme la vraie porte d'entrée du cluster. C'est une IP statique à nœud unique limitée par le débit de ce nœud ; l'entrée de couche 7 en production est l'ALB provisionné séparément, avec le contrôleur d'ingress intra-cluster derrière lui.
• Placer le plan de contrôle Kubernetes dans un centre de données américain pour cette charge de travail réglementée. Choisissez le plan de contrôle de Francfort afin que les données du plan de contrôle restent en Allemagne ; les données du pool de nœuds restent dans la région choisie, quelle qu'elle soit.
• Connecter un LAN privé à Internet « pour tester », ou essayer d'entourer un ALB ou un NLB géré par un Network Security Group. Les équilibreurs gérés n'ont pas de NSG ; la sécurité de la couche de données provient entièrement du fait qu'elle réside sur un LAN privé, donc une seule connexion Internet sur le LAN de données démantèle l'argument de conformité.
• Attribuer au cluster PostgreSQL ou au cache une adresse dans la plage DHCP. Réutilisez les trois premiers octets du LAN et choisissez une adresse que le DHCP n'attribue jamais (se terminant par .3 à .10) ; une collision produit des échecs de connexion intermittents et difficiles à diagnostiquer.
• Faire correspondre les paramètres de phase 1 ou de phase 2 du VPN entre la passerelle IONOS CLOUD et le pair d'entreprise, ou chercher une option IKEv1. Il n'y a pas d'IKEv1 ; les paramètres doivent correspondre exactement aux deux extrémités, sinon le tunnel ne s'établit jamais, et la paire HA présente une IP partagée unique au pair.

Résumé

Le noyau de FinCorp est désormais un VDC unique qui met en œuvre l'architecture en couches de l'Unité 1.2 : un ALB public de couche 7 qui met fin à TLS à la périphérie, une couche applicative Dedicated Core sans état, un NLB privé de couche 4, et une couche de données strictement privée composée d'un cluster PostgreSQL strictement synchrone précédé d'un cache In-Memory DB, avec un cluster Managed Kubernetes et les passerelles VPN et NAT hybrides attachées. La leçon du projet de synthèse ne réside dans aucune valeur de champ isolée ; celles-ci ont été établies lors des constructions par module. Elle est qu'un environnement intégré est un graphe de dépendances, et que la construction de bas en haut (IP, puis LAN, puis calcul, puis données, puis équilibreurs de charge, puis conteneurs, puis la périphérie hybride) est ce qui transforme un ensemble de constructions individuelles correctes en une architecture de production cohérente et conforme.

Points clés :

• L'ordre de construction est un graphe de dépendances : réserver d'abord les IP publiques, créer les LAN avant que quoi que ce soit ne soit attaché, provisionner les cibles avant l'équilibreur de charge qui les sert, et rediriger la route par défaut avant d'attendre une sortie NAT.
• La couche de données ne touche jamais un LAN public ; la segmentation, et non un NSG, est ce qui protège les équilibreurs de charge gérés et la base de données, car les équilibreurs de charge gérés n'ont pas de NSG.
• Le cluster PostgreSQL n'a pas de réplique de lecture ; le cache In-Memory DB est le substitut pour la mise à l'échelle de lecture et l'état externalisé qui permet à la couche applicative de mettre à l'échelle et de basculer en toute sécurité.
• Le Service LoadBalancer du cluster Kubernetes est une IP statique sur un nœud unique, et non le point d'entrée de production ; l'ALB public plus un contrôleur d'admission intra-cluster est la véritable porte d'entrée de couche 7, et un plan de contrôle à Francfort conserve les données du plan de contrôle en Allemagne.
• Le projet de synthèse fait référence à chaque unité par module au lieu de la répéter : les laboratoires par module épurés existent afin que ce laboratoire d'intégration puisse porter la synthèse.

Lectures complémentaires

• Unité 8.2 : L'architecture d'entreprise de référence (la conception réalisée par ce laboratoire)
• Unités 3.1, 3.3, 3.4, 3.6 : les architectures de réseau et d'équilibrage de charge assemblées ici
• Unités 5.3, 5.5 : le cluster relationnel et le cache sur la couche de données privée
• Unité 6.2 : le déploiement du cluster Managed Kubernetes public
• Unité 7.1 : la mise en place de la résilience et de la bascule sur ce noyau