web-dev-qa-db-fra.com

Comment cloner un référentiel Git à partir d'un conteneur Docker

Nous avons un outil qui doit cloner plusieurs référentiels Git pour agréger les données de documentation. Nous voulons mettre cet outil dans un conteneur Docker pour l'exécuter facilement localement et avec Jenkins, et permettre la reproductibilité.

Les référentiels Git sont hébergés sur un serveur privé nécessitant une authentification avec des clés SSH. Ainsi, le conteneur Docker doit en quelque sorte accéder aux clés SSH de l'utilisateur exécutant le conteneur.

Nous avons une liste de contraintes:

  1. nous ne voulons pas intégrer des clés SSH dans l'image Docker
  2. nous ne voulons pas que les utilisateurs construisent l'image Docker. Nous considérons qu'un Dockerfile ne permet pas la reproductibilité alors qu'une image Docker déjà générée ne
  3. nous ne voulons pas que le conteneur s'exécute en tant qu'utilisateur root
  4. nous voulons utiliser les clés SSH de l'utilisateur hôte exécutant le conteneur
  5. des paramètres peuvent être fournis à la commande démarrant le conteneur (-v, -u,…)

Question: Comment pouvons-nous y parvenir, si cela est possible?

Liés:

gitdockerssh-keys
9
Jim

Vous pouvez utiliser quelque chose comme:

echo "git-user:x:$(id -u):$(id -g):Git User:/tmp:/bin/bash" > /tmp/fake_passwd # See below why to use this
docker run \
   -u $(id -u):$(id -g) \
   -w /tmp \
   -v $HOME/.ssh:/path/to/.ssh \
   -v /tmp/fake_passwd:/etc/passwd  \
   --entrypoint sh \
   -it \
   Alpine/git

  # commands in the container:
  $ export GIT_SSH_COMMAND='ssh -i /path/to/.ssh/id_rsa -o "StrictHostKeyChecking=no"'
  $ git clone [path to git repo]

Cela garantira que le conteneur s'exécute avec le même UID/GID que l'utilisateur hôte, pouvant ainsi lire les clés sans modifier leurs autorisations ou utiliser les droits root. En détails:

  • -u $(id -u):$(id -g) définissez l'utilisateur du conteneur pour qu'il corresponde à l'utilisateur hôte
  • -w /tmp Assurez-vous de travailler dans un répertoire dans lequel nous pouvons écrire (nous pouvons également monter un volume sur lequel nous avons des autorisations de lecture/écriture ou créer l'image avec ce répertoire)
  • -v $HOME/.ssh:/path/to/.ssh Monte la clé SSH de l'utilisateur local à partir de l'hôte
  • --entrypoint sh Et -it Sont spécifiques à Alpine/git Pour avoir une session Shell interactive, vous n'en aurez peut-être pas besoin avec votre image

Pourquoi monter un faux fichier /etc/passwd?

Lorsque vous exécutez un conteneur basé sur Linux (tel que Alpine ou debian) avec un UID/GID inconnu (un qui n'est pas présent dans /etc/passwd), git clone La commande peut entraîner une erreur avec un message tel que:

Cloning into 'myrepo'...
No user exists for uid 1000
fatal: Could not read from remote repository.

En montant ce "faux" fichier passwd, nous nous assurons que le système d'exploitation reconnaîtra l'utilisateur exécutant le conteneur et permettra à notre commande git clone de fonctionner. Notre fichier de mots de passe ressemblera à:

git-user:x:1000:1000:Git User:/tmp:/bin/bash

Ce qui signifie grosso modo:

  • git-user Existe avec UID 1000 et GID 1000
  • son répertoire HOME est /tmp (il est facultatif mais ce répertoire est accessible en écriture et évite les avertissements de git clone)

En définissant /tmp (Ou un autre répertoire qui peut être créé lors de la création de l'image), nous nous assurons que nous avons un répertoire HOME accessible en écriture pour git-user, Ce qui empêchera un avertissement de git clone Indiquant qu'il pourrait pas créé de répertoire .ssh

Cependant, cela peut avoir d'autres effets secondaires si vous avez l'intention d'exécuter différentes tâches avec votre conteneur.

Pourquoi utiliser GIT_SSH_COMMAND?

GIT_SSH_COMMAND='ssh -i /path/to/.ssh/id_rsa' S'assurera que git clone Utilise notre clé, mais cela peut également être fait à l'aide de ssh-agent - voir https://serverfault.com/questions/447028/non- interactive-git-clone-ssh-fingerprint-Prompt

Dans l'exemple que j'utilise -o "StrictHostKeyChecking=no" mais cela peut ne pas être sûr , une autre solution serait de monter un fichier Host connu dans le conteneur avec le git repo server Host key et en utilisant -o "UserKnownHostsFile=/path/to/KnownHostFile"

15
Pierre B.

Le clonage des référentiels sur la machine hôte et le montage des répertoires dans l'image du docker seraient-ils corrects?

par exemple. :

git clone github:repo1
git clone github:repo2
  ...

docker run -v repo1:/path/to/repo1 -v repo2:/path/to/repo2 ...
2
LeGEC