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

[Fabien ADAM]

Le 29/03/2020 à 12:14, Sébastien Dinot via technique a écrit :
> 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. :)

Tout à fait, d'ailleurs je savais même pas qu'il était intégré à Gitlab ;).

>
> 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.

Dans mon cas, pour une question de déplacement de l'applicatif, il m'est 
plus facile de travailler avec des conteneurs qu'avec une VM.
Ça me permet en effet de sauvegarder les données entre 2 serveurs, et je 
n'ai plus qu'à redémarrer le conteneur sur l'autre serveur. Je fais mes 
màj de la même façon (en basculant), me permettant un retour arrière 
immédiat si la màj se passe mal.

>   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.

C'est très juste. Il existe cependant des projets pour ça, ou sinon, il 
est également possible de se faire des scripts en cron pour le faire.
Dans mon cas d'usage perso à nouveau, je préfère gérer les màj de mes 
différents applicatifs moi même, pour pouvoir agir en cas de pépin. En 
général je le fais pas lot, mais effectivement l'inconvénient est de 
laisser plus de failles de sécurité.

>   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.

Je ferais probablement la même chose pour une utilisation en entreprise.

>
>> 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é.

J'ai un runner dans un conteneur séparé.
Il n'y a pas de recommandations cpu/ram pour les runners, car ça dépend 
complètement de ce qu'on en fait.

>
> Sébastien
>