Dans le billet de blog précédent, nous avons présenté les généralités sur les cloud Provider et avons fait une rapide présentation des frameworks.

Sur quoi Terraform et CloudFormation étaient construit ? Nous avons compris qu’il s’agissait d’interagir le plus efficacement possible avec les multiples API. Pour Terraform, il s’agissait d’organiser, avec le HCL, les multiples API/AWS. Du côté de CFN**,** les équipes de AWS proposaient leur propre API. Cette gestion des API, permettait d’introduire une description sur la logique interne de ces deux frameworks. Avec Terraform, l’infrastructure souhaitée était stockée, avant déploiement ou redéploiement, dans un tfstate, même logique avec Cfn avec le concept de stack. A partir de ces états, il est possible de calculer les écarts entre ce qui souhaité et ce qui est disponible.

Place à la pratique ! Dans ce deuxième billet de blog, nous allons construire un environnement d’infrastructures avec l’outil Terraform afin de vous montrer comment prendre en main l’outil et aussi comment enrichir une infrastructure d’éléments mis à notre disposition par les objets AWS.

Gestion de votre infrastructure Cloud chez AWS avec Terraform :

Concernant terraform, l’état de votre infrastructure est stocké dans un fichier « terraform.tfstate » (https://www.terraform.io/docs/language/state/index.html) au format json.  A partir de ce fichier stocké, il va pouvoir comparer l’état déployé à ce qui est voulu.

Pour illustrer la gestion de votre infrastructure, prenons le cas concret de la création d’une architecture simple : mise à disposition d’un serveur Web sur AWS

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

https://github.com/bobiwembley/aws\terraform\demo

• Création d’un VPC. (Virtual Private Cloud) :

Network : 10.10.0.0/16

Subnet privé : 10.10.0.0/24

Une Gateway pour accéder à l’extérieur

Schéma d’un simple VPC

• Création d’une instance Ec2 (simple server Web)
• Création d’un groupe de sécurité (autoriser le 22 et le 80 pour se connecter sur le serveur)

Un fichier comportant les éléments du réseau :

• vpc.tf

resource "aws_vpc" "WebServerVpc" {
    cidr_block         = "${var.vpc_cidr}"
    enable_dns_support = "true"
    enable_dns_hostnames = "true" #gives you an internal host name
      tags      = {
          Name = "WebServer"        
      }
  }

Un fichier comportant les éléments de computing :

• ec2.tf

resource "aws_instance" "WebServer" {
	ami                    = "${lookup(var.amis,var.region)}"
	key_name               = "${var.key_name}"
	source_dest_check      = false
	instance_type          = "t2.micro"
	subnet_id = "${aws_subnet.subnet_WebServer_public.id}"
	vpc_security_group_ids = ["${aws_security_group.WebServer.id}"]
}

Un fichier comportant les éléments de sécurité (ACL/FireWall de notre infra) :

• security.tf

resource "aws_security_group" "WebServer" {
    name = "Ec2-WebServer-Group"
    vpc_id      = "${aws_vpc.WebServerVpc.id}"
    ingress  {
      cidr_blocks = ["0.0.0.0/0"]
      description = "authorize 80 on ec2 WebServer"
      from_port   = 80
      protocol    = "tcp"
      self        = false
      to_port     = 80

En dernier, nous mettons en place un fichier de variables afin de faire le setting des valeurs :

• variables.tf

variable "vpc_cidr" {
  type    = string
  default = "10.10.0.0/16"
}

variable "subnets_cidr" {
  type    = list(string)
  default = ["10.10.0.0/24", "10.10.1.0/24"]
}

Voici la représentation de cette infrastructure avec l’outil BlastRadius que je vous conseille d’utiliser pour visualiser les dépendances d’état entre les éléments de AWS.

Représentation des dépendances entre les éléments de l’infrastructure aws\demo1 générée par Terraform

Dépendance des éléments ec2 (aws\instance WebServer) entre le group sécurité et les éléments Réseaux ( Aws\vpc & aws\subnet)

Dépendance des briques réseaux à partir de l’élément de table de routage access\route\table\association (accès à l’extérieur et aux autres subnets)

Lorsqu’on parle de scalabilité ici, il s’agit d’étendre votre infrastructure à d’autres éléments afin de rendre le service résilient. Dans ce cas simple, nous allons associer une Database SQL pour un gain de performance et de résilience de la donnée et nous allons introduire de fait un nouvel élément de AWS : le service RDS permettant de créer  des bases de données.

Représentation des dépendances entre les éléments de l’infrastructure aws\demo2 générée par Terraform

Représentation des dépendances entre les éléments de l’infrastructure aws\demo2 générée par Terraform

Nous avons ainsi introduit une complexité dans notre infra, en nous appuyant sur de nouveaux éléments. Ainsi, dans le VPC introduit par aws\demo1, nous avons ajouté :

• Un subnet supplémentaire,
• Une base de données Mysql porté par le service RDS-Aurora,
• De nouvelles règles de sécurités pour sécuriser les échanges entre le EC2 et la base de données.

Dépendance de la brique RDS aws\instance\rds de son intégration dans AWS\demo2

Conclusion :

Comme vous avez pu le voir, avec terraform, il est possible de maintenir et de répéter des schémas d’infrastructures  chez AWS. Par la suite, vous pouvez  les mettre à la disposition de vos équipes de Dev ou de Ops. Ainsi, un respect de conformité convenu par la gouvernance de vos Ops et de vos devs peut être dessiner. A Partir d’un Template de base, vous pouvez introduire un pattern d’infra partagé : mis à la disposition de vos équipes, il est possible de l’enrichir avec des éléments pour répondre à des spécificités. Dans le prochain billet, nous reproduirons cet exercice pour une prise en main de Cloudformation.

A vous de jouer !