Il y a, dans le monde surpeuplé des outils DevOps, une société qui aujourd’hui tire son épingle du jeu en proposant des produits open source novateurs et devenus des références sur le marché. HashiCorp est une start-up fondée en 2012 par Mitchell Hashimoto et Armon Dadgar, ils se sont donnés pour but d’offrir un panel d’outils complet pour l’automatisation du datacenter. Cela se traduit par des outils « Infrastructure as a Code » permettant de créer et manager des environnements complexes (Terraform), gérer de manière sécurisée et distribuée les « secrets » liés aux applications (Vault) ou bien faciliter la mise à disposition d’environnement de développement (Vagrant). Dans cet article, je vous propose de nous attarder sur un autre produit, Packer.
Packer a été développé pour faciliter la création d’images de système d’exploitations, que ce soit des machines virtuels ou bien des containers. A partir d’un simple fichier de configuration, Packer est capable de préparer en parallèle ces images sur différents environnements cloud (AWS, Azure, GCE), on-premises (vSphere, Hyper-V,etc…) ou bien même sur son propre ordinateur (VirtualBox, Fusion, Workstation…). Packer est une réponse concrète aux problèmes de gestion des images, que ce soit sur une infra « simple » (qui n’a jamais rêvé d’avoir à disposition des images de VM toujours à jour ?) ou bien sur des environnements plus complexes (une application développée sur des laptops, testée sur une infra locale et mise en production sur un cloud public).
Prérequis techniques
On en a terminé avec la présentation marketing, voyons maintenant comment Packer fonctionne et si oui ou non il est bien l’outil qui réconciliera à jamais les devs et les ops ! Commençons par les habituels prérequis. Il va vous falloir créer un répertoire de travail (pour stocker le fichier de conf ainsi que les différents scripts), un éditeur de texte et… installer Packer… Que vous soyez sous Linux, Windows ou MacOS, pas de problème HashiCorp a pensé à vous. Il vous suffit juste de télécharger l’exécutable (liens vers site) et de le placer dans un répertoire qui est disponible dans le PATH. Maintenant sortez votre plus beau shell et exécutez la commande packer:
https://gist.github.com/equelin/5f4ce41c2adc3889d53ead1740a9eeea#file-packer-md
En avant pour une première image !
Vous voilà fin prêt à construire votre première image! Je sens d’ici votre excitation ! Mais avant que vous ne vous lanciez à corps perdu dans l’aventure, je vous propose que nous passions du temps à détailler le contenu d’un fichier de configuration qui nous permettra de créer une image Windows Server 2016 sur AWS.
Le reste de l’article va faire appel à des notions liées à AWS ou bien les OS Microsoft. Ce n’est pas grave si cela vous est complètement étranger, cela ne vous empêchera pas de comprendre comment fonctionne Packer.
Vous pouvez retrouver le fichier de configuration Packer ainsi que les différents scripts sur Github.
Le fichier de configuration (appelé template dans la documentation officielle) est au format JSON, il va contenir la trame des différentes étapes qui auraient été nécessaires à un déploiement manuel, à savoir:
- Créer une « machine virtuelle » (VM VMware vSphere, Instance AWS EC2, container Docker, etc…)
- Provisionner un système d’exploitation (ce n’est pas forcément nécessaire dans les clouds publics)
- Personnaliser l’OS à l’aide de scripts (exécutés par exemple via SSH ou WinRM) ou bien d’outils tiers tels que Chef ou Ansible
- Et enfin, créer une image que vous pourrez utiliser par la suite pour déployer d’autres environnements identiques.
Les Builders, spécialistes du gros œuvre
On va commencer par définir un Builder qui aura la tâche de créer la machine virtuelle avec les caractéristiques qu’on lui aura indiquées. Il existe plusieurs types de Builder en fonction de l’environnement sur lequel vous voulez déployer votre machine. Etant donné que la cible est AWS, nous allons utiliser un Builder du type amazon-ebs
https://gist.github.com/equelin/5f4ce41c2adc3889d53ead1740a9eeea#file-builders-json
Je ne vais pas rentrer dans les détails car les différents paramètres sont spécifiques à AWS et Windows. Pour résumer, ce Builder va se connecter à AWS en utilisant la clé spécifiée (access_key, secret_key), créer une instance EC2 à partir d’une image fournie par AWS (source_ami) et essayer de se connecter au serveur Windows via le protocole WinRM. Une fois qu’il aura réussi à établir une connexion, il laissera la main pour la suite des opérations.
Les Provisionners, détails et finitions
Maintenant que nous disposons d’un OS « de base » nous allons pouvoir le configurer suivant nos besoins. C’est là qu’entre en scène les provisionners. Comme leur nom l’indique, ils vont nous permettre d’interagir avec l’OS via différents moyens de communication (Scripts, Chef, Ansible…) pour pouvoir le personnaliser.
https://gist.github.com/equelin/5f4ce41c2adc3889d53ead1740a9eeea#file-provisioners-json
provisionners différents. Ils seront exécutés séquentiellement par Packer. Le premier va exécuter plusieurs scripts Powershell qui sont stockés dans le sous-répertoire scripts de notre répertoire de travail. Étant donné qu’un des scripts va effectuer les mises à jour Microsoft Update, le deuxième provisionner va redémarrer Windows et attendre qu’il soit de nouveau disponible. Enfin, le dernier va exécuter des scripts stockés sur l’OS et qui font partis des outils qu’inclus AWS dans ses images. Ils ont pour but de préparer l’OS à être transformé en template.Si tout se passe comme prévu lors de l’exécution des différentes opérations de personnalisation, Packer va faire tout le travail restant à savoir:
- Éteindre l’instance EC2
- La transformer en un template (AMI) qui sera disponible dans votre console AWS.
Maintenant que nous avons créé notre fichier de configuration, nous allons pouvoir valider qu’il ne contient pas d’erreurs de syntaxe avec la commande packer validate monfichier.json
> packer validate .\aws-windows-dsc.json Template validated successfully.Si la commande ne retourne pas d’erreur alors nous pouvons lancer la création du template avec la commande packer build monfichier.json
Attention, la création d’un template peut prendre beaucoup de temps notamment si, comme dans cette exemple, vous mettez à jour votre serveur Windows…
https://gist.github.com/equelin/5f4ce41c2adc3889d53ead1740a9eeea#file-packer_exec-md
Il n’y a plus qu’à attendre que Packer finalise la création du template et vous devriez avoir à votre disposition un AMI flambant neuf dans votre interface EC2.
J’espère que cet article vous aura donné envie de tester plus en profondeur Packer. A mon avis le potentiel de l’outil est énorme et devrait faire partie des indispensables de votre trousse à outils, que vous soyez Ops ou Dev.
N’hésitez pas à laisser un commentaire ou bien contactez moi sur twitter (@erwanquelin) pour toutes questions.
Pour aller plus loin
Les sites ou articles ci-dessous ont été une source d’inspiration non négligeable !:
- https://packer.io: Site officiel de Packer, un incontournable.
- Best Practices with Packer and Windows – Matt Hodgkins: Cet article regorge de conseils pratiques et pertinent. Il est plutôt orienté Windows et Powershell mais il vaut aussi le coup d’œil pour les autres OS.
Le titre auquel vous avez échappé
- Packer Lewis ne perd jamais
