Sortie de Squest, le portail de service pour Tower/AWX, en version 1.0

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
• Tutoriel de création d’un service
  • Provisionner un service
  • Mise à jour ou suppression d’un service

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)