Tag - gitlab - PAB's blog

Monday, June 18 2018

Gitlab behind a reverse proxy handling https

By Pierre-Alain B on Monday, June 18 2018, 14:58

I share below my configuration of GitLab when served behind a reverse proxy (haproxy to name it) that is handling the HTTPS part of the communication (and is also load balancing). <Disclaimer> I am not claiming this is the best configuration or the only possible configuration but I can report that it works well</Disclaimer>.

Infrastructure

The network transaction is established as follows:

User <~~- HTTPS HTTP/2~~ -> HAPROXY <~~- HTTP~~ -> NGINX <~~- HTTP~~ -> Unicorn/GitLab

I will not detail here the configuration of HAProxy which is pretty classical.

Configuration of GitLab

In gitlab.yml (presumably in /home/git/gitlab/config/ if you installed from source), I have the following:

production: &base
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: gitlab.domain.tld
    port: 443
    https: true

And yes I indicate https true and port 445 even if Gitlab itself does not handle the https part of the communication.

Configuration of Nginx

In the config of Nginx (another layer of reverse proxy), I have:

    proxy_set_header    X-Forwarded-Proto   https;

which differs from the configuration proposed by the Gitlab team. Indeed, it does not convey the protocol that is seen by Nginx but rather forces the header to https as initially the communication was https-secured.

And it works flawlessly!

Sunday, October 22 2017

Gitlab, fail of yarn when migrating to 10.0.x

By Pierre-Alain B on Sunday, October 22 2017, 08:12

gitlab
linux

For once, the Gitlab upgrade process from 9.5.8 to 10.0.x was not totally smooth on my end. I encountered the following error:

error "webpack#ajv" not installed
error "webpack#ajv-keywords" not installed
error Found 2 errors.
Error: You have unmet dependencies. (`yarn check` command failed)

And installing ajv manually did the trick:

sudo -u git -H yarn add ajv@^4.0.0

In case this helps someone out there!

Sunday, February 19 2017

Réduire l'empreinte mémoire de GitLab en contrôlant le nombre de processus Sidekiq

By Pierre-Alain B on Sunday, February 19 2017, 16:25

Par défaut, GitLab démarre 25 processus Sidekiq pour gérer les travaux de tâche de fond de GitLab. Si ce nombre est justifié sur une instance à fort traffic, il y a fort à parier qu'un bien plus petit nombre de processus suffit pour gérer une instance de GitLab de petit volume.

Le nombre de processus Sidekiq se règle aisément dans le fichier /path/to/gitlab/config/sidekiq_queues.yml par ajout de la ligne suivante :

:concurrency: 2

où l'on remplacera "2" par le nombre de processus souhaités. 2 semble suffisant pour ma petite installation GitLab personnelle et ses quelques utilisateurs et dizaines de projets.

Voilà de quoi optimiser l'empreinte mémoire et processeur de GitLab !

Adjust number of Sidekiq processes for GitLab

By Pierre-Alain B on Sunday, February 19 2017, 16:19

By default, GitLab starts 25 processes of Sidekiq. If this certainly makes sense on systems with high load, this could be overkill for simple instances of GitLab with only a handful of users and active projects. To reduce memory usage, it is possible to reduce the number of concurrent processes for Sidekiq by adding the following line to the /path/to/gitlab/config/sidekiq_queues.yml file:

:concurrency: 2

Monday, October 17 2016

Gitlab, empty repository mystery, when a workhorse comes to help a unicorn!

By Pierre-Alain B on Monday, October 17 2016, 18:06

Gitlab is a wonderful piece of open source software, incredibly pleasant to use to manage development projects. My own instance, installed from source, is updated version after version. Today, I was faced with a weird issue:

all downloads of archive (whatever the format .tar.gz, .zip, .tar.bz2) of the files of the projets were failing, more precisely only empty (0 byte) archives were returned
when cloning with git clone http://urlofgitlab/group/repo.git, I consistently obtained warning: You appear to have cloned an empty repository.
interestingly, cloning the same repository with git clone git@urlofgitlab:group/repo.git worked seamlessly.

After some research, it appeared my Gitlab instance was not using Gitlab-workhorse at all. The magic unicorn was the only one serving the content of the instance without any help from the local workhorse :-)

Some context

It appears that Gitlab-workhorse was developed and added to Gitlab 8 to circumvent some limitations of Unicorn when serving large files (some history here)... and since then big files would not be served anymore by Unicorn.

As a consequence, if the requests are not treated by Gitlab-workhorse, then the git clone over HTTP and download of large archive files would not complete.

How did it happen?

My instance is regularly updated from version to version and pre-dates Gitlab 8. Before Gitlab 8, it was normal to have my reverse proxy/load balancer (Pound) point directly to the Unicorn server. When upgrading to Gitlab 8, I should have changed the setting of the reverse proxy/load balancer to point to Gitlab-workhorse instead of Unicorn. And then it was necessary to properly set Gitlab-workhorse to rely on Unicorn.

How fix it?

Well, 3 steps.

Step 1: fix the link between Gitlab-workhorse and Unicorn Gitlab-workhorse expects to connect to Unicorn through a Unix socket. It is therefore necessary to make sure that Unicorn is set up accordingly in /home/git/gitlab/config/unicorn.rb, with this line active:

listen "/home/git/gitlab/tmp/sockets/gitlab.socket", :backlog => 1024

Step 2: make sure that Gitlab-workhorse is well set to connect to this socket. This can be done by tweaking the parameters in /etc/default/gitlab, with inspiration from /home/git/gitlab/lib/support/init.d/gitlab.default.example.

Step 3: make sure that the reverse proxy correctly points to workhorse. As a default, Gitlab-workhorse uses a socket. In my case, I had to make it use a TCP connection/port so that the reverse proxy could use it. Again, based on the settings found in /home/git/gitlab/lib/support/init.d/gitlab.default.example, I tweaked the /etc/default/gitlab file to read:

gitlab_workhorse_options="-listenUmask 0 -listenNetwork tcp -listenAddr a.b.c.d:8181 -authBackend http://127.0.0.1:8080 -authSocket $socket_path/gitlab.socket -documentRoot $app_root/public"

Last, with the reverse proxy pointing to a.b.c.d:8181 everything worked very fine.

I am relieved to know that my Unicorn is now so efficiently supported by the Workhorse!

Wednesday, June 1 2016

Git 2.8+ sur Debian Jessie pour Gitlab 8.5

By Pierre-Alain B on Wednesday, June 1 2016, 07:43

Si vous hébergez Gitlab sur Debian Jessie, alors la mise à jour de la version 8.4 à la version 8.5 vous aura sans doute demandé une version de Git plus récente que Git 2.1.4 actuellement disponible sur Jessie. Pas de panique : il est possible presque sans effort d'installer une version plus récente de Git depuis les dépôts testing/stretch.

Dans /etc/apt/sources.list, on ajoute ces lignes :

deb http://debian.mirrors.ovh.net/debian/ stretch main
deb-src http://debian.mirrors.ovh.net/debian/ stretch main

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

Il faut ensuite indiquer à la distribution l'ordre de priorité d'installation en plaçant dans un fichier /etc/apt/preferences.d/mes_priorites (le nom du fichier est tout à fait personnalisable) le contenu suivant :

ackage: *
Pin: release l=Debian-Security
Pin-Priority: 1000

Package: *
Pin: release a=stable
Pin-Priority: 999

Package: *
Pin: release a=testing
Pin-Priority: 50

Package: *
Pin: release a=unstable
Pin-Priority: 50

A ce stade, la commande apt update doit rapatrier les informations de la version testing/stretch mais ne doit pas automatiquement proposer une mise à jour car la priorité donnée à testing (& unstable) est bien moindre que celle donnée à la branche stable.

Pour forcer alors l'installation de la version de Git disponible dans testing/stretch, il faut exécuter :

apt install git/stretch git-man/stretch

Monday, December 28 2015

Let's Encrypt et Gitlab

By Pierre-Alain B on Monday, December 28 2015, 10:24

Pour permettre la génération d'un certificat avec Let's Encrypt pour Gitlab, il m'a été nécessaire d'effectuer les opérations suivantes :

Modifier la gestion des fichiers d'assets dans gitlab/config/environments/production.rb,

config.serve_static_assets = true

Redémarrer Gitlab par

service gitlab restart

Puis effectuer la génération du certificat avec le script Let's Encrypt en pointant le webroot vers le dossier public :

certbot certonly -a webroot --webroot-path /path/to/gitlab/public -d mongit.domaine.tld

Monday, July 13 2015

Gitlab : la documentation est très riche !

By Pierre-Alain B on Monday, July 13 2015, 09:37

gitlab

On ne présente plus Gitlab, la forge libre de très grande qualité qui chasse sur les terres de Github. Chapeau bas à toute l'équipe de Gitlab pour la formidable qualité de la documentation : elle est abondante, d'une grande clarté et très détaillée.

Voici une petite liste des documentations qui m'ont semblé les plus utiles dans mes récents essais de déploiement.

pour faire des sauvegardes et réimporter les sauvegardes

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

Utile pour assurer la préservation des donnée ! Cette procédure est également utile pour transférer des données d'un serveur à un autre lors d'une migration.

pour mettre à jour l'instance de Gitlab

https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update

pour vérifier les variables d'environnement de Gitlab et maintenir le système

https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/maintenance.md

pour déployer Gitlab à partir des sources

https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md

PAB's blog

Tag - gitlab