Configuration du Web Terminal de Gitlab

É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 besoins
advertise_address correspond à l’URL pour accéder au Runner, si elle n’est pas définie listen_address sera utilisée
session_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.