Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:gitlab_admin [2016/12/11 20:09] – backup zatalyz
+++ fr:gitlab_admin [2024/06/19 16:35] (Version actuelle) – [Problèmes courants et résolution] zatalyz
@@ Ligne 6: / Ligne 6: @@
 </WRAP>
+Le tour d'horizon [[https://makina-corpus.com/blog/metier/2019/gitlab-astuces-projets/|Gérer des projets avec Gitlab]] peut aussi vous servir à mieux comprendre les possibilités de Gitlab.
 ===== Installation =====
@@ Ligne 22: / Ligne 23: @@
 ==== Configuration de base : gitlab.rb ====
 Éléments à changer (je met ce qu'il y a chez nous) :
+<WRAP center round important 60%>
+J'ai modifié un peu la config : le serveur gitlab n'a pas à gérer https, seul le reverse proxy va s'en occuper. Les communications au sein du réseau des VM vont être en http simple.
+nginx['redirect_http_to_https'] = false
+</WRAP>
 <code ruby /etc/gitlab/gitlab.rb>
 #############################
@@ Ligne 57: / Ligne 66: @@
 ## log
 logrotate['enable'] = true
+## Localisation des dépôts (indiquez là où seront les votres !)
+git_data_dir "/mnt/depots/"
+#
+## Pour les conteneurs
+package['modify_kernel_parameters'] = false
 </code>
-Adaptez à l'adresse de votre site, votre fournisseur mail, etc.
+Adaptez à l'adresse de votre site, votre fournisseur mail, etc. La version complète par défaut (avec toutes les options commentées) est disponible [[https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template|ici sur le dépôt de gitlab]].
 Pour paramétrer le mail : https://docs.gitlab.com/omnibus/settings/smtp.html
@@ Ligne 228: / Ligne 243: @@
 Voir aussi la doc : https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/backup_restore.md
-Pour faire une sauvegarde
+==== Pour faire une sauvegarde ====
   gitlab-rake gitlab:backup:create SKIP=repositories
@@ Ligne 248: / Ligne 264: @@
 On peut mettre en place un cron régulier qui lancera ce backup. Il faut, en plus, sauvegarder le contenu de ''/etc/gitlab'', qui contiens les clés ssh mais surtout ''gitlab.rb'' et ''gitlab-secrets.json'', ce dernier étant essentiel en cas de backup car il contient la clé qui va déchiffrer certaines données.
+=== Version gitlab ===
+Dans le fichier gitlab.rb, paramétrez cette partie :
+<code>
+gitlab_rails['backup_keep_time'] = 86300
+gitlab_rails['backup_upload_connection'] = {
+  :provider => 'Local',
+  :local_root => '/opt/gitlab_backup/'
+}
+gitlab_rails['backup_upload_remote_directory'] = '.'
+</code>
+Récupérez ensuite les données de ''/opt/gitlab_backup/''.
+=== Version manuelle ===
+Si vous n'avez pas envie de passer par gitlab, placez ce script dans root :
+<code bash /root/backup.sh>#!/bin/bash
+# Sauvegarde de gitlab
+gitlab-rake gitlab:backup:create SKIP=repositories
+cp -R /var/opt/gitlab/backups/ /home/user/gitlabsavebackups
+chown -R branaz:branaz /home/user/gitlabsave
+chmod -R g+rw /home/user/gitlabsave</code>
+Remplacer ''/home/user/gitlabsave'' par le dossier où stocker les sauvegardes, qui soit accessible avec votre utilisateur chargé des sauvegardes.
+Insérez ensuite cette ligne dans cron (''crontab -e''), qui fera un backup tout les jours :
+01 * * * /root/bachup.sh
+==== Pour restaurer ====
+  * s'assurer que gitlab est lancé et fonctionnel,
+  * Éteindre unicorn et sidekiq
+<code bash>
+sudo gitlab-ctl stop puma
+sudo gitlab-ctl stop sidekiq
+sudo gitlab-ctl status
+</code>
+  * remettre en place le fichier ''/etc/gitlab/gitlab-secrets.json'',
+<code>mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.jsonbak
+cp /home/save/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json</code>
+  * mettre le fichier de sauvegarde dans ''/var/opt/gitlab/backups/'' s'il vient d'un autre serveur et lui donner les bonnes permissions,
+<code>cp /home/save/[le nom du backup]_gitlab_backup.tar /var/opt/gitlab/backups/[le nom du backup]_gitlab_backup.tar
+chown git:git /var/opt/gitlab/backups/[le nom du backup]_gitlab_backup.tar
+</code>
+  *  puis lancer les commandes suivantes (en adaptant au nom du fichier de sauvegarde) :
+  sudo gitlab-rake gitlab:backup:restore BACKUP=[le nom du backup]
+  sudo gitlab-ctl reconfigure
+  sudo gitlab-ctl start
+  sudo gitlab-rake gitlab:check SANITIZE=true
+''[le nom du backup]'' est à remplacer par la partie chiffrée, l'extension ''_gitlab_backup.tar'' ne sert à rien.
+==== Sauvegarder le reste ====
+Le backup plus haut ne se suffit pas à lui-même ; il faut sauvegarder les repositories à part (sauf si vous voulez remplir votre disque dur) et la configuration de gitlab.
+Comme nous sommes des gens sérieux, nous ne faisons pas des sauvegardes en se connectant automatiquement depuis un serveur distant avec root.
+Comme gitlab n'est pas aussi sérieux, il va nous prendre la tête.
+Bref, commençons par créer un utilisateur basique, qui aura uniquement des droits en lecture, et qui servira à se connecter. Ajoutez-le dans le groupe git. Donnez les droits sur les dépôts et le dossier où les backup de gitlab seront stockés.
+<code>adduser lambda git
+chown g+rx /mnt/depots</code>
+Pensez aussi à lui permettre de se connecter via ssh dans ''/etc/ssh/sshd_config'' (option ''AllowUsers'').
+Gérez l'accès depuis [[fr:sauver_serveur|votre serveur de sauvegarde]], avec les bonnes options. Ici, sauvegarder ''/mnt/depots/repositories'' et ''/mnt/depots/backupgitlab'' par exemple.
+Et maintenant la bonne blague : <wrap hi>à chaque fois que vous ferez ''gitlab-ctl reconfigure'', il faudra remettre branaz dans le groupe git et redonner les droits ''g+rx'' sur ''/mnt/depots''</wrap>. Sinon les sauvegardes seront bloquées.
+<WRAP center round tip 60%>
+Une alternative pourrait être d'installer git sur votre serveur de sauvegarde et de cloner de là, mais je n'ai pas encore les détails sur comment faire. Et il faudra quand même copier régulièrement les backups de gitlab là où on peut se synchroniser, mais un crontab de root devrait gérer ça.
-<WRAP center round todo 60%>
+Participez à ce fichu tuto si vous savez comment faire !
-Work in progress : ajouter un crontab aux oignons pour tout envoyer là ou un serveur de sauvegarde peut aller chercher les données sans risques.
 </WRAP>
-Pour restaurer, remettre en place le fichier ''/etc/gitlab/gitlab-secrets.json'', mettre le fichier de sauvegarde dans ''/var/opt/gitlab/backups/'' s'il vient d'un autre serveur, s'assurer que gitlab est lancé et fonctionnel, puis lancer les commandes suivantes (en adaptant au nom du fichier de sauvegarde) :
-  gitlab-ctl stop unicorn
-  gitlab-ctl stop sidekiq
-  gitlab-ctl status
-  gitlab-rake gitlab:backup:restore BACKUP=[le nom du backup]
-  gitlab-ctl reconfigure
-  gitlab-ctl start
-  gitlab-rake gitlab:check SANITIZE=true
+==== Récupérer les images ====
+On doit pouvoir ajouter la sauvegarde des images d'avatars et de projets au backup auto (option à trouver) mais sinon, ils se trouvent dans le dossier ''gitlab-rails/uploads'' (dans la version omnibus, le chemin complet est ''var/opt/gitlab/gitlab-rails/uploads''.
+Il suffit de copier ce dossier ''uploads'' d'une sauvegarde, puis de donner les bons droits :
+  chown -R gitlab-www:gitlab-www uploads
+  chmod -R 2770 uploads
+==== Erreur de version de Gitlab ====
+Dans les features merveilleuses de Gitlab, ce dernier demande à ce qu'un backup vienne exactement de la même version que le gitlab où il sera restauré. Donc, si votre backup date de la version 8.14.3 de Gitlab et que depuis, vous êtes en 8.14.4, impossible de remettre en place le backup. Vu les mises à jour rapides, vous aurez donc des problèmes si vous souhaitez restaurer un backup datant d'un mois avant.
+Vous avez donc lancé la commande citée plus haut, et vous avez un message d'erreur :
+<code>
+gitlab-rake gitlab:backup:restore BACKUP=1481484380
+Unpacking backup ... done
+GitLab version mismatch:
+  Your current GitLab version (8.14.4) differs from the GitLab version in the backup!
+  Please switch to the following version and try again:
+  version: 8.14.3</code>
+Copiez le backup dans un dossier, puis sortez-le de son archive :
+<code>cp 1481484380_gitlab_backup.tar fucking_backup/
+tar xvf 1481484380_gitlab_backup.tar</code>
+Modifiez le fichier ''backup_information.yml'' (un des fichier qui a été dézippé), en changeant le numéro de version. Puis recompressez l'ensemble du dossier, en incrémentant le nom de l'archive par rapport au backup précédent :
+  tar cvf ../1481484381_gitlab_backup.tar ./*
+Reprenez le processus de restauration, avec ce nom de backup. Avec un peu de chance, ça passe.
 ==== Sous Docker ====
@@ Ligne 271: / Ligne 380: @@
 Pour restaurer :
+  docker exec -t [Nom Du Container] gitlab-rake gitlab:backup:restore BACKUP=1393513186
 ==== Notes pour les sauvegardes ====
 ===== Brancher avec les dépôts =====
+Pour que gitlab utilise des dépôts situés sur une autre partition, il suffit de lui indiquer dans ''gitlab.rb'' où se situe ces dépôts avec ''git_data_dir "/localisation_des_depots/"''.
+==== Installer une partition annexe avec Xen/LVM et y accéder ====
+J'ai créé un volume logique qui n'aura pour but QUE d'héberger la partie git des dépôts. En gros, il y a dedans le plus vital. Si on change de gestionnaire (passer à un autre gitlab, ou utiliser gogs, tuleap ou je ne sais quoi), ce dépôt n'aura pas besoin de migrer.
+<WRAP center round important 60%>
+Pour des raisons de persistance des données, il ne faut pas utiliser un volume en même temps avec deux systèmes. Donc, soit la VM1 fait appel au volume de dépôt, soit la VM2, mais jamais les deux en même temps !
+</WRAP>
+  lvcreate -n depots-branaz -L 50g groska
+La taille doit évidement être adaptée, 50g c'est pour un petit projet.
+Ensuite on éteins branaz((Ou le nom de la VM créé pour gérer Gitlab ; dans cet exemple, elle s'appelle branaz.)), et on modifie son fichier de config (''/etc/xen/branaz.cfg'') pour lui permettre de gérer notre nouveau dépôt. Dans la partie "disk" du fichier, on ajoute ''phy:/dev/groska/depots-branaz,xvda3,w','' pour avoir ceci :
+<code>
+disk        = [
+                  'phy:/dev/groska/branaz-disk,xvda2,w',
+                  'phy:/dev/groska/branaz-swap,xvda1,w',
+                  'phy:/dev/groska/depots-branaz,xvda3,w',
+              ]
+</code>
+  * xvda3 : pour le système, ce sera un équivalent de "sda3" en partition.
+  * w : pour permettre l'écriture.
+On relance branaz et on va paramétrer <del>gitlab</del> <del>''/etc/fstab''</del> xvda3 afin de pouvoir monter la partition.
+Formatage de la partition :
+  mkfs.ext4 /dev/xvda3
+Vérifier que tout va bien en la montant :
+  mkdir /mnt/depots
+  mount /dev/xvda3 /mnt/depots/
+Si tout est bon, ajouter cette partition dans ''/etc/fstab'' pour que ce soit monté au démarrage :
+  /dev/xvda3 /mnt/depots ext4 defaults 0 0
+<WRAP center round tip 90%>
+En cas d'erreur malgré tout ça, penser à l'utilitaire ''fdisk'' ( ''fdisk /dev/xdvb1/'' ), puis pour que ce soit pris en compte :
+  partx -u /dev/xvda3
+</WRAP>
+Il suffit ensuite d'ajouter l'option dans ''gitlab.rb'' et d'envoyer les données.
+Ensuite s'assurer de donner les bons droits :
+  chown -R git:git /mnt/depots
+  chmod -R 2770 /mnt/depots
+==== Permettre l'accès en ssh ====
+Gitlab offre, pour chaque dépôt, un accès "git" ssh afin de cloner les dépôts et, si on a les droits, de pusher. Tout est bon de base... il faut juste ajouter git dans les utilisateurs autorisés de ssh !
+Éditer le fichier ''/etc/ssh/sshd_config'' et ajouter/vérifier le paramètre ''AllowUsers'' :
+<code>
+AllowUsers root git
+</code>
 ===== Architecture =====
 Lors d'une installation basique comme cité plus haut, voici où trouver le bazar lié à gitlab :
-# find / -name *gitlab* -type d
+<code># find / -name *gitlab* -type d
 /etc/gitlab
 /var/log/gitlab
 /var/opt/gitlab
-/opt/gitlab
+/opt/gitlab</code>
+===== Problèmes courants et résolution =====
+En plus de ce qui est listé ici et là, Gitlab est adepte de quelques petites pannes "classiques".
+Après une mise à jour, il faut régulièrement relancer la commande ''gitlab-ctl reconfigure'', quand bien même rien n'a été modifié dans le fichier de conf ''/etc/gitlab/gitlab.rb''. Il est aussi utile de noter si la commande informe que certains paramètres sont obsolètes... et de mettre à jour.
+De temps en temps et suivant les versions, Gitlab sature. Généralement il remplit la RAM, plante, et bloque. Parfois aussi il remplit l'espace disque avec ses logs de plantage.
+Plus le temps passe et moins je crois à la finesse avec ce truc, donc avant de chercher trop loin, commencez simplement par vous connecter à la VM et :
+  reboot
+Après le reboot, attendez au moins 15 minutes, gitlab est très long à lancer correctement tous ses services. Si un coup de ''gitlab-ctl status'' indique que tous les services sont lancés MAIS que gitlab n'est pas opérationnel sur le web, attendez bien ces 15 minutes !
+Si toujours rien, tentez ''gitlab-ctl stop'' puis ''gitlab-ctl start''. Ces deux commandes marchent mieux que la seule ''gitlab-ctl restart'' qui parfois ne ferme pas correctement les services (espérons aussi que ça se réglera au fur et à mesure des versions...). Là aussi, attendez 15 minutes avant de vous inquiéter si malgré le démarrage correct des services, rien n’apparaît sur l'interface web.
+Enfin, en dernier ressort, Gitlab aime bien ''gitlab-ctl reconfigure'', même en dehors des mises à jours. Pourquoi ? je n'en sais rien, cela me fait penser qu'il doit parfois corrompre certains de ses fichiers, mais je n'ai pas de preuves. Toujours est-il que ça marche... Faites un restart après ce reconfigure et attendez encore 15 minutes.
+Si ça ne marche toujours pas, allez prendre l'air un grand coup, faites autre chose pendant quelques heures. Avec un peu de chance, un des petits dieux de l'informatique passe et relance gitlab.
+Ensuite, si aucun des disques n'est plein (''df -h''), faites un snapshot, vérifiez les backup et mettez gitlab à jour, avec un peu de chance c'est un bug qui viens d'être résolu.
+Si rien de tout ça n'a marché, il va falloir chercher plus... Retour aux outils traditionnels de sysadmin, vérification des logs, des services de systemd, etc. Ou bien éteignez gitlab et branchez vos dépôts sur un autre système, ça ne doit pas être bien plus long.
+===== Astuces =====
+==== Enlever la fenêtre de pop-up des emojis ====
+Un truc très pénible quand on écris français : les deux points précédés d'une espace font apparaître un pop-up d'emoji, qui ne se ferme pas facilement et m'a beaucoup fait pester en ajoutant des emojis n'importe où.
+Deux solutions :
+  * La touche Echap ferme ce popup, jusqu'à son prochain appel.
+  * Avec uBlock Origin, dans mes filtres, ajouter la règle suivante : ''gitlab.freedesktop.org###div.atwho-container:remove()''((Source : https://linuxfr.org/nodes/126962/comments/1884078 )). Adapter le nom de domaine à l'instance gitlab, par exemple chez nous, c'est ''git.numenaute.org###div.atwho-container:remove()''.