L’équipe de développement est heureuse de vous annoncer la sortie de la première version prête pour la production de Squest, l’outil à destination des DevOPs/SRE.
Pour rappel, Squest, que vous retrouverez en introduction dans une dépêche précédente dans sa version alpha, est un outil auto hébergé vous permettant d'exposer votre automatisation disponible depuis votre instance de Ansible Tower/AWX en tant que service.
Après un résumé des principales nouveautés, nous allons vous présenter un tutoriel de création d’un service.
Sommaire
Résumé des principales nouveautés
- Image docker officielle ;
- Gestion des annonces aux utilisateurs ;
- Gestion de documentation (markdown) rattachable aux services ;
- Gestion des jetons d’authentification pour l’API ;
- Interface de détails pour les requêtes et les instances ;
- Suppression/archive des requêtes ou instances en tant qu’administrateur ;
- Ajout d’attribut de type « texte » sur les groupes de ressources ;
- Ajout d’un ratio sur les attributs des groupes de ressources ;
- Vérification de la compatibilité avec les « job templates » de Tower/AWX ;
- Gestion intégrée de la sauvegarde.
Tutoriel de création d’un service
Squest permet d’exposer l’automatisation présente dans votre instance d’Ansible Tower/AWX en tant que service.
Nous allons ici exposer un service d’exemple sur le portail Squest. L’objectif est de comprendre les interactions entre le portail et le moteur d’automatisation sous-jacent Ansible.
Provisionner un service
Pour cet exemple, nous souhaitons exposer à nos utilisateurs un service qui permet de créer un fichier sur un serveur Linux et d’y placer du contenu. Voici le code Ansible permettant cette création :
- name: Create a directory with UUID
ansible.builtin.file:
path: "{{ file_path }}"
state: directory
recurse: yes
mode: u+rw,g-wx,o-wx
modification_time: preserve
access_time: preserve
- name: Write the given content in file
ansible.builtin.copy:
content: "{{ file_content }}"
dest: "{{ file_path }}/{{ file_name }}"
Il suffirait donc de placer ce playbook dans un répertoire Git, de déclarer le répertoire sur Tower, et enfin de créer un « job template » qui pointe sur le playbook.
Seulement voilà, si l’on souhaite effectuer plus tard d’autres opérations sur ce fichier en particulier, par exemple changer le contenu, il faut donner des informations à Squest pour le retrouver. C’est là qu’intervient l’instance.
Lorsqu’un utilisateur effectue une requête pour un service, Squest va automatiquement créer une « instance » et la placer en statut « en attente » (PENDING). L’idée est de faire en sorte que le playbook exécuté appel l’API de Squest afin de donner des informations permettant de retrouver l’objet que nous avons créé (ici un simple fichier).
En résumé la séquence est la suivante :
Lorsque le playbook est exécuté sur Tower par la demande de Squest, ce dernier reçoit deux blocs d’information :
- les variables de l’utilisateur (appelées « extra_vars ») qui proviennent du formulaire du service (survey) ;
- une variable « squest » qui contient toutes les informations sur la requête et l’instance en attente sur Squest.
Notre playbook va donc se servir des « extra_vars » pour créer la ressource, dans notre exemple, un fichier. Nous aurons donc un formulaire qui demande un nom de fichier et un contenu.
Et enfin le playbook va se servir de la variable « squest » pour connaitre l’identifiant de l’instance en attente afin de lui donner des informations (spec) qui permettront de l’identifier de façon formelle dans un prochain appel.
Voici un exemple d’une variable « squest » que le playbook va recevoir :
squest:
request:
instance:
id: 1
name: test
service: 1
spec:
file_name: foo.conf
state: PROVISIONING
Voilà notre playbook de création au complet. (Les variables « file_name » et « file_content » proviennent du formulaire du « job template » et sont donc injectées au moment de l’exécution) :
- hosts: squest_testing
become: False
gather_facts: False
tasks:
- name: Generate UUID
set_fact:
uuid_file: "{{ file_name | to_uuid }}"
- name: Generate path
set_fact:
file_path: "/tmp/squest_functional_test/{{ uuid_file }}"
- name: Prints variables
ansible.builtin.debug:
msg:
- "UUID: {{ uuid_file }}"
- "file_name: {{ file_name }}"
- "file_content: {{ file_content }}"
- name: Create a directory with UUID
ansible.builtin.file:
path: "{{ file_path }}"
state: directory
recurse: yes
mode: u+rw,g-wx,o-wx
modification_time: preserve
access_time: preserve
- name: Write the given content in file
ansible.builtin.copy:
content: "{{ file_content }}"
dest: "{{ file_path }}/{{ file_name }}"
- name: Update squest instance with spec
uri:
validate_certs: no
url: "{{ squest_api_url }}/service_catalog/admin/instance/{{ squest['request']['instance']['id'] }}/"
headers:
Authorization: "Token {{ squest_token }}"
method: PATCH
body:
spec:
file_name: "{{ file_name }}"
uuid_file: "{{ uuid_file }}"
status_code: 200
body_format: json
Vous aurez remarqué que, dans cet exemple, nous générons notre propre identifiant unique (uuid).
L’identifiant unique va totalement dépendre du service que vous souhaitez exposer. L’idée est de nourrir le spec de l’instance avec des informations qui permettront à un autre playbook de modifier cette instance précise et pas une autre.
Si, par exemple, votre service propose la création d’une base de données dans un serveur Postgres, l’identifiant unique de cette base sera son nom et le nom du serveur qui l’héberge.
Mise à jour ou suppression d’un service
Pour chaque service dans le catalogue de Squest il est possible d’attacher des « opérations » qui permettent de gérer le cycle de vie de l’objet créé via ce service. Une opération correspond à un « job template » et donc un playbook Ansible.
Ce nouveau playbook devra lire les informations envoyées dans la variable « squest » et plus particulièrement les valeurs placées dans le champ « spec » afin de mettre à jour l’objet qui avait été créé dans l’opération de provisionnement.
Si l’on repart de notre exemple, et que nous souhaitons cette fois proposer a l’utilisateur de modifier le contenu du fichier qu’il avait créé. Au moment de l’appel, Squest va automatiquement attacher la variable « squest » avec toutes les informations « spec » fournies au moment du provisionnement de l’instance.
La séquence est cette fois-ci la suivante :
Voici un exemple de variable « squest » qu’un playbook pourrait recevoir :
squest:
request:
instance:
id: 1
state: UPDATING
spec:
file_name: 'my_file.txt'
uuid_file: 51b1d14c-cedf-5837-9063-b8cb45f950fe
Et voici un exemple de code Ansible qui permettrait la mise à jour du fichier :
- hosts: squest_testing
become: False
gather_facts: False
tasks:
- name: Get UUID and file name from Squest
set_fact:
uuid_file: "{{ squest['request']['instance']['spec']['uuid_file'] }}"
file_name: "{{ squest['request']['instance']['spec']['file_name'] }}"
- name: Generate path
set_fact:
file_path: "/tmp/squest_functional_test/{{ uuid_file }}"
- name: Prints variables
ansible.builtin.debug:
msg:
- "UUID: {{ uuid_file }}"
- "file_name: {{ file_name }}"
- "file_content: {{ file_content }}"
- name: Write the given content in file
ansible.builtin.copy:
content: "{{ file_content }}"
dest: "{{ file_path }}/{{ file_name }}"
Dans l’exemple nous avons effectué une mise à jour, mais nous aurions pu tout aussi bien supprimer le fichier et donc l’instance sur Squest.
Aller plus loin
- Code source (152 clics)
- Documentation (122 clics)
- Demo du catalogue de service (227 clics)
# Coquille
Posté par mr_unichs . Évalué à 1. Dernière modification le 09 octobre 2021 à 09:42.
Il me semble qu’il y a une coquille dans la dépêche, j’imagine qu’il faut lire AWX et non AWS.
[^] # Re: Coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci. La dépêche parle bien de AWX, et pas de AWX sur AWS.
# interressant, ça donne envie d'essayer
Posté par jez (site web personnel) . Évalué à 3. Dernière modification le 19 octobre 2021 à 06:25.
Bon c'est le deuxième article que je lit sur Squest, ça a l'air cool. Ça s'inscrit bien dans un workflow de travail. J'aime bien le côté "je presse un bouton et ça marche". Note: je travaille en ce moment dans une grosse compagnie avec des process bien lourds et des paradigmes antiques: bref, cliquer sur des boutons ça plaît. Je vois un bon potentiels chez les TPME/assoc aussi.
Sans avoir testé (yet!), je note la qualité de l'écriture des playbooks ansible (dans les exemples surtout), l'effort et le soin porté a la documentation et a la communication. Dernier point, le plus important, merci de contribuer au logiciel libre! (HPE remonte un tout petit peu dans mon estime, -la série des Gen10, je suis pas prêt de l'oublier celle là lol-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.