Installation d'un serveur Gitlab

Présentation

Git est un logiciel de versioning créé en 2005 par Linus Torvalds, le créateur de Linux.

Un logiciel de versioning, ou logiciel de gestion de version est un logiciel qui permet de conserver un historique des modifications effectuées sur un projet afin de pouvoir rapidement identifier les changements effectuées et de revenir à une ancienne version en cas de problème.

Les logiciels de gestion de versions sont quasiment incontournables aujourd’hui car ils facilitent grandement la gestion de projets et car ils permettent de travailler en équipe de manière beaucoup plus efficace.

Parmi les logiciels de gestion de versions, Git est le leader incontesté et il est donc indispensable pour tout développeur de savoir utiliser Git.

Installation

Mise en place d’un serveur GitLab et du protocole https dans le cadre de la situation professionnelle M2L.

Configuration

Editer le fichier de configuration : /etc/gitlab/gitlab.rb

On va définir un nom de domaine pour servir notre application, la ligne à changer est la suivante :

external_url 'http://domain.com'

Ici on sous entend que l’application sera servie sur le le port 80, on l’indique tout de même pour une plus grande clarté.

external_url 'http://gitlab.m2a.local:80'

A chaque modification du fichier de configuration, il faudra relancer le build de notre application avec la commande suivante :

La reconfiguration devrait durer 5 min. Une fois effectuée, le message GitLab Reconfigured! devrait apparaître.

Accessibilité depuis l’extérieur

Puis que nous sommes derrière un serveur Proxmox, il faut transmettre les requêtes depuis l’adresse IP publique vers le serveur Gitlab pour le rendre accessible depuis l’extérieur. Pour cela, on effectue un NAT où l’on va dire à Proxmox que l’on veut autoriser les requêtes entrantes sur le port 4001 (Port choisi au hasard) à communiquer avec le port 80 du serveur Gitlab et inversement.

Sur le serveur Proxmox, on utilise la commande iptables pour effectue le nat :

On effectue un test avec l’adresse IP publique suivie du numéro de port dans le navigateur comme ceci : http://@IpPublique:4001

L’identifiant par défaut est root et il est demandé de changer le mot de passe dés la 1ère connexion.

Sécuriser Gitlab en HTTPS avec un certificat auto-signé

Par défaut, Gitlab intégère un module TLS/SSL qui permet de sécuriser les connexions au site et de passer en HTTPS mais elle nécessite d’avoir un vrai nom de domaine valide avec un enregistrement A pointant vers le serveur Gitlab.

Ici on va plutôt utilisé un certificat auto-signé avec OpenSSL. Normalement, il est déjà installé par défaut sur le serveur, on le vérifie avec :

Sinon on fait :

La génération du certificat s’effectue avec la commande suivante :

Expliquer cette commande avec ce lien

On nous demande de répondre à des informations liés à la localisation du serveur :

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Calvados
Locality Name (eg, city) []:Caen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:M2L
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:gitlab
Email Address []:

On édite à nouveau le fichier de configuration principal /etc/gitlab/gitlab.rb

On va changer ces lignes :

external_url 'https://gitlab.m2l.local'
(...)
nginx['enable'] = true
nginx['client_max_body_size'] = '250m'
nginx['redirect_http_to_https'] = true
nginx['redirect_http_to_https_port'] = 80
(...)
nginx['ssl_certificate'] = "/etc/gitlab/ssl/selfsigned.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/selfsigned.key"
nginx['ssl_protocols'] = "TLSv1.2 TLSv1.3"

On peut voir ici que le serveur web de Gitlab n’est autre que Nginx. Une fois les modifications effectuées, on lance la reconfiguration de l’application avec :

Puis pour vérifier notre installation :

Utilisation d’un dépôt distant

Pour qu’un dévéloppeur puisse commencer à travailler avec un dépot distant qui sera créé sur notre serveur Gitlab, il va falloir créé une paire de clef SSH sur la machine cliente dont la clef publique sera déposée sur notre serveur Gitlab. Le but de cette manœuvre est d’éviter de rentrer les identifiants du compte git à chaque push.

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\toto/.ssh/id_ed25519):
Created directory 'C:\Users\toto/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\toto/.ssh/id_ed25519.
Your public key has been saved in C:\Users\toto/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:RyUWJrQkN/JHfKc5a1EhpAanPWmMbv5Fw41B9t7GkIc Gitlab
The key's randomart image is:
+--[ED25519 256]--+
|      o.B.Bo*.. |
|       * #.B.ooo |
|        = @..=E .|
{|       . = o== = |
|        S . =+o +|
|       o . .o. . |
|        .  ..    |
|         . .     |
|          .      |
+----[SHA256]-----+

PS C:\Users\toto\Documents\Gitlab> git clone git@192.168.1.1:root/projet-de-test.git
Cloning into 'projet-de-test'...
remote: Enumerating objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.

fatal: No configured push destination.
Either specify the URL from the command-line or configure a remote repository using

    git remote add <name> <url>

and then push using the remote name

    git push <name>