Différences

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

--- fr:gitlab_admin [2017/01/08 11:41] – [Configuration de base : gitlab.rb] Shepeng
+++ 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 todo 60%>
-branaz redirige le flux http vers https://localhost:8080
-ça ne fonctionne pas avec le reverse proxy
-Je ne trouve pas comment supprimer cette redirection
-</WRAP>
 <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.
@@ Ligne 72: / Ligne 69: @@
 git_data_dir "/mnt/depots/"
 #
+## Pour les conteneurs
+package['modify_kernel_parameters'] = false
 </code>
 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]].
@@ Ligne 262: / Ligne 263: @@
 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
-<WRAP center round todo 60%>
-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 ====
   * s'assurer que gitlab est lancé et fonctionnel,
   * Éteindre unicorn et sidekiq
-<code>gitlab-ctl stop unicorn
+<code bash>
-gitlab-ctl stop sidekiq
+sudo gitlab-ctl stop puma
-gitlab-ctl status</code>
+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
@@ Ligne 283: / Ligne 310: @@
   *  puis lancer les commandes suivantes (en adaptant au nom du fichier de sauvegarde) :
-  gitlab-rake gitlab:backup:restore BACKUP=[le nom du backup]
+  sudo gitlab-rake gitlab:backup:restore BACKUP=[le nom du backup]
-  gitlab-ctl reconfigure
+  sudo gitlab-ctl reconfigure
-  gitlab-ctl start
+  sudo gitlab-ctl start
-  gitlab-rake gitlab:check SANITIZE=true
+  sudo gitlab-rake gitlab:check SANITIZE=true
@@ Ligne 425: / Ligne 452: @@
 /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()''.