AUTOMATISATION & SCRIPTING
Développer des scripts et des processus automatisés. Réduire les interventions manuelles et les risques d’erreur opérationnelle.
Définition et contexte
L’automatisation & scripting, c’est écrire du code pour faire des tâches répétitives. Au lieu de relancer manuellement un serveur ou de configurer manuellement 100 VMs, tu écris un script qui le fait.
C’est une compétence hyper valorisée en infrastructure. Plus tu automatises, moins tu fais d’erreurs humaines, plus tu gains du temps.
En entreprise, c’est la différence entre « on a 1 personne qui gère l’infra » et « on a une infra qui se gère presque toute seule ». Le scripting, c’est la route vers l’Infrastructure as Code.
Avec Proxmox, j’ai appris que l’automation peut être simple (cron + quelques commandes) ou complexe (orchestration complète). Dépend du besoin.
Éléments de preuve: Deux anecdotes
Le système d’extinction/réveil programmé au HomeLab
Au HomeLab, le serveur consomme de l’électricité. Au lieu de le laisser tourner 24/7, j’ai mis en place une automation complète :
- Cron jobs pour l’extinction programmée :
Pourquoi deux étapes ? Parce que TrueNAS gère le stockage ZFS. Si tu le coupes brutalement, tu risques la corruption. Du coup, d’abord on l’éteint proprement via qm shutdown (qui utilise QEMU Guest Agent pour dire « ferme-toi gentiment »), puis on ferme Proxmox qui ferme les autres VMs.
- RTC Wake-up en BIOS pour le réveil automatique à 09h00 (réglé directement dans le BIOS, pas de script).
- Séquençage des VMs au boot (configuré dans Proxmox) :
Résultat : Le serveur s’éteint automatiquement chaque soir, se réveille chaque matin, et les VMs démarrent dans le bon ordre sans intervention. Ça économise environ 40% de l’électricité. [Lire la réalisation complète : HomeLab]
Un wrapper Bash pour plus de robustesse (amélioration)
Le cron + qm shutdown, c’est fonctionnel. Mais si quelque chose casse (guest agent pas réactif, timeout), le serveur continue de tourner.
J’ai créé un script Bash plus avancé pour plus de contrôle :
Ce script fait plusieurs choses:
- Log tout (utile pour debugger si ça casse)
- Attend que TrueNAS s’éteigne proprement (max 60s)
- Force l’arrêt si ça traîne (fallback)
- Éteint les autres VMs avant Proxmox
- Gère les timeouts (pas de hang infini)
Résultat: Une automation beaucoup plus robuste qui gère les edge cases. [Lire la réalisation complète: HomeLab]
Mon autocritique: Où j’en suis vraiment
Je me considère à un niveau intermédiaire sur cette compétence. Je peux écrire des scripts Bash simples et des cron jobs. Je comprends la logique d’automation (quoi automatiser, comment).
Ma marge de progression: Je suis bon sur du scripting ponctuel (un script pour faire une tâche spécifique). Je suis moins bon sur de l’orchestration complexe (Ansible, Terraform, Docker Compose). C’est une marche au-dessus qui demande du temps.
Contextualisation: L’automation fonctionne pas pareil selon le contexte. En lab? Tu peux experimenter. En prod? Faut que tu testes d’abord (tu veux pas crasher le serveur en prod par un script bugué).
Vitesse d’acquisition: J’ai appris ça en ayant des vrais besoins (économiser de l’électricité, gérer des tâches répétitives). L’automation par curiosité, c’est moins motivant que l’automation par nécessité.
Mon conseil: Avec ce que je sais maintenant, je dirais: commence par automatiser les tâches répétitives et erreur-prone. Pas besoin de Kubernetes day one. Un bon script Bash bien pensé qui sauve 30 min par jour, ça vaut déjà le coup.
Mon évolution : Où je veux aller
À moyen terme, je veux apprendre Ansible et Terraform pour de l’infrastructure as code. Aussi explorer Docker et Kubernetes pour de l’orchestration à l’échelle.
Formations en cours : Je lis sur Ansible et Terraform. Pas de certifications, mais ça m’intéresse.
Réalisations rattachées :
- HomeLab (scripts shutdown/wake-up, séquençage VMs)