URL: https://linuxfr.org/news/sortie-de-squest-le-portail-de-service-pour-tower-awx-en-version-1-0 Title: Sortie de Squest, le portail de service pour Tower/AWX, en version 1.0 Authors: sispheor palm123, Pierre Jarillon, Xavier Teyssier, Benoît Sibaud et Ysabeau Date: 2021-10-03T19:16:03+02:00 License: CC By-SA Tags: ansible, python3 et devops Score: 3 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](https://linuxfr.org/news/squest-portail-de-services-pour-sre-devops-en-frontal-d-ansible-tower-awx) dans sa version alpha, est un outil auto hébergé vous permettant d'exposer votre automatisation disponible depuis votre instance de Ansible Tower/AWS 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. ---- [Code source](https://github.com/HewlettPackard/squest) [Documentation](https://hewlettpackard.github.io/squest/latest/) [Demo du catalogue de service](https://www.youtube.com/watch?v=ZfTjS1t7X74) ---- # 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 : ```yml - 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 : [![squest-request-workflow.png](https://i.postimg.cc/PqBtq4rV/squest-request-workflow.png)](https://postimg.cc/Z9xk76N6) 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 : ```yml 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) : ```yml - 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 : [![squest-request-update-workflow.png](https://i.postimg.cc/T2K1jCsw/squest-request-update-workflow.png)](https://postimg.cc/jCrRtQt0) 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 : ```yml - 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.