Gitlab ~ Pièce maîtresse du DEVOPS opensource

L'adoption du devops passe par des changements de process, de mentalités et bien entendu par l’adoption d’outils plus agiles, plus résilients, plus automatisables.

Un de ces outils, ou plutôt un groupement d’outils s’appelle Gitlab.

En seulement quelques années, Gitlab est passé du rang de clone opensource de Github à celui de la meilleure solution de gestion d’usine logicielle open source, et docker-friendly qui plus est.

Faisons le point sur ses points forts

Gitlab le rassembleur

Le nouveau positionnement de Gitlab est de rassembler tous les outils indispensables à une usine logicielle moderne au sein d’un même package opensource.

De quels outils parle-t-on spécifiquement ?

• serveur de build
• repos git
• registry docker privée
• gestion centralisée des accès
• interface de management
• outils de gestion de projet agile
• orchestrateur de containeurs (peut être un jour ?)

Jusqu’à présent si on voulait être sur une stack opensource qui fait tout cela, on était obligé de choisir un composant différent pour chacun de ces outils.

Le choix le plus populaire ressemble souvent à cela: Jenkins + Gitlab + Docker Registry + Kubernetes ou Swarm.

Le tout était grossièrement scotché ensemble mais faute d’alternatives viables, cette combinaison a été adoptée par beaucoup.

Récemment Gitlab a introduit Gitlab CI, qui lui permet de complètement remplacer un Jenkins par exemple.

Regardons de prés les deux approches, pour comprendre pourquoi Gitlab est un choix supérieur à l’ancienne combinaison.

Serveur de build

Gitlab CI utilise une syntaxe déclarative YAML à la fois élégante et puissante pour definir les jobs d’un pipeline, un pipeline étant lui même composé de jobs.

Les jobs sont définis par de simples commandes shell. Pas besoin de se plier à de nouvelles contraintes ou apprendre un nouveau langage, contrairement aux pipelines Groovy de Jenkins par exemple.

Tout comme Jenkins, Gitlab ci utilise des machines externes appelés “runners” qui vont exécuter vos pipelines.

Sans rentrer dans les détails, plusieurs modéles d’execution sont disponibles pour les runners.

Voici ceux qui nous intéressent le plus:

• shell: pipelines exécutés directement sur le runner, dans un shell
• docker: pipelines exécutés à l’intérieur d’un container docker, dont on choisit l’image de base
• docker machine: les jobs sont exécutés sur un cluster docker, autoscalé et managé par docker machine
• kubernetes: exécute vos pipelines sur un cluster kubernetes

Registry docker

La killer feature qui différencie cette registry de la registry docker de base, c’est la gestion d’accès centralisée.

Si vous pouvez vous connecter à votre gitlab avec un compte local ou Active Directory, vous pourrez également vous authentifier sur la registry avec les mêmes credentials et n’aurez accès qu’à vos repositories ou ceux qu’on vous a partagé.

Chacun son login chacun son mdp, et le tout est synchronisé avec les credentials gitlab.

Magique !

Gestionnaire de serveur git

Bien plus qu’un simple serveur GIT, GItlab est dés le départ une interface complète de gestion de serveur GIT et la fonctionnalité à l’origine de la création de Gitlab est toujours aussi efficace.

Rien ne manque ou presque, comparé à un Github. On est très loin de l’austérité d’un bitbucket par exemple.

Visualisation riche, Merges depuis l’interface (avec résolution de conflits), Diffs, Wiki, Issues, Gitlab Pages, Gestion fine d’accès, Le login SSO, Kanboard… tout y est.

Extensibilité: Plugins vs API

Le fait d’avoir un système de plugins est plutôt une qualité hors contexte, mais dans le cas de Jenkins c’est un désastre, voici pourquoi.

Avec Jenkins, la moindre petite fonctionnalité considérée indispensable dans une stack devops moderne est sous traitée à un plugin, souvent développé par des auteurs tiers.

A cause de cela, réaliser une montée de version du Jenkins s’apparente à la roulette russe: quel plugin va donc casser en premier cette fois ci ?

Gitlab intègre nativement tout ce qu’on peut en attendre d’un serveur CI moderne, et gère l’extension à travers une api REST HTTP moderne, ce qui est une approche bien plus propre et puissante.

Quand on met à jour Gitlab, il n’y a pas de surprises, puisque toutes les features ont été testés ensemble dés le départ et ce avant la release.

Interface graphique

Avec tout le respect que l’on doit à Jenkins après toutes ces années de bons et loyaux services, admettons le: l’ergonomie de Jenkins a toujours été horrible.

Récemment, des efforts ont été faits pour moderniser l’interface, portés par le projet Blue Ocean, actuellement en bêta: https://jenkins.io/projects/blueocean/ … à surveiller

Coté Gitlab on se retrouve devant un UX extrêmement bien pensé et un UI moderne & agréable. Si vous venez de github, vous trouverez vos marques immédiatement.

Gestion de projet agile

Celui ci sort complètement du scope de la première stack, mais comparé à Github ou BItbucket, qui sont des alternatives très populaires à Gitlab, ce dernier s’en sort très bien du coté planification et issues management.

Gitlab intègre un système d’issues en tout point similaire à celui de github, mais également une vue kanban qui permet à votre équipe de gérer son backlog en mode agile.

A mon humble avis, le fait que Github et Gitlab sortent une vue kanban n’est pas anodin aux raisons du rachat de Trello par Atlassian, en dehors de l’énorme base utilisateur de trello bien entendu.

Coté gestion de projet, c’est Gitlab qui s’en sort le mieux avec une intégration à part entière (vs trello+bitbucket), dans l’édition “community” opensource (vs version “entreprise” coté github)

Deploiement continu

Vous pouvez effectuer le déploiement d’une nouvelle version de votre image docker en staging sur votre cluster docker, directement à partir des pipelines GItlab.

Pour les environnements de production vous pouvez également configurer des déploiements manuels, avec des boutons pour l’upgrade et de rollback de version.

Gitlab n’a pas (encore ?) d’interface pour gérer votre cluster de production, mais à mon sens il en a pas besoin et par ailleurs il se marie très bien avec les solutions très complémentaires comme Rancher et OpenShift.

La boucle est bouclée.

Et vous, que vous manque t-il pour passer à Gitlab pour gérer votre usine logicielle open source ?