Quelques heures avec Terraform : outiller le provisioning Amazon Web Services

Actualité ekino -

Gérer le cycle de vie d'une infrastructure normée sur Amazon Web Services

Article paru le :
Article paru le :

Depuis des années, les besoins d’industrialisation des composants du SI se sont étendus.

Nous avons, dans un premier temps, industrialisé le cycle de vie des applications (code) avec la création d’outils de build, test et déploiement (Rspecs, Jenkins, Capistrano, Fabric…). En parallèle, nous avons industrialisé le cycle de vie des plateformes au sens large avec l’émergence d’outils permettant une gestion déterministe des briques runtime et OS des serveurs (Puppet, Chef, Ansible, Salt…).

La dernière étape logique de cette industrialisation était donc la gestion du cycle de vie de l’infrastructure (facilitée par l’adoption massive du cloud et de la virtualisation) avec l’apparition d’outils permettant la description de composants devenus virtuels tels que le réseau, le stockage, les machines ou encore les pare-feus (Cloudformation, Heat, …).

C’est sur cette derniere étape, l’Infrastructure as Code, que nous allons nous pencher.

Le besoin est donc bien sur de pouvoir créer et supprimer des ressources, mais surtout gérer efficacement leur modification dans le temps : connaitre l’état actuel, comparer à l’état attendu et en déduire les actions de modifications à réaliser.
Par exemple : lire la configuration actuelle d’un pare-feu, analyser la configuration souhaitée, et en déduire qu’il faut ajouter le flux HTTPS à destination d’un serveur.

Par ailleurs, on souhaite généralement pouvoir travailler sur une base de fichiers texte, intégrables dans tout système de gestion de version (git, mercurial, tfs…), afin de bénéficier d’historisation, diff, …

Divers outils sont apparus sur le marché pour répondre à cette problématique, la plupart limités à un périmètre restreint ou à un service de cloud donné.

Un nouvel arrivant, Terraform,  tente d’unifier la gestion d’une infrastructure multi fournisseurs. Cet article a pour but de présenter le résultat de quelques heures de tests de Terraform sur Amazon Web Services.

Terraform & cas d’usage

Terraform est développé par Hashicorp, éditeur de 2 produits bien connus : Vagrant et Packer.

Il permet de gérer différents environnements cibles, appelés providers. À date, en version 0.3.5, ces providers incluent entre autres Amazon Web Services, Google Cloud, Microsoft Azure, Digital Ocean, et Heroku. Le produit étant relativement jeune, il ne permet pas encore de gérer l’intégralité des ressources de chaque provider.

Pour nos tests, nous avons choisi comme cas d’usage la gestion d’une plateforme web “type” sur AWS : le projet “Skynet” pour notre client “Cyberdyne”.

Avant de commencer

Un peu de terminologie Amazon Web Services :

  • VPC ou Virtual Private Cloud : Amazon Virtual Private Cloud (Amazon VPC) vous permet de mettre en service une section du cloud Amazon Web Services (AWS) qui a été isolée de manière logique et dans laquelle vous pouvez lancer des ressources AWS dans un réseau virtuel que vous définissez.
  • Subnet : le VPC est découpé en sous-réseaux (subnets), pouvant disposer de routages spécifiques (leur donnant par exemple accès à internet).
  • AZ ou Availability Zone : AWS est disponible sur plusieurs zones géographiques (Amérique du Nord, Irlande, Allemagne, …). Chaque zone géographique est découpée en 2 à 4 Availability Zones (AZ), elles mêmes constituées d’un ou plusieurs datacenters. Répartir ses ressources sur plusieurs AZ permet d’obtenir un meilleur taux de disponibilité des services.
  • Security group : un security group est un ensemble de règles d’ouvertures de flux réseau (ouverture du flux ssh depuis une IP source précise, ouverture du HTTP depuis tout internet, …).
  • RDS ou Relational Database Service : service de base de données managées. On provisionne un type de moteur (mysql, postgresql, …), une capacité. AWS gère backups, upgrades mineures, réplication …
  • ELB ou Elastic Load Balancing : service de partage de charge qui permet de répartir un flux entrant vers plusieurs serveurs (ou instances) cibles.

 

Dans la pratique

Notre plateforme sera composée de 3 niveaux :

  1. niveau Load-Balancing,
  2. niveau rendu avec 3 frontaux web répartis sur des AZ,
  3. niveau de persistance avec les bases de données.

 

architecture AWS de la plateforme de test

Nous souhaitons également normer le nommage des ressources et utiliser les tags Amazon (très utiles pour l’identification des ressources, la gestion des droits et l’analyse de coûts). Nous avons rencontré quelques problèmes sur ce point et levé ainsi des incohérences dans les règles de nommage autorisées par AWS ; par exemple : la plupart des noms peuvent contenir des “_”, mais pas les ELB qui n’autorisent que les “-“.

Le code Terraform est de type déclaratif : il n’y a pas de contrainte d’ordonnancement. Cependant nous recommandons de garder une certaine logique dans l’écriture du code.

Terraform fonctionne avec des fichiers de configuration JSON, format très connu et réputé pour les interactions entre systèmes,  mais peu pour sa lisibilité par une personne physique. Ainsi Hashicorp introduit un langage de définition orienté utilisateur appelé HCL (Hashicorp Configuration Language). L’extension des fichier attendu pour ces fichier de configuration est .tf

Note: Un plugin de syntaxe HCL pour Sublime Text (editeur disponible sur Mac, Windows et Linux) est disponible ici : https://github.com/MerlinDMC/sublime-terraform

Définition de l’infrastructure

La définition se déroule en 5 temps :

  • Presets : Variables et Credentials
  • Network : VPC et Subnets
  • Firewall : Security Groups
  • Servers : EC2, ELB & RDS
  • DNS : Route53

Variables et credentials

On définit ici un certain nombre de paramètres qui seront repris tout au long du code dont :

  • nom du client,
  • nom du projet,
  • régions de déploiement AWS,
  • second octet du réseau cible.

Note :
Dans cette démonstration les credentials d’API AWS sont inclus dans le fichier de configuration. N’incluez jamais vos credentials dans le code source !
Pour un usage réel il conviendra de les externaliser dans un fichier séparé. Ce fichier pourra être ignoré par le systeme de versioning si le code y est soumis (ex: .gitignore).
Cette solution présente l’avantage de ne pas avoir à passer les variables en argument de chaque appel à Terraform.

VPC et subnets

Nous définissons ici :

  • 1 VPC,
  • 3 subnets front avec routage public pour les serveurs web (1 subnet par AZ),
  • 3 subnets back pour les bases de données (1 subnet par AZ).

 

Chaque composant Terraform doit avoir un nom. Celui ci doit être unique et n’est utilisé que par Terraform pour références interne entre les composants. Les noms n’ont aucun impact sur votre infrastructure cible !
Dans notre exemple, le VPC est nommé en interne « vpc33 ». Il sera utilisé lors de la création des Subnets pour référencer le VPC auquel ils appartiennent « vpc_id = « ${aws_vpc.vpc33.id} ».

Security groups

Nous définissons ici :

  • un SG autorisant le HTTPS entrant depuis internet vers les LB.
  • un SG autorisant le HTTP entrant depuis les LB vers les WEB.
  • un SG autorisant le SSH entrant et ICMP depuis une IP spécifique vers toutes les instances.
  • un SG autorisant le flux MySQL entrant depuis les WEB (permettant à l’application de se connecter à la base de données).

 

Note: Terraform ne permet que la définition des règle ingress; les règles egress ne sont pas encore gérées.

Instances EC2, ELB & RDS

Nous définissons ici :

  • 1 LB (load balancer, endpoint SSL qui renvoie le traffic HTTP sur le port 80 des instances EC2).
  • 3 EC2 (machines virtuelles, pour lesquelles on indique capacité, taille de disque, etc…)
  • 1 RDS (base de donnée, ici MySQL).

DNS

Enfin, l’ensemble des ressources étant défini, il convient maintenant de prévoir quelques entrées DNS qui permettront de tester le service et de se connecter plus aisément aux serveurs :

 

Notre configuration est prête, reste à l’exécuter !

 

Création

L’exécution se passe en 2 étapes.

Dans un premier temps :

Terraform va parser la configuration, relever d’éventuelles erreurs de syntaxe, vérifier l’état des ressources & configurations existantes, « calculer » les dépendances entre les ressources et définir un plan d’exécution.
Ce plan sera affiché à l’utilisateur sur la sortie standard (user-friendly) et dans le fichier plan.out (format terraform)
Il recense les actions à réaliser (création +, modification ~, suppression -) pour arriver à l’état cible.

Cette étape est obligatoire et permet à l’opérateur de contrôler les actions qui vont être effectuées si la configuration est effectivement appliquée.
Lorsque l’on connait les potentiels risques à modifier automatiquement toute une infrastructure, on apprécie cette approche “dry-run obligatoire”.

Un exemple de ce plan tel que rendu à l’utilisateur (sortie standard) :

Dans un second temps, nous lançons maintenant la création des ressources à proprement parler :

terraform apply plan.out

Un exemple d’exécution du plan :

L’exécution prend quelques minutes en fonction des tâches à réaliser (la création des instances EC2 est asynchrone, mais pas celle des instances RDS)

Comme indiqué par les dernières lignes de la commande, l’état post exécution est sauvé en local dans un fichier .tfstate. Ce fichier est essentiel car il permet de faire le diff pour les exécutions suivantes !

Modification

Nous allons maintenant modifier la configuration de l’ELB pour supprimer l’un des nœuds. Dans la configuration indiquée plus haut, la ligne :

devient :

Exécutons maintenant un plan et un apply :

Terraform indique les modifications qu’il va apporter, qu’elles soient ajouts, éditions ou suppression de ressources.
Ici, comme demandé, l’une des instances sera retirée du pool du load balancer mais…. il indique aussi qu’il va supprimer et recréer la base RDS !

La raison en est indiquée : c’est le paramètre password. Il s’agit d’un bug identifié : https://github.com/hashicorp/terraform/issues/689

L’apply se déroule comme « prévu », en modifiant l’ELB et en supprimant / recréant la base de données RDS :

Destruction

Notre test (ou le projet) arrivant à sa fin, il est temps de détruire l’environnement. La commande est simple : terraform destroy.

Si l’intégralité de votre infrastructure n’est pas gérée par terraform vous pouvez avoir un doute sur les ressources qui vont effectivement être détruites.
Dans ce cas, il est aussi possible de passer par un plan intermédiaire :

Avant de détruire les ressources :

Quelques messages d’erreur attirent notre attention. Il s’agit, là aussi, d’un type de bug que l’on rencontre actuellement sur le produit : les erreurs d’ordonnancement dans les opérations.

Si Terraform arrive sans problème à gérer l’ordre de création des ressources, il rencontre encore des soucis pour les suppressions. Heureusement les messages sont relativement explicites et la fin des suppressions pourra être réalisée en exécutant une seconde fois la commande ou encore manuellement.

Conclusion

Sur le principe, clairement, Terraform apporte un plus dans la gestion de l’écosystème “cloud”. Le produit, bien que jeune, est déjà prometteur. De plus, l’historique de Hashicorp sur Vagrant et Packer laisse espérer un produit de qualité à terme.

Quelques points rendent cependant son utilisation “en production” délicate pour le moment. Entre autres (en v0.3.5) :

  • une tendance à détruire et recréer les ressources lorsqu’elles pourraient être simplement modifiées ;
  • impossible d’utiliser les variables d’environnement $AWS_ACCESS_KEY et $AWS_SECRET_KEY alors qu’ils s’agit de standards pour l’utilisation des outils AWS en ligne de commande ;
  • pas de gestion des tags sur les bases RDS et sur les volumes EBS ;
  • impossible de créer une base RDS avec un disque SSD ;
  • des bugs de gestion des dépendances lors du destroy ;
  • sauvegarde de l’état en local (dans le fichier tfstate), au lieu d’une lecture systématique de l’état réel.

 

Reste qu’en l’état, pour à minima gérer la création rapide d’environnements AWS proprement normés et définis, son utilisation permet de gagner un temps et une qualité considérables ! C’est exactement ce que l’on attend de lui.

Nous suivrons donc de près les prochaines releases, et profiterons de l’occasion pour tester son utilisation sur les autres plateformes cloud majeures du marché.

Matthieu Fronton ( @frntn ) & Axel Pavageau ( @axelpavageau )

Laisser un commentaire