samedi , 4 avril 2020

Comment fonctionne CloudFormation ? Comment créer un VPC avec ce modèle ?

Mis à jour le:

Voici un tutoriel détaillé sur comment fonctionne CloudFormation et une analyse d’un modèle qui crée un VPC.

Dans cet article, nous allons apprendre un peu plus sur CloudFormation. Grace à un modèle que nous avons écrit, vous pouvez créer un cloud privé virtuel (VPC) et le faire fonctionner vous-même.

Commençons !

Que comprend le modèle CloudFormation ?

Voici un modèle CloudFormation super simple qui crée un compartiment S3 :

 AWSTemplateFormatVersion: 2010-09-09
 Description: Bucket Stack
 Resources:
   S3Bucket:
     Type: AWS::S3::Bucket
     Properties:
       BucketName: my-bucket 

Vous pouvez créer des modèles CloudFormation en utilisant JSON ou YAML. Nous préférons ce dernier, donc tous les modèles inclus dans cet article sont en YAML.

Quel que soit votre choix, les modèles peuvent être constitués des principales sections d’informations que nous expliquons ci-dessous. Toutefois, la section Ressources étant la seule obligatoire.

Version de format (facultative)

Version du format

Il s’agit de la version du modèle AWS CloudFormation à laquelle votre modèle est conforme et identifie les capacités du modèle. Ce n’est pas la même chose que la version API ou WSDL.

Au moment de la rédaction de cet article, la dernière et seule version valide du modèle est celle de 2010-09-09.

Bien qu’il n’y ait qu’une seule version valide pour le moment et que ce champ soit facultatif, c’est une bonne idée de l’inclure dans vos modèles pour référence future.

Description (facultative)

Cette section comprend une chaîne de texte qui fournit au lecteur une brève description (de 0 à 1024 octets) du modèle. Elle doit apparaître juste après la section Format de la version.

Soyez descriptif mais court !

Métadonnées (facultatives)

Cette section n’est pas souvent utilisée, mais vous pouvez y ajouter plus d’informations sur votre modèle.

Il peut s’agir des outils tiers que vous pouvez utiliser pour générer et modifier ces modèles et d’autres données générales.

Veuillez noter que la section Métadonnées ne doit pas être confondue avec l‘attribut Métadonnées qui relève de la section Ressources. Cette section Métadonnées doit contenir des informations sur le modèle dans son ensemble. À l’encontre, l’attribut Métadonnées doit inclure des données sur une ressource spécifique.

Paramètres (facultatifs)

Paramètres

Vous pouvez utiliser la section Paramètres pour ajouter des valeurs personnalisées dans votre modèle. Cela est fait lorsque vous créez ou mettez à jour une pile afin de rendre ces modèles portables pour une utilisation dans d’autres projets.

A titre d’exemple, vous pouvez créer des paramètres qui spécifient le suivant:

  1. Le type d’instance EC2 à utiliser,
  2. Un nom de compartiment S3,
  3. Une plage d’adresses IP et
  4. D’autres propriétés qui peuvent être importantes pour votre pile.

Les sections Ressources et Sorties se réfèrent souvent aux Paramètres. Ces références doivent être ajoutés dans le même modèle.

Mappages (facultatifs)

La section Mappages vous permet de créer des dictionnaires de valeurs-clés pour spécifier les valeurs des paramètres conditionnels.

Exemples : le déploiement de différentes AMIs pour chaque région AWS, ou le mappage de différents groupes de sécurité aux environnements Dev, Test, QA et Prod qui partagent d’une autre manière la même pile d’infrastructure.

Pour récupérer des valeurs dans une mappe, vous utilisez la fonction intrinsèque « FN::FindInMap » dans les sections Ressources et Sorties.

Conditions (facultatives)

Les conditions vous permettent d’utiliser des instructions logiques (tout comme une instruction « si alors ») pour déclarer ce qui doit se passer dans certaines situations.

Nous avons mentionné un exemple ci-dessus concernant les environnements Dev, Test, QA et Prod.

Dans cet exemple, vous pouvez utiliser des conditions pour spécifier le type d’instance EC2 à déployer dans chacun de ces environnements.

Si l’environnement est Prod, vous pouvez définir l’instance EC2 sur m4.large. Si l’environnement est Test, vous pouvez le définir sur t2.micro pour économiser de l’argent.

Transformation (facultative)

Transformation

La section Transformation vous permet de simplifier votre modèle CloudFormation. Cela se fait en condensant plusieurs lignes de code de déclaration de ressource et en réutilisant les composants du modèle.

Le CloudFormation prend en charge deux types de transformations :

  1. « AWS::Include » se réfère aux extraits de modèle qui sont stockés séparément en modèle CloudFormation principal avec lequel vous travaillez.
    Ainsi, vous pouvez faire des déclarations de ressources sur plusieurs lignes dans des fichiers YAML ou JSON stockés ailleurs. Ensuite, vous y référer avec une seule ligne de code dans votre modèle CloudFormation principal.
  2. « AWS::Serverless » spécifie la version du modèle d’application AWS Serverless (SAM) à utiliser et comment il est traité.

Vous pouvez déclarer plusieurs transformations dans un modèle et CloudFormation les exécute dans l’ordre spécifié.

Vous pouvez également utiliser des extraits de modèle sur plusieurs modèles CloudFormation.

Ressources (obligatoires)

La section Ressources est la seule section obligatoire dans un modèle CloudFormation.

Dans cette section, vous déclarez les ressources AWS, telles que:

  1. Les instances EC2,
  2. Les compartiments S3,
  3. Les clusters Redshift
  4. et autres, que vous voulez déployer dans votre pile.

Vous spécifiez aussi les propriétés, telles que la taille de l’instance, les rôles IAM et le nombre de nœuds, pour chacun de ces composants.

C’est la section qui occupera la majeure partie de vos modèles.

Sorties (facultatives)

Dans la section Sorties, vous décrivez les valeurs qui sont renvoyées lorsque vous voulez afficher les propriétés de votre pile.

Vous pouvez exporter ces sorties pour les utiliser dans d’autres piles. Il est aussi possible de les afficher simplement sur la console CloudFormation ou CLI comme un moyen pratique d’obtenir des informations importantes sur les composants de votre pile.

Il y a beaucoup d’informations à comprendre sur les sections CloudFormation. Tout cela deviendra plus clair au fur et à mesure que nous parcourrons réellement certains modèles. C’est ce que nous allons faire maintenant.

Créer un VPC avec AWS CloudFormation

Créer un serveur cloud privé avec AWS CloudFormation

Le modèle que nous avons fourni ci-dessous crée un cloud privé virtuel (VPC) avec des sous-réseaux publics et privés. Ceci vous permettra de lancer des ressources AWS dans un réseau virtuel que vous définissez et que vous contrôlez entièrement.

Dans ce modèle, nous créons un VPC avec un sous-réseau public pour vos serveurs Web qui sont publiquement adressables. De plus, nous aurons un sous-réseau privé où vos composants backend dont les bases de données ou les serveurs d’applications seront stockés et à l’abri des regards indiscrets sur Internet.

Le sous-réseau public se connecte à Internet via une passerelle Internet. Une table de routage indique au sous-réseau public comment trouver la passerelle Internet.

Nous allons ensuite répliquer les sous-réseaux publics et privés dans une autre zone de disponibilité pour une haute disponibilité.

Ce modèle est assez simple et ne contient que les sections Version de format, Description et Ressources.

Voici le modèle CloudFormation dans son intégralité :

AWSTemplateFormatVersion: 2010-09-09
Description: Creates a VPC with public and private subnets
Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 192.168.101.0/24
  PublicSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 0
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.0/28
      MapPublicIpOnLaunch: true
      VpcId: !Ref VPC
  PrivateSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 0
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.32/28
      MapPublicIpOnLaunch: false
      VpcId: !Ref VPC
  InternetGateway:
    Type: AWS::EC2::InternetGateway
  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref VPC
  PublicRouteTable:
    DependsOn: AttachGateway
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
  PublicDefaultRoute:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
      RouteTableId: !Ref PublicRouteTable
  PublicRouteAssociationA:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable
      SubnetId: !Ref PublicSubnetA
  PublicSubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 1
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.16/28
      MapPublicIpOnLaunch: true
      VpcId: !Ref VPC
  PrivateSubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 1
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.48/28
      MapPublicIpOnLaunch: false
      VpcId: !Ref VPC
  PublicRouteAssociationB:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable
      SubnetId: !Ref PublicSubnetB

OK ! Allons examiner ce qui se passe ici.

Créer un VPC et des sous-réseaux publics et privés

VPC, sous-réseaux publics et privés

Tout d’abord, nous ajoutons un VPC qui englobe l’ensemble du réseau que nous sommes sur le point de créer :

Resources: 
  VPC: 
    Type: AWS::EC2::VPC 
    Properties: 
      CidrBlock: 192.168.101.0/24

Voilà ce qui se passe :

  • VPC : c’est le nom que vous donnez à la ressource.
  • Type : définit le type de ressource CloudFormation. Consultez la documentation des types de ressources pour trouver les propriétés prises en charge.
  • Propriétés : chaque ressource a des propriétés obligatoires et facultatives. Dans ce cas, vous pouvez définir la plage d’adresses IP en notation CIDR.

Ensuite, nous ajoutons un sous-réseau public et privé :

PublicSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 0
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.0/28
      MapPublicIpOnLaunch: true
      VpcId: !Ref VPC
  PrivateSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 0
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.32/28
      MapPublicIpOnLaunch: false
      VpcId: !Ref VPC 

Comme précédemment, vous remarquerez la même structure de ressources de nom, type et propriétés prises en charge. Le type « AWS::EC2::Subnet » prend en charge quelques propriétés supplémentaires.

L’exemple ci-dessus utilise également une syntaxe spéciale pour rendre le modèle un peu plus dynamique, telle que :

Pseudo paramètres

Un pseudo-paramètre se résout dynamiquement en une valeur, compte tenu du contexte de la pile CloudFormation.

A titre d’exemple, « Ref: AWS::Region » est converti dans la région dans laquelle vous déployez le modèle (c’est-à-dire us-east-1).

Fonctions intrinsèques

Un modèle CloudFormation est une configuration, pas un code. Cependant, vous avez accès à une logique d’exécution de base.

Dans l’exemple ci-dessus, « !GetAZs Ref: AWS::Region » a toutes les zones de disponibilité dans la région actuelle. Et la fonction « !Select » a le premier AZ de la liste.

Une autre utilisation d’une fonction intrinsèque est « !Ref VPC ». Celle-ci a l’ID VPC de la ressource VPC définie précédemment.

Voici un aperçu de ce qui se passe dans le code ci-dessus :

  • PublicSubnetA est notre sous-réseau public et toutes les instances EC2 provisionnées recevront une adresse IP publique.
  • PrivateSubnetA est notre sous-réseau privé.
  • Chaque sous-réseau est provisionné dans la première zone de disponibilité de la région actuelle. Par exemple, cela pourrait être « us-east-1a ».
  • Chaque sous-réseau est placé à l’intérieur du VPC défini précédemment.
  • La plage d’adresses IP de chaque sous-réseau contient 16 adresses. Ces plages ne se chevauchent pas et se situent dans la plage IP globale du VPC.

Nous nous retrouvons avec cette architecture :

Architecture VPC sous-réseau

Ajouter une passerelle Internet et une table de routage

Ensuite, nous créons une passerelle Internet. Cela permet aux instances dans VPC d’accéder à Internet. Elle permet aussi à Internet d’accéder aux serveurs du sous-réseau public :

InternetGateway:
    Type: AWS::EC2::InternetGateway
  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref VPC 

Dans les coulisses, la passerelle Internet n’a aucun moyen de s’associer à notre VPC. Vous devez donc créer une ressource « AWS::EC2:: VPCGatewayAttachment » pour effectuer cette tâche.

Ensuite, nous créons une table de routage, ainsi que quelques ressources connexes :

PublicRouteTable:
    DependsOn: AttachGateway
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
  PublicDefaultRoute:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
      RouteTableId: !Ref PublicRouteTable
  PublicRouteAssociationA:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable
      SubnetId: !Ref PublicSubnetA 

La Table de Routage n’a qu’une seule propriété, « VpcId: !Ref VPC », qui s’associe à un VPC.

Les ressources Route (« AWS::EC2::Route ») contiennent une seule route, qui pointe une plage d’adresses IP vers une passerelle. La Route s’associe à la Table de Route.

Une Association de Table de Routage de Sous-réseau relie la table de routage à un sous-réseau. Dans ce cas, la table de routage dirige tout le trafic de PublicSubnetA vers Internet.

Il faut noter l’attribut « DependsOn ». En principe, CloudFormation est plutôt bon pour faire tourner les dépendances dans le bon ordre. Cependant, vous pouvez utiliser l’attribut « DependsOn » pour définir explicitement une dépendance.

Cette architecture montre l’ajout de la Passerelle Internet et de la Table de Routage :

VPC table de routage

Répliquer les sous-réseaux pour une haute disponibilité

Enfin, nous répliquons les sous-réseaux dans une nouvelle zone de disponibilité pour faciliter la haute disponibilité.

PublicSubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 1
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.16/28
      MapPublicIpOnLaunch: true
      VpcId: !Ref VPC
  PrivateSubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Select
        - 1
        - !GetAZs
          Ref: AWS::Region
      CidrBlock: 192.168.101.48/28
      MapPublicIpOnLaunch: false
      VpcId: !Ref VPC
  PublicRouteAssociationB:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable
      SubnetId: !Ref PublicSubnetB 

C’est à peu près la même chose que ce que nous avons déjà créé pour les sous-réseaux publics et privés A.

Comme précédemment, les plages d’adresses IP sont uniques et ne se chevauchent pas. La principale différence avec l’ensemble B est qu’ils sont provisionnés dans la deuxième zone de disponibilité plutôt que dans la première.

Il faut noter que PublicSubnetB a besoin de sa propre association de route, car il s’agit d’une association par sous-réseau.

Enfin, vous vous retrouvez avec cette jolie architecture VPC :

architecture Serveur Privé Cloud

Vous avez maintenant l’infrastructure réseau pour lancer des instances EC2, des bases de données ou d’autres ressources AWS avec une sécurité de base ! Vous pouvez utiliser ce modèle comme point de départ pour de futurs projets.

Ou vous pouvez télécharger tous ces articles ensemble dans un eBook pratique en cliquant sur le lien ci-dessous. Merci d’avoir lu !

À lire aussi

Guide complet du logiciel en tant que service (SaaS)

Mis à jour le: 15 février 2020 Découvrez comment fonctionne le Logiciel En tant Que …

Share via
Copy link