Dans ce module, vous allez diviser l’application node.js en plusieurs services interconnectés et envoyer l’image de chaque service vers un référentiel Amazon ECR. Commencer la construction

L'architecture finale de l'application utilise Amazon Elastic Container Service et l'équilibreur de charge d'application. 

présentation de l’architecture

a. Client
Le client envoie des demandes de trafic sur le port 80.

b. Équilibreur de charge
L’Application Load Balancer (ALB) achemine le trafic externe vers le service correspondant. L’ALB inspecte la requête du client et se base sur les règles de routage pour l’acheminer vers une instance et un port du groupe cible.

c. Groupes cibles
Chaque service possède un groupe cible qui répertorie les instances et les ports de chaque conteneur en cours d’exécution pour ce service.

d. Services conteneurisés
Amazon Elastic Container Service (Amazon ECS) déploie chaque service dans un conteneur sur un cluster EC2. Chaque conteneur gère uniquement une seule fonctionnalité.

Isolement des pannes
Il arrive même aux meilleures entreprises d’ingénierie de souffrir de graves pannes de production. En plus de toutes les bonnes pratiques standard permettant de corriger les pannes de manière convenable, la création de microservices constitue l’une des approches pouvant limiter l’impact de telles défaillances. Si vous disposez d’une bonne architecture de microservices, lorsqu’un microélément de votre service tombe en panne, seul cet élément cessera de fonctionner. Le reste de votre service continuera de fonctionner correctement.

Isolement pour la sécurité
Dans une application monolithique, si une fonctionnalité de l’application souffre d’une faille de sécurité (par exemple une vulnérabilité permettant l’exécution de code à distance), vous devez alors supposer qu’un pirate pourrait également avoir accès à toutes les autres fonctionnalités du système. Ceci peut être dangereux si, par exemple, votre fonctionnalité de chargement d’avatar souffre d’un problème de sécurité qui finit par compromettre votre base de données et les mots de passe des utilisateurs. La séparation des fonctionnalités en microservices à l’aide d’Amazon ECS vous permet de sécuriser l’accès aux ressources AWS en conférant à chaque service son propre rôle IAM. Lorsque vous suivez les meilleures pratiques en matière de microservices, si un pirate compromet un service donné, il peut alors uniquement accéder aux ressources de ce dernier et n’aura accès aux ressources d’autres services qu’en s’y infiltrant également.

Dimensionnement indépendant
Lorsque les fonctionnalités sont divisées en microservices, il est alors possible d’augmenter ou de réduire de manière indépendante la quantité d’infrastructures et le nombre d’instances utilisées par chaque classe de microservice. Il devient alors plus facile d’évaluer le coût d’une fonctionnalité particulière, d’identifier les fonctionnalités à optimiser en priorité ou encore de préserver la fiabilité des performances des autres fonctionnalités au cas où l’une d’entre elles dépasserait excessivement ses besoins en ressources.

Rapidité de développement
Les microservices réduisent les risques au cours du développement, ce qui peut permettre à une équipe de développer plus rapidement. Dans un monolithe, l’ajout d’une nouvelle fonctionnalité peut potentiellement avoir un impact sur toutes les autres fonctionnalités qu’il contient. Les développeurs doivent étudier soigneusement l’impact de tout code qu’ils ajoutent et s’assurer de ne rien casser. D’un autre côté, une architecture de microservices correcte se compose d’un nouveau code pour chaque nouvelle fonctionnalité intégrée à un nouveau service. Les développeurs peuvent être certains qu’aucun des codes qu’ils écrivent ne pourra avoir d’impact sur le code existant, sauf s’ils écrivent explicitement une connexion entre deux microservices.

Temps nécessaire : 20 minutes

Services utilisés :


Suivez les instructions détaillées ci-dessous pour diviser le monolithe. Cliquez sur chaque numéro d’étape pour développer la section correspondante.

break-the-monolith
  • Étape 1. Allocation des référentiels ECR

    Dans les deux étapes précédentes, vous avez déployé votre application de manière monolithique à l’aide d’un seul service et d’un seul référentiel d’image de conteneur. Pour déployer l’application sous la forme de trois microservices, vous devrez allouer trois référentiels (un pour chaque service) dans Amazon ECR.

    Nos trois services sont les suivants :

    1. users
    2. threads
    3. publications


    Créez le référentiel :

    • Accédez à la console Amazon ECR.
    • Sélectionnez « Créer un référentiel »
    • Nom du référentiel :
      • users
      • threads
      • publications
    • Notez les informations relatives aux référentiels : [ID_compte].dkr.ecr.[région].amazonaws.com/[nom_service]

    Répétez ces étapes pour chaque microservice.

    Vous devez maintenant disposer de quatre référentiels dans Amazon ECR.

    référentiels
  • Étape 2. Authentification Docker avec AWS (facultatif)

    Vous pouvez ignorer cette étape si vous avez achevé récemment le module 1 de cet atelier.

    • Exécutez aws ecr get-login --no-include-email --region [région]
      Exemple : aws ecr get-login --no-include-email --region us-west-2
    • Vous obtiendrez alors un résultat de très grande taille commençant par docker login -u AWS -p ... Copiez et collez-le intégralement et exécutez-le dans le terminal.

    • Un message confirmant la connexion devrait s’afficher.

      ⚐ REMARQUE : un échec de la connexion peut être lié à une version plus récente de Docker qui déprécie l’indicateur -e none. Pour corriger ce problème, collez le résultat dans votre éditeur de texte, supprimez l’indicateur -e none qui se trouve à la fin de celui-ci et exécutez cette nouvelle version du résultat dans le terminal.

  • Étape 3. Création et envoi d’images pour chaque service

    Le dossier du projet amazon-ecs-nodejs-microservices/3-microservices/services contient des dossiers comprenant les fichiers de chaque service. Notez que chaque microservice est essentiellement un clone du service monolithique précédent.

    Vous pouvez constater dans quelles mesures chaque service est désormais spécialisé en comparant le fichier db.json de chaque service et du service monolithique api. Auparavant, les publications, les threads et les utilisateurs étaient tous stockés dans un seul fichier de base de données. Dorénavant, chacun est stocké dans le fichier de base de données de son service respectif.

    Ouvrez votre terminal et suivez le chemin vers la section 3-microservices/services du code GitHub. ~/amazon-ecs-nodejs-microservices/3-microservices/services

    Développez et balisez chaque image

    • Dans le terminal, exécutez docker build -t [nom_service]./[nom_service] Exemple : docker build -t posts ./posts
    • Une fois la création terminée, balisez l’image afin de pouvoir l’envoyer au référentiel : docker tag [nom_service]:latest [ID_compte].dkr.ecr.[région].amazonaws.com/[nom_service]:v1 exemple : docker tag posts:latest [ID_compte].dkr.ecr.us-west-2.amazonaws.com/posts:v1
    • Exécutez docker push pour envoyer votre image à ECR : docker push [ID_compte].dkr.ecr.[région].amazonaws.com/[nom_service]:v1

    Lorsque vous accédez à votre référentiel ECR, vous devriez voir vos images balisées avec v1. 

    ♻ Répétez cette procédure pour chaque image de microservice.  

    ⚐ REMARQUE : n’oubliez pas de créer et baliser les trois images.