Unité 8.3 : Laboratoire de projet - Construire le noyau d'entreprise de bout en bout

Introduction

Chaque module précédent a construit une pièce de l'environnement de FinCorp en isolation et a maintenu cette construction délibérément légère. Cette unité est où les pièces deviennent un système. Vous allez mettre en place le noyau de production dans un seul centre de données virtuel : la topologie à trois niveaux du Module 3, les équilibreurs de charge publics de la couche 7 et privés de la couche 4, les PostgreSQL Cluster et le cache In-Memory DB sur la couche de données privée du Module 5, un Managed Kubernetes Cluster du Module 6, et les passerelles hybrides VPN et NAT qui assurent la bascule.

Le capstone ne répète pas chaque construction ; il fait référence à l'unité qui l'a fait. Ce qu'il ajoute, c'est la chose que aucune unité ne pouvait montrer : l'ordre d'assemblage et les dépendances entre les ressources. L'échec récurrent lors de la rencontre de ces constructions n'est pas une valeur de champ incorrecte, c'est une séquence incorrecte, un équilibreur de charge créé avant que ses cibles n'existent, une passerelle créée avant que son IP public ne soit réservé, une base de données à laquelle une adresse est attribuée qui entre en collision avec DHCP. Obtenir l'ordre correct et l'architecture de l'Unité 8.2 devient réelle.

1. L'ordre de construction est un graphique de dépendances, et non une liste de tâches

La décision la plus conséquente dans une construction intégrée est la séquence. Plusieurs ressources IONOS ne peuvent pas être créées, ou ne peuvent pas fonctionner, jusqu'à ce que quelque chose d'autre existe déjà, et la plateforme ne réorganise pas toujours les tâches pour vous. Traitez la construction comme un graphique de dépendances et résolvez-le de bas en haut.

Quatre règles d'ordre comportent la plupart des risques, et chacune a été établie dans une unité antérieure :

• Réservez les adresses IP publiques en premier. Un équilibreur de charge public ALB a besoin d'au moins un écouteur IP, le VPN Gateway et le NAT Gateway sélectionnent chacun parmi les adresses réservées, et un Kubernetes LoadBalancer entrée IP doit être réservé pour éviter que la suppression d'un service ne le libère. L'adresse IPv4 réservée est liée à la région, donc réservez-la dans la région du VDC. C'est la règle derrière les erreurs courantes dans les unités 3.1, 3.3 et 3.6.
• Le VDC et ses LANs précèdent tout le reste. La topologie à trois LAN de l'unité 3.1 est le substrat. Les serveurs, les bases de données, les équilibreurs de charge et les passerelles s'attachent tous à des LANs qui doivent déjà exister, avec des adresses réservées pour que les services gérés et les passerelles aient de la place (la plage .2 à .9 est gardée vide, le niveau des données sur une adresse statique stable).
• Un équilibreur de charge a besoin de ses cibles en premier. L'équilibreur de charge NLB de couche 4 privé de l'unité 3.4 distribue aux serveurs du niveau des données qui doivent déjà être provisionnés sur leur LAN privé ; un NLB pointant vers des cibles qui n'existent pas n'a rien à router. La même chose 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. La passerelle NAT Gateway doit exister et la route par défaut LAN doit pointer vers elle avant que les charges de travail privées puissent atteindre Internet pour l'installation de packages ou les appels API sortants ; le changement de routage est l'étape que les équipes oublient.

Ces règles produisent un ordre naturel : substrat réseau, puis calcul, puis niveau des données, puis les équilibreurs de charge qui le font face, puis la plateforme de conteneurs, puis le bord hybride. La démonstration ci-dessous suit exactement cet ordre.

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

La cible est la forme canonique en couches de l'Unité 1.2, maintenant peuplée des produits spécifiques choisis tout au long du cours. Le tableau suivant mappe chaque niveau à son produit, à l'unité qui l'a construit et à la décision de conception derrière le choix, de sorte que la présentation puisse référencer plutôt que répéter.

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

DCD Marche à suivre pour la mise en œuvre

Vous allez assembler le noyau complet de FinCorp dans le centre de données virtuel créé à l'unité 2.1, en assemblant les constructions des modules 3, 5 et 6 dans l'ordre des dépendances. Plutôt que de répéter chaque champ, chaque étape nomme l'unité qui documente la construction détaillée et indique uniquement ce que l'intégration ajoute : ce qui doit déjà exister, où il s'attache et la décision qui le relie à ses voisins. Traitez les marches à suivre par unité comme référence au niveau des champs et celle-ci comme séquence d'assemblage.

Objectif de construction : Construire le noyau d'entreprise FinCorp de bout en bout dans le Data Center Designer, en reliant les marches à suivre des modules.

Prérequis : Le centre de données virtuel 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é (feuille RSA unique plus clé correspondante) dans le Certificate Manager pour l'écouteur HTTPS de l'ALB ; et les détails de connexion du centre de données d'entreprise pour le pair IKEv2.

Étapes (dans le Data Center Designer) :

1. Réserver les adresses IP publiques (faites-le en premier). Dans Menu > Services réseau > Gestion IP, réservez des adresses IP publiques IPv4 dans la région du centre de données virtuel pour : l'écouteur ALB public, le VPN Gateway, la passerelle NAT et le point d'entrée d'ingress Kubernetes. Vous recevez des adresses à partir du pool plutôt que de les choisir, et chacune est liée à la région. Cette étape unique en amont supprime la défaillance d'ordre la plus courante à travers les unités 3.1, 3.3 et 3.6.

2. Construire la topologie à trois LAN (comme construit à l'unité 3.1). Dans le centre de données virtuel FinCorp, créez le bord public LAN (le seul LAN attaché à l'accès à Internet), le LAN d'application privé et le LAN de données privé. Gardez chaque défaut /24, laissez .2 à .9 clair 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 en sécurité sans NSG.

3. Provisionner les serveurs de niveau application (comme construit à l'unité 4.1). Placez les serveurs d'application sans état sur le LAN d'application privé en tant que serveurs Dedicated Core. Dedicated Core est le choix délibéré pour une garantie de performances prévisibles sous charge ; le niveau est maintenu sans état afin que les données de session vivent dans le cache, et non sur le serveur, et ainsi VM Auto Scaling peut ajouter et supprimer des répliques librement (unité 4.3).

4. Provisionner les serveurs ou les points de terminaison de niveau données sur le LAN de données privé. L'équilibreur de couche 4 de l'étape 7 nécessite des cibles qui existent déjà, donc les cibles de niveau données doivent être présentes avant que l'NLB ne soit créé. Donnez aux cartes réseau de niveau données des adresses statiques stables en dehors de la plage DHCP.

5. Construire le PostgreSQL Cluster (comme construit à l'unité 5.3). Sous Menu > Bases de données > PostgreSQL, créez une base de données Cluster multi-Node sur le LAN de données privé. Pour le livre de FinCorp, sélectionnez la réplication Strictement Synchronisée avec trois instances ou plus, définissez une fenêtre de maintenance réelle en dehors des heures de pointe, et attribuez une adresse IP privée se terminant entre .3 et .10 afin qu'elle ne collide jamais avec DHCP. Il n'y a pas de point de terminaison public et pas de réplique de lecture ; cet espace est comblé à l'étape suivante.

6. Construire le cache In-Memory DB (comme construit à l'unité 5.5). Sous Menu > Bases de données > In-Memory DB, créez le cache sur le même LAN de données privé avec une connexion privée unique. Ceci est la moitié de mise à l'échelle de la lecture du modèle sans réplique de lecture et le magasin d'état externalisé qui rend le niveau application sûr pour l'autoscaling. Dimensionnez-le par RAM à l'ensemble de travail ; capturez les informations d'identification à la création car elles ne peuvent pas être modifiées plus tard.

7. Construire l'équilibreur de charge de couche 4 privé devant le niveau données (comme construit à l'unité 3.4). Placez un équilibreur de charge réseau avec les deux interfaces sur des réseaux LAN privés : l'écouteur sur le LAN d'application, le backend sur le LAN de données. Ajoutez les serveurs de niveau données existants comme cibles avec une règle de transfert TCP et une vérification de santé TCP. L'NLB ne termine pas TLS, donc le certificat reste sur le backend ; ceci est la fin privée du chemin couché.

8. Construire l'équilibreur de charge de couche 7 public ALB à la limite (comme construit à l'unité 3.3). Créez d'abord le groupe cible de serveurs d'application, puis placez un équilibreur d'application avec son interface nord sur l'accès à Internet et son interface sud sur le LAN d'application. Configurez l'écouteur HTTPS sur l'adresse 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 cible, et ordonnez des règles spécifiques au-dessus de la règle par défaut. L'ALB termine TLS et donne la substitution de passerelle API sa moitié de limite ; il n'a pas de liste d'autorisation ou de NSG, donc le filtrage reste sur les cartes réseau cibles.

9. Construire le Managed Kubernetes Cluster (comme construit à l'unité 6.2). Sous Menu > Conteneurs > Managed Kubernetes, créez un Cluster public avec un plan de contrôle à Francfort pour garder les données de plan de contrôle en Allemagne, puis ajoutez un pool de Node Dedicated Core. Attachez le LAN du pool de Node du Cluster à l'intérieur du même centre de données virtuel. Réservez l'adresse d'entrée IP de l'étape 1, déployez un contrôleur d'entrée dans le Cluster exposé comme un service LoadBalancer unique fixé à cette adresse IP, et rappelez-vous qu'un service LoadBalancer est une adresse IP statique unique-Node, et non un équilibreur géré ; la véritable couche 7 devant le Cluster est l'ALB de l'étape 8.

10. Construire la passerelle NAT pour la sortie privée (comme construit à l'unité 3.6). Ajoutez une passerelle NAT, connectez-la au LAN d'application privé, attribuez-lui une adresse 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 (0.0.0.0/0) du LAN privé sur la passerelle ; sans ce changement de routage, la sortie ne se produit jamais en silence. NAT est SNAT uniquement, donc il ne fournit pas de chemin d'entrée. Ajoutez une règle SNAT UDP afin que DNS fonctionne toujours pour les machines virtuelles utilisant la route par défaut NAT.

11. Construire le VPN Gateway et le tunnel vers le centre de données d'entreprise (comme construit à l'unité 3.6). Créez un VPN Gateway IKEv2 sur son adresse IP publique réservée, attachez-le au LAN privé avec une adresse de passerelle dans la plage .2 à .9, puis créez un tunnel vers le pair d'entreprise avec un PSK fort et des paramètres de phase 1 et de phase 2 correspondants. Listez les CIDR de réseau cloud et de 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 active-passive partage l'adresse IP de la passerelle unique.

12. Provisionner et valider l'ensemble du centre de données virtuel. Provisionnez les changements accumulés. Validez le chemin couché de bout en bout : un client atteint l'ALB sur son adresse IP publique sur HTTPS, le niveau application lit à travers le cache et revient à PostgreSQL en cas de défaut, l'NLB distribue les connexions chiffrées au niveau données, les charges de travail privées atteignent Internet uniquement via la passerelle NAT, et le centre de données d'entreprise atteint les réseaux LAN privés uniquement à travers le tunnel VPN. Le niveau données est accessible à partir de nulle part public.

Erreurs courantes :

• Construire un consommateur avant que son adresse IP réservée n'existe. L'écouteur ALB, les deux passerelles et le point d'entrée d'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 les consomme.
• Créer l'NLB avant que les cibles de niveau données n'existent. Un équilibreur pointant vers des cibles absentes route vers rien ; provisionnez le niveau données (étape 4) avant l'NLB (étape 7).
• Pointer la passerelle NAT vers la mauvaise chose, ou oublier la route par défaut. NAT est SNAT uniquement avec aucun chemin d'entrée, et la passerelle ne fait rien jusqu'à ce que la route par défaut du LAN privé soit réorientée vers elle. Ajoutez la règle SNAT UDP également, ou DNS se brise pour ces machines virtuelles.
• Traiter le service LoadBalancer Kubernetes comme la véritable porte d'entrée du Cluster. Il s'agit d'une adresse IP statique unique-Node limitée à son débit Node ; l'entrée de production de couche 7 est l'ALB distinctement provisionné, avec le contrôleur d'entrée dans le 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 à Francfort afin que les données de plan de contrôle restent en Allemagne ; les données du pool Node restent dans la région choisie, quel que soit le cas.
• Connecter un LAN privé à Internet "pour tester", ou essayer d'envelopper un équilibreur ALB ou NLB géré dans un groupe de sécurité réseau. Les équilibreurs gérés n'ont pas de NSG ; la sécurité du niveau données vient entièrement de vivre sur un LAN privé, donc une seule connexion Internet sur le LAN de données démonte l'argument de conformité.
• Donner à la base de données PostgreSQL Cluster ou au cache une adresse à l'intérieur de la plage DHCP. Réutilisez les trois premiers octets du LAN et choisissez une adresse que DHCP n'attribue jamais (se terminant par .3 à .10) ; une collision produit des défaillances de connexion intermittentes et difficiles à diagnostiquer.
• Faire correspondre les paramètres de phase 1 ou de phase 2 VPN entre la passerelle IONOS et le pair d'entreprise, ou rechercher une option IKEv1. Il n'y a pas d'IKEv1 ; les paramètres doivent correspondre exactement aux deux extrémités, ou le tunnel ne s'établit jamais, et la paire HA présente une adresse IP partagée unique au pair.

Résumé

Le noyau de FinCorp est maintenant un centre de données virtuel qui réalise l'architecture en couches de l'unité 1.2 : un équilibreur de charge public de niveau 7 qui termine TLS à la limite, un niveau d'application dédié sans état, un équilibreur de charge privé de niveau 4, et un niveau de données privé d'un PostgreSQL Cluster strictement synchrone, fronté par un cache In-Memory DB, avec un Managed Kubernetes Cluster et les passerelles hybrides VPN et NAT attachées. La leçon de la pierre angulaire n'est pas une valeur de champ unique ; celles-ci ont été établies dans les constructions par module. C'est qu'un environnement intégré est un graphique de dépendances, et que la construction de bas en haut (adresses IP, puis réseaux locaux, puis calcul, puis données, puis équilibreurs de charge, puis conteneurs, puis la limite 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 graphique de dépendances : réservez d'abord les adresses IP publiques, créez des réseaux locaux avant que quoi que ce soit s'y attache, provisionnez les cibles avant l'équilibreur de charge qui les sert, et redirigez la route par défaut avant d'attendre la sortie NAT.
• Le niveau de données ne touche jamais un LAN public ; la segmentation, et non un groupe de sécurité réseau, 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 groupe de sécurité réseau.
• Le PostgreSQL Cluster n'a pas de réplique de lecture ; le cache In-Memory DB est le substitut de mise à l'échelle de la lecture et l'état externalisé qui permet au niveau d'application de mettre à l'échelle et de basculer en toute sécurité.
• Le service LoadBalancer du Kubernetes Cluster est un Node statique unique, et non le point d'entrée de production ; l'équilibreur de charge public plus un contrôleur d'entrée dans le Cluster est la véritable porte d'entrée de niveau 7, et un plan de contrôle de Francfort maintient les données de plan de contrôle en Allemagne.
• La pierre angulaire fait référence à chaque unité par module plutôt que de la répéter : les laboratoires minces par module existent pour que ce laboratoire d'intégration puisse porter la synthèse.

Lecture supplémentaire

• Unité 8.2 : l'architecture d'entreprise de référence (la conception que ce laboratoire met en œuvre)
• Unité 3.1, 3.3, 3.4, 3.6 : les constructions de réseau et d'équilibrage de charge cousues ici
• Unité 5.3, 5.5 : la base de données relationnelle Cluster et le cache sur la couche de données privée
• Unité 6.2 : la construction publique Managed Kubernetes Cluster
• Unité 7.1 : le câblage de la résilience et du basculement sur ce noyau