"Deploy & Scale" en toute simplicité

Le monde avance à grande vitesse. Survivre revient à se mettre au rythme et les projets techniques ne sont pas épargnés.

Historiquement, la mise en place de l'infrastructure nécessaire pour les applications web exigeait un investissement considérable en temps, en ressources et en expertise.

De l'achat du matériel à la configuration des équilibreurs de charge, en passant par la garantie d'une haute disponibilité, le processus était complexe, chronophage et semé d’embûches.

Aujourd’hui, le cloud computing propose une solution alternative… AWS, Azure ou GCP  permettent de créer des solutions complexes à l’aide de services gérés et automatisés qui non seulement simplifient le déploiement mais permettent de gérer une haute disponibilité et tolérance aux pannes sans gros casses-têtes ( Ce dernier étant l’expertise propre des cloud providers).

Aujourd'hui, un seul développeur peut non seulement coder sa web-app ou son API, mais aussi, avec un peu de connaissances en AWS, provisionner toute une infrastructure en quelques dizaines de lignes de code. Cette infrastructure peut gérer l'accessibilité, la scalabilité, la sécurité, et même l'intégration continue, transformant ainsi des tâches autrefois complexes et chronophages en un processus rapide, efficace, et entièrement automatisé.

L’Intégration avec AWS :

I -  ECS/ELB/Autoscaling : la solution de facilité :

A - ECS , la solution packagée :

ECS est idéal pour les applications conteneurisées complexes qui nécessitent une gestion fine des ressources, un contrôle précis des environnements d'exécution, ou des processus de longue durée. Par exemple, si vous avez une application microservices avec plusieurs composants qui doivent communiquer entre eux, ECS est un choix naturel.

B - ELB, le répartiteur de charge :

L'Elastic Load Balancer (ELB) est un service qui s'assure que le trafic des utilisateurs est réparti équitablement entre les différentes instances de ton application. Si une instance est occupée ou rencontre un problème, ELB redirige automatiquement le trafic vers une autre instance disponible. Cela garantit que ton application reste accessible et performante, même en cas de forte demande ou de panne d'un serveur.

C - Autoscaling, l'adaptabilité automatique :

Le service d'Auto Scaling permet à ton application de s'adapter automatiquement aux variations de la demande. Si le trafic augmente, Auto Scaling ajoutera des instances pour gérer la charge. Inversement, si le trafic diminue, il réduira le nombre d'instances pour économiser des ressources. Cela garantit que ton application utilise toujours la bonne quantité de ressources, ni plus ni moins, tout en restant disponible pour les utilisateurs.
‍

II - l’architecture complète

L’architecture est complexe et fait intervenir plusieurs concepts différents comme vous pouvez le voir sur le schéma ci-dessous.

Cependant avec AWS cloudformation, toute l’infra peut être provisionnée en quelques lignes de code. Nous verrons dans la 3ème partie la Stack responsable de la création de cette infra :

Voyons comment tous ces services intéragissent entre eux :

L'image Docker : Ta principale responsabilité

• Task Definition : Ton travail principal en tant que développeur sera de créer une image Docker pour ton application. Cette image contient tout ce dont ton application a besoin pour fonctionner (le code, les dépendances, etc.).
• Tu définis ensuite une Task Definition qui décrit comment cette image Docker doit être exécutée sur AWS (combien de CPU et de mémoire sont nécessaires, quelles commandes doivent être exécutées, etc.).

ECS Cluster : Le chef d'orchestre

• Une fois que ton image Docker est prête, elle sera exécutée dans ce qu'on appelle un ECS Cluster. Le cluster est un ensemble de ressources informatiques (des serveurs EC2) qui exécuteront ton application.
• Le ECS Service dans le cluster veille à ce que ton application reste en cours d'exécution et puisse répondre à toutes les requêtes des utilisateurs.

Auto Scaling : Adapte automatiquement les ressources

• Pour s'assurer que ton application puisse gérer plus de trafic lorsqu'elle devient populaire, un Auto Scaling Group gère le nombre de serveurs EC2 (machines virtuelles) en fonction de la demande. Il peut augmenter ou réduire le nombre de serveurs automatiquement.
• Le Capacity Provider fait le lien entre l'Auto Scaling Group et ton ECS Cluster pour s'assurer que les ressources sont allouées de manière optimale.

Load Balancer (ELB) : Distribution du trafic

• Un Elastic Load Balancer (ELB) reçoit tout le trafic des utilisateurs (les requêtes). Il distribue ensuite ce trafic de manière équitable entre les serveurs de ton ECS Cluster qui exécutent ton application.
• Le Target Group est le groupe de serveurs (EC2 instances) où ton application est exécutée. Le Load Balancer s'assure que chaque requête est envoyée à un serveur capable de la gérer.

III - La super star - Infra as a Code :

A- Considérations sur la Stack :

‍

Pour avoir un aperçu de la stack globale qui est utilisée pour provisionner l’infrastructure visitée plus haut dans le diagramme, vous pouvez visiter le GitHub qui contient la template en entier. GitHub repo : https://github.com/errajibadr/DataEngineeringUnboxed

Pour des raisons pratiques, il peut être plus intéressant de séparer la Stack en plusieurs simplement pour ne pas avoir à tout redéployer si on veut changer une partie de la Stack.

Dans le cas d’ECS, une ségrégation intéressante à faire peut être entre :

le côté infra dur : le Cluster, le cluster Provider, sclaingGroup qui vont plus gérer les machines physiques.  

le côté service  : qui lui est à un couche d’abstraction plus haut.

Ce qui nous donnerait plutôt cela comme découpage :

Dans le diagramme ci-dessus, les éléments de l'infrastructure de base, tels que le Cluster ECS, le Capacity Provider et le Scaling Group, sont mis en évidence en orange. Ces éléments gèrent les aspects matériels de l'infrastructure. Les services exécutés sur cette infrastructure, tels que le Service ECS, le Load Balancer et les groupes cibles, sont mis en évidence en bleu, indiquant leur rôle en tant que couche d'abstraction supérieure.

Bon nous pouvons passer aux choses sérieuses, nous allons présenter ici un à un les éléments importants de la Stack.

B - la Stack

Les stack CloudFormation peuvent être composés de plusieurs éléments que nous détaillerons plus bas :  

- Outputs

- parameters

- mappings

- resources

Pour voir la Stack complète : rdv ici. https://github.com/errajibadr/DataEngineeringUnboxed
‍

1. Mappings (Mappages)

• But : Définir comment inclure les configurations réseau spécifiques à différents comptes et régions AWS

Mappings:
  AccountNetworkMap:
    Fn::Transform:
      Name: AWS::Include
      Parameters:
        Location:
          Fn::Sub: s3://votre-bucket/network_configs/${AWS::AccountId}/${AWS::AccountId}_network.json

‍

Explication : Cette section importe des configurations réseau externes stockées dans un bucket S3, permettant à la stack de s'adapter dynamiquement aux paramètres spécifiques au compte et à la région.

2. Outputs (Sorties)

• But : Fournir des références aux composants clés de l'infrastructure que d'autres stacks ou services peuvent utilise

Outputs:
  Ec2EcsClusterPolicyCpAsgLtLaunchTemplate:
    Description: Référence du modèle de lancement EC2
    Export:
      Name:
        Fn::Sub: ${AWS::StackName}-LT
    Value:
      Ref: Ec2EcsClusterPolicyCpAsgLtLaunchTemplate … 

3. Parameters (Paramètres)

• But : Définir des valeurs configurables qui peuvent être fournies lors du lancement de la stack pour personnaliser son comportement.

Parameters:
  ScriptsBucket:
    Default: votre-bucket-scripts
    Type: String

Explication : Ces paramètres permettent de personnaliser l'infrastructure, par exemple en spécifiant le propriétaire, l'ID de l'équipe, et le bucket S3 pour les scripts, ce qui rend la stack réutilisable dans différents environnements.

4. Resources : les ressources AWS

A -   Cluster

But : Définir le cluster ECS où les services seront déployés.

EcsEcsClusterPolicyCluster:
    Type: AWS::ECS::Cluster
    Properties:
      ClusterName:
        Fn::Sub: ${RoleOwner}_ecs_cluster_policy
      CapacityProviders:
        - Ref: EcsEcsClusterPolicyCpCapacityprovider
      ClusterSettings:
        - Name: containerInsights
          Value: disabled
      Tags:
        - Key: Name
          Value:
            Fn::Sub: ${RoleOwner}_ecs_cluster_policy

Explication : Cette ressource définit le cluster ECS, spécifiant le nom, les fournisseurs de capacité (Capacity Providers), et les tags pertinents. Ce cluster constitue la base sur laquelle les services ECS seront déployés.

B- Autoscaling Group :

But : Gérer la mise à l'échelle des instances EC2 en fonction de la demande, en s'assurant que le bon nombre d'instances est en cours d'exécution.

Resources:
  AutoscalingEcsClusterPolicyCpAsgGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AutoScalingGroupName:
        Fn::Sub: ${RoleOwner}_ecs_cluster_policy_cp_asg
      DesiredCapacity: '2'
      HealthCheckGracePeriod: 300
      LaunchTemplate:
        LaunchTemplateId:
          Ref: Ec2EcsClusterPolicyCpAsgLtLaunchTemplate
        Version:
          Fn::GetAtt:
            - Ec2EcsClusterPolicyCpAsgLtLaunchTemplate
            - LatestVersionNumber
      MaxSize: '4'
      MinSize: '1'
      Tags:
        - Key: Name
          PropagateAtLaunch: true
          Value:
            Fn::Sub: ${RoleOwner}_ecs_cluster_policy_cp_asg
      VPCZoneIdentifier:
        Fn::FindInMap:
          - AccountNetworkMap
          - Ref: AWS::Region
          - DefaultSubnetIds

Explication : Cette section définit un groupe de mise à l'échelle automatique (Auto Scaling Group) qui ajuste dynamiquement le nombre d'instances EC2 en fonction de la demande. Il utilise un modèle de lancement (Launch Template) et applique les règles de mise à l'échelle spécifiées.

‍

Le mot de la fin

En résumé, la mise en place d'une infrastructure cloud performante et sécurisée peut être réalisée de manière efficace et rapide, à condition de bien maîtriser les concepts fondamentaux des applications web et de les combiner avec une bonne compréhension des services Cloud.

Une fois ces bases acquises, vous serez en mesure de tirer pleinement du Cloud. Cette approche vous ouvrira des portes nouvelles par rapport à votre gestion des projets. Je vous invite donc à vous intéresser au cloud si ce n’est pas déjà le cas.