Docker gitlab: conflit user

Support Debian
#1

Bonjour,

J’ai installé gitlab via docker-compose.
L’installation fonctionne sans problème mais je viens de m’apercevoir d’un truc.
Quand je regarde les process, j’en ai qui appartiennent à l’uid 996,997,998,999

Tout ce que je voie, c’est que les sous process qui changent d’uid correspondent à
997 = redis
998 = gitaly
996 = postgresql
999 = nginx
992 = grafana

sauf que certains existent déjà
lslogins
998 dante 32 0 0
999 systemd-coredump 5 0 1 systemd Core Dumper

dante, c’est un utilisateur que j’ai créé pour le proxy
par contre systemd-coredump, ça semble être lié à debian

Maintenant, comment je fais pour remettre de l’ordre parce que ça me plaît moyennement de mélanger tout ça.

edit: je viens de tomber sur Provide different configuration for docker-based omnibus installation (#681) · Issues · GitLab.org / omnibus-gitlab · GitLab et Configuration options for the GitLab Linux package | GitLab
je vais tester quand j’aurais un peu de temps ( faut que je fasse attention aux droits de certains fichiers maintenant)

le docker-compose :

version: "3.3"

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    container_name: "gitlab"
    restart: always
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://git.home.xyz'
        nginx['listen_https'] = false
        nginx['listen_port'] = 80
    volumes:
     - '/home/gitlab/data:/var/opt/gitlab'
     - '/home/gitlab/config:/etc/gitlab'
     - '/home/gitlab/logs:/var/log/gitlab'
    networks:
     - gitlab_network
    ports:
     - '46080:80'
     - '46443:443'
     - '46022:22'

  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    container_name: "gitlab-runner"
    restart: always
    depends_on:
     - gitlab
    volumes:
     - "/home/gitlab_runner/config:/etc/gitlab-runner"
     - "/var/run/docker.sock:/var/run/docker.sock"
    networks:
     - gitlab_network

networks:
  gitlab_network:
#2

Tu regardes sur l’hôte ou dans le conteneur Docker Gitlab ?
Si tu regardes sur l’hôte, ce n’est pas un problème, si c’est sur le conteneur, effectivement, ça devrait peut-être poser problème.

#3

C’est sur l’hôte que j’ai regardé.

Pourquoi tu dis que ce n’est pas un problème ?

#4

Personnellement sur Debian et pour plus de simplicité lorsqu’il me faut déployer du Gitlab j’utilise la version Community Omnibus :

… Juste ça fonctionne, et pour maintenir à jour un simple apt install gitlab-ce suffit ^^ (attention toutefois à) conserver une copie du fichier de conf et des secrets).

la version Docker je l’évite je lui préfère une version Kubernetes déployé sur du très gros cluster, avec un ou plusieurs runner sui tu fais de la CI.

#5

Parce que les base utilisateurs de l’hôte et du conteneur ne sont pas les mêmes, il est donc normal d’avoir des numéros qui se chevauchent.
J’ai une machine avec de multiples conteneurs LXC et j’ai également la même chose qui se produit.

#6

faudrait que je creuse d’avantage le sujet, je savais pas que c’était possible.
c’est pas terrible de voir pour un utilisateur connu d’autres processus, idem pour les droits des fichiers.
je ne sais pas depuis combien de temps c’est comme ça (j’ai des doutes que ça soit le cas lors de l’install) mais ça fonctionne.
tu conseilles de laisser en l’état ?

#7

Aucun problème, le processus s’exécute dans le conteneur et n’a pas accès à l’hôte.

Oui, c’est comme ça depuis longtemps, c’est comme ça que fonctionnement les conteneurs.

Je ne pense pas qu’il soit possible de « corriger » ça, donc, oui, laisse en l’état.

#8

Si les containers sont déployés depuis des dockerfile ou si il est possible de créer les images avec , il est tout à fait envisageable de modifier les users en question.

Bien entendu si ça marche comme ça, tu peux laisser tel quel.

C’est principalement pourquoi je regarde à trois fois si les images que je pompe sur les registry sont correctement réalisé, nombre de layers, users, facilité de mise à jour, persistance des données …

PS : Parfois il est plus simples de s’appuyer sur des images officiels et de monter soit même via un fichier compose sa stack, parfois vouloir réinventer la roue est inutile si tous à été bien pensé (mais c’est rare).

#9

Oui, il semble possible de modifier les id dans ce cas : Configuration options for the GitLab Linux package | GitLab

J’ai trouvé un article traitant du sujet : Understanding how uid and gid work in Docker containers | by Marc Campbell | Medium

est-ce qu’il existe un utilitaire capable de faire la distinction entre les processus hôtes / containeurs ?

#10

Alors, de mon côté, j’ai remarqué que si je lance la commande

systemctl status

les processus des différents conteneurs sont le scope correspondant à leur conteneur.
J’ai aussi remarqué que les conteneur LXC sont des processus et que les processus qu’ils exécutent sont leur enfant, tu peux aussi le voir avec des commande du genre de pstree.
Je pense que ça doit être sensiblement pareil pour Docker…

#11

Oui, systemctl status affiche les CGroups des processus