Bonjour à tous,

Aujourd’hui, je vais vous parler de l’essai que j’ai fait de Gitlab pour mon usage personnel.

Contexte

Pour gérer tous mes dépôts Git, je possède une instance de Gitea. C’est un service léger et très simple à installer et maintenir que j’héberge sur mon serveur. Je m’en sers pour faire des miroirs des principaux logiciels Open-Source que j’utilise mais également pour stocker entre autres des Dockerfile et docker-compose.yml de services que j’héberge ainsi que des petits projets personnels.

Au travail, j’ai découvert très récemment Gitlab CI/CD. Jusque-là, j’avais principalement utilisé Jenkins pour tout ce qui relève de l’intégration continue. L’avantage de Gitlab CI/CD est que c’est (et ça semble logique) très bien intégré à Gitlab.

Là où Gitea se veut être un outil Open-Source simple mais complet, Gitlab est vraiment un équivalent de Github mais qui reste Open-Source. Ces 2 derniers vont beaucoup plus loin que le simple serveur Git avec gestion de tickets et de merge requests comme Gitea donc ce n’est pas directement comparable.

N’ayant pas d’intégration continue avec Gitea Vanilla, j’ai donc 2 possibilités si je veux en mettre une en place:

• Installer un outil tel que Jenkins associé à un plugin côté Gitea.
• Installer Gitlab ainsi qu’un runner et profiter d’une totale intégration.

Comme c’est plus par curiosité que pour un besoin absolument nécessaire, je me suis dit que ça pourrait être sympa de tester de Gitlab. En effet, ça me permettrait de ne pas multiplier le nombre de services sur mon serveur, ce qui devrait en simplifier la maintenance (ou pas, parce qu’un outil qui fait tout, c’est plus complexe donc ce postulat n’est pas totalement vrai).

Pour moi, le cas d’utilisation pourrait par exemple être de construire mes images Docker:

• Dans la version latest à chaque commit pour tester dans ma machine virtuelle type bac à sable.
• Dans une version taguée à chaque fois qu’un tag git est posé pour n’utiliser que des versions définies sur le serveur de production.

Mise en place

Avant de partir sur une mise en place de Gitlab totalement propre et fonctionnelle, j’ai donc fait au plus simple avec les images Docker de Gitlab qui nous sont mises à disposition.

Voici un exemple de mon docker-compose.yml avec l’exposition de Gitlab à travers Traefik:

(Si vous ne connaissez pas Traefik, je vous conseille de lire cet article dans lequel je présente mon retour d’expérience sur Traefik après quelques mois d’utilisation).

version: '3.7'

services:
    gitlab:
        image: gitlab/gitlab-ce:14.0.3-ce.0
        container_name: "gitlab"
        environment:
            GITLAB_OMNIBUS_CONFIG: |
                gitlab_rails['gitlab_shell_ssh_port'] = 2222
                external_url 'https://git.example.com'
                nginx['listen_https'] = false
                nginx['listen_port'] = 80
        volumes:
            - ./data/gitlab/data/:/var/opt/gitlab/
            - ./data/gitlab/config/:/etc/gitlab/
            - ./data/gitlab/logs/:/var/log/gitlab/
            - /etc/timezone:/etc/timezone:ro
            - /etc/localtime:/etc/localtime:ro
        networks:
            - traefik-frontend
            - gitlab-backend
        ports:
            - "2222:22"
        restart: always
        labels:
            - "traefik.enable=true"
            - "traefik.docker.network=traefik-frontend"
            - "traefik.http.services.gitlab.loadbalancer.server.port=80"
            - "traefik.http.routers.gitlab.rule=Host(`git.example.com`)"
            - "traefik.http.routers.gitlab.entrypoints=websecure"
            # TLS and security
            - "traefik.http.routers.gitlab.tls=true"
            - "traefik.http.routers.gitlab.tls.options=my-file-options@file"
            - "traefik.http.routers.gitlab.middlewares=my-headers-options@file"

    gitlab-runner:
        image: gitlab/gitlab-runner:alpine
        container_name: "gitlab-runner"
        restart: always
        depends_on:
            - gitlab
        volumes:
            - ./data/gitlab/runner/:/etc/gitlab-runner/
            - /var/run/docker.sock:/var/run/docker.sock
        networks:
            - gitlab-backend

networks:
    traefik-frontend:
        name: traefik-frontend
    gitlab-backend:
        name: gitlab-backend

Il y a ensuite quelques bidouilles à faire pour avoir un utilisateur avec lequel on peut se connecter. Si vous êtes intéressé, je vous laisse retrouver ces manipulations dans la documentation Gitlab (notamment sur cette page).

Avec ce fichier docker-compose.yml, je peux alors lancer Gitlab et son runner. Là où Gitea ne prends que quelques secondes, Gitlab démarre tout de même 3-4 minutes (y compris lors de futurs redémarrages, pas que la première fois).

Retour d’expérience

Consommation

On vient à peine de lancer le serveur Gitlab et déjà, sans rien faire, on a un serveur (ruby) qui tourne. En soit, ça ne serait pas un souci mais Gitlab consomme en moyenne et au repos 4,26Go. Cela n’est quand même pas anodin pour un serveur réservé à un usage relativement personnel.

Migration

Premier bon point, on peut facilement importer un dépôt Git quelle que soit la source. Sur ces fonctionnalités basiques, Gitlab comme tous les autres outils sont très pratiques.

De même, il est ultra simple avec Gitlab d’importer tous les dépôts hébergés dans mon instance Gitea. Il suffit de donner l’adresse de l’instance Gitea et de générer un token (cela se passe dans <url-gitea>/user/settings/applications) et le tour est joué. On peut alors choisir parmis tous les dépôts dont l’utilisateur donné a accès dans Gitea.

Cela dit, les issues ne semblent pas pouvoir être importées simplement de Gitea à Gitlab. J’ai testé depuis Github vers Gitlab et les issues ont bien été importées. Donc je ne sais pas si la faute est côté Gitlab ou Gitea (dans le sens Gitlab vers Gitea, les issues sont bien importées.

Par contre, un gros point noir pour mon utilisation est que la fonctionnalité miroir (où mon instance Gitlab récupèrerait des commits sur des dépôts d’autres serveurs) n’est pas disponible gratuitement mais que depuis des versions Premium (source). Or on peut le voir ici, je possède tout de même un nombre important de miroirs donc je perds quand même une fonctionnalité importante dans la version gratuite.

Interface

Bon, l’interface de Gitea n’est pas forcément la meilleure, mais celle de Gitlab est tout autant remplie de fonctionnalité et de boutons dans tous les sens.

Par exemple arrivez-vous à compter le nombre de boutons ou liens cliquables dans l’interface Gitlab ?

Rien que sur la page Gitlab, je compte 72 liens cliquables. Et encore, chaque bouton du menu sur la gauche fait apparaitre un autre menu avec encore d’autres boutons et de fonctionnalités.

Cela dit, je compte pas moins de 55 boutons sur Gitea alors que cet outil propose moins de fonctionnalités (pas d’intégration continue intégrée sur cette instance par exemple). L’écart n’est donc pas si important, mais on se perd très rapidement dans Gitlab pour n’utiliser que 5% de ce qu’il est capable de faire.

Utilisation de Gitlab CI/CD

Bon, le premier test que j’ai fait était avec la fonctionnalité Auto DevOps. Je ne vais pas y aller par 4 chemins, ça ne sert pas à grand-chose, j’imagine que cet outil ultra générique va s’améliorer au fil du temps mais ce n’est pas le sujet de l’article.

Après avoir écrit mon .gitlab-ci.yml et pas mal bidouillé et jonglé avec la documentation pour que le runner fonctionne, j’avais donc l’intégration continue qui fonctionnait.

Je savais déjà (car je l’utilisais au travail comme je l’ai dit) à quoi l’intégration ressemblait, donc l’effet WOW n’était pas aussi resplendissant mais c’est toujours beau et agréable de voir des tâches et des actions se lancer automatiquement.

Avis

Gitlab est donc un outil complet mais trop complet pour un usage personnel tel que le mien. En effet, l’interface de la version Community Edition est ultra lourde, il y a beaucoup de boutons que je ne vais jamais utiliser. C’est sûrement configurable (les autres instances de Gitlab que j’ai vu ailleurs avaient beaucoup moins de boutons) mais je n’ai pas autant de temps à passer pour un usage personnel de Gitlab.

D’autant que j’ai déjà fait des scripts (certes en bon vieux bash) que j’ai juste à lancer à la main. Par exemple sur ce dépôt qui fournit une image Docker pour sauvegarder des bases de données MariaDB. Il me suffit de poser un tag git (git tag mon-tag) puis de lancer le script build-and-push.sh qui va rechercher le tag git le plus récent, générer l’image puis la pousser sur mon registre Docker.

Enfin, la consommation RAM d’une instance de Gitlab n’est pas vraiment adaptée à mon usage et une fonctionnalité importante pour mon usage ne serait plus disponible.

Conclusion

En résumé, j’ai testé Gitlab pour mon usage personnel, mais c’est beaucoup trop lourd et complexe pour cela. Je vais donc rester sur Gitea et continuer à lancer mes scripts à la main, cela reste tout à fait acceptable dans un cadre personnel comme le mien, je ne passe pas (plus ?) mes journées sur mon temps personnel à faire des bidouilles sur mon serveur (d’ailleurs cela se ressent sur la difficulté que je rencontre en ce moment pour écrire des articles techniques).

Par contre, pour un usage professionnel, Gitlab & Co sont des excellents outils lorsqu’ils sont bien utilisés. En tant que développeurs, ces outils peuvent faire gagner un temps fou en apportant également la satisfaction de voir son processus automatisé. Il faut cependant faire attention à ne pas se reposer dessus et à comprendre comment tout le processus fonctionne (à la fois pour pouvoir l’améliorer mais aussi pour ne pas être bloqué en cas de pépin).

Pour terminer le propos, je ne pense pas qu’une instance pour une seule personne (ou même quelques personnes) soit la cible de Gitlab, c’est plus pour des organisations et des entreprises. C’est donc selon moi tout à fait logique que je reste sous Gitea. Après, chacun possède ses usages et besoins spécifiques.

Et pour terminer l’article, si vous avez besoin d’un compte sur mon instance Gitea, n’hésitez pas à m’en faire part, les inscriptions ne sont fermées que suite à des abus et des bots.