Mise à jour vers Gitlab 10, rio ne répond plus

Mise à jour vers Gitlab 10, rio ne répond plus

Le proverbe sysadmin « Pas d’installation, ni de mise à jour le vendredi » a pris tout son sens en ce vendredi matin. Cela faisait quelques mois que je n’avais pas touchés mon serveur gitlab et donc je décide d’un pas tranquille de le mettre à jour, ainsi que le container qui l’héberge. Mais tout ne se passe pas comme prévu et une simple mise à jour de 5 mn m’a finalement bloqué une bonne partie de la matinée. La mise à jour s’est déroulée correctement, le container est monté de jessie vers stretch sans embûches. Gitlab est passé de la version 9.5 à 10.2. Je redémarre tout ce petit monde tout semble normal, pas d’anomalies ni de messages d’erreurs. Mais lorsque j’ai voulu me connecter à mon instance, celle-ci  me répondait toujours la même chose :  502 Whoops, GitLab is taking too much time to respond. Et me voilà parti pour identifier le problème.

 

Premièrement, jeter un coup d’œil aux journaux systèmes, ils donnent toujours de bonnes informations. Justement les devs de gitlab ont très bien fait les choses car il est possible de parcourir tous les logs services en une seule commande :

La vérité me fut révélée, mon problème venait du service gitlab_workhorse :

Deuxièmement, une fois le problème identifié, parcourir le site de gitlab afin de savoir si d’autres ont eu ce problème et s’ils l’ont résolu. D’après les premières constations de l’enquête  il s’agit d’un problème de droit que rencontre nginx sur le socket du service gitlab_workhorse. Vérifions cela :

On voit bien que seul l’utilisateur GIT et le groupe GIT ont accès au socket. J’ai orienté mes recherches dans ce sens et j’ai fini par trouver :

https://gitlab.com/gitlab-org/gitlab-workhorse/issues/129

Je décide de faire comme préconisé :

Je redémarre gitlab et paf ! Toujours cette maudite erreur 502 et toujours ce problème de droit sur le socket gitlab_workhorse. J’approfondis encore mes recherches directement sur la documentation de gitlab, je finis par trouver une piste qui n’avait rien avoir avec mon problème:

Set the right gitlab-workhorse settings if using Apache.

L’évidence me sauta aux yeux. Pourquoi utiliser le service en mode socket ? Pourquoi ne pas essayer en mode tcp ?

Ni une, ni deux je modifie le /etc/gitlab/gitlab.rb avec les paramètres suivants (directement récupérés de la doc) :

Comme à chaque modification du gitlab.rb, il faut lancer une reconfiguration.

Me croyant sorti d’affaire je pousse un ouf de soulagement et bien non, pendant la reconfiguration un nouveau problème apparut.

Cela m’apprendra à faire des mises à jour sans lire la note de version :

https://about.gitlab.com/2017/09/22/gitlab-10-0-released/#gitlab-git-http-server-configuration-support-removed

Je retourne dans le gitlab.rb, je commente la ligne :

Je relance une configuration, tout ce passe bien. Je vérifie le service gitlab_workhorse, aucune erreur apparente. Je tente une connexion depuis l’interface web tout fonctionne parfaitement. Je peux enfin pousser mon gros ouf de soulagement.

C’est décidé j’arrête les mises à jour bancales juste après le petit-déjeuner, enfin jusqu’à la prochaine 🙂 .

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.