Le Cloud Computing est devenu une partie du quotidien des ingénieurs DevOps. La demande est grandissante. Les D.S.I. veulent réduire leurs coûts, séduites par l’idée du Pay-as-you-use. Les acteurs opérationnels (Infra Ingineer, Backend & Frontend Developer) ont à leur disposition des solutions packagées afin de démarrer des projets en réduisant le coût d’étude et de mise à disponibilité sur des infrastructures On-Premise. Pour préparer les lecteurs à ces billets de blogs consacrés aux outils de gestions d’infrastructure Cloud, prenons le temps d’exposer quelques concepts-clés.
Quelques considérations sur l’infrastructure Cloud :
Lorsqu’il s’agit d’aborder la question des Clouds Providers, c’est-à-dire, la possibilité d’externaliser une partie, ou bien la totalité de son infrastructure informatique chez un partenaire de cloud public. Il est nécessaire d’avoir quelques concepts clés afin d’appréhender « l’informatique dans les nuages. »
Il n’y a pas qu'un type de Cloud mais plusieurs types d’usage des Clouds, pouvant répondre aux besoins de votre S.I.
Vous pouvez identifier ainsi plusieurs stratégies d’usages telles que :
1. Le Cloud Hybride :
Vous avez des contraintes opérationnelles complexes : Vous avez besoin de rallier votre cloud On-Premise, pertinent pour vos usages legacy et/ou vos contraintes de sécurité, à des services managés par un Cloud Provider pour des contraintes de scalabilité et/ou d’accélération de Delivery.
2. Le Multi-Cloud :
La complexité de votre infrastructure, s’identifie par l’usage de plusieurs partenaires de Cloud public. Vous utilisez les possibilités offertes par différents partenaires pour répondre à des contraintes métiers ou à des choix de contraintes budgétaires.
A la différence du Cloud Hybride, nous réservons l’usage du terme MultiCloud lorsque l’infrastructure mélange plusieurs Cloud Providers publics mais exclue la présence d’un Cloud On-Premise qui est la propriété de votre S.I (hébergé dans vos Data-Centers).
3. Le Single Cloud :
Vos infrastructures sont exclusivement déployées chez un seul Cloud-Provider, vous répondez aux besoins de votre S.I par l’usage des services managés du Cloud Provider choisi.
C’est avec ces quelques rappels, en guise d’introduction, que je souhaiterai discuter des outils proposés aux équipes dédiées au maintien du code et de la gestion des services chez le Cloud Providers. Il s’agit, plus spécifiquement, de comparer deux frameworks dont la valeur ajoutée dans l’automatisation des tâches de provisonning est indéniable. La plupart des Cloud Providers offrent des API complètes afin de mieux manipuler les services proposés ou encore d’assembler des services pour construire vos propres services.
Dans le cas qui nous intéresse, il s’agira de comparer deux frameworks, Terraform & Cloudformation. Ces deux outils répondent au doux nom de frameworks d’Infrastructure As Code pour piloter vos services et le déploiement de votre code sur AWS (Amazon Web Service).
Infrastructure As Code en pratique : Terraform & CloudFormation :
Quand il s’agit de travailler sur AWS, en tant qu’ingénieur des opérations ou Lead Développeur, notre besoin est de savoir préparer l’infrastructure Cloud afin de déployer les services en vue de la demande des clients. Pour cela, nous pouvons nous tourner vers des solutions, facilement intégrables, et à haute valeur ajoutée pour réaliser des livraisons automatisables et piloter par tests.
Dans l’approche DevOps, Terraform par Haschicorp est un outil connu dont la réputation n’est plus à faire. Proposé dans la stack Infra As Code, Terraform peut s'associer à d’autres services pour construire vos infrastructures.
A côté de Terraform, vous avez le choix de CloudFormation, solution proposée par AWS. Cette solution interne du Cloud Provider permet de créer les services et d'avoir accès le plus rapidement possible aux dernières évolutions de L’infra AWS.
Ces deux Frameworks permettent de s’adresser aux multiples API de AWS pour provisionner votre architecture de services.
CloudFormation et Terraform : faire place à la description et à la combinaison :
CloudFormation (abrégé en Cfn) et Terraform sont deux produits visant à déployer, maintenir des services, modifier la nature de ceux-ci, ou encore étendre votre infrastructure Cloud publique par de nouveaux services. Ces deux frameworks orchestrent la création de vos services à travers les API mis à votre disposition par AWS.
Terraform fait appels aux APIs AWS pour provisionner vos infrastructures. Le framework est codé dans le langage Go. Concernant AWS, vous pouvez vous référer au github de Hashicorp : https://github.com/hashicorp/terraform-provider-aws
Terraform s’appuie sur le sdk-go de AWS afin de construire les catalogues de services. Il n’est pas nécessaire d’avoir des connaissances dans ce langage pour commencer à manipuler le framework. En effet, et c’est là tout l’intérêt de Terraform, il propose sa syntaxe le HCL (Hashicorp Configuration Language), couche d’abstraction supplémentaire, permettant à l’outil de prendre en charge d’autres Cloud Providers (Third Party) comme Azure, GCP, Digital Ocean, Scaleway etc.
Cfn de son côté est disponible via la console AWS ou encore, pour ceux comme moi qui préfèrent la ligne de commande dans AWS-CLI (https://github.com/aws/aws-cli) ou, bonheur, le AWS-SHELL (https://github.com/awslabs/aws-shell). La prise en charge du langage pour CFN, est dans le format YAML, ou JSON. Avec Cfn, nous uploadons via console, ou passons en paramètre avec le AWS-CLI le fichier yaml ou json de l’infrastructure souhaitée.
D’un côté, Hashicorp demande que nous nous saisissons d’une syntaxe dite « low-level » pour se représenter le service. (https://www.terraform.io/docs/language/syntax/configuration.html). La prise en main est rapide, lorsqu’on s’agit de créer le service demandé en le déclarant dans un mode « block ».
Le block doit être perçu comme un container décrivant l’état souhaité de votre service (type de service/taille du service/zone de disponibilité) et/ou propriété de ce service (règle d’accès à ce service, règle de réseau de ce service).
De l'autre côté, Cfn crée les services demandés en s’appuyant sur la possibilité d’une liste en Yaml ou en Json.
Les deux Frameworks font place à ces langages de représentations de données par clés/valeurs. Nous combinons des listes, des tableaux pour décrire l’état du service.
C’est ici que les stratégies diffèrent entre les deux sur plusieurs points.
Terraform est à installer sur votre poste local ou encore sur un serveur dédié (entrainant un coût supplémentaire de maintien dans l’upgrade). Tandis que CloudFormation est disponible sur la console AWS ou sur AWS-CLI, la Maj de l’outil se fait du côté des équipes AWS responsables de son développement.
Terraform désigne le résultat de votre infrastructure (ce que nous verrons plus loin) sous le terme de tf.state, là où Cfn la désigne sous l’intitulé de stack.
Prise en main des deux Frameworks :
Mettons en pratique ce qui a été énoncé plus haut et jetons un coup d’œil sur la rédaction et l’exécution du code Terraform et cfn.
Exemple : Création d’une ressource ec2 en mode block (terraform)
resource "aws_instance" "Kouka_exemple_tf" { ami = "ami1234" instance_type = "t2.micro" }
Exemple : Création d’une ressource ec2 en Yaml (CloudFormation)
Resources:
Ec2Instance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t2.micro
ImageId: ami1234
Pour appliquer le fichier de configuration, nous faisons appel aux commandes suivantes en (Ligne de commande).
Terraform :
terraform init
Initialisation du module AWS pour la prise en charge du Cloud provider
terraform plan (…) Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.
Vérifier la disponibilité des services demandés avant d’appliquer ceux-ci
terraform apply (…) Plan: 6 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes
Appliquer à votre infrastructure l’état souhaité
CloudFormation (avec Aws-Shell)
aws> cloudformation create-stack --stack-name KoukaDemo --parameters ParameterKey=myKeyPair,ParameterValue=kouka --region 'us-east-1' --template-body file://Cfn_demo.yml { "StackId": "arn:aws:cloudformation:us-east-1:808186499947:stack/KoukaDemo/16c1aac0-389b-11ec-891a-0a7afef9bd97" }
Exécution à partir de l’aws-shell
Résultat visible sur la console AWS
Intégration de ces outils dans l’opérabilité quotidienne du maintien de l’infrastructure :
En tant qu’Ingénieur infrastructure et opérationnel, nous avons pour coutume de déterminer notre infrastructure dans l’état le plus stable possible (Stability Infrastructure). Nous prenons en compte plusieurs paramètres afin de qualifier les conditions d’opérations du rendu de services sur les environnements IT de l’entreprise. Ainsi, nos indicateurs sont les coûts de maintien, le cycle de vie de nos services et la tolérance acceptable aux incidents éprouvant nos méthodes et nos procédures. C’est en aparté aux SysOps que cette considération s’adresse. La puissance de ces deux Frameworks bouscule l’idée de l’infrastructure stable.
En optant pour une Infrastructure Cloud, il s’agit de piloter, de mettre à la disposition de votre IT les services de votre production et/ou des autres environnements. Quelles sont les stratégies à adopter pour administrer ces écosystèmes ? Quel est l’intérêt de choisir l’un plutôt que l’autre ?
Entre Terraform et Cfn, c’est choisir en fonction de certains critères : critère de prise en main par une équipe d’infrastructure (quel est le gain ? la courbe d’apprentissage ?..) ; critère d’intégration dans un panel gestion des services (partage de cet outil ? Tolérance à la panne de services ?) ; et, à long terme, réfléchir leur intégration dans des outils d’automatisation pour gagner du temps dans la livraison ?
Conclusion :
Ici se conclut la première partie d’une suite de billets consacrés à l’Infrastructure As Code (IAC) et destinés pour une prise en main de ressources chez AWS. Nous verrons par la suite, la prise en main respective de ces outils sur des cas concrets de déploiements avec des exemples que vous pourrez reproduire.
