Squest passe en v2 + retour d’expérience sur la pile Ansible/RHAAP/Squest

Squest est un outil auto hébergé vous permettant d’exposer votre automatisation disponible depuis votre instance de Ansible Tower/AWX en tant que service. La version v2.0.0 vient d’être publiée. Il a déjà fait l’objet de dépêches précédentes sortie de la version 1.0 et présentation comme portail de services pour SRE/DevOps en frontal d’Ansible Tower/AWX.

Sommaire

• Contexte technique
• Ansible
• Red Hat Ansible Automation Platform (AWX/Ex Tower)
• Squest
  • Le catalogue de service
  • Le gestionnaire de ressource
• Retour d’expérience après deux ans de production
• Squest v2
• Mot de la fin

Contexte technique

Je travaille dans une équipe infrastructure au sein de HPE. Notre rôle consiste à fournir des services à nos ingénieurs en fonction des besoins métier du moment (virtualisation, conteneurisation, réseau, stockage…).

Pour remplir notre mission avec une efficacité optimale, nous suivons les pratiques SRE (Site Reliability Engineering). Cela signifie que nous appliquons les méthodes de l’ingénierie logicielles dans le contexte d’opérations système et réseau. Plus vulgairement, cela signifie que l’on met du code partout, tout le temps.

De façon générale, les bénéfices de l’approche « Infrastructure-as-Code » du modèle SRE sont multiples :

• des environnements testables et reproductibles
• une facilité à restaurer en cas de panne
• rapidité d’exécution (temps de mise sur le marché)
• fiabilité des exécutions (moins d’opérations exécutées manuellement et donc moins d’erreurs)
• les briques logicielles peuvent être partagées, ré-utilisées et améliorées par toute l’organisation

Pour parvenir à nos fins, nous utilisons plusieurs langages (Python, Go ou Bash) ainsi que plusieurs outils comme Terraform, Packer ou Ansible.

Ansible

L'écosystème complet d’Ansible ainsi que sa communauté très active font de lui l’outil idéal. Les modules core, les collections, les playbook, les rôles d’Ansible ne demandent qu'à être assemblés comme une énorme boîte de Lego.

De l’orchestration de conteneur jusqu'à la gestion de configuration, en passant par le déploiement d'applications, le provisionnement d’infrastructure, l’application de patch de sécurité ou le déploiement continue. Toutes ces opérations peuvent être effectuées par Ansible sur divers types d'objets comme des pare-feu, des répartiteurs de charge, des conteneurs, des plateformes cloud, du réseau, des serveurs, du stockage, etc.

Pour répondre à un nouveau besoin, commencez par regarder ce qui est déjà présent dans l'écosystème open source d‘Ansible. Dans la plupart des cas, vous trouverez directement la brique qu’il vous faut. Parfois, une contribution à l’évolution sera nécessaire afin de l’adapter à votre environnement d’entreprise (oui, c'est souvent le support du proxy qu’il manque😉). Le cas échéant, Ansible met à disposition tout le nécessaire pour développer vous-mêmes ce qu’il vous manque.

Mais nous pouvions aller un cran plus loin !

Red Hat Ansible Automation Platform (AWX/Ex Tower)

RHAAP, l’évolution logique d’Ansible, est très facile à prendre en main lorsque l’on vient du monde Ansible. L'outil apporte deux choses à Ansible: une UI et une API.

Les avantages de son utilisation sont multiples :

• Centraliser l’automatisation : Avec le temps qui passe, les dépôts de code se multiplient.RHAAP permet de centraliser tout cela en un seul endroit.
• API : L’automatisation devient consommable depuis d’autres outils ou services comme des moteurs de CI/CD.
• Rendre l’automatisation simple à consommer : C’est le point fort de RHAAP. Des automatisations peuvent être placées derrière un simple bouton. Un playbook très complexe, effectuant des centaines d'opérations, peut être lancé en remplissant un formulaire sur votre navigateur. L’automatisation peut donc être exécutée par n’importe quel membre de l’équipe sans avoir besoin de compétence technique particulière.

RHAAP nous a permis d’accélérer et rendre encore plus fiable nos activités. Les tâches répétitives sont systématiquement automatisées et intégrées à l’outil. Une action exécutée sur un système peut déclencher une automatisation afin de synchroniser un nouvel état sur un autre système, qui lui-même déclenchera potentiellement une autre exécution de script.

Mais nous pouvions aller un cran plus loin!

Squest

L'idée à l'origine de Squest a émergé en tentant de répondre à des besoins non adressés par Ansible et RHAAP, plus particulièrement :

Besoin d’un portail : RHAAP n’est pas un catalogue de services. Il n’est pas un outil que l’on peut mettre à disposition directement des utilisateurs finaux.

Gestion des requêtes : Les demandes n’étaient pas centralisées, les flux de travail non homogènes et différents canaux de communication coexistaient tels que les e-mails, conversation au coin de couloir, portails Web, messageries instantanées… Les demandes de service étaient donc difficiles à suivre dans le temps autant pour nous que pour nos utilisateurs.

Gestion du cycle de vie des instances : La gestion du cycle de vie correspond à ce que nous appelons de nos jours des "opérations du jour-2" (“day 2 operations” en anglais). Ces opérations comme la modification ou la suppression des ressources sont effectuées après la mise à disposition du service. À titre d’exemple, un utilisateur qui aurait demandé la création d’une machine virtuelle, souhaitera plus tard modifier le système d'exploitation, augmenter la mémoire, étendre le disque, ou plus simplement la supprimer la VM. RHAPP n’apporte pas de réponse dans cette situation. En effet, c'est un outil de type “fire and forget”. Cela signifie qu’il ne garde pas de trace de ce qu’il a pu créer en termes d’instance de service. Pour lancer l’automatisation afin de répondre à cette requête de type jour-2, l’opérateur devrait fournir à RHAAP toutes les informations nécessaires pour retrouver cette VM. Ces opérations, qui sont par ailleurs les plus fréquemment demandées, sont donc très coûteuses en temps pour notre équipe.

Gestion des ressources physiques : Les ressources physiques sont finies. Par conséquent, en tant que fournisseur de plateforme, nous devons avoir une visibilité sur les demandes de service et les ressources consommées pour garantir la disponibilité de notre infrastructure. Suivre la consommation de chaque collaborateur parmi toutes les combinaisons possibles d'environnement et de technologies est un défi. Plus encore dans le contexte informatique moderne, ou des conteneurs consomment des ressources dans des machines virtuelles, elles-mêmes consommant leurs propres ressources depuis des machines physiques. Augmenter la charge sur les couches les plus hautes augmente le risque de sur-provisionnement sur les couches les plus basses si aucune mesure n’est effectuée.

Notre équipe n’a pas vocation à créer des logiciels lourds. Avant de débuter ce projet, nous avons effectué un état de l’art en comparant les solutions disponibles sur le marché telles que ManageIQ, Scalr, Cloudify, Red Hat Service Catalog ou Morpheus.

N’ayant pas trouvé l’outil, ni un socle adaptable répondant à tous nos besoins, nous avons finalement décidé de développer une solution maison : Squest.

Squest est un framework, développé à l’aide d'outils open source, qui fonctionne au-dessus de la couche Red Hat Ansible Automation Platform (AWX) et fournit deux principales fonctionnalités : un portail de service et un gestionnaire de suivi de ressources.

Le catalogue de service

Le portail fournit une interface intuitive pour l'utilisateur final qui expose, centralise et rend consommable toute notre automatisation en tant que service. Les demandes sont examinées, peuvent être mises à jour et enfin envoyées en traitement par RHAPP.

Le catalogue de Squest est générique. Un service est en réalité un pointeur vers un playbook Ansible dans RHAPP. Cela signifie que tout script d'automatisation peut être exposé en tant que service. Nous l'utilisons dans un contexte d'infrastructure pour déployer des machines virtuelles, des orchestrateurs de conteneurs ou des plateformes de cloud privés. Mais il pourrait être utilisé pour tout autre chose, la seule limite est votre propre capacité d'automatisation avec Ansible.

Squest vient combler un manque de RHAAP en conservant les métadonnées de chaque instance de service qu’il a déployé. Ceci permet à l’utilisateur de demander des opérations de jour-2 qui sont elles-mêmes des pointeurs vers d’autres playbooks de RHAAP.

L’utilisateur rempli pour nous via le formulaire de l’opération les variables nécessaires à la bonne exécution du playbook et Squest ajoute de son côté les métadonnées permettant au playbook de retrouver l’instance ciblé par cette opération.
Le processus d'approbation est personnalisable et certaines opérations peuvent même être configurées pour être exécutées sans approbation, augmentant ainsi l'autonomie de nos utilisateurs.

Tout cela est pilotable depuis l’interface ou depuis l’API afin que les utilisateurs retrouvent une expérience proche de ce qu'ils pourraient trouver chez un hébergeur de cloud public.

Le gestionnaire de ressource

Les infrastructures informatiques d’aujourd’hui se composent de multiples couches. Par exemple, des serveurs physiques mettent à disposition des ressources comme du CPU, de la mémoire et de l’espace de stockage. Un hyperviseur va ensuite agréger cette puissance de calcul pour créer des machines virtuelles. Ces machines virtuelles peuvent elle-même travailler en cluster afin de fournir un autre service comme de l’orchestration de conteneur. En somme, le dernier niveau de consommation a un impact sur le niveau au-dessus de lui, qui a lui-même un impact sur les premiers niveaux.

Squest maintien de façon automatique une carte des réservations de ressource effectuées depuis le catalogue de service et génère un graphique représentant chaque niveau. Ainsi, lorsqu’une nouvelle demande arrive depuis le portail, un simple coup d'œil sur le graphique permet de valider si nous sommes en capacité d’accepter la requête.

Retour d’expérience après deux ans de production

Après deux ans de production, le bilan pour notre équipe est positif. Squest adresse l’ensemble des problèmes mentionnés. Nous avons réduit le nombre de canaux de communication à un seul et unique portail qui centralise toutes les demandes de services ainsi que les supports associés. Les temps de déploiement sont réduits au temps d'exécution des playbooks. Le portail a géré plus de 2000 demandes de service et d’opérations de type jour-2, épargnant à notre équipe des centaines d’heures de support et d’interventions manuelles.

Squest nous permet de passer moins de temps sur les tâches à faible valeur ajoutée.

Le bon playbook ainsi que son environnement d'exécution sont disponibles derrière un simple formulaire, qui de plus est rempli à notre place par l’utilisateur. Toutes ces tâches apparaissent à présent comme une requête dans Squest et ne nécessitent qu’une simple approbation pour être exécuté.

L'approche générique permet d’étendre les capacités et les services disponibles au fur et à mesure de l'amélioration de notre automatisation. Nous intégrons selon les besoins métiers de nouveaux services ou de nouvelles opérations de type jour-2.

Avant Squest, la gestion des réservations était effectuée au travers de multiples feuilles de calculs dans des formats différents. À présent, Squest consolide ces informations de façon automatique et fournit une vue unique de la sollicitation de nos infrastructures. Rendant difficile l’extraction d'indicateurs de performance.

Couplé à un système de monitoring, la réservation calculée dans Squest permet de mesurer l’efficacité de l’usage de nos infrastructures. Cette comparaison entre la réservation et la réelle consommation a permis aux équipes R&D de mieux dimensionner leurs environnements et donc d’optimiser au mieux l’usage du matériel.

La solution a également été validée par nos utilisateurs grâce notamment à une réduction des délais de traitement des demandes et une centralisation de leurs ressources et services.

L’automatisation apporte à notre équipe comme à nos utilisateurs finaux l’opportunité de passer plus de temps en R&D. Ce temps gagné nous a permis de revoir l’architecture de notre infrastructure pour la rendre plus générique et dynamique et ainsi automatiser de façon plus efficace.

Squest v2

Avant cette version, il n’existait que deux types de profil dans Squest: L’utilisateur final et l’administrateur. Avec les RBAC, nous allons pouvoir dissocier les actions au travers des permissions. Nous pouvons par exemple avoir une équipe chargée des approbations, une autre chargée du catalogue, etc…

Le système de quota est à présent directement lié aux formulaires. Les demandes de services peuvent donc être limitées par équipe ou organisation. Les requêtes peuvent également être exécutées automatiquement si la limite du quota n’est pas atteinte.

Enfin, le nouveau système de création de processus d’approbation permet de découper les formulaires des requêtes en multiples étapes de validation. Un cas d’usage consiste à ajouter par exemple un référant en amont d’une validation de la part de l’équipe technique.

Les principales nouveautés de la v2 sont les suivantes :

• RBAC (Role Based Access Control) pour une gestion fine des permissions
• ajout du niveau Organisation
• gestion avancée des quotas
• possibilité d'accepter automatiquement une requête en fonction du quota
• un quota peut être défini au niveau de chaque champ du formulaire de service
• redistribution du quota entre les équipes d’une organisation
• un thème sombre
• possibilité de déplacer des ressources du gestionnaire de ressource d’un groupe à un autre
• un nouveau tableau de bord
• nouvelle vue de gestion des requêtes
• ajout de nouvelles variables dans le contexte des template Jinja
• nouveau système d’approbation par étape. Chaque étape peut avoir son propre formulaire et sa propre permission.
• refonte du système de suivi des ressources (plus simple d’utilisation)
• refonte de l’API.

Mot de la fin

Nous sommes très heureux de pouvoir nous rendre à la communauté Ansible en proposant ce projet en open source. On espère que cet article vous donnera des idées pour à votre tour pousser l’automatisation de vos services un cran plus loin.

N’hésitez pas à nous rejoindre pour discuter sur le chat Gitter du projet. Et si ce dernier vous plaît, n’hésitez pas à lui mettre une star sur Github, cela motive énormément la petite équipe derrière.

Aller plus loin

• Code source (202 clics)
• Note de migration v1 à v2 (27 clics)
• Journal des modifications v2 (24 clics)