Bonjour la liste,
On a un GitLab qui explose au vol lorsque l'on fait des commandes git trop rapidement.
Pour tenter de résumer, on a un repo principal qui a un pipeline, dans les tâches il va prendre des images docker de plusieurs distributions en plusieurs versions pour préparer les images avec un git clone d'une cinquantaine de repos présents sur le même serveur. Le but avoir des images avec les git clonés et consolidés avant de lancer les tests unitaires / linter / code quality ... et les tests fonctionnels. Les clones se font en utilisant ansible-galaxy avec un fichier des dépendances attendues. Donc quand le pipeline se lance ça fait plusieurs centaines de git clone à faire.
Tout se passait bien jusqu'au moment où le serveur hébergeant le gitlab a saturé une partition (la purge des images et layers docker non utilisés n'était pas en place). Les services ont été arrêté, la partition agrandie et tout est reparti sauf que depuis ce moment là sans que l'on sache si c'est lié, on peut faire quelques dizaines de commande git par ssh puis des erreurs, par exemple en faisant un simple git pull.
exec request failed on channel 0 fatal: Impossible de lire le dépôt distant.
gitlab-ctl status a tout qui tourne, les logs n'indiquent rien au niveau gitlab comme système
Il faut faire un gitlab-ctl restart pour pouvoir à nouveau faire quelques commandes.
Alors bien entendu on a réinstallé le serveur et restauré une sauvegarde du git mais le problème persiste donc on pense que le souci est dans le jeu de donnée de gitlab.
On a supprimé le projet qui porte le pipeline, pour le recréer sans changement. On est arrivé à abandonner ansible-galaxy pour faire des git clones dans une boucle for bash avec des sleep 15 entre chaque clone et là le git par ssh ne plante plus.
Mais le pipeline devient bien trop long à tourner. On a tenté de mettre un concurrency à 1 pour les jobs des pipelines mais sans succès c'est vraiment les git clone trop rapides qui font planter un élément de gitlab que ce dernier ne voit même pas dans son status.
On a fait une demande de support à gitlab.com mais le temps qu'on ait un retour, je préfère demander aussi à la communauté.
Auriez-vous des idées? Connaissez-vous des experts en GitLab qui pourrait aider?
Merci par avance
Bonjour Wallace,
Je n'utilise pas gitlab mais lorsque j'entend "beaucoup connexion ssh (via git)" je ne peux m'empècher de penser que ca peut venir du daemon sshd lui-même. je me permet de le dire parce que tu risques de te concentrer sur gitlab.
Le daemon sshd se protège contre les attaques d'une facon bien a lui.
Lorsqu'il recoit un grand nombre de connexions vers le daemon, il arrive que le démon refuse des connexions.
La parade que j'ai trouvé est d'utiliser le ControlMaster.
Si tu as l'occasion d'essayer:
cat .ssh/config
Host ton_server_git ControlMaster auto ControlPath "~/.ssh/.master-%r@%h:%p" ControlPersist 60s
Ensuite tu peux tenté une tempète de git pull par exemple: for i in $(seq 1 1000); do git pull -q; done
Evidement je n'ai aucune idée de pourquoi ca marchait avant et plus maintenant. Peut-être que ca vient bien de gitlab lui-même...
En attendant ca te fait une piste en plus.
Bon courage!
Gab.
Le 2019-12-09 15:21, Wallace a écrit :
Bonjour la liste,
On a un GitLab qui explose au vol lorsque l'on fait des commandes git trop rapidement.
<Snip> Ton repo git ne serait-il pas super gros ? Si oui, as-tu mis en place git-lfs pour les gros fichiers binaires et vérifier que ces fichiers sont bien enregistrés en LFS dessus ?
J'ai eu des comportements très hasardeux sur un repo lorsque je n'avais pas mis mes fichiers en LFS et que j'atteignais une certaine taille...
Cdlt,
-- Jean-Yves LENHOF jean-yves@lenhof.eu.org Tel: 06 50 95 41 26
Le 09/12/2019 à 18:52, Jean-Yves LENHOF a écrit :
Le 2019-12-09 15:21, Wallace a écrit :
Bonjour la liste,
On a un GitLab qui explose au vol lorsque l'on fait des commandes git trop rapidement.
<Snip> Ton repo git ne serait-il pas super gros ? Si oui, as-tu mis en place git-lfs pour les gros fichiers binaires et vérifier que ces fichiers sont bien enregistrés en LFS dessus ?
J'ai eu des comportements très hasardeux sur un repo lorsque je n'avais pas mis mes fichiers en LFS et que j'atteignais une certaine taille...
Alors pour le coup non ce n'est pas ce type de souci, on parle de simple codes et pour être précis les 50 repos sont pratiquement vide (un README et quelques fichiers texte qu'on modifie pour déclencher les pipelines). On a pas encore déposé le vrai code source dedans. On voyait à faire le CI/CD avant.
On a réussi à isoler plus le problème.
Le pipeline d'un repo déclenché par le .gitlab-ci va lancer un makefile qui fait le ansible-galaxy, il récupère tous les rôles indiqués (une cinquantaine) puis fait ses tests puis si tout est ok va changer la branche du code validé pour la passer sur le master, il fait son commit et lorsque le premier push intervient ça fait crasher GitLab.
On pensait à tord qu'il s'agissait du clone en masse mais non un simple push dans le CI avec les bonnes autorisations depuis une image docker dans le gitlab-runner fait voler en éclat le GitLab pour l'accès git par ssh.
On est top à jour version Gitlab, gitlab-runner direct éditeur, Docker direct éditeur, kernel 5.4.2 et système Debian.
Merci quand même pour l'idée.