cClaude.rocks ☕ Le blog

[Nouvelles technologies, sciences et coups de gueule…]

Menu

Depuis quelques jours l’instance GitLab de la plateforme n’est pas stable, c’est même un euphémisme puisqu’elle plante au bout de quelques minutes.

J’ai fait pas beaucoup de recherche pour corriger ce problème, suivit beaucoup de pistes et j’ai même pensé l’avoir solutionné plusieurs fois.



Ce que l’on voit :

Depuis l’interface web :

On obtient une erreur HTTP 502

Dans les logs de la machine :

sudo gitlab-ctl tail gitlab-workhorse
==> /var/log/gitlab/gitlab-workhorse/current <==
{"build_time":"20201022.044637","level":"info","msg":"Starting","time":"2022-04-23T08:48:06+02:00","version":"v8.39.0"}
{"configFile":"config.toml","error":"open config.toml: no such file or directory","level":"fatal","msg":"Can not load config file","time":"2022-04-23T08:48:06+02:00"}

La commande :

sudo gitlab-rake gitlab:check

Indique qu’il manque un fichier de configuration /opt/gitlab/embedded/service/gitlab-shell/config.yml. En creusant, je comprends qu’il s’agit d’un lien vers /var/opt/gitlab/gitlab-shell/config.yml et que c’est finalement ce second fichier qui manque.



Ce qui a changé récemment sur la machine :

Je ne fais pas les mises à jour automatique de GitLab ayant eu un subir par le passer des problèmes liés à cette stratégie. C’est une solution que l’on peut éventuellement envisager en entreprise lorsqu’une équipe peut intervenir rapidement pour solutionner un éventuel problème. Sur une petite instance, c’est solution donne trop de travail. Ce qui fait que je suis très en retard sur la version actuellement disponible de GitLab.

  • Cependant je mets à jour le système régulièrement.

Cela doit être considéré comme une cause possible.

  • Suite à une analyse de la machine, j’ai exécuté la commande :
sudo gitlab-rake gitlab:check

Et j’ai relevé un message qui m’a recommandé de faire une migration du stockage des dépôts.

sudo gitlab-rake gitlab:storage:migrate_to_hashed

C’est donc une seconde cause possible, mais il me semble que j’aurais eu un message d’erreur un peu plus clair.

Durant mes recherches sur Internet, je me suis aperçu qu’il y avait entre 50 et 100 personnes confronté à des symptômes très proches des miens dans le dernier mois. Certains de ces messages précisaient que depuis l’instance n’avait pas été mise à jour depuis plusieurs mois, voir plusieurs années.

Cela m’a mis sur une piste que je n’ai trouvée évoqué nulle part.

Les exécuteurs externes tournant à l’aide de gitlab-runner.

  • Je mets à jour régulièrement les exécuteurs externes basé sur gitlab-runner.

Du coup, je trouve cette seconde hypothèse plus crédible, car la mise à jour du système est fort différente entre une machine basée Red-Hat et une machine basée sur Raspbian.

J’ai donc arrêté tous les gitlab-runner présent sur la plateforme et relancer la configuration du serveur GitLab pour reprendre la configuration qui marchait il y a disons 15 jours, après un redémarrage du serveur, il semble tenir.



Vers une résolution

Bilan, je vais tenter de retrograder (mettre une version plus ancienne) le programme gitlab-runner sur les machines où il est installé.

D’abord il faut identifier la version actuelle de GitLab, cela peut se faire sur le serveur à l’aide de :

sudo gitlab-rake gitlab:env:info RAILS_ENV=production # ou : bundle exec rake gitlab:env:info RAILS_ENV=production

Pour automatiser ce point, je propose le code suivant :

GITLAB_VERSION="$(
  sudo gitlab-rake gitlab:env:info RAILS_ENV=production |
    grep -A 2 -E '^GitLab information' |
    grep -E '^Version:[[:blank:]]' |
    sed -E 's,^Version:[[:blank:]]*([0-9]+.[0-9]+.[0-9]+),\1,'
  )"

Sur chacun des exécuteurs :

Je suppose que GITLAB_VERSION contient la valeur calculée ci-dessus, par exemple :

GITLAB_VERSION='13.12.0' # Valeur donnée comme exemple à adapter à vos besoins.

On peut calculer le numéro de version de base à l’aide de :

GITLAB_RELEASE_VERSION="$(
  sed -E 's,^([0-9]+)\.([0-9]+)\.([0-9]+)$,\1,' <<<"${GITLAB_VERSION}"
)"

Donc dans cet exemple 13.

GITLAB_RUNNER_VERSION="$(
  apt-cache policy gitlab-runner | grep -E "[[:blank:]]+${GITLAB_RELEASE_VERSION}.[0-9]+.[0-9]+[[:blank:]]" | head -n 1 | sed -E 's,^.*[[:blank:]]([0-9]+.[0-9]+.[0-9]+)[[:blank:]].*$,\1,'
)"

À ce jour, dans cet exemple 13, on obtient 13.12.0.

Pour installer la version choisie :

sudo apt-get install gitlab-runner="${GITLAB_RUNNER_VERSION}"

Ensuite on bloque la mise à jour du paquet :

echo 'gitlab-runner hold' | sudo dpkg --set-selections
  • Un premier jet pour une automatisation…
    function update_gitlab_runner {
      local -r _gitlab_runner_="$1"
    
      local _gitlab_release_version_=
      _gitlab_release_version_="$(
        sed -E 's,^([0-9]+)\.([0-9]+)\.([0-9]+)$,\1,' <<<"${_gitlab_runner_}"
      )"
      local -r _gitlab_release_version_
    
      local _gitlab_runner_version_=
      _gitlab_runner_version_="$(
        apt-cache policy gitlab-runner |
          grep -E "[[:blank:]]+${_gitlab_release_version_}.[0-9]+.[0-9]+[[:blank:]]" |
          head -n 1 |
          sed -E 's,^.*[[:blank:]]([0-9]+.[0-9]+.[0-9]+)[[:blank:]].*$,\1,'
      )"
    
      echo "gitlab-runner install" | sudo dpkg --set-selections
      sudo apt-get install gitlab-runner="${_gitlab_runner_version_}"
      echo 'gitlab-runner hold' | sudo dpkg --set-selections
    }
    
    GITLAB_VERSION='13.12.0' # Doit contenir la version présente sur le serveur
    
    update_gitlab_runner "${GITLAB_VERSION}"
    


Références

ᦿ


ℹ 2006 - 2022 | 🏠 Accueil du domaine | 🏡 Accueil du blog