Dans un environnement où l’infrastructure demande de plus en plus de souplesse et d’agilité, le système qui repose sur cette infrastructure doit lui aussi être en mesure de facilement pouvoir évoluer, et être modifié en fonction des besoins présents, voire futurs.

Que ce soit à travers une solution de virtualisation ou un environnement dans le Cloud, il est devenu aujourd’hui monnaie courante de créer fréquemment des nouvelles machines en fonction du besoin. C’est le point de départ de Packer.

En juin 2013, Mitchell Hashimoto, fondateur de Hashicorp, annonce la sortie de Packer en version 0.1. Depuis, de nombreuses évolutions ont eu lieu, notamment grâce à la communauté open source, pour permettre de pouvoir répondre au mieux aux besoins des utilisateurs.

L’objectif principal de Packer est de permettre à l’utilisateur de pouvoir créer sa propre machine chez différents fournisseurs (Cloud ou virtualisation, comme par exemple VMware, AWS, Google Cloud Engine, Docker, OpenStack, VirtualBox…) tout en s’assurant qu’elle soit identique, quel que soit le fournisseur, à partir d’un simple fichier de configuration.

Packer est cependant différent des outils de “Configuration Management” comme Chef ou Ansible, il n’a pas pour but de remplacer ces outils, au contraire il peut être complémentaire.

Pour assimiler au mieux le concept, rien de mieux que de la pratique !

Tutoriel Packer sur AWS

Packer étant multi plateforme, il peut être installé aussi bien sur un poste Windows que Linux.

Pour notre exemple, le déploiement va se faire sur Amazon Web Services. À noter que durant la première année suivant l’ouverture d’un compte AWS, certains services sont disponibles gratuitement.

La configuration de Packer peut se faire ensuite dans un seul fichier de type JSON, qu’on va nommer pour l’exemple “apache.json”.

On va y définir en premier lieu différentes variables qui vont permettre à Packer de se connecter et de pouvoir utiliser le service EC2 d’Amazon avec les “access_key” et les “secret_key” de l’utilisateur, et ensuite la partie “Builder” qui va justement permettre de créer notre image virtuelle sous la forme d’une AMI (Amazon Machine Image).

Une fois qu’on a défini ce qui va servir pour builder notre image, on passe au provisionnement avec la partie “provisioners” de notre json : dans le cadre de cette démo, installer Apache ainsi que PHP 5 en passant par le shell pour exécuter les commandes d’installations des paquets.

Ce qui nous donne :

{
  "variables": {
     "aws_access_key": "x",
     "aws_secret_key": "y"
},    

"builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "eu-west-1",
    "source_ami": "ami-f95ef58a",
    "instance_type": "t2.micro",
    "ssh_username": "ubuntu",
    "ami_name": "packer-example apache {{timestamp}}"
   }], 

  "provisioners": [
    {   
      "type": "shell",
      "inline": [
          "sleep 30",
          "sudo apt-get update",
          "sudo apt-get -y upgrade",
          "sudo apt-get install -y apache2 php5 libapache2-mod-php5 php5-curl php5-mysql"
      ]   
    }   
  ]
}

Pour valider la syntaxe et les paramètres de notre fichier, on peut utiliser la commande packer validate apache.json. Une fois la validation effectuée, on peut exécuter notre commande pour créer notre AMI avec packer build apache.json.

A noter le “sleep 30” au niveau du provisioners, qui est la pour permettre de laisser du temps à l’instance de s’initialiser correctement, car lorsqu’on exécute le “packer build” pour créer notre AMI, Packer va derrière tenter de se connecter en SSH à l’instance dès l’instant où celle-ci est disponible sur le service EC2 d’Amazon. Cela peut poser problème dans certains cas, car le système n’aura pas eu le temps de démarrer correctement et initialiser tous les composants systèmes. Afin de laisser le temps au système de s’initialiser correctement, on utilise dans ce cas le “sleep 30”.

Une fois que notre “packer build” s’est exécuté on retrouvera notre AMI dans EC2:

À partir de cette image on pourra ensuite lancer une ou plusieurs instances en fonction de notre architecture, ce qui permet de facilement créer une image système optimisé en fonction du besoin présent.