Dockerfile Versionierung Best Practice

Question

Wir sind ein paar Entwickler, die derzeit eine C++ App entwickeln.

Um sicherzustellen, dass alle die gleichen Bibliotheken und Abhängigkeiten verwenden wie der Remote-Produktionsserver, verwenden wir Docker, um die Quellcodequelle in unserem localhost zu kompilieren.

Meine Frage ist, was die beste Praxis ist, git mit docker zu verwenden?

1. die Dockerfile zum Repository Quellcode hinzufügen
2. Erstellen Sie ein dediziertes Repository für alle unsere Dockerfiles
3. ein spezielles Repository für jede Dockerfile
4. Andere Erstellt?

Answer 1

Behalten Sie Ihre Dockerfile mit dem Quellcode. Wir verwenden Labels, um Versionsinformationen zum erzeugten Bild hinzuzufügen. Wir fügen:

• die git commit und Zweig
• ob es "dirty", was bedeutet, dass Änderungen wurden von lokal auf dem src-Code gemacht, was in git
• eine CI-Versionsnummer (öffentlich sichtbar)
• die Person, die das Bild erstellt hat (nicht die Person, die zuletzt git eingecheckt hat)

Wir markieren auch das Bild mit der Commit-Nummer.

Hier ist unser Code für einen unserer Dienste. Wir verwenden Buildkite für unsere CI und Quay.io für unsere Bildregistrierung.

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 

Dann können Sie Skripte, dass die Version des Bildes überprüfen. ZB:

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

Answer 2

ich gehen würde, für 2 oder 3

ich nicht die Dockerfile mit den Quellen halten würde, weil der Zweck jedes ist anders:

• Docker und Dockerfile gehören in der Regel zur devops world und verhalten sich unabhängig von der eigentlichen Software. z.B. Docker ist eine Möglichkeit, Ihre Software zu implementieren, aber es ist nicht die einzige.
• Ihre Dockerfile kann in Zukunft Software von einem anderen Git-Repository aggregieren - in welchem ​​Repo behalten Sie es?
• eine Änderung in der Software nicht systematiaclly sollte die Version der Branche Dockerfile Repo auswirken
• eine Änderung der dockerfile sollte die Version der Software Repo-Zweig

Manchmal nicht beeinflussen tho ich, dass das verstehen Dockerfile ist so eng mit der Softwarequelle verbunden, dass man sie eigentlich nur einfach zusammen speichern möchte. Aber ich würde es in keiner Weise zu einem Standard machen.