Automatizer vos déploiements avec Ansible et GitLab

Temps de lecture : 5 minutes

Vous gérez des artefacts Maven sur GitLab et recherchez une solution simple, sécurisée et efficace pour les déployer ?
Cet article vous guide pas à pas pour utiliser Ansible et automatiser ce processus sans accroc.

Ce que vous apprendrez :

➡️ Gestion des dépendances Python indispensables
➡️ Deux playbooks clés : téléchargement sur l’hôte administré ou via la machine de contrôle
➡️ Les meilleures pratiques pour sécuriser vos tokens d’authentification

Le module Ansible community.general.maven_artifact (anciennement maven_artifact) est un module qui permet de télécharger un artefact depuis un dépôt Maven.

Dépendances du module Ansible
Le module community.general.maven_artifact nécessite certaines librairies Python tierces qui ne sont pas incluses par défaut avec Ansible. Selon votre environnement, vous devrez peut-être installer ces dépendances sur vos machines cibles :

• La librairie lxml : elle permet à Ansible d’analyser les fichiers XML.
• La librairie boto : elle permet d’accéder aux artefacts Maven stockés sur un dépôt S3 (service Cloud AWS).

Comment installer les dépendances nécessaires
Le module community.general.maven_artifact s’exécute par défaut sur l’hôte administré par Ansible. Il est donc nécessaire d’installer les dépendances sur les machines cibles. Cependant, si vous n’avez pas les droits pour installer les dépendances sur ces machines, vous pouvez contourner le problème en installant les dépendances sur la machine de contrôle Ansible.

Conseil
Si votre machine de contrôle Ansible peut accéder à votre serveur GitLab, vous pouvez installer les dépendances sur cette machine. Généralement, nous avons moins de restrictions sur cette machine grâce à l’utilisation d’un virtualenv ou de l’option --user de pip.

Pour cela, utilisons le gestionnaire de paquets Python pip :

$ pip install lxml (1)
Collecting lxml
Downloading lxml-5.3.0-cp38-cp38-manylinux_2_28_x86_64.whl.metadata (3.8 kB)
Downloading lxml-5.3.0-cp38-cp38-manylinux_2_28_x86_64.whl (5.1 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.1/5.1 MB 25.7 MB/s eta 0:00:00
Installing collected packages: lxml
Successfully installed lxml-5.3.0

(1)Les artefacts Maven étant stockés sur GitLab, nous n’avons pas besoin de la librairie boto.

Interfacer le dépôt Maven de GitLab avec Ansible
Dans les exemples fournis dans la documentation du module community.general.maven_artifact, il est utilisé pour télécharger des artefacts depuis des dépôts Maven publics ou des dépôts Maven privés avec une authentification standard (arguments username et password).

Le registre de paquet GitLab utilise un système d’authentification basé sur des tokens dans les en-têtes HTTP des requêtes. Par conséquent, l’authentification standard du module community.general.maven_artifact n’est pas compatible avec GitLab.

Néanmoins, ce module propose l’argument optionnel headers (un dictionnaire) permettant de spécifier des en-têtes HTTP supplémentaires. Pour nous authentifier auprès du registre GitLab, nous devons fournir les en-têtes spécifiques à notre token. Voici un exemple de tâche Ansible :

1. - name: Téléchargement du JAR Maven
2. community.general.maven_artifact:
3. group_id: com.lavoiedudev
4. artifact_id: example
5. version: '1.0.0'
6. repository_url: "{{ gitlab_base_url }}/api/v4/projects/{{ gitlab_project_id }}/packages/maven"
7. headers: "{{ {gitlab_token_type: gitlab_token} }}" (1)
8. dest: "{{ application_path }}/exemple.jar"

(1) Les variables gitlab_token_type et gitlab_token contiennent respectivement le nom de l’en-tête HTTP et le token d’authentification. Nous utiliserons les mêmes informations que celles déclarées dans le fichier settings.xml de Maven, comme par exemple Deploy-Token: .

Télécharger un artefact Maven depuis l’hôte administré
Généralement, nous privilégions le téléchargement d’artefacts Maven depuis l’hôte administré par Ansible. L’artefact est directement récupéré par la machine cible, ce qui réduit le nombre d’actions à effectuer pour le déployer.

Pour télécharger un artefact Maven depuis GitLab Registry, nous pouvons proposer le playbook suivant :

# /playbook.yml
- name: Déploiement de l'utilitaire Java
hosts: all
become: yes
become_user: "{{ application_user }}"

tasks:
- name: Création du répertoire du logiciel Java
ansible.builtin.file:
path: "{{ application_path }}"
state: directory
mode: '0755'
owner: "{{ application_user }}"
group: "{{ application_group }}"

- name: Téléchargement du JAR Maven
community.general.maven_artifact:
group_id: com.lavoiedudev
artifact_id: example
version: '1.0.0'
repository_url: "{{ gitlab_base_url }}/api/v4/projects/{{ gitlab_project_id }}/packages/maven"
headers: "{{ {gitlab_token_type: gitlab_token} }}"
dest: "{{ application_path }}/exemple.jar"
owner: "{{ application_user }}"
group: "{{ application_group }}"
mode: '0644'

En exécutant ce playbook, vous retrouverez l’artefact Maven téléchargé depuis le registre GitLab dans le répertoire {{ application_path }} de votre machine cible.

Note
En cas de problème avec la vérification des certificats SSL, vous pouvez utiliser l’argument validate_certs: false pour désactiver ce contrôle.

Télécharger un artefact Maven depuis l’hôte de contrôle
Si vous ne pouvez pas télécharger l’artefact Maven directement sur l’hôte administré par Ansible, nous pouvons contourner le problème en le téléchargeant depuis l’hôte de contrôle. Dans ce cas, l’artefact est récupéré par la machine de contrôle, puis transféré vers l’hôte administré.

Cette méthode demande plus d’actions de la part d’Ansible. Nous pouvons faire évoluer le playbook précédent de la manière suivante :

# /playbook.yml
# ...
version: '1.0.0'
repository_url: "{{ gitlab_base_url }}/api/v4/projects/{{ gitlab_project_id }}/packages/maven"
headers: "{{ {gitlab_token_type: gitlab_token} }}"
+ dest: "{{ inventory_dir }}/exemple.jar"
+ delegate_to: localhost
+ run_once: true
+
+ - name: Copie du JAR Maven sur l'hôte cible
+ ansible.builtin.copy:
+ src: "{{ inventory_dir }}/exemple.jar"
dest: "{{ application_path }}/exemple.jar"
owner: "{{ application_user }}"
group: "{{ application_group }}"
mode: '0644'
+
+ - name: Suppression du JAR Maven temporaire
+ ansible.builtin.file:
+ path: "{{ inventory_dir }}/exemple.jar"
+ state: absent
+ delegate_to: localhost
+ run_once: true

Les tokens d’authentification sont des informations sensibles. Pour garantir la sécurité de votre infrastructure, veillez à mettre en place des stratégies cohérentes. Voici quelques conseils pour les sécuriser :

• Ne stockez pas les tokens dans le code source : Les tokens d’authentification ne doivent pas être stockés dans le code source de vos projets. Utilisez des variables déclarées dans vos inventaires Ansible ou dans les dossiers group_vars ou hosts_vars associés, ou passez-les en argument lors de l’exécution du playbook (option -e).
• Chiffrez les tokens : Si vous stockez les tokens dans des fichiers, chiffrez-les pour éviter qu’ils ne soient lus en clair. Pour cela, utilisez Ansible Vault (au niveau de la clé ou du fichier).
• Limitez les droits des tokens : De tels tokens doivent avoir des droits d’accès limités. Lors d’un déploiement, vous n’avez généralement besoin que des droits de lecture dans le registre GitLab.

Conclusion
Dans cet article, nous avons vu comment télécharger un artefact Maven depuis GitLab en utilisant Ansible. Nous avons détaillé la configuration du module Ansible community.general.maven_artifact pour qu’il puisse s’authentifier auprès du registre GitLab. Nous avons également présenté deux méthodes pour télécharger un artefact Maven depuis GitLab : directement sur l’hôte administré par Ansible ou sur la machine de contrôle.

Ansible est un outil puissant pour automatiser le déploiement de vos applications. En combinant Ansible avec le registre GitLab, vous pouvez facilement automatiser le téléchargement des artefacts Maven de vos projets. Vous pourrez ainsi faciliter le travail des équipes opérationnelles tout en garantissant un accès sécurisé aux artefacts de vos projets.