This is a really good question which describes a principle that I've faced a few times now, actually two separate but related issues:
1.) 如何最好地处理Docker中的瞬态文件
Docker非常擅长封装环境的完全重建。如果你在容器外部处理部分流程,例如在docker build过程之外运行composer install,则你的构建过程会变得不太可移植,因为你可能引入了你不知道的机器/环境依赖项。
如果你总是在Docker内部重新构建整个环境,那么你就能保证你的依赖始终被满足,并且你可以将dockerfile交给任何其他人,他们也将有高度的信心能够在本地重新构建而不会出现问题。
瞬态文件非常适合在Docker内部构建!因此,我会尽可能在容器内部构建它们。
2.) 如何将授权与Docker构建过程解耦
这让我们进入第二个问题,如何将授权与构建过程解耦?
Option 1 - 预先使用具有专用构建用户凭据的composer auth.json:
正如其他答案所说,您可以“烘焙”凭据,然后再将其删除。但是,您不希望“烘焙”像ssh密钥这样敏感的东西。
Composer支持auth.json文件,为什么不创建一个专用的构建用户,并将其凭据(而不是您的凭据)存储在auth.json文件中?如果它被攻击了,您可以更改密码。一旦composer install完成,删除或覆盖该文件。
COPY . ./
RUN composer install --no-dev --no-interaction -o
RUN rm -f ./auth.json
选项二 - 使凭证本身是短暂的,并使用docker exec将它们传递到Docker容器中:
我尚未完全测试此方法,但我想不出为什么这样的方法不起作用。
1.) 您构建一个基础的PHP容器,该容器能够运行“composer install”(或者使用来自docker hub的容器)
2.) 您启动此基础容器,使其运行
3.) 您使用docker exec将凭证传递给已经包含在容器中的包装脚本。包装脚本将使用HTTP基本身份验证运行composer install - 它已经包含了用户名,因此您只需要提供密码,就像http-basic technique一样。
docker exec -d my_base_php_container php -f /my_wrapper_script.php ${PASSWORD}
4.) 您将此容器提交为新图像
docker commit --change "composer install" ${CONTAINER_ID} my_installed_image:1.0