Лучшая практика управления версиями докеров

Question

Мы - несколько разработчиков, которые в настоящее время разрабатывают приложение на C++.

Чтобы убедиться, что все используют те же библиотеки и зависимости, что и удаленный сервер, мы используем докер для компиляции источника кода в нашем локальном хосте.

Мой вопрос в том, что лучше всего использовать git с докером?

1. Добавьте Dockerfile к исходному хранилище кода
2. Создание специализированного хранилища для всех наших Dockerfiles
3. Создан специальный репозиторий для каждого Dockerfile
4. других?

Answer 1

Сохраните файл Docker с исходным кодом. Мы используем ярлыки для добавления информации о версиях в созданное изображение. Добавим:

• мерзавец фиксации и ветви
• ли это «грязный» означает, что изменения были сделаны локально на коде Src от того, что в мерзавца
• ряд CI версия (общедоступен)
• лицо, которое построило изображение (не тот, кто последний проверял в git)

Мы также помечаем изображение номером фиксации.

Вот наш код для одного из наших услуг. Мы используем Buildkite для нашего CI и Quay.io для нашего реестра изображений.

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 

Answer 2

я бы на 2 или 3.

Я бы не держать Dockerfile с источниками, потому что цель каждого отличается:

• Docker и Dockerfile обычно принадлежат миру детонов и ведут себя независимо от реального программного обеспечения. например Docker - это один из способов развертывания вашего программного обеспечения, но он не единственный.
• Ваш Dockerfile может в будущем агрегировать программное обеспечение из другого хранилища git - в каком репозитории вы его сохраните?
• изменения в программном обеспечении не должно systematiaclly повлиять на версию отрасли репо Dockerfile
• изменение dockerfile не должно влиять на версию отрасли на программное обеспечение репо

Иногда Тхо я могу понять, что Dockerfile настолько тесно связан с источником программного обеспечения, что на самом деле вы просто хотите сохранить их все вместе для простоты. Но я бы не стал стандартом.