Ce blog démarre une série d’articles consacrée à l’outil Terraform.

Dans ce premier article, nous aborderons le concept d’Infrastructure as Code, les différentes catégories d’outil, un focus sur Terraform.

Un deuxième article traitera de la prise en main de Terraform dans le cadre Azure. Nous aborderons l’installation, l’authentification, le provisioning.

Un troisième article ou nous approfondirons plusieurs sujets : les états, le remote backend, les workspace et bien plus.

 

L’IaC, qu’est-ce que c’est ?

Avant de parler de Terraform, il est important de faire un petit rappel et ainsi d’évoquer la notion d’Infrastructure as Code (ou IaC).

Lorsque l’on parle d’IaC, on fait référence à la possibilité d’administrer et d’automatiser le déploiement ou la mise à jour d’une infrastructure à travers du code, contre un processus manuel. L’Infrastructure as Code représente un important changement d’état d’esprit quand on traite d’infrastructure programmable. L’Infrastructure as Code peut être utilisé dans plusieurs environnements informatiques. Mais il est très utilisé voir essentiel dans le Cloud public/privé.
De plus, la philosophie DevOps pousse à travailler en Agile et à automatiser tout ce qui peut être automatisable.

Il existe quatre grandes catégories d’outils d’IaC :

• Les scripts classiques de type bash (ad hoc scripts)
• Les outils de gestions de configuration (configuration management tools)
• Les outils de template serveur (server templating tools)
• Les outils de provisionnement de serveur (server provisioning tools)

 

Scripts ad hoc

L’approche la plus directe pour automatiser n’importe quoi qui peut être faite à la main est de faire des scripts de type bash, python, ruby et de les exécuter côté serveur.

Dans l’exemple suivant, nous avons un script nommé « install-jenkins.sh » écrit en bash que l’on exécute côté serveur, qui va nous permettre d’installer l’application Jenkins.

#!/bin/bash
# Add the repo key to the system
wget -q -O - https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add -
# Add the repo add to the server's sources.list
echo deb https://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list
# Update for using the new repo
sudo apt update
# Verify if default-jre are installed
var1="default-jre"
var2="aptitude"
sudo apt install $var2
if [ `aptitude search $var1 | tr -s " " | cut -d " " -f 1,2 | grep "^i" | wc -l` -ne 0 ];
        then echo "$var1 INSTALLE";
        else sudo apt -y install $var1; fi
# Installation of jenkins
sudo apt install jenkins
# Starting jenkins.service
sudo systemctl start jenkins
# Status to verify that it started successfully
sudo systemctl status jenkins

L’avantage de ce type de scripts et qu’il utilise des langages connus et que ce code peut être simplement écrit. Ce type de langage est personnalisable en fonction des tâches que l’on souhaite effectuer, contrairement aux outils spécialement conçus pour l’IaC. Ces outils utilisent une structure particulière avec des API fournis pour effectuer des tâches plus complexes. L’utilisation de scripts est intéressante pour des tâches automatisables, simples, comme l’installation d’une application, mais devient beaucoup plus complexe quand il va s’agir de gérer plusieurs serveurs, bases de données, etc.

 

Outils de gestion de configuration

Il existe plusieurs outils de gestion de configuration tels que Chef, Puppet, Ansible et Saltstack qui sont utilisés pour installer et gérer des applications (software) dans un serveur existant.

Dans l’exemple suivant, nous utilisons un « playbook » Ansible « web-server.yml » pour installer toute une stack web qui comprend Ngnix, MySQL et PHP.

- name: Install Nginx
  apt:
    name: nginx
    state: latest
- name: Instal PHP-FPM
  apt:
    name: ['php','php-fpm','php-common','php-cli','php-curl']
    state: latest
- name: start nginx
  service:
    name: nginx
    state: started
    enabled: yes
- name: start php-fpm
  service:
    name: php{{ php_version }}-fpm
    state: started
    enabled: yes

On peut appliquer cette nouvelle configuration à plusieurs serveurs en spécifiant leur adresse IP dans un fichier appelé « hosts » :

[webservers]
10.0.0.1
10.0.0.2
10.0.0.3

On peut appliquer les configurations avec la commande suivante :

ansible-playbook -i hosts web-server.yml

Le problème avec les scripts classiques de type bash est qu’ils ne peuvent souvent pas s’exécuter à plusieurs reprises, car il faut garder en tête tout ce que le script a, ou créé, ou exécuté lors de la première exécution (dossiers, fichiers, services, etc.) , et donc changer le script en conséquence en ajoutant de nouvelles lignes et des conditions if-then pour s’adapter à tout changement. Donc, écrire un script qui peut être exécuté à plusieurs reprises est plus compliqué.
On appelle un script qui peut s’exécuter correctement plusieurs fois, idempotent.
Ansible inclut plusieurs fonctionnalités idempotentes par défaut. Dans l’exemple ci-dessus, l’installation des applications ne va se faire que si elles ne sont pas installées, et de la même manière, elles ne vont pas s’exécuter si elles sont déjà en cours d’exécution.

Contrairement à un script classique qui peut être exécuté que sur une machine, Ansible permet d’exécuter un script (Playbook) sur une ou plusieurs machines en série, en spécifiant l’adresse IP de chaque serveur cible.

 

Outils de Template serveur

Les outils de Template serveur sont de plus en plus utilisés comme alternative aux outils de gestion de configuration avec Docker, Packer et Vagrant.
Au lieu de monter des serveurs et d’exécuter des scripts de configuration dans chacun d’eux, on crée une image d’un serveur (avec son OS, logiciels, fichiers, etc.) et on utilise un outil comme Ansible pour installer l’image sur plusieurs serveurs.
On peut ainsi affecter un numéro de version à chaque image créée et donc revenir à une précédente version si un problème survient.

Dans le cas d’Azure, chaque machine virtuelle est créée à partir d’une image qui définit la distribution Windows et la version du système d’exploitation. Les images peuvent inclure des configurations et des applications préinstallées.
Par exemple, ci-dessous, vous pouvez trouver un Template Packer au format .json pour créer une machine virtuelle sur Azure.

{
  "builders": [{
    "type": "azure-arm",
    "managed_image_resource_group_name": "myPackerGroup",
    "managed_image_name": "myPackerImage",
    "os_type": "Windows",
    "image_publisher": "MicrosoftWindowsServer",
    "image_offer": "WindowsServer",
    "image_sku": "2016-Datacenter",
    "communicator": "winrm",
    "winrm_use_ssl": true,
    "winrm_insecure": true,
    "winrm_timeout": "5m",
    "winrm_username": "packer",
    "azure_tags": {
        "dept": "Engineering",
        "task": "Image deployment"
    },
    "location": "East US",
    "vm_size": "Standard_DS2_v2"
  }],
  "provisioners": [{
    "type": "powershell",
    "inline": [
      "Add-WindowsFeature Web-Server",
      "& $env:SystemRoot\System32\Sysprep\Sysprep.exe /oobe /generalize /quiet /quit",
      "while($true) { $imageState = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State | Select ImageState; if($imageState.ImageState -ne 'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { Write-Output $imageState.ImageState; Start-Sleep -s 10  } else { break } }"
    ]
  }]
}

Source : https://docs.microsoft.com/fr-fr/azure/virtual-machines/windows/build-image-with-packer

On pourra exécuter ce Template à l’aide de la commande Packer suivante :

./packer build windows.json

Ce Template construit une VM Windows Server 2016, installe IIS, puis prépare la VM avec Sysprep.
L’installation d’IIS montre comment vous pouvez utiliser PowerShell pour exécuter des commandes supplémentaires.

Chaque outil de Template serveur a un but précis :

• Packer est utilisé pour créer une image qui sera directement utilisée sur un ou plusieurs serveurs en production.
• Vagrant va être utilisé pour créer des images qui vont être utilisées sur des machines de développement comme une image VirtualBox que l’on puisse démarrer depuis une machine Windows, Mac ou Linux.
• Docker va être utilisé pour créer une image d’une application spécifique. Les images Docker peuvent être utilisées sur des machines de production ou développement.

 

Outils de provisionnement de serveur

Les outils de template serveur ou de gestion de configuration vont servir à définir un code qui va être exécuté sur un ou plusieurs serveurs alors que les outils de provisionnement de serveur comme Terraform, CloudFormation, OpenstackHeat, sont utilisés pour créer les serveurs en question.
Ces outils de provisionnement peuvent être utilisés pour créer des espaces de stockages, interfaces réseau, bases de données, des répartiteurs de charge (load balancer), sous-réseaux, pare-feu, etc.
Ces outils sont capables de provisionner les principaux services proposés par les différents Cloud Public.

 

Terraform vs les autres

Terraform est un outil créé en 2014 par la société HashiCorp qui est aussi à l’origine du développement d’autres outils comme :

• Consul : Service Mesh distribués permettant de connecter, sécuriser et configurer des services sur toutes les plates-formes d’exécution et les Clouds publics ou privés.
• Vagrant : système pour configurer, distribuer et virtualiser le travail, le développement, et les environnements de production.
• Packer : permets l’automatisation de la création de n’importe quel type d’images à partir d’un simple fichier de configuration.
• Vault : permets de stocker des secrets de manière sécurisée, tels que vos mots de passe, vos clés privées, vos identifiants de connexion.
• Nomad : gestionnaire de cluster et un planificateur distribué, hautement disponibles et sensibles au centre de données, qui permet de déployer des applications sur n’importe quelle infrastructure, à n’importe quelle échelle, sur site ou dans le Cloud.
• Atlas : réunit les outils open source populaire de HashiCorp pour le développement et la gestion d’infrastructure afin de créer un système de contrôle de version pour l’infrastructure.

Terraform est un outil open source écrit en Go et repose sur une architecture basée sur les plugins. Le code Go est compilé en un seul binaire (un binaire pour chacun des systèmes d’exploitation supportés). Son code source est disponible sur Github. C’est un outil suivi de très près par une large communauté qui le met à jour très fréquemment.

Cet outil permet de construire, modifier et versionner une infrastructure. Il permet de gérer plusieurs providers au sein d’un même Template de configuration.

Il existe certains outils qui peuvent fournir les mêmes services (on peut par exemple citer l’outil CloudFormation), mais ces outils à l’inverse de Terraform sont basés sur des infrastructures précises ou propriétaires. En effet, CloudFormation est un outil permettant de provisionner des ressources à travers du code, mais seulement avec le Cloud AWS (Amazon Web Services).

Terraform propose lui, une transparence totale vis-à-vis des plateformes sur lesquelles il opère.
Par défaut, il supporte plusieurs « Cloud providers » comme Amazon Web Services, Microsoft Azure ou Google Cloud Plateform (les références du Cloud public). Ainsi, Terraform peut provisionner des ressources sur chacun des Cloud providers séparément ou conjointement.
Le langage utilisé pour développer des ‘scripts’ Terraform est le HCL (HashiCorp Configuration Language) et le JSON. Le HCL est un langage propre à Terraform qui se veut plus lisible et facilement compréhensible pour les utilisateurs.

Dans cet article nous avons vu en quoi consiste l’Infrastructure as Code ainsi que les quatre catégories d’outils qui utilisent cette approche.
Lors du prochain article, nous aborderons certaines notions liées à Terraform afin de bien le cerner. Puis sa prise main pour bien commencer.
À terme, le but de ces articles sera de montrer en quoi Terraform est un outil puissant et s’il correspond à vos besoins.