Maintenez l'ordre et gagnez du temps - Infrastructure en tant que Code

Chez Droptica, les serveurs jouent un rôle très important, car nous hébergeons des sites web et des applications développés par nos soins. En implémentant l'Infrastructure as Code dans notre entreprise, nous avons réussi à augmenter la stabilité et la disponibilité des services et à optimiser le temps nécessaire pour apporter des changements dans l'infrastructure. La gestion automatique des serveurs a grandement simplifié plusieurs de nos processus.

Infrastructure as Code - de quoi s'agit-il ?

Jusqu'à récemment, la plupart des entreprises opérant dans le secteur IT et fournissant des services liés au Web devaient avoir leurs propres serveurs, ce qui nécessitait beaucoup de préparation – les installer dans des centres de données, configurer le système d'exploitation, le réseau, mettre en place des mécanismes de sécurité et se préparer à la fourniture des services.

Cependant, cette tendance a changé depuis quelques années. Nous assistons actuellement à la révolution du Cloud – des solutions où des acteurs puissants du marché du traitement de données offrent leurs ressources inutilisées, le plus souvent sous forme de machines virtuelles qui peuvent être provisionnées en quelques clics. Dans ce cas, vous n'avez pas à vous occuper de tout le processus de préparation d'un environnement basé sur du matériel, ce qui est en soi un excellent moyen de réduire les dépenses. Cependant, le plus grand avantage de cette solution est le provisionnement rapide et facile, qui peut être en outre automatisé par le biais des APIs fournies par les fournisseurs.

C'est là que le concept d'Infrastructure as Code apparaît – un paradigme dont l'objectif est de définir l'ensemble de l'environnement sous forme de code, qui, s'il est soumis à un processus approprié, préparera l'infrastructure décrite. Nous utilisons une telle solution sur nos plateformes d'hébergement Drupal. Cela nous aide à nous concentrer sur les services de développement Drupal plutôt que sur la gestion des serveurs.

Et maintenant, pour répondre à la question "pourquoi avons-nous décidé de mettre en œuvre IaC chez Droptica ?" Eh bien, il y a de nombreuses raisons, mais les plus importantes sont :

• stocker l'état du serveur dans le dépôt – ce qui est dans le code reflète l'état actuel et est en plus clair et compréhensible, non seulement pour les administrateurs ;
• possibilité de revenir à n'importe quel moment de l'historique – si le code est stocké dans le dépôt, alors nous connaissons tout l'historique des changements et nous pouvons facilement passer de l'un à l'autre;
• une telle représentation est facilement validée et testée, et les technologies que nous utilisons nous fournissent de tels mécanismes;
• l'automatisation du déploiement, qui accélère encore la préparation et la fourniture des serveurs dans l'environnement de production.

Comment s'y prendre ?

La mise en œuvre de l'Infrastructure as Code dans notre cas a été réduite à deux étapes – trouver le logiciel qui répondrait à nos attentes et préparer le code qui reflète l'environnement.

Dans le cas de la première étape, nous avons défini deux conditions de base :

• prise en charge de plusieurs plateformes Cloud – chez Droptica, nous ne sommes pas limités à une solution spécifique. Nous testons constamment de nouveaux produits sur le marché pour offrir à nos clients des solutions de plus en plus intéressantes et stables (actuellement nous utilisons les services proposés par AWS, Digital Ocean et Linode, entre autres).
• Infrastructure immutable – notre objectif est de stocker l'état réel de l'environnement dans un dépôt afin qu'il puisse être récupéré et restauré à tout moment. Nous ne pouvons donc pas avoir une situation où il y a eu des changements dans l'état de l'infrastructure qui n'ont pas été inclus préalablement dans le code – c'est une définition pratique du paradigme de l'infrastructure immutable. 

Sélection de l'outil

Il existe de nombreux outils disponibles sur le marché qui vous permettent de mettre en œuvre l'Infrastructure as Code. Dans nos délibérations, nous en avons pris en compte un certain nombre, y compris Ansible, Cloud Formation et Terraform, que nous avons finalement décidé d'utiliser.

Bien que la tâche principale d'Ansible ne soit pas l'orchestration d'environnements mais la gestion des configurations, l'outil dispose de modules qui lui permettent de fonctionner avec les services de cloud computing. Cette solution semble très pratique. Le code responsable de la configuration souhaitée de l'infrastructure et sa configuration ultérieure peuvent être stockés et maintenus dans un seul dépôt. Cependant, contrairement aux deux autres, Ansible utilise un style de code procédural où nous spécifions les tâches à accomplir étape par étape. Dans certains cas, cela peut conduire à des modifications non intuitives dans le code, comme montré dans l'exemple ci-dessous.
Le code simplifié dans Ansible, qui créera 10 machines virtuelles, ressemble à ceci :

- ec2:
    count: 10
    image: ami-v1    
    instance_type: t2.micro

Et le même dans Terraform :

resource "aws_instance" "example" {
  count = 10
  ami = "ami-v1"
  instance_type = "t2.micro"
}

Après l'exécution des deux extraits de code, nous obtiendrons le même résultat – 10 serveurs virtuels seront provisionnés dans AWS. Toutefois, que se passe-t-il si vous décidez d'augmenter le nombre à 15 ?

Dans le cas d'Ansible, l'état actuel n'est stocké nulle part, donc si vous augmentez le nombre de serveurs dans le code à 15, vous en fournirez exactement autant. Au final, vous en aurez 25, c'est pourquoi le nombre de nouvelles machines inclus dans le code doit être de 5 :

- ec2:
    count: 5
    image: ami-v1    
    instance_type: t2.micro

Tant CloudFormation que Terraform stockent des informations sur l'état actuel de l'infrastructure, donc le changement est cosmétique et beaucoup plus intuitif :

resource "aws_instance" "example" {
  count = 15
  ami = "ami-v1"
  instance_type = "t2.micro"
}

Pour cette raison, nous avons décidé de ne pas utiliser Ansible. Cloud Formation a été écarté pour une raison beaucoup plus simple – c'est un outil dédié à AWS, donc il ne remplit pas notre première condition – il ne fonctionne pas avec de nombreux fournisseurs. 

Comment fonctionne Terraform ?

Dans cette partie de l'article, nous vous présenterons un court guide pratique, qui vous permettra de faire vos premiers pas dans le domaine de l'automatisation et de la mise en œuvre d'IaC. Nous allons nous concentrer sur Ubuntu car nous utilisons cet environnement chez Droptica au quotidien.

Installation

Terraform se trouve désormais dans les dépôts officiels Ubuntu / Debian, mais le développeur fournit des paquets prêts à être décompressés et installés.

wget https://releases.hashicorp.com/terraform/0.11.2/terraform_0.11.2_linux_amd64.zip
unzip terraform_0.11.2_linux_amd64.zip
cp terraform /usr/local/bin

Installation des plug-ins

Tous les fournisseurs de cloud ne sont pas pris en charge nativement, vous pourriez donc avoir besoin d'installer des plug-ins pour certains d'entre eux, par exemple Linode et OVH. Dans la plupart des cas, ces procédures sont bien décrites dans les dépôts, comme dans les deux cas suivants :

• Linode - https://github.com/btobolaski/terraform-provider-linode
• OVH - https://github.com/remijouannet/terraform-provider-ovh

Les plug-ins compilés doivent être copiés dans le répertoire  ~/.terraform.d/plugins

Décrire le premier serveur

Utiliser Terraform est vraiment simple ! Le code montré ci-dessus est suffisant pour créer la première machine virtuelle dans AWS, mais traitons d'une question légèrement plus compliquée.

resource "aws_instance" "server-01" {
  ami               = "ami-0d77397e"
  availability_zone = "eu-west-1a"
  instance_type     = "t2.large"

  root_block_device {
    volume_type = "gp2"
    volume_size = "120"
    delete_on_termination = "true"
  }

  tags {
    Name = "server-01"
    Org  = "droptica"
  }
}

L'exemple ci-dessus conduira également à la création d'un nouveau serveur virtuel nommé server-01 dans AWS – cela est spécifié par le type de ressource aws_instance. Ensuite, vous devez remplir les paramètres nécessaires (définis dans la documentation AWS) :

• ami – identifiant d'image (dans notre cas Ubuntu Server 16.04) ;
• availability_zone – région et zone dans lesquelles le serveur sera provisionné ;
• instance_type – le type et la taille de l'instance.

Dans la section root_block_device, vous pouvez spécifier les paramètres du disque qui sera associé à cette instance ; dans notre cas, nous avons opté pour le type gp2 de base avec une taille de 120 Go.

Exécuter le code

Après les préparations nécessaires, le code est prêt à être exécuté. Cependant, avant de mettre en œuvre les changements dans l'environnement cible, il est préférable de lire la liste des étapes qui seront effectuées. Cela vous permettra de détecter d'éventuelles erreurs dans le code. Pour le faire, il suffit de lancer la commande :

$ terraform plan

Si tout est correct, il ne vous reste plus qu'à exécuter le code et appliquer les changements :

> terraform plan
aws_instance.example: Refreshing state... (ID: i-6a7c545b)
(...)
~ aws_instance.example
   tags.%:    "0" => "2"
   tags.Name: "" => "server-01"
   tags.Org: "" => "droptica"
Plan: 1 to add, 0 to change, 0 to destroy.

Si tout est correct, il ne vous reste plus qu'à exécuter le code et appliquer les changements :

terraform apply

Et après ?

La description de la machine elle-même n'est que le début, car les services de cloud computing sont maintenant si étendus qu'ils permettent de créer une architecture beaucoup plus complexe. Chez Droptica, nous avons défini, entre autres, le réseau (à la fois public et privé), les serveurs qui hébergent nos sites web, les bases de données et les équilibreurs de charge – en bref, nous avons créé une plateforme d'hébergement fiable basée sur AWS.

Pour ceux qui veulent connaître toutes les possibilités de Terraform, je recommande de lire la documentation, et si vous souhaitez l'essayer, le guide officiel sera le point de départ idéal pour vous.