Packer

Pendant l'année 2014, Athoune m'a fait découvrir les concepts DevOps "Baking" et "Frying".

Je le remercie, car ce sont des concepts que je considère très importants pour comprendre les différents paradigmes de déploiement.

Je n'ai aucune idée dans quelles conditions il avait découvert ces concepts. J'ai essayé de faire des recherches limitées à l'année 2014 et je suis tombé sur cette photo :

J'en déduis que cela devait être un sujet à la méthode dans l'écosystème DevOps de 2014.

Cet ami me l'avait très bien expliqué avec une analogie du type :

« Le baking en DevOps, c’est comme dans un restaurant où les plats sont préparés en cuisine et ensuite apportés tout prêt salle à la table du client. Le frying, c’est comme si le plat était préparé directement en salle sur la table du client. »

Bien que cette analogie ne soit pas totalement rigoureuse, elle m'a bien permis de saisir, en 2014, le paradigme Docker qui consiste à préparer des images de container en amont. Ce paradigme permet d'installer, de configurer ces images "en cuisine", donc pas sur les serveurs de production, "de goûter les plats" et de les envoyer ensuite de manière prédictible sur le serveur de production.

Ces images peuvent être construites soit sur la workstation du développeur ou mieux, sur des serveurs dédiés à cette fonction, comme Gitlab-Runner…

Définitions proposées par LLaMa :

Baking (ou "Image Baking") : Il s'agit de créer une image de serveur prête à l'emploi, avec tous les logiciels et les configurations nécessaires déjà installés et configurés. Cette image est ensuite utilisée pour déployer de nouveaux serveurs, qui seront ainsi identiques et prêts à fonctionner immédiatement. L'avantage de cette approche est qu'elle permet de réduire le temps de déploiement et d'assurer la cohérence des environnements.

Frying (ou "Server Frying") : Il s'agit de déployer un serveur "nu" et de le configurer et de l'installer à la volée, en utilisant des outils d'automatisation tels que Ansible, Puppet ou Chef. Cette approche permet de personnaliser la configuration de chaque serveur en fonction des besoins spécifiques de l'application ou du service.

Exemple :

Cas d'usage	Baking	Frying
Docker	Construire une image complète (docker build) et la stocker dans un registre	Lancer un conteneur minimal et installer les dépendances au démarrage.
Machines virtuelles (VMs)	Créer une image VM avec Packer et la déployer telle quelle	Démarrer une VM de base et appliquer un script d’installation à la volée
CI/CD	Compiler et packager une application en image prête à être déployée	Construire l’application à chaque déploiement sur la machine cible

En 2014, lorsque le concept de baking m’a été présenté, j’ai immédiatement été enthousiasmé, car il répondait à trois problèmes que je cherchais à résoudre :

• Réduire les risques d’échec d’une installation sur le serveur de production
• Limiter la durée de l’indisponibilité (pendant la phase d’installation)
• Éviter d'augmenter la charge du serveur durant les opérations de build lors de l’installation

Depuis, j'évite au maximum le frying et j'ai intégré le baking dans ma doctrine d'artisan développeur.

Je souhaite créer un playground d'un development kit pour Python + PostgreSQL (via Docker) + Flask + Flask-Migrate, basé sur Mise.

J'ai la contrainte suivante : le development kit doit fonctionner sous MS Windows !

Je me dis que c'est une bonne occasion pour moi de tester Windows Subsystem for Linux 🙂.

Problème : je ne possède pas d'instance MS Windows.

#JaiDécouvert que depuis 2015, Microsoft met à disposition des ISOs officiels de MS Windows :

• ISO pour Windows 10 : https://www.microsoft.com/fr-fr/software-download/windows10ISO
• ISO pour Windows 11 : https://www.microsoft.com/fr-fr/software-download/windows11
• Virtual machine MS Windows pour VirtualBox et d'autres : https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/

J'ai testé dans ce playground le lancement d'une Virtual machine MS Windows avec Vagrant : https://github.com/stephane-klein/vagrant-windows-playground.

Cela a bien fonctionné 🙂.

J'ai aussi découvert le repository windows-vagrant qui semble permettre de construire différents types d'images MS Windows avec Packer. Je n'ai pas essayé d'en construire une.

#JeMeDemande s'il est possible d'installer des serveurs Scaleway Elastic Metal avec des images d'OS préalablement construites avec Packer 🤔.

Je viens de poser la question suivante : Is it possible to create Elastic Metal OS images with Packer and use it to create a Elastic Metal serveurs?

En français :

Bonjour,

Je sais qu'il est possible de créer des images d'OS avec Packer utilisables lors de la création d'instance Scaleway (voir https://www.scaleway.com/en/docs/tutorials/deploy-instances-packer-terraform/).

De la même manière, je me demande s'il est possible de créer des images d'OS avec Packer pour installer des serveurs Elastic Metal .

Question : est-il possible de créer des images Elastic Metal avec Packer et d'utiliser celle-ci pour créer des serveurs Elastic Metal ?

Si c'est impossible actuellement, pensez-vous qu'il soit possible de l'implémenter ? Ou alors, est-ce que des limitations techniques de Elastic Metal rendent impossible cette fonctionnalité ?

Bonne journée, Stéphane

Je viens d'envoyer cette demande au support de Scaleway.

Dans le tutoriel "Proxmox Template with Cloud Image and Cloud Init", #JaiDécouvert un usage de la commande virt-customize :

# wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
# virt-customize -a noble-server-cloudimg-amd64.img --install qemu-guest-agent --run-command 'systemctl enable qemu-guest-agent.service'

Je trouve cela extrêmement pratique, cela évite de devoir utiliser Packer pour personnaliser une image disque.

J'ai fait quelques recherches et j'ai appris que la fonctionnalité d'installation de package est ancienne, elle a été implémentée dans libguestfs en 2014 par Richard Jones, employé de chez Red Hat (auteur de libguestfs).