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.
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.
L’interface designer disponible sur la Console AWS
Rendu de l’infrastructure cloud WebServer à partir de Designer
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 :
!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 :
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 :
InstanceType: !Ref 'InstanceType' KeyName: !Ref 'KeyName'`
Dans InstanceType et Keyname, la fonction intrinsèque « !ref » appelle des variables définies dans la section « 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.
Rendu de l’infrastructure cloud WebServer et ajout d’une base de données RDS (mysql) à partir de Designer
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.
