我把一个非常简单的解决方案放在一起，它适用于我的用例，我使用一个“builder”docker映像来构建一个单独部署的可执行文件。换句话说，我的“构建器”映像永远不会离开我的本地机器，并且只需要在构建阶段访问私有回购/依赖。

对于这个解决方案，您不需要更改Dockerfile。

运行容器时，挂载~/。SSH目录(这避免了必须将键直接烘焙到映像中，而是确保它们在构建阶段只在短时间内对单个容器实例可用)。在我的例子中，我有几个构建脚本来自动化我的部署。

在我的build-and-package.sh脚本中，我像这样运行容器:

# do some script stuff before    

...

docker run --rm \
   -v ~/.ssh:/root/.ssh \
   -v "$workspace":/workspace \
   -w /workspace builder \
   bash -cl "./scripts/build-init.sh $executable"

...

# do some script stuff after (i.e. pull the built executable out of the workspace, etc.)

build-init.sh脚本如下所示:

#!/bin/bash

set -eu

executable=$1

# start the ssh agent
eval $(ssh-agent) > /dev/null

# add the ssh key (ssh key should not have a passphrase)
ssh-add /root/.ssh/id_rsa

# execute the build command
swift build --product $executable -c release

因此，我们不是直接在docker run命令中执行swift构建命令(或任何与您的环境相关的构建命令)，而是执行build-init.sh脚本，该脚本启动ssh-agent，然后将ssh密钥添加到代理，最后执行swift构建命令。

注1:为了使其工作，您需要确保您的ssh密钥没有密码短语，否则ssh-add /root/。Ssh /id_rsa行将要求口令并中断构建脚本。

注意2:确保在脚本文件上设置了适当的文件权限，以便它们可以运行。

希望这为具有类似用例的其他人提供了一个简单的解决方案。

您可以使用多级构建来构建容器 你可以这样做:-

阶段1使用ssh构建映像

FROM ubuntu as sshImage
LABEL stage=sshImage
ARG SSH_PRIVATE_KEY
WORKDIR /root/temp

RUN apt-get update && \
    apt-get install -y git npm 

RUN mkdir /root/.ssh/ &&\
    echo "${SSH_PRIVATE_KEY}" > /root/.ssh/id_rsa &&\
    chmod 600 /root/.ssh/id_rsa &&\
    touch /root/.ssh/known_hosts &&\
    ssh-keyscan github.com >> /root/.ssh/known_hosts

COPY package*.json ./

RUN npm install

RUN cp -R node_modules prod_node_modules

阶段2:构建容器

FROM node:10-alpine

RUN mkdir -p /usr/app

WORKDIR /usr/app

COPY ./ ./

COPY --from=sshImage /root/temp/prod_node_modules ./node_modules

EXPOSE 3006

CMD ["npm", "run", "dev"] 

在你的合成文件中添加env属性:

   environment:
      - SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}

然后像这样从构建脚本传递参数:

docker-compose build --build-arg SSH_PRIVATE_KEY="$(cat ~/.ssh/id_rsa)"

并移除中间容器，以确保安全。 这将帮助你干杯。

Docker容器应该被视为它们自己的“服务”。为了分离关注点，你应该分离功能:

1)数据应该在数据容器中:使用链接卷将repo克隆到。然后可以将该数据容器链接到需要它的服务。

2)使用一个容器来运行git克隆任务(即它唯一的任务是克隆)，当你运行它时将数据容器链接到它。

3) ssh-key也一样:把它作为一个卷(如上所述)，当你需要它时链接到git克隆服务

这样，克隆任务和密钥都是临时的，只在需要时才活动。

现在，如果你的应用程序本身是一个git接口，你可能会考虑直接使用github或bitbucket REST api来完成你的工作:这就是它们的设计目的。

注意:只使用这种方法的图像是私有的，将永远是!

ssh密钥仍然存储在映像中，即使您在添加密钥后在层命令中删除密钥(参见本文中的评论)。

在我的情况下，这是可以的，所以这是我使用的:

# Setup for ssh onto github
RUN mkdir -p /root/.ssh
ADD id_rsa /root/.ssh/id_rsa
RUN chmod 700 /root/.ssh/id_rsa
RUN echo "Host github.com\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config

如果您不关心SSH密钥的安全性，这里有许多很好的答案。如果你有，我找到的最好的答案是从上面一个评论的链接到这个GitHub评论由diegosandrim。所以其他人更有可能看到它，以防回购消失，这里是这个答案的编辑版本:

这里的大多数解决方案最终都将私钥保留在映像中。这很糟糕，因为任何访问映像的人都可以访问您的私钥。由于我们对挤压的行为了解不够，即使你删除键并挤压该层，情况仍然可能是这样。

我们用aws s3 cli生成一个预签名URL来访问密钥，并限制访问大约5分钟，我们将这个预签名URL保存到repo目录下的一个文件中，然后在dockerfile中将其添加到映像中。

在dockerfile中，我们有一个RUN命令，执行所有这些步骤:使用pre-sing URL获取ssh密钥，运行npm install，并删除ssh密钥。

通过在单个命令中执行此操作，ssh密钥将不会存储在任何层中，但将存储预签名URL，这不是问题，因为URL将在5分钟后失效。

构建脚本看起来像:

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

Dockerfile是这样的:

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no git@github.com || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

“你可以选择性地让远程服务器访问你的本地ssh-agent，就像它在服务器上运行一样”

https://developer.github.com/guides/using-ssh-agent-forwarding/