L’industrialisation d’un parc consiste à se doter de la capacité de gérer ledit parc de manière centralisée et automatisée. C’est la mise en place de processus et d’outils qui vont améliorer la fiabilité et la vélocité des actions régulières (création de VMs et d’utilisateurs, attribution de droits, application de patchs, …) et évidemment l’automatisation des tâches techniques qui en découlent. Cette industrialisation va permettre aux équipes de passer moins de temps sur des problématiques isolées (qui d’écoulent essentiellement d’actions manuelles dans les environnements non industrialisés) ou sur des tâches répétitives et consommatrices de temps, et de s’orienter vers des tâches amenant de la valeur, de l’amélioration continue de l’existant, … et avec cela une progression technique/métier des équipes et une valorisation de leur travail.
Les objectifs de l’industrialisation sont les suivants :
- Avoir une vision d’ensemble du parc permettant de prendre les bonnes décisions (réaction face à un incident ou une alerte de sécurité, réponses aux demandes des métiers, capacity planning, …) et de partager/donner accès aux informations via des interfaces et données communes, ainsi que via des dashboards orientés en fonction du métier de l’utilisateur.
- Piloter opérationnellement le parc de manière rapide, en diminuant les coûts d’intervention et en maximisant la réactivité face aux situations.
- Assurer une homogénéité du parc pour minimiser le travail au cas par cas et se concentrer sur des projets transverses avec une plus grande valeur ajoutée.
- Optimiser la sécurité des VMs en les maintenant à jour et en conformité avec les règles définies par les standards d’entreprise en général et les règles spécifiques de l’entreprise en particulier.
- Possibilité de déléguer/répartir les tâches sur différentes équipes via la gestion des habilitations dans les différents outils.
Les outils peuvent varier, mais les besoins sont sensiblement les mêmes dans les différentes infrastructures.
Les besoins récurrents que j’ai identifiés sont les suivants :
- le provisionnement des VMs et des services,
- la gestion de la configuration,
- la gestion des dépôts de packages et du patch management,
- la gestion de la conformité,
- la gestion des identités et des habilitations,
- la supervision.
Il y a bien sûr d’autres besoins qui s’expriment en fonction des clients et de leur réglementations, de leurs spécificités et également de leur maturité : quand l’essentiel précité est maîtrisé, il est ensuite possible d’adresser des besoins plus avancés (CMDB, Intrusion Detection System, …). Plus avancé ne veut pas dire superflu, mais si la base du fonctionnement d’un parc n’est pas industrialisée, poser « au-dessus » des briques pour affiner la gestion dudit parc n’aura pas de réel effet.
Je vais présenter le cas sur lequel je travaille : celui d’un parc constitué de VMs RHEL (7.X) et Windows. Pour information, nous utilisons VMware ESXi piloté par vCenter Server comme hyperviseur. Utiliser un autre hyperviseur n’a pas d’impact sur le modèle décrit, cependant il peut y en avoir au niveau de la compatibilité avec les outils que je présente et au niveau de la gestion des licences. Par exemple, la mise à disposition des dépôts de packages Red Hat (via Red Hat Satellite dans ce cas) va nécessiter l’achat de licences à attribuer à chaque ESXi (hôte) qui va déléguer (via Satellite) des licences « guest » à chaque VM : la possibilité de délégation de licence est à vérifier pour votre hyperviseur. D’un point de vue compatibilité technique, la liste des ESX et des VMs qui s’exécutent « dessus » devra être récoltée par l’agent virt-who (via un appel à l’API exposée par vCenter qui a connaissance des ESXi) pour ensuite les enregistrer dans Satellite (à nouveau via API) : à nouveau il faudra vérifier ce point pour votre hyperviseur, à savoir le bon fonctionnement technique de cette séquence.
Dans le cadre de cette mission de longue durée, j’ai travaillé particulièrement sur la gestion des VMs RHEL de ce parc. Certains des outils que j’ai mis en place permettent de gérer à la fois les VMs Windows et les VMs RHEL, mais certains besoins ont été adressés via une gamme d’outils dédiés à RHEL : dans ces cas là un outil équivalent pour Windows a été utilisé par un autre collègue bien plus compétent que moi dans l’univers Microsoft. ?
J’ai donc mis en place plusieurs outils pour industrialiser la gestion du parc :
- ManageIQ (Projet upstream de Red Hat CloudForms) pour le provisionnement des VMs et des services, via la mise à disposition d’un catalogue d’architectures (associations de VMs et de services). Cet outil propose un moteur de workflow surchargeable qui permet d’orchestrer demandes et validations de ressources, leur cycle de vie, ainsi que l’inter-connexion avec tout autre service exposant des APIs (IPAM, firewall, …). Cet outil sert aux VMs RHEL et Windows.
- Chef de Opscode pour la configuration des OS (RHEL et Windows) post-instanciation des VMs, et l’installation et la configuration des logiciels.
- Satellite de Red Hat pour la mise à disposition des dépôts de packages (Red Hat et éditeurs logiciels) et la gestion des patchs (security/bugfix/enhancement) ainsi que pour la gestion de la conformité via les outils intégrés OpenSCAP et Red Hat Insights. Evidemment dans ce cas c’est WSUS (Windows Server Update Services) qui est utilisé pour la mise à disposition des patchs Windows (hors gestion de la conformité).
- IPA (IdM) de Red Hat pour la gestion des identités, des accès aux VMs/services et des habilitations (via sudo), pour la mise à disposition de home itinérantes montées à la volée et pour la prise en compte (Trust One-way) des utilisateurs déclarés dans l’AD (Active Directory). Dans ce cas les VMs Windows sont directement raccordées à l’AD. IPA permet que les VMs RHEL puissent se baser sur le même référentiel (AD) que les VMs Windows tout en bénéficiant d’une gestion spécifique à Linux des accès/habilitations.
Pour la supervision, j’ai travaillé indirectement sur le sujet dans ce cas. Dans d’autres missions, j’ai fait confiance à Centreon ou Zabbix pour des projets internes de monitoring (supervision + métrologie) distribué, ou encore pour des besoins plus ponctuels dans de petites structures à Cacti ou Munin.
Je vais m’attacher à rédiger, au cours des semaines/mois à venir, un post par besoin/outil pour une meilleure lisibilité du contenu, certains lecteurs pourront en effet être intéressé par une fonctionnalité en particulier.
Le premier article de la série est Architecture, dépôts, patchs, licences et conformité avec Red Hat Satellite. ?
Frédéric FAURE
