Évoluer comme un cloud provider : comment nous automatisons l’infrastructure de manière fiable

Plus de 500 VM, plusieurs centres de données, des environnements clients, des routeurs mobiles dans les transports publics et une équipe d’ingénierie d’environ 12 personnes. Cela ne fonctionne pas si chaque configuration et chaque changement doivent être effectués manuellement.

Chez onway, nous misons donc fortement sur Ansible. Ansible est un outil open source qui décrit les configurations et les processus dans des fichiers YAML lisibles, puis les exécute automatiquement sur un nombre quelconque de systèmes. Non pas parce que l’automatisation est passionnante en soi (elle l’est !), mais parce qu’elle résout un problème opérationnel concret : gérer de nombreux systèmes de manière fiable, traçable et cohérente.

Le premier article de cette série était consacré à NetBox comme source of truth. C’est là que nous gérons les VM, les adresses IP, les VLAN, les VRF et d’autres informations d’infrastructure. NetBox décrit ce qui existe et à quoi l’environnement doit ressembler. Mais rien n’est encore configuré pour autant. Ansible prend le relais : il lit les données dans NetBox et applique l’état souhaité sur les systèmes.

Adapter manuellement une seule VM ne pose pas de problème. Mais avec plusieurs centaines de VM - réparties sur deux centres de données, avec des routeurs, des switches, des firewalls et des hôtes ESXi - une approche manuelle devient rapidement source d’erreurs, surtout lorsque les changements doivent aussi être documentés proprement.

En exploitation, les mêmes questions reviennent régulièrement :

• Quels systèmes sont concernés par un changement ?
• Toutes les VM ont-elles la même configuration de base ?
• Une mise à jour de sécurité a-t-elle été déployée partout ?
• Existe-t-il des systèmes qui s’écartent de la configuration souhaitée ?
• Notre équipe OPS peut-elle exécuter elle-même les tâches récurrentes en toute sécurité ?

Si ces questions ne peuvent être résolues que manuellement, l’exploitation ralentit. La situation devient encore plus complexe lorsque la documentation et la configuration effective divergent. C’est précisément pour cette raison que nous combinons NetBox et Ansible.

Une nouvelle VM est d’abord saisie dans NetBox : nom, adresse IP, rôle, environnement et autres détails. Ansible ne travaille pas avec une liste d’hôtes statique, mais directement avec cette source of truth. Si les données dans NetBox sont correctes, Ansible peut les utiliser.

Notre modèle est volontairement simple :

• NetBox décrit l’état souhaité.
• Ansible applique cet état souhaité sur les systèmes.
• Rundeck rend l’automatisation facilement exécutable pour Engineering et OPS.
• Les e-mails et Logstash garantissent la traçabilité des changements.

Un cas d’utilisation typique est le provisionnement de nouvelles VM : configurer le réseau, créer les utilisateurs, intégrer le monitoring, configurer les services. Avec Ansible, ces étapes sont exécutées de manière standardisée au lieu d’être élaborées manuellement à chaque fois.

C’est particulièrement important pour les nouveaux environnements clients, qui peuvent rapidement comprendre 20 composants ou plus, tels que des routeurs, des switches, des firewalls, des hôtes ESXi et plusieurs VM. Nous pouvons mettre de tels environnements en service en quelques heures, avec moins d’erreurs manuelles et une structure reproductible.

Même après le provisionnement, une VM doit rester correctement configurée sur la durée. Pour cela, nous utilisons des rôles Ansible. Un rôle décrit, sur la base de la fonction de la VM enregistrée dans NetBox, la configuration dont un système a besoin.

Extrait de nos près de 50 rôles :

• `base` pour les réglages de base généraux
• `monitoring` pour l’intégration au monitoring
• `snmpd` pour la configuration SNMP
• `sssd_login` pour l’intégration centralisée des connexions
• `sshd` pour la configuration SSH
• `mpp` pour notre appliance mpp

Une configuration de base ne doit pas être appliquée manuellement 500 fois. Elle doit être définie proprement une seule fois, puis déployée de manière fiable sur tous les systèmes concernés. Cela rend l’exploitation plus prévisible et réduit les différences qui coûtent du temps lors du troubleshooting.

Chez onway, Ansible fonctionne via l’interface web Rundeck. Les jobs prédéfinis peuvent y être lancés, planifiés et journalisés sans devoir travailler directement en ligne de commande. C’est important, car l’automatisation ne doit pas fonctionner uniquement pour les personnes qui l’ont construite. Notre équipe OPS peut exécuter des jobs définis via Rundeck sans connaître chaque détail technique. Cela réduit les dépendances envers certains ingénieurs et rend les tâches récurrentes plus accessibles.

Si une automatisation ne fonctionne que sur l’ordinateur portable d’une seule personne, son utilité en exploitation reste limitée.

Lorsqu’une vulnérabilité critique est publiée, il faut savoir rapidement quels systèmes sont concernés. Les mises à jour doivent ensuite être déployées de manière ciblée et les changements doivent rester traçables. Avec plus de 500 VM, ce n’est pas quelque chose que l’on veut rechercher manuellement.

Un exemple tiré de notre exploitation était une vulnérabilité critique nginx. En l’espace d’une heure, nous avons pu identifier les systèmes concernés et déployer les mises à jour correspondantes. Sans base de données propre et sans automatisation, cela aurait été nettement plus fastidieux. Il aurait d’abord fallu vérifier où nginx est installé, quels systèmes sont en production et quels environnements clients pourraient être concernés. Le risque d’oublier certains systèmes aurait été élevé.

Avec NetBox et Ansible, nous pouvons travailler de manière plus structurée :

• identifier les systèmes concernés
• déployer les mises à jour de manière ciblée
• retracer les changements
• contrôler l’état des systèmes

La sécurité n’est donc pas seulement une question de bons patches. Il s’agit aussi de savoir avec quelle rapidité et quel niveau de contrôle on peut réagir lorsque c’est nécessaire.

Tous les changements ne sont pas critiques. Certains sont simples sur le plan technique, mais fastidieux sur le plan opérationnel. Sans automatisation, ces tâches restent facilement en suspens.

Un bon exemple interne a été notre rebranding de WLAN-Partner à onway : le MOTD devait être adapté sur toutes les VM. Techniquement, ce n’était pas une grande affaire, mais manuellement, sur de nombreux systèmes, l’effort aurait été disproportionné. Avec Ansible, le changement a été déployé en environ 30 minutes et n’aurait probablement même pas été réalisé manuellement.

Les systèmes évoluent en exploitation : mises à jour, hotfixes, tests, interventions manuelles. Au fil du temps, les VM peuvent diverger les unes des autres sans que cela soit visible au premier coup d’œil. C’est ce que l’on appelle le config drift. On le remarque souvent seulement lors du prochain changement ou pendant le troubleshooting.

C’est pourquoi nous exécutons Ansible une fois par jour sur toutes les VM. Lorsque des changements sont détectés, nous recevons un e-mail avec les systèmes concernés ; en plus, nous écrivons les changes dans Logstash. Logstash sert à l’agrégation centralisée des logs, collecte les événements provenant de différentes sources et les rend consultables. La cohérence ne naît pas du fait qu’un système est installé proprement une seule fois, mais du fait que l’état souhaité est régulièrement vérifié et, si nécessaire, rétabli.

Chez onway, Ansible n’est pas une fin en soi. Nous l’utilisons parce que notre infrastructure est trop vaste et trop dynamique pour être gérée durablement de manière manuelle. L’effort initial - construire des rôles, maintenir les données, tester les processus - porte ses fruits en exploitation : moins de travail répétitif, plus de temps pour l’architecture, le troubleshooting et les solutions clients.

Pour nos clients, cela signifie une mise à disposition plus rapide de nouveaux environnements, des systèmes configurés de manière cohérente et une réaction nettement plus rapide aux incidents de sécurité. Pour nous, l’automatisation n’est pas une fin en soi, mais un outil pour exploiter l’infrastructure de manière efficace, sûre et fiable.

Vous exploitez vous-même une infrastructure IT ou réseau complexe et souhaitez automatiser les tâches récurrentes de manière plus fiable ?

onway aide les entreprises à relier source of truth, automatisation et processus d’exploitation de façon pertinente et pragmatique.