[technique] Note d'installation : gitlab + mattermost sur debian 10 (buster)

[Sébastien Dinot]

Fabien ADAM via technique a écrit :
> Tout dépend ce qu'on en fait. Pour mon usage perso (1 personne donc),
> je me contente de 2Go de RAM sans problème (Gitlab 11.6... qu'il
> faudra que je mettre à jour d'ailleurs) :

Waouh, je ne pensais pas possible de faire tourner Gitlab avec aussi peu
de RAM. Mais comme tu l'indiques, il s'agit d'une instance utilisée par
une seule personne. Dès qu'on commence à avoir quelques utilisateurs, je
vous assure que 8 Go de RAM sont requis.

> Y'a des optimisations à faire (unicorn / sidekiq) là dessus pour
> arriver à ce résultat.

En effet, et en plus, si tu es seul à l'utiliser, tu n'as sans doute pas
activé Mattermost. :)

Je vois que tu as déployé Gitlab via Docker et je me permets donc une
petite disgression à ce sujet. J'utilise beaucoup Docker, mais Gitlab
est à mon sens l'une des rares applications pour lesquelles Docker
n'apporte que des désagréments et peu ou prou pas d'avantages. Le paquet
Omnibus est très bien fait et s'intègre parfaitement au système (tout au
moins sur Debian). Gitlab s'installe donc facilement via ce paquet et
les mises à jour sont transparentes pour les utilisateurs (modulo
d'éventuelles interruptions de service de deux ou trois minutes). Or,
administrant des instances publiques et ouvertes, l'application des
patchs de sécurité est pour moi une priorité. Mes serveurs sont ainsi
mis à jour automatiquement toutes les 4 heures et Gitlab l'est aussi
potentiellement à cette occasion. Dans les faits, Gitlab publie une
version mineure le 22 de chaque mois et, entre deux versions mineures,
entre 3 et 6 patches. Depuis les incidents survenus il y a 3 ou 4 ans,
qui avaient pas mal écorné l'image de l'éditeur, le processus de mise
à jour est particulièrement bien géré et vérifié. Un pur bonheur.

À contrario, un conteneur est rarement mis à jour de manière
automatique, d'autant moins lorsqu'il est déployé via Docker Compose. Du
coup, la mise à jour se fait avec un grand retard. L'un de mes clients
a exigé que je déploie Gitlab via Docker et c'est la seule instance sur
les 5 que j'administre sur laquelle les failles de sécurité persistent
plus que de raison (je ne passe pas ma journée à vérifier la
disponibilité de nouvelles versions du conteneur, j'ai bien d'autres
chats à fouetter). Et lorsque j'effectue les mises à jour, le saut
direct d'une « vieille » version à la dernière disponible n'est pas
toujours possible de manière directe. Heureusement, lorsque cela arrive,
Gitlab le détecte et indique les mises à jour intermédiaires à effectuer
(une preuve de plus que la mise à jour est bien gérée). Je ne rencontre
pas ces difficultés avec les instances déployées via le paquet Omnibus.

> Quoi qu'il en soit, les recommandation du projet expliquent très bien
> les choses, et vont dans le sens de ce que dit Seb. C'est ici :
> https://docs.gitlab.com/ce/install/requirements.html#memory

Je n'avais jamais prêté attention à cette page, mon estimation étant
empirique, mais je suis heureux de voir que Gitlab confirme mes propos.
Un peu plus bas, il est aussi question des ressources nécessaires
à Gitlab Runner. Il faut effectivement prendre celui-ci en compte si
vous faites de l'intégration continue, sauf si vous faites tourner les
instances de Gitlab Runner sur d'autres machines (c'est le cas sur la
plupart de mes instances). Et là, les besoins en ressources peuvent
monter en flèche selon le projet considéré.

Sébastien

-- 
Sébastien Dinot, sebastien.dinot at free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !