Dockerfile版本控制的最佳实践
我们是一些正在开发C ++应用程序的开发人员。
为了确保每个人都使用与远程生产服务器相同的库和依赖项，我们使用docker来编译本地主机中的代码源。
我的问题是什么与docker使用Git的最佳做法？
- 将Dockerfile添加到源代码库
- 为我们所有的Dockerfiles创build一个专用的存储库
- 为每个Dockerfile创build一个专用的存储库
- 其他？
保持您的Dockerfile与源代码。 我们使用标签将版本信息添加到生成的图像。 我们增加：
- git提交和分支
- 是否“脏”，意味着在src代码上进行了本地修改
- CI版本号（公开可见）
- build立图像的人（而不是上次在git中检查的人）
我们也用提交号码标记图像。
这是我们的服务之一的代码。 我们正在为我们的CI和Quay.io使用Buildkite来处理我们的图像registry。
build-image.sh
echo '===> Building docker image...' GIT_BRANCH=$(git name-rev --name-only HEAD | sed "s/~.*//") GIT_COMMIT=$(git rev-parse HEAD) GIT_COMMIT_SHORT=$(echo $GIT_COMMIT | head -c 8) GIT_DIRTY='false' BUILD_CREATOR=$(git config user.email) BUILD_NUMBER="${BUILDKITE_BUILD_NUMBER-0}" # Whether the repo has uncommitted changes if [[ $(git status -s) ]]; then GIT_DIRTY='true' fi docker build \ -q \ -t quay.io/myco/servicename:latest \ -t quay.io/myco/servicename:"$GIT_COMMIT_SHORT" \ --build-arg GIT_BRANCH="$GIT_BRANCH" \ --build-arg GIT_COMMIT="$GIT_COMMIT" \ --build-arg GIT_DIRTY="$GIT_DIRTY" \ --build-arg BUILD_CREATOR="$BUILD_CREATOR" \ --build-arg BUILD_NUMBER="$BUILD_NUMBER" \ . echo "Done" echo "Push to quay using:" echo " docker push quay.io/myco/servicename:latest" echo " docker push quay.io/myco/servicename:$GIT_COMMIT_SHORT"
Dockerfile
FROM ... ARG GIT_COMMIT ARG GIT_BRANCH=master ARG GIT_DIRTY=undefined ARG BUILD_CREATOR ARG BUILD_NUMBER LABEL branch=$GIT_BRANCH \ commit=$GIT_COMMIT \ dirty=$GIT_DIRTY \ build-creator=$BUILD_CREATOR \ build-number=$BUILD_NUMBER ... etc
然后，您可以制作检查图像版本的脚本。 例如：
docker inspect --format "{{.ContainerConfig.Labels.commit}}" imageid
我会去2或3。
我不会保留Dockerfile与源，因为每个的目的是不同的：
- Docker和Dockerfile通常属于devops世界，并且独立于实际的软件。 例如Docker是部署软件的一种方式，但并不是唯一的方式。
- 你的Dockerfile可能会在未来从另一个git仓库汇集软件 – 在哪个仓库你会保留它？
- 软件中的更改不应该系统地影响Dockerfile回购分支的版本
- dockerfile中的更改不应该影响Software repo分支的版本
有时候我可以理解，Dockerfile与软件源是如此紧密地联系在一起，实际上你只是为了简单起见而将它们存储在一起。 但是我不会以任何方式使它成为一个标准。