Geek Answers Handbook

Dockerfile Best Versioning Practices

We are the developers who are currently developing the C ++ application.

To make sure that everyone uses the same libraries and dependencies as the remote production server, we use docker to compile the source code in our local host.

My question is what is the best way to use git with docker?

  • Add Docker File to Source Code Repository
  • Create a dedicated repository for all of our Dockerfiles
  • Created a dedicated repository for each Dockerfile
  • Others?
+6
source share
2 answers

Save the Docker file with the source code. We use shortcuts to add version information to the generated image. Add:

  • git commit and branch
  • whether it is "dirty", which means that the changes were made locally on the src code from what is in git
  • CI version number (public)
  • the person who created the image (and not the one who last checked in git)

We also mark the image with a commit number.

Here is our code for one of our services. We use Buildkite for our CI and Quay.io for our image 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

Then you can create scripts that check the version of your image. For instance:

 docker inspect --format "{{.ContainerConfig.Labels.commit}}" imageid
+11
source

I would go 2 or 3.

I will not store the Docker file with the sources, because each of them is different:

  • Docker and Dockerfile usually belong to the world of devops and behave independently of real software. For example, Docker is one way to deploy your software, but it is not the only one.
  • your Dockerfile may in future aggregated software from another git repository - in which repository will you save it?
  • a change in software should not systematically affect the version of the Dockerfile replication branch
  • changing docker file should not affect repo Software branch version

Sometimes I can understand that the Dockerfile is so closely related to the source of the software that in fact you just want to keep them all together for simplicity. But I would not become the standard.

+2
source

More articles:


All Articles