Écrit par Medhi Ravily
Dans un contexte DevOps, l’utilisation de pipelines CI/CD est devenue un incontournable, dans la manière de construire des images Docker, d’effectuer des tests applicatifs ainsi que de déployer l’application. Elle couvre les différentes phases qui s’étalent du développement jusqu’à la production.
Malgré l’utilisation de templates chez Ouidou pour normaliser et rendre maintenables nos infrastructures plus aisément, chaque phase de construction (job) peut apporter son lot de surprises. Dans ce contexte, il peut devenir intéressant d’interagir avec le processus de construction en cours. C’est là que l’Interactive Web Terminal fait son entrée.
Les instances Runners
sur Gitlab.com ne proposant pas cette feature, il faudra utiliser vos propres project runner
.
Context
Pour ce qui est de notre infrastructure, elle est composée d’un firewall et d’un proxy de type HA. L’objectif est de garder les infrastructures étanches de l’extérieur. Les runners s’exécutent donc dans un réseau privé.
Côté Gitlab, nous utilisons une version en Self-Hosted
, avec 5 runners
externalisés utilisant un executor Docker
, 4 d’entre eux au sein du réseau privé, tandis que le dernier est exposé publiquement pour les besoins spécifiques d’un projet, cela va avoir son intérêt dans les étapes de configuration.
Toutes les briques qui composent l’infrastructure sont déployées «as code», avec Terraform et des playbook Ansible. La connexion à nos VMs s’effectue via Boundary. Dans un souci de simplicité, dans nos exemples nous effectuerons les actions manuellement.
Comment ça marche ?
Depuis le Gitlab UI, un utilisateur possédant un rôle à partir du developer
, pourra effectuer l’action de Debug
depuis un job d’un pipeline en cours d’exécution, cela va initier l’ouverture d’un WebSocket
auprès du serveur Gitlab qui jouera le rôle de proxy
vers le Runner
concerné.
NB: Le temps d’exécution de votre job doit être suffisamment long pour que la connexion s’effectue, pensez à ajouter un sleep
pour l’étendre et avoir le temps d’effectuer vos commandes de debug.
Configuration
Il existe trois manières, selon la configuration d’exposition de vos runners, d’activer cette feature
:
- Votre serveur Gitlab et votre runner sont sur la même instance
- Votre runner est exposé publiquement
- Votre runner est dans un réseau privé
Quelque soit la configuration d’exposition de vos Runners
, ils disposent tous du fichier de configuration config.toml
. Une fois cette configuration effectuée, si votre runner est derrière un proxy
, nous détaillerons les étapes relatives afin que la communication s’effectue sans encombre entre votre serveur Gitlab
et vos Runners
.
Configuration du Runners
Commencez par vous connecter à la machine éxécutant votre runner avec les droits root pour ouvrir le fichier config.toml
➜ ~ ssh root@127.0.0.1 -p 52004
root@gitlab:~$ vim /etc/gitlab-runner/config.toml
Localiser la section [session_server]
et ajouter les valeurs suivantes :
[session_server]
listen_address = "[::]:8093"
advertise_address = "url-runner:8093"
session_timeout = 1800
listen_address
permet de définir sur quelle interface réseau votre runner doit écouter, le port est arbitraire et peux être changé selon vos besoinsadvertise_address
correspond à l’URL pour accéder au Runner, si elle n’est pas définielisten_address
sera utiliséesession_timeout
défini le TTL en secondes pendant laquelle la session restera active
Pour une configuration Gitlab et runner sur la même instance, l’advertise_address
sera localhost:8083
.
Pour des runnners externalisés, elle sera l’URL de votre runner ex: gitlab-runner.internal.ouidou.fr:8093
ou une URL publique.
Il ne vous reste plus qu’à effectuer la même manipulation sur tous vos runners et redémarrer le service sur chacun d’entre eux.
root@gitlab-runners-2:/home/ouidou# gitlab-runner restart
Configuration du proxy
Passons maintenant à la configuration du Proxy, cette section va dépendre du type de Proxy que vous utilisez, dans notre exemple nous éditerons le fichier de configuration d’un type HA
pour naviguer automatiquement entre HTTP
et le Tunnel WebSocket
.
Vous pouvez retrouvez les autres configurations selon votre type de proxy à cette adresse: enabling-and-disabling-terminal-support
Rendez-vous maintenant sur votre VM et ouvrez le fichier de configuration avec votre éditeur :
defaults
mode http
log global
option httplog
option http-server-close
option dontlognull
option redispatch
option contstats
retries 3
backlog 10000
timeout client 25s
timeout connect 5s
timeout server 25s
# timeout tunnel available in ALOHA 5.5 or HAProxy 1.5-dev10 and higher
timeout tunnel 3600s
timeout http-keep-alive 1s
timeout http-request 15s
timeout queue 30s
timeout tarpit 60s
default-server inter 3s rise 2 fall 3
option forwardfor
Notre proxy est configuré, nous allons vérifier que le proxy du serveur Gitlab autorise bien l’utilisation des headers nécessaire au WebSocket
.
Config Gitlab pour runner derrière proxy
Connectez-vous en tant que root
à votre VM, ouvrez le fichier gitlab.rb
avec votre éditeur.
Cherchez la section nginx['proxy_set_headers']
, et vérifiez qu’elle possède bien les headers suivants : Connection
et Upgrade
.
Il ne nous reste qu’une dernière chose à faire, depuis l’interface Admin de Gitlab.
Dirigez-vous dans Settings / Network / Outbound request
, puis cocher Allow requests to the local network from webhooks and integrations
Conclusion
Voilà, toutes les configurations requises sont effectuées, vous pouvez maintenant vous connecter à un Web Terminal depuis l’un de vos jobs sur l’ensemble des pipelines.
Sources
À lire aussi
![Nouveau podcast Canap’Agile by Ouidou Nouveau podcast Canap’Agile by Ouidou](https://ouidou.fr/wp-content/uploads/2024/08/92b502f8-7108-46d2-8c7b-8f7be996b8af.png)
Nouveau podcast Canap’Agile by Ouidou
![Intégration des tests Spring Boot avec Testcontainers (PostgreSQL) Intégration des tests Spring Boot avec Testcontainers (PostgreSQL)](https://ouidou.fr/wp-content/uploads/2024/03/Configuration-du-Web-Terminal-de-Gitlab-1.png)
Intégration des tests Spring Boot avec Testcontainers (PostgreSQL)
![Ouidou x Captain Cause : un cadeau qui a du sens Ouidou x Captain Cause : un cadeau qui a du sens](https://ouidou.fr/wp-content/uploads/2024/08/Captain-cause-1.png)
Ouidou x Captain Cause : un cadeau qui a du sens
![Agile SAFe : Une Approche Évolutive pour la Gestion de Projets à Grande Échelle Agile SAFe : Une Approche Évolutive pour la Gestion de Projets à Grande Échelle](https://ouidou.fr/wp-content/uploads/2024/06/Configuration-du-Web-Terminal-de-Gitlab-1.png)