A quoi sert à l'automatisation ? Est-ce si utile que ça pour un opérateur télécom ?
Qu'importe le milieu, l'automatisation est et doit être essentielle. Dans un monde en perpétuelle évolution, quelle est la plus value à ce que soit un humain qui fasse une action répétitive, enfantine et inintéressante ?
Dans le domaine de l'IT, il est encore plus aisé de développer des scripts pour faire ce travail rébarbatif. Par contre, des bouts de code à droite et à gauche ne feront ni améliorer le processus ni l’accélérer. De plus, si personne ne l'utilise, à quoi bon développer?
Pour répondre à ces problématiques, beaucoup d'outils ont vu le jour : Ansible, Terraform, Gitlab et aussi les IA : Gemini, OpenAI, Claude pour ne citer que ceux là.
Les solutions proposés par un opérateur sont multiples (Internet, MPLS, SDWAN, Hébergement , etc). Pour les demandes simples (du style production CPE, production Firewall, production VM), à quoi ça sert qu'un humain le fasse ? Déballer un CPE du carton, l'allumer, le brancher, pousser sa configuration, le débrancher, le remballer, l’expédier ......... Que de tâches fastidieuses et pas marrante à faire !
C'est là qu'intervient l'infra NetOps (C'est un joli mot bien fun donc je l'utilise 😎). Elle va servir à automatiser tous les trucs chiants pour permettre d'avoir des humains qui proposent une expertise technique, une plus-value sur un projet !
Durant cette nouvelle épopée, je vais monter pleins d'outils et les lier ensemble. Je développerai aussi quelques API sur mes services que j'utilise déjà. Vous l'avez surement deviné mais ces outils, je vais les monter sur mes proxmox donc pour commencer, automatisons la création des VM sur mon hyperviseur préféré ! (Ce code sera retravaillé par la suite, le but étant d'avoir une petite base d'autom pour commencer le vrai boulot)
Packer : Le templating
Pour créer des VM, il est intéressant d'utiliser des templates. Par exemple, on peut utiliser une template pour debian, une autre pour windows, etc. Dedans, on leur attribue un nombre de CPU, de RAM, le stockage (qui peut être changer en fonction de ce que le client demande mais cela servira de base si aucune variable n'est renseigné) mais aussi les drivers, le type de CPU, etc.
Cela permet de pouvoir tester et versionner les templates (qui seront la base de toutes les VM). On peut aussi dire quels paquets est installé sur la machine nativement (nano, qemu-guest-agent, curl, net-utils, etc). Enfin bref, un outil bien sympathique ! Il est développé par la société Hashicorp (Packer, Terraform, Hashicorp Vault, etc)
Comment il fonctionne ? Rien de mieux qu'un tree dans mon projet :
root@devops:~/packer-proxmox-template# tree
.
|-- cloud-cfg
| `-- 99-base.cfg
|-- debian.pkr.hcl
|-- preseed.cfg
|-- var.pkrvars.hcl
`-- vars.pkr.hcl
- debian.pkr.hcl sert à décrire à Packer toutes les étapes de la création de la VM et de sa transformation en template. Dedans, je vais avoir l'ISO, le node, le nom de la VM, etc.
- var.pkrvars.hcl sert à renseigner les variables pour mon debian.pkr.hcl (clé api, username, etc).
- vars.pkr.hcl permet de déclarer les variables et le type
- preseed.cfg sert à automatiser la création de la VM quand on est en console dessus (le formatage du disque, l'utilisateur, les partitions, etc)
- 99-base.cfg me sert à avoir une base pour le cloud-init
Grosso modo, packer lance un serveur web :
boot_command = ["auto url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg"]
La VM, quand elle boot, fait une requête à cette URL. Et dans mon preseed, il y a toutes les infos ligne par ligne quand on crée la VM. Exemple pour le pays :
d-i mirror/country string France
Une fois configuré, packer se connecte en ssh pour aller déposer le fichier cloud.cfg (fichier par défaut quand on ne précise pas de cfg lors de la création de la VM avec cette template. Ca sera plus clair juste après !).
C'est l'ensemble de ces fichiers qui me permettent de créer ma template. Je ne vais pas détailler toutes les lignes de configurations (trop long sah). Tout est dispo sur mon github !
Pour lancer mon projet, je fais un packer build -var-file="var.pkrvars.hcl" .
root@devops:~/packer-proxmox-template# packer build -var-file="var.pkrvars.hcl" .
proxmox-iso.debian: output will be in this color.
==> proxmox-iso.debian: Creating VM
==> proxmox-iso.debian: Starting VM
==> proxmox-iso.debian: Starting HTTP server on port 8644
==> proxmox-iso.debian: Waiting 10s for boot
==> proxmox-iso.debian: Typing the boot command
==> proxmox-iso.debian: Waiting for SSH to become available...
==> proxmox-iso.debian: Connected to SSH!
==> proxmox-iso.debian: Uploading cloud.cfg => /etc/cloud/cloud.cfg
proxmox-iso.debian: cloud.cfg 2.62 KiB / 2.62 KiB [===================================================================================================================] 100.00% 0s
==> proxmox-iso.debian: Stopping VM
==> proxmox-iso.debian: Converting VM to template
==> proxmox-iso.debian: Adding a cloud-init cdrom in storage pool local
Build 'proxmox-iso.debian' finished after 4 minutes 31 seconds.
==> Wait completed after 4 minutes 31 seconds
==> Builds finished. The artifacts of successful builds are:
--> proxmox-iso.debian: A template was created: 6666
Et ma template est crée :
Le but n'est pas d'avoir une template pour juste la cloner et avoir nos VM sans personnalisation. Toutes les parties custom seront modifiées avec .............. OpenTofu !
OpenTofu : On crée nos VM
OpenTofu est un fork de terraform sorti en réponse du changement de licence de terraform par hashicorp. C'est le même langage, tout est quasiment identique sauf les licences !
On va utiliser cet outil pour créer nos VM en se basant sur la template créée précédemment (on clone le template tout en lui précisant des informations, comme l'utilisateur, le disque, le réseau, etc).
Voici la structure d'un projet :
root@devops:~/tofu-proxmox/test-blog# tree
.
|-- terraform.tfstate
|-- terraform.tfvars
|-- tofu.tf
`-- var.tf
Je sais qu'on peut faire des projets plus complexe mais je voulais que ma base soit simpliste as fuck. Donc j'ai un fichier var.tf (déclaration des variables), terraform.tfstate (fichier que opentofu va créer pour garder en mémoire l'état de la VM), mon tofu.tf (instructions pour la créer) et mon terraform.tfvars (fichier où je renseigne mes variables et leur valeurs).
Un petit aperçu du fichier terraform.tfvars :
root@devops:~/tofu-proxmox/test-blog# cat terraform.tfvars
proxmox_api_url = "https://192.168.1.200:8006/api2/json"
proxmox_api_token_id = "USER API OPENTOFU"
vm_name = "gitlab"
vm_id = 2006
target_node = "naruto"
template_id = 3333
vm_cpu = 6
vm_memory = 8192
vm_disk = 60
vm_ip_address = "192.168.10.101/24"
vm_gateway = "192.168.10.1"
dns_servers = ["1.1.1.1", "192.168.10.193"]
vm_interface = "VNET10"
admin_username = "USER DE MA VM"
ssh_public_key = "MA CLEE PUBLIQUE"
Il faut savoir que opentofu garde en mémoire l'état de la VM crée. Ainsi, pour chaque VM, il faut créer un autre tofu.tf (perso je crée un répertoire pour chaque VM). Allez, lançons le boudin :
root@devops:~/tofu-proxmox/gitlab# tofu init
Initializing the backend...
Initializing provider plugins...
- Finding bpg/proxmox versions matching ">= 0.60.0"...
- Installing bpg/proxmox v0.89.1...
- Installed bpg/proxmox v0.89.1 (signed, key ID F0582AD6AE97C188)
Providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://opentofu.org/docs/cli/plugins/signing/
OpenTofu has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that OpenTofu can guarantee to make the same selections by default when
you run "tofu init" in the future.
OpenTofu has been successfully initialized!
You may now begin working with OpenTofu. Try running "tofu plan" to see
any changes that are required for your infrastructure. All OpenTofu commands
should now work.
If you ever set or change modules or backend configuration for OpenTofu,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
root@devops:~/tofu-proxmox/gitlab# tofu validate
Success! The configuration is valid.
root@devops:~/tofu-proxmox/gitlab# tofu apply
.
.
.
.
.
.
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
OpenTofu will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
proxmox_virtual_environment_vm.vm: Creating...
proxmox_virtual_environment_vm.vm: Still creating... [10s elapsed]
proxmox_virtual_environment_vm.vm: Creation complete after 19s [id=2000]
Ma VM est bien crée et avec les bons paramètres hardware :
J'arrive bien à me connecter en SSH après ma clé privée :
root@devops:~/tofu-proxmox/gitlab# ssh user@192.168.10.101
Linux gitlab 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Dec 21 21:30:33 2025 from 192.168.1.240
user@gitlab:~$
Bon c'est pas si mal ! Certes, c'est pour nos besoins mais admettons qu'un client veuille un VPS, on peut très bien utiliser ce code pour lui fournir !
Suite
Dans cet épisode, on a posé les bases des bases pour notre infra Netops : la création de template et de VM sur notre hyperviseur. Packer et OpenTofu forment un bon duo pour ça.
Mais bon, vous vous doutez bien que cela ne va pas s'arrêter là ! Tout ça n'avait qu'un seul but : la création des VM pour héberger nos outils (vous avez du voir gitlab juste en dessus).
Je sais que ces deux codes ne sont pas parfaits. Rien n'est parfait sauf naruto ...
Cap sur le prochain épisode, ! On fait une liste de ce qu'on va utiliser pour automatiser toute nos actions dans l'opérateur (et on les installe, soyons fou).
Je termine sur un mot de fin : Je commence ma dream team... Au poste de responsable support, je choisis Briac !