Cloning private git repo in the docker container

问题:

I have a project (written in ruby) which I want to run in a docker image. The project source code is stored in a private git repo, the image is created as usual by Dockerfile. The project is huge and so git clone takes relatively long.

The problem is that, I'm not sure how (when/where) to clone the git repo to the docker image properly. I can clone the git repository to the temp directory and copy the source code by COPY command in Dockerfile. I don't like to do that since I would have to maintain the second clone in the temp dir.

Or, I can clone the repo within the docker image. The problem is my ssh-key which I can't reasonably keep in the image. I can add only "my own" keys to the git server which allow to access everything.

So, I created a script like this:

UUID=`uuid`    
docker run \
    -v $HOME/.ssh:/home/user/.ssh:ro\
    --name=$UUID \
    -it $1 /scripts/git-clone-update.sh
docker commit $UUID $1
docker rm $UUI

git-clone-update.sh clones the project if it doesn't exist or just updates if it does. The keys are mounted to the .ssh for that. It works great. I can update the code in the image easily by just calling the script passing the image name as an argument. The only problem is Config.Cmd which always changes to /scripts/git-clone-update.sh.

Any idea how to keep the original Config.Cmd? What is the best practice cloning the private ropo in/to the docker image?

Thx

回答1:

As you've discovered, keeping your private ssh keys in a docker image isn't great for security. I've seen two approaches for this:

1. Create a new, read-only account and keep its keys in the docker image. The more limitations you can put on this account the better for security, but you're still packaging a secret on top of your actual source code.

   Also, this doesn't solve your scripts problem, which I've admittedly no clue how to solve.

2. Host the whole, packaged docker file with your code already copied in. This is the approach Mark O'Conner mentions in his comment. The workflow for a release would be:

   • Copy the code into the docker container.
   • Update the docker image.
   • Upload the new image to your docker repository (e.g. hub.docker.com or Amazon Web Services Elastic Beanstalk).
   • Update or launch new instances of your new container image.

For development i.e. every day use with the second approach, you could have a launch script that copies your code into the docker container and runs or restarts the container or server inside the container as needed. Or you could have a separate development docker image that you configure to mount your source control directory as a separate volume.