Dans ce module, vous déploierez votre application node.js en tant qu’ensemble de services interconnectés derrière un équilibreur de charge d’application (ALB). Ensuite, vous utiliserez l’ALB pour rediriger le trafic avec fluidité du monolithe vers les microservices. Commencer la construction

Voici la procédure à suivre pour établir vos microservices et rediriger en toute sécurité le trafic depuis le monolithe vers l’application.

présentation de l’architecture
  1. Monolithe déployé
    Il s’agit de la configuration de départ. L’application monolithique node.js s’exécute dans un conteneur sur Amazon ECS.
  2. Démarrage des microservices
    En utilisant les trois images de conteneur que vous avez construites et transmises à Amazon ECR au cours du module précédent, vous démarrerez trois microservices sur votre cluster Amazon ECS existant.
  3. Configuration des groupes cibles
    Comme dans le module 2, vous allez ajouter un groupe cible pour chaque service et mettre à jour les règles de l’ALB pour connecter les nouveaux microservices.
  4. Basculement du trafic et arrêt du monolithe
    En changeant une règle dans l’ALB, vous allez commencer à acheminer le trafic vers les microservices en cours d’exécution. Une fois que tout fonctionne correctement, arrêtez le monolithe.

Suivez les instructions détaillées ci-dessous afin de déployer les microservices. Cliquez sur chaque numéro d’étape pour développer la section correspondante.

  • Étape 1. Écriture des définitions des tâches pour vos services

    Vous déploierez trois nouveaux microservices sur le même cluster que vous exécutez depuis le module 2. Comme dans le module 2, vous écrirez des définitions de tâches pour chaque service.

    ⚐ REMARQUE : il est possible d’ajouter plusieurs conteneurs à une définition de tâche. Par conséquent, vous pourriez exécuter les trois microservices en tant que conteneurs distincts sur un seul et même service. Cependant, cette configuration serait toujours monolithique, car chaque conteneur aurait besoin de s’aligner de façon linéaire avec le service. Votre objectif est de disposer de trois services indépendants et que chacun de ces services ait besoin que sa propre définition de tâche exécute un conteneur avec l’image du service respectif.

    Vous pouvez soit écrire ces définitions de tâches dans l’interface utilisateur de la console ou accélérer les choses en les écrivant sous forme de fichier JSON. Pour écrire la définition de la tâche sous forme de fichier JSON, sélectionnez Configurer via JSON en bas de l’écran de la nouvelle définition de tâche.

    Les paramètres de la définition de tâches sont les suivants :

    • Nome = [nom_service] 
    • Image = [URL répertoire service ECR]:dernière 
    • CPU = 256 
    • Mémoire = 256 
    • Port du conteneur = 3000 
    • Publication hôte = 0



    Ou avec un fichier JSON :

    {
        "containerDefinitions": [
            {
                "name": "[service-name]",
                "image": "[account-id].dkr.ecr.us-west-2.amazonaws.com/[service-name]:[tag]",
                "memoryReservation": "256",
                "cpu": "256",
                "essential": true,
                "portMappings": [
                    {
                        "hostPort": "0",
                        "containerPort": "3000",
                        "protocol": "tcp"
                    }
                ]
            }
        ],
        "volumes": [],
        "networkMode": "bridge",
        "placementConstraints": [],
        "family": "[service-name]"
    }

    ♻ Répétez cette procédure pour créer une définition de tâche pour chaque service :

    • publications
    • threads
    • users
  • Étape 2. Configuration de l’équilibreur de charge d’application : groupes cibles

    Comme dans le module 2, vous allez configurer des groupes cibles pour chacun de vos services. Les groupes cibles permettent au trafic d’atteindre correctement chaque service.

    Vérifiez le nom de votre VPC : la pile AWS CloudFormation a son propre VPC, qui est très probablement différent de votre VPC par défaut. Il est important de configurer vos groupes cibles avec le bon VPC.

    • Accédez à la section Équilibreur de charge de la console EC2.
    • Vous devriez voir qu’il existe déjà un équilibreur de charge nommé « demo ».
    • Cochez la case pour afficher les détails de l’équilibreur de charge.
    • Notez la valeur de l’attribut VPC sur la page de détails.

     

    Configuration des groupes cibles

    • Accédez à la section Groupe cible de la console EC2.
    • Sélectionnez Créer un groupe cible.
    • Configurez le groupe cible (ne modifiez pas les valeurs par défaut qui ne sont pas spécifiées ici) : Nom = [nom_service] Protocole = port HTTP = 80 VPC = sélectionnez le VPC qui correspond à votre équilibreur de charge de l’étape précédente.
      • Paramètres avancés de vérification de l’état : Seuil de bonne santé = 2 Seuil de défectuosité = 2 Expiration = 5 Intervalle = 6
    • Sélectionnez Créer.

     

    ♻ Répétez cette procédure pour créer un groupe cible pour chaque service :

    • publications
    • threads
    • users

     

    Enfin, créez un quatrième groupe cible

    • drop-traffic

    Ce groupe cible est une cible « fictive ». Vous l’utiliserez pour empêcher que le trafic n’atteigne votre monolithe une fois que vos microservices s’exécutent intégralement. Vous devez avoir un total de 5 groupes cibles dans votre table.

    groupes cibles
  • Étape 3. Configuration des règles des écouteurs

    L’écouteur vérifie s’il y a des demandes de connexion entrantes vers votre ALB afin d’acheminer correctement le trafic.

    À l’heure actuelle, vos quatre services (le monolithe et vos trois microservices) sont tous exécutés derrière le même équilibreur de charge. Pour faciliter la transition du monolithe aux microservices, vous allez commencer par acheminer le trafic vers vos microservices et cesser d’acheminer ce trafic vers votre monolithe.

    Ouvrez votre écouteur

    • Accédez à la section Équilibreur de charge de la console EC2.
    • Vous devriez voir qu’il existe déjà un équilibreur de charge nommé « demo ».
    • Cochez la case pour afficher les détails de l’équilibreur de charge.
    • Sélectionnez l’onglet Écouteurs.

     

    Mettez à jour les règles d’écouteur

    • Sélectionnez Afficher/modifier les règles > pour l’écouteur.
    • Sélectionnez le signe + et insérez une règle.
    • Les critères de cette règle sont les suivants :
      • SI Chemin =/api/[nom_service]* ALORS Réacheminer vers [nom_service]
      • Par exemple : Chemin = /api/publications* réacheminer vers publications
    • Créez quatre nouvelles règles, l’une pour continuer d’acheminer le trafic vers le monolithe et une autre pour chaque service. Vous disposerez de cinq règles au total, y compris la règle par défaut. Veillez à ajouter vos règles dans l’ordre suivant :
      • api : /api* réachemine vers l’api
      • utilisateurs : /api/utilisateurs* réachemine vers les utilisateurs
      • threads : /api/threads* réachemine vers les threads
      • publications: /api/publications* réachemine vers les publications
    • Sélectionnez la flèche de retour en haut à gauche de la page pour revenir à la console de l’équilibreur de charge.
    configuration des règles des écouteurs
  • Étape 4. Déploiement de vos microservices

    Vous allez maintenant déployer vos trois services sur votre cluster. Répétez les étapes suivantes pour chacun de vos trois services :

    • Naviguez vers le menu « Clusters » sur le côté gauche de la console Amazon ECS.
    • Sélectionnez votre cluster : BreakTheMonolith-Demo-ECSCluster.
    • Sous l’onglet « Services », sélectionnez « Créer ».
    • Configurez le service (ne modifiez pas les valeurs par défaut) Définition de tâche = sélectionner la plus haute valeur pour X : [nom_service] : X (X devrait être = 1 dans la plupart des cas) Nom du service = [nom_service] Nombre de tâches = 1
    • Sélectionnez « Configurer ELB »
      • Type d’ELB = Équilibreur de charge d’application
      • Pour le rôle IAM, sélectionnez BreakTheMonolith-Demo-ECSServiceRole.
      • Sélectionnez votre équilibreur de charge « démo »
      • Sélectionnez « Ajouter à ELB ».
    • Ajoutez votre service au groupe cible :
      • Port d’écoute = 80:HTTP
      • Nom du groupe cible = sélectionnez votre groupe : [nom_service]
    • Sélectionnez « Enregistrer ».
    • Sélectionnez « Créer un service ».
    • Sélectionnez « Afficher le service ».


    Le démarrage de l’ensemble de vos services ne devrait prendre que quelques secondes. Vérifiez que tous les services et les tâches sont en cours d’exécution et en bonne santé avant de continuer.

    déploiement des microservices
  • Étape 5. Basculement du trafic vers vos microservices

    Actuellement, vos microservices sont en cours d’exécution, mais tout le trafic se dirige toujours vers votre monolithe.

    Mettez à jour les règles d’écouteur pour réacheminer le trafic vers les microservices :

    • Accédez à la section Équilibreur de charge de la console EC2.
    • Sélectionnez Afficher/modifier les règles > pour l’écouteur sur l’équilibreur de charge « démo ».
    • Supprimez la première règle (/api* réachemine vers api).
    • Mettez à jour la règle par défaut de réacheminement vers drop-trafic.

    Vos règles devraient ressembler aux suivantes :

    basculement du trafic vers vos microservices

    Désactivez le monolithe : maintenant que le trafic est acheminé vers vos microservices, vous pouvez diminuer le service « Monolithe ».

    • Revenez sur votre cluster Amazon ECS : BreakTheMonolith-Demo-ECSCluster.
    • Sélectionnez le service api, puis « Mettre à jour ».
    • Modifiez le nombre de tâches à 0.
    • Sélectionnez « Mettre à jour le service ».

     

    Amazon ECS déchargera alors toutes les connexions partant des conteneurs déployés par le service sur le cluster, puis arrêtera les conteneurs. Si vous actualisez les listes de tâches ou de déploiements après environ 30 secondes, vous verrez que le nombre de tâches sera descendu à 0. Le service est toujours actif, donc si vous avez besoin de le restaurer pour quelque raison que ce soit, vous pouvez simplement le mettre à jour pour déployer d’autres tâches.

    • Sélectionnez le service api, puis « Supprimer » et confirmez la suppression.


    Vous avez procédé au transfert complet de votre node.js depuis le monolithe vers vos microservices, sans aucune interruption !

  • Étape 6. Validation de votre déploiement

    Trouvez l’URL de votre service : il s’agit de l’URL que vous avez utilisée dans le module 2 de ce didacticiel.

    • Accédez à la section Équilibreurs de charge de la console EC2.
    • Sélectionnez votre équilibreur de charge « demo-microservices ».
    • Copiez et collez la valeur du nom DNS dans votre navigateur.
    • Vous devriez voir le message « Prêt à recevoir des requêtes ».

     

    Affichez les valeurs de chaque microservice : votre ALB achemine le trafic en fonction de l’URL de requête. Pour voir chaque service, il vous suffit d’ajouter le nom du service à la fin de votre nom DNS, comme suit :

    • http://[nom DNS]/api/utilisateurs
    • http://[nom DNS]/api/threads
    • http://[nom DNS]/api/publications
    afficher les valeurs de chaque micro-service

    ⚐ REMARQUE : ces URL fonctionnent exactement de la même manière que lorsque le monolithe est déployé. Ceci est très important, car les API ou les consommateurs qui s’attendent à se connecter à cette application ne seront pas affectés par les modifications que vous avez effectuées. Pour passer du monolithe aux microservices, aucune modification n’a dû être apportée aux autres parties de votre infrastructure.

    Vous pouvez également utiliser des outils tels que Postman pour tester vos API.