Ce qui suit s’adresse à celles et ceux qui souhaitent administrer un service Gitlab. Si vous êtes un simple utilisateur, allez plutôt voir Gitflow et Git.

Le tour d'horizon Gérer des projets avec Gitlab peut aussi vous servir à mieux comprendre les possibilités de Gitlab.

À faire en root :

apt-get install curl openssh-server ca-certificates postfix
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash
apt-get install gitlab-ce
gitlab-ctl reconfigure

Postfix configuré en “site internet”.

Gitlab se configure dans /etc/gitlab/gitlab.rb puis on applique la commande gitlab-ctl reconfigure pour prendre en compte la configuration.

Éléments à changer (je met ce qu'il y a chez nous) :

/etc/gitlab/gitlab.rb

#############################
## Personnal configuration ##
#############################
## Ce qui suit est propre a Branaz. C'est plus facile de voir ce qui a ete 
## modifie en rassemblant tout... le reste est la pour verifier les options
## par defaut. Merci d'ajouter les elements modifies dans cette section.
external_url 'https://branaz.khaganat.net'
## features      
gitlab_rails['gitlab_default_projects_features_wiki'] = false
gitlab_rails['gitlab_default_projects_features_container_registry'] = false     
gitlab_rails['gitlab_shell_ssh_port'] = 1022
gitlab_rails['git_timeout'] = 1200
## smtp
gitlab_rails['smtp_enable'] = true                  
gitlab_rails['smtp_address'] = "mail.gandi.net"
gitlab_rails['smtp_port'] = 25            
gitlab_rails['smtp_user_name'] = "asso@khaganat.net"
gitlab_rails['smtp_password'] = "..."
gitlab_rails['smtp_domain'] = "khaganat.net"
gitlab_rails['smtp_authentication'] = "plain"
gitlab_rails['smtp_enable_starttls_auto'] = true
## unicorn
unicorn['worker_timeout'] = 1200
unicorn['worker_processes'] = 2 
## nginx         
nginx['redirect_http_to_https'] = true
nginx['listen_port'] = '80'
nginx['listen_https'] = false               
nginx['proxy_set_headers'] = {    
  "X-Forwarded-Proto" => "https",
  "X-Forwarded-Ssl" => "on"                         
}
## 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

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 ici sur le dépôt de gitlab.

Pour paramétrer le mail : https://docs.gitlab.com/omnibus/settings/smtp.html

Par défaut, tout n'est pas en https sur Gitlab. Il redirige régulièrement sur http, ce qui présente un problème, surtout sur les VM.

Une fois qu'on a indiqué l'adresse de base en https, ça peut aussi coincer à la reconfiguration. C'est la section nginx plus haut.

En plus de ces modifications dans /etc/gitlab/gitlab.rb, il faut aussi mettre en place les bons certificats ssl.

Créer le dossier ssl et mettre un lien vers le certificat auto-généré (dans le cas d'une VM dont l'accès se fait via un pare-feu, sinon utiliser le certificat let's encrypt).

mkdir -p /etc/gitlab/ssl
chmod 700 /etc/gitlab/ssl
ln -s /etc/ssl/private/ssl-cert-snakeoil.key branaz.khaganat.net.key
ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem branaz.khaganat.net.cert
gitlab-ctl reconfigure

Voir aussi, en complément : https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md#setting-the-nginx-listen-port

Pour gérer gitlab, c'est la commande gitlab-ctl

gitlab-ctl stop
gitlab-ctl start
gitlab-ctl restart
gitlab-ctl status

Après un changement sur /etc/gitlab/gitlab.rb

gitlab-ctl reconfigure

Ça prend en compte le bazar. C'est long la première fois. Ça relance automatiquement gitlab ( ? à confirmer).

Une fois gitlab lancé ( gitlab-ctl start ), aller sur la page web. Il est demandé de paramétrer un mot de passe, c'est celui de l'administration.

Ensuite, se loguer avec “root” et le nouveau mot de passe. Changer son nom et commencer à tester.

La liste des options dans le fichier est ici : https://docs.gitlab.com/omnibus/settings/configuration.html

Allez dans l'administration. Déployez le menu lié au petit engrenage, sélectionnez “appearance”.

• Title : Titre en accueil
• Description : vous pouvez utilisez la syntaxe markdown. Profitez-en pour guidez les utilisateurs vers votre page d'accueil, votre dépôt principal et l'aide ?
• Logo : apparaîtra sur la page pour se connecter (page d'accueil), en gros, il peut donc être détaillé.
• Header logo : apparait sur toutes les pages, en petit.

Source : https://docs.gitlab.com/ce/customization/branded_login_page.html

Pour personnaliser lors de la signature, c'est dans l'administration, le menu lié au petit engrenage, “settings”, dans la partie “Sign-in Restrictions”. Il suffit de personnaliser “Sign in text”. “Help page text” est pour personnaliser la page d'aide.

lien : https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/ldap.md

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
  ## label
  #
  # A human-friendly name for your LDAP server. It is OK to change the label later,
  # for instance if you find out it is too large to fit on the web page.
  #
  # Example: 'Paris' or 'Acme, Ltd.'
  label: 'LDAP'

  host: '10.10.100.1'
  port: 389 # or 636
  uid: 'uid'
  method: 'plain' # "tls" or "ssl" or "plain"
  bind_dn: 'cn=consultation,dc=khaganat,dc=net'
  password: '...'

  # This setting specifies if LDAP server is Active Directory LDAP server.
  # For non AD servers it skips the AD specific queries.
  # If your LDAP server is not AD, set this to false.
  active_directory: false

  # If allow_username_or_email_login is enabled, GitLab will ignore everything
  # after the first '@' in the LDAP username submitted by the user on login.
  #
  # Example:
  # - the user enters 'jane.doe@example.com' and 'p@ssw0rd' as LDAP credentials;
  # - GitLab queries the LDAP server with 'jane.doe' and 'p@ssw0rd'.
  #
  # If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to
  # disable this setting, because the userPrincipalName contains an '@'.
  allow_username_or_email_login: false

  # Base where we can search for users
  #
  #   Ex. ou=People,dc=gitlab,dc=example
  #
  base: 'ou=people,dc=khaganat,dc=net'

  # Filter LDAP users
  #
  #   Format: RFC 4515 http://tools.ietf.org/search/rfc4515
  #   Ex. (employeeType=developer)
  #
  #   Note: GitLab does not support omniauth-ldap's custom filter syntax.
  #
  user_filter: ''
EOS

Ajout d'un virtualhost sur vpstests

        <VirtualHost *:443>
                ProxyPreserveHost On
                ServerName mattermost.khaganat.net
                ProxyVia On
                ProxyRequests Off
                ProxyPass / http://10.10.100.18:80/
                ProxyPassReverse / http://10.10.100.18:80/
                ProxyPreserveHost on
SSLCertificateFile /etc/letsencrypt/live/vpstests.khaganat.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/vpstests.khaganat.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
        </VirtualHost>

Authoriser omniauth :

gitlab_rails['omniauth_enabled'] = true

Configurer mattermost :

mattermost_external_url 'https://mattermost.khaganat.net/'
mattermost_nginx['listen_port'] = 80 
mattermost_nginx['listen_https'] = false 
mattermost_nginx['proxy_set_headers'] = {
  "X-Forwarded-Proto" => "https",
  "X-Forwarded-Ssl" => "on"
} 

Voir aussi la doc : https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/backup_restore.md

gitlab-rake gitlab:backup:create SKIP=repositories

L'option SKIP permet d'éviter de sauvegarder certaines parties.

• db (database)
• uploads (attachments)
• repositories (Git repositories data)
• builds (CI build output logs)
• artifacts (CI build artifacts)
• lfs (LFS objects)
• registry (Container Registry images) (désactivé par défaut)

On peut éviter plusieurs choses par une virgule, comme ceci

gitlab-rake gitlab:backup:create SKIP=db,uploads

Ces sauvegardes sont dans /var/opt/gitlab/backups/ par défaut et peuvent être configurées via le fichier gitlab.rb.

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.

Dans le fichier gitlab.rb, paramétrez cette partie :

gitlab_rails['backup_keep_time'] = 86300
gitlab_rails['backup_upload_connection'] = {
  :provider => 'Local',
  :local_root => '/opt/gitlab_backup/'
}
gitlab_rails['backup_upload_remote_directory'] = '.'

Récupérez ensuite les données de /opt/gitlab_backup/.

Si vous n'avez pas envie de passer par gitlab, placez ce script dans root :

/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

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 01 * * * /root/bachup.sh

• s'assurer que gitlab est lancé et fonctionnel,
• Éteindre unicorn et sidekiq

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl status

• remettre en place le fichier /etc/gitlab/gitlab-secrets.json,

mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.jsonbak
cp /home/save/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json

• mettre le fichier de sauvegarde dans /var/opt/gitlab/backups/ s'il vient d'un autre serveur et lui donner les bonnes permissions,

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

• 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.

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.

adduser lambda git
chown g+rx /mnt/depots

Pensez aussi à lui permettre de se connecter via ssh dans /etc/ssh/sshd_config (option AllowUsers).

Gérez l'accès depuis votre serveur de sauvegarde, avec les bonnes options. Ici, sauvegarder /mnt/depots/repositories et /mnt/depots/backupgitlab par exemple.

Et maintenant la bonne blague : à 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. Sinon les sauvegardes seront bloquées.

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

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 :

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

Copiez le backup dans un dossier, puis sortez-le de son archive :

cp 1481484380_gitlab_backup.tar fucking_backup/
tar xvf 1481484380_gitlab_backup.tar

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.

Pour sauvegarder sous Docker :

docker exec -t [Nom Du Container] gitlab-rake gitlab:backup:create 

Remplacer [Nom Du Container] et ajouter l'option SKIP si nécessaire.

Pour restaurer :

docker exec -t [Nom Du Container] gitlab-rake gitlab:backup:restore BACKUP=1393513186

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/”.

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.

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¹⁾, 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 :

disk        = [
                  'phy:/dev/groska/branaz-disk,xvda2,w',
                  'phy:/dev/groska/branaz-swap,xvda1,w',
                  'phy:/dev/groska/depots-branaz,xvda3,w',
              ]

• 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 gitlab /etc/fstab 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

partx -u /dev/xvda3

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

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 :

AllowUsers root git

Lors d'une installation basique comme cité plus haut, voici où trouver le bazar lié à gitlab :

# find / -name *gitlab* -type d
/etc/gitlab
/var/log/gitlab
/var/opt/gitlab
/opt/gitlab

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.

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()²⁾. Adapter le nom de domaine à l'instance gitlab, par exemple chez nous, c'est git.numenaute.org###div.atwho-container:remove().

• Un article chez Korben
• Doc officielle gitlab pour l'installation en direct