PARTIE 3 – L’Infrastructure As Code : Les Frameworks CloudFormation & Terraform. Quand ? Comment ? Pourquoi ?

par Samy HAMIDOU publié le 7 décembre 2021 0 Commentaires

Après une prise en main de AWS, avec terraform, nous reprenons ce TP de présentation avec l’outil maison CloudFormation. Il s’agira de reprendre ce qui a été précédemment créé et le transposer dans le langage propre à CFN. Nous verrons comment les deux frameworks se distinguent, dans l’approche code de AWS.

Cloudformation : Le framework « maison » de AWS pour gérer votre infrastructure :

Dans le cas de AWS CloudFormation, nous sommes invités à choisir entre deux types de langage pour décrire l’infrastructure souhaitée, entre YML et JSON. Première différence, et première contrainte, de passer de Terraform à Cloudformation, est l’obligation de rédiger un unique fichier. Ainsi, pour reproduire ce qui a été fait avec Terraform dans l’exemple précédent, nous allons créer un fichier que nous allons uploader par la suite sur la console AWS ou à travers le AWS-shell. Lorsque nous créons une infrastructure virtuelle avec cfn, elle est désignée sous le nom de stack (pile).

Ce qui suit est disponible à la lecture et pour votre usage personnel sur le repository github suivant :

https://github.com/bobiwembley/aws_cfn_demo

Pour définir votre Stack, vous avez à votre disposition plusieurs sections dans votre fichier :

				
					Parameters: ### Section pour définir vos propres variables (optionnelle) 
Mappings:   ### Section pour associer des valeurs spécifiques à une clé (optionnelle)  
Resources:  ### Section pour définir les objets que vous allez créer à partir de la MarketPlace AWS (obligatoire) 
Outputs:    ### Section pour récupérer les valeurs héritées de votre stack après sa création  (optionnelle)

Les différentes sections disponibles dans le fichier de création de stack (format Yml).

Penchons-nous sur la section resource, élément central de toute création de stack avec cfn. Ici, un extrait de la section définissant la création des éléments de notre infra. Comme dans l’article de Terraform, nous allons procéder à la création des éléments suivants :

Un VPC
Un subnet privé
Une gateway afin d’accéder à l’extérieur

Un Groupe de sécurité.
Un Ec2 qui sera notre serveur web.

				
					Resources: 
  VpcWebServer: 
    Type: AWS::EC2::VPC 
    Properties: 
      CidrBlock: 10.10.0.0/16 
      EnableDnsHostnames: true 
      EnableDnsSupport: true 
  VpcWebServerPublicSubnet: 
    Type: AWS::EC2::Subnet 
    Properties:  
       CidrBlock: 10.10.0.0/24 
       AvailabilityZone: !Select [ 0, !GetAZs ]  
       MapPublicIpOnLaunch: true 
       VpcId:  
         Ref: 'VpcWebServer' 
       Tags: 
       - Key: Name 
         Value: !Sub ${AWS::StackName}-Public-WebServer   
  InternetGateway: 
    Type: AWS::EC2::InternetGateway 
    DependsOn: VpcWebServer 
  AttachGateway: 
    Type: AWS::EC2::VPCGatewayAttachment 
    Properties: 
      VpcId: !Ref VpcWebServer 
      InternetGatewayId: !Ref InternetGateway 
  PublicRouteTable: 
    Type: AWS::EC2::RouteTable 
    Properties: 
      VpcId: !Ref VpcWebServer 
      Tags: 
      - Key: Name 
        Value: Public 
  PublicRoute1:    
    Type: AWS::EC2::Route 
    DependsOn: AttachGateway 
    Properties: 
      RouteTableId: !Ref PublicRouteTable 
      DestinationCidrBlock: 0.0.0.0/0 
      GatewayId: !Ref InternetGateway   
  WebServer: 
    Type: AWS::EC2::Instance 
    Properties: 
      InstanceType: !Ref 'InstanceType' 
      KeyName: !Ref 'KeyName' 
      ImageId:  
        Fn::FindInMap: 
        - RegionMap 
        - !Ref AWS::Region 
        - AMI 
      SecurityGroupIds:  
        -  WebSecurityGroup  
      SubnetId:  
        Ref: VpcWebServerPublicSubnet 
  WebSecurityGroup: 
    Type: AWS::EC2::SecurityGroup 
    Properties: 
      GroupDescription: Enable SSH on Ec2 WebServer 
      SecurityGroupIngress: 
        - IpProtocol: tcp 
          FromPort: 22 
          ToPort: 22 
          CidrIp: !Ref 'SSHLocation' 
      VpcId: 
        Ref: VpcWebServer

AWS met à notre disposition Designer sur la console afin d’avoir un rendu schématique de notre Infra Cloud.

Les fonctions intrinsèques de cloudformation :

Si vous prêtez attention à la lecture de la section ressource du fichier yml, vous avez dû noter l’usage de certains mots-clés tels que :

				
					!Ref  

!Select 

!Sub 

!GetAttr

Ces mots-clés sont propres à l’usage de Cfn, il s’agit des fonctions intrinsèques (intrinsic Function) disponibles pour manipuler les objets à construire sur AWS.

Ainsi, nous utilisons « !Ref » afin de lier la création des ressources à l’usage de variables que nous définissons dans la section «Parameters».

La création de l’ec2 se fait ainsi :

				
					WebServer: 
    Type: AWS::EC2::Instance

Nous faisons appel à un type d’objet AWS ::EC2 ::Instance. Par la suite, il s’agit de définir des propriétés :

				
					Properties: 
      InstanceType: !Ref 'InstanceType' 
      KeyName: !Ref 'KeyName'

Dans InstanceType et Keyname, la fonction intrinsèque « !ref » appelle des variables définies dans la section « Parameters » :

				
					Parameters: 
  InstanceType: 
    Description: WebServer EC2 instance type 
    Type: String 
    Default: t2.micro 
    AllowedValues: [t2.nano, t2.micro, t2.small] 
  KeyName: 
      Description: ssh private key to connect to ec2 
      Type: AWS::EC2::KeyPair::KeyName 
      Default: cloud 
      ConstraintDescription: Must be a keyPair existing on AWS account

Votre fichier de création de stack avec cfn se lit ainsi :

				
					Votre fichier de création de stack avec cfn se lit ainsi  
Parameters: 
  InstanceType: 
    Description: WebServer EC2 instance type 
    Type: String 
    Default: t2.micro 
    AllowedValues: [t2.nano, t2.micro, t2.small] 
  KeyName: 
      Description: ssh private key to connect to ec2 
      Type: AWS::EC2::KeyPair::KeyName 
      Default: cloud 
      ConstraintDescription: Must be a keyPair existing on AWS account 
Resources: 
  WebServer: 
    Type: AWS::EC2::Instance 
    Properties: 
      InstanceType: !Ref 'InstanceType' 
      KeyName: !Ref 'KeyName'

Comme pour l’infrastructure créée avec Terraform, nous souhaitons mettre à notre disposition la scalabilité et la flexibilité que peut nous offrir Cfn. Nous ajoutons ici une base de données RDS à notre infrastructure.

Intégration de ces outils dans l’opérabilité quotidienne du maintien de l’infrastructure :

Entre ces deux frameworks, nous avons la possibilité de créer notre infrastructure chez AWS. Il n’y a pas réellement de différence notable entre les deux. C’est ici que nous allons comparer les deux outils. Il s’agit de savoir comment adopter ces outils dans le maintien et dans le cycle de vie des infrastructures.

Comme nous l’avons vu précédemment, porter une partie de son infrastructure sur le Cloud AWS, c’est se donner les moyens de la scalabilité et de la transformation.

Conclusion :

Comme vous avez pu le constater, Cfn se distingue par une prise en main avec des langages tel YML ou JSON, là ou Terraform se distinguait par le HCL. Cfn est propre à AWS et est non-multicloud (comme son concurrent). Nous verrons par la suite, dans la dernière partie de l’article, à titre comparatif, quel Framework choisir pour AWS. Il s’agira de discuter sur les possibilités de code et de sa gestion dans des écosystèmes de logiciels multiples.

Blog Details