Nuestros desarrolladores estrellas han agotado sus depósitos de café, investigando todo el tiempo por la solución, hasta que Josué halló la contestación en GitLab por lo tanto hoy la comparte aquí.
Solución:
Puedes usar algo como:
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]
Esto asegurará que el contenedor se ejecute con el mismo UID/GID que el usuario del host, pudiendo así leer el keys sin cambiar sus permisos o usar derechos de root. En detalles:
-u $(id -u):$(id -g)
configurar el usuario del contenedor para que coincida con el usuario del host-w /tmp
asegurarnos de trabajar en un directorio en el que podamos escribir (también podemos montar un volumen en el que tengamos permisos de lectura/escritura o construir la imagen con dicho directorio)-v $HOME/.ssh:/path/to/.ssh
monta el SSH del usuario local key del anfitrión--entrypoint sh
y-it
son específicos paraalpine/git
para tener una sesión de shell interactiva, es posible que no la necesite con su imagen
¿Por qué montar una falsificación? /etc/passwd
¿expediente?
Cuando ejecuta un contenedor basado en Linux (como alpine
o debian
) con un UID/GID desconocido (uno que no está presente en /etc/passwd
), git clone
El comando puede dar como resultado un error con un mensaje como:
Cloning into 'myrepo'...
No user exists for uid 1000
fatal: Could not read from remote repository.
Al montar este archivo passwd “falso”, nos aseguramos de que el sistema operativo reconozca al usuario que ejecuta el contenedor y permita que funcione nuestro comando git clone. Nuestro archivo de contraseña se verá así:
git-user:x:1000:1000:Git User:/tmp:/bin/bash
Lo que significa aproximadamente:
git-user
existe con UID 1000 y GID 1000- su directorio HOME es
/tmp
(es opcional pero este directorio es escribible y evita alguna advertencia degit clone
)
Configurando /tmp
(u otro directorio que se pueda crear durante la creación de la imagen) nos aseguramos de tener un directorio HOME en el que se pueda escribir para git-user
que evitará una advertencia de git clone
diciendo que no podía crear un .ssh
directorio
Sin embargo, esto puede tener otros efectos secundarios si tiene la intención de ejecutar diferentes tareas con su contenedor.
Por que usar GIT_SSH_COMMAND
?
GIT_SSH_COMMAND='ssh -i /path/to/.ssh/id_rsa'
asegurará git clone
está usando nuestro keypero esto también se puede hacer usando ssh-agent; consulte https://serverfault.com/questions/447028/non-interactive-git-clone-ssh-fingerprint-prompt
En el ejemplo que uso -o "StrictHostKeyChecking=no"
pero puede ser insegurootra solución sería montar un archivo de host conocido en el contenedor con el host del servidor git repo key y usando -o "UserKnownHostsFile=/path/to/KnownHostFile"
¿Estaría bien clonar los repositorios en la máquina host y montar los directorios en la imagen de la ventana acoplable?
p.ej :
git clone github:repo1
git clone github:repo2
...
docker run -v repo1:/path/to/repo1 -v repo2:/path/to/repo2 ...
Puedes añadir valor a nuestro contenido colaborando tu veteranía en las críticas.