1. Введение
.Git — ведущая система контроля версий для разработки программного обеспечения. С другой стороны, Dockerfile содержит все команды для автоматического создания образа нашего приложения. Эти два продукта — идеальное сочетание для тех, кто хочет внедрить DevOps .
В этом руководстве мы рассмотрим несколько решений для объединения этих двух технологий. Мы подробно рассмотрим каждое решение и рассмотрим его плюсы и минусы.
2. Dockerfile внутри репозитория Git
Самое простое решение для постоянного доступа к репозиторию Git внутри Dockerfile — хранить Dockerfile непосредственно в репозитории Git:
ProjectFolder/
.git/
src/
pom.xml
Dockerfile
...
В приведенной выше настройке мы дадим нам доступ ко всему исходному каталогу проекта. Далее мы можем включить его в наш контейнер с помощью команды ADD , например:
ADD . /project/
Конечно, мы можем ограничить область копирования каталогом сборки:
ADD /build/ /project/
или вывод сборки, например файл .jar:
ADD /output/project.jar /project/
Самым большим преимуществом этого решения является то, что мы можем тестировать любые изменения кода без внесения их в репозиторий. Все будет жить в одном и том же локальном каталоге.
Здесь нужно помнить одну вещь: создать файл .dockerignore . Он похож на файл .gitignore , но в этом случае он исключает из контекста Docker файлы и каталоги, соответствующие шаблонам в нем. Это помогает нам избежать ненужной отправки больших или конфиденциальных файлов и каталогов в процесс сборки Docker и потенциального добавления их в образы.
3. Клонируйте репозиторий Git
Еще одно простое решение — просто получить наш репозиторий git во время процесса сборки образа. Мы можем добиться этого, просто добавив ключ SSH в локальное хранилище и вызвав команду git clone :
ADD ssh-private-key /root/.ssh/id_rsa
RUN git clone git@github.com:foreach/tutorials.git
Приведенная выше команда извлечет весь репозиторий и поместит его в каталог ./tutorials в нашем контейнере.
К сожалению, у этого решения есть и недостатки.
Прежде всего, мы будем хранить наш закрытый SSH-ключ в образе Docker, что может вызвать потенциальные проблемы с безопасностью. Мы можем применить обходной путь, используя имя пользователя и пароль для репозитория git:
ARG username=$GIT_USERNAME
ARG password=$GIT_PASSWORD
RUN git clone https://username:password@github.com:foreach/tutorials.git
и передать их как переменные окружения с нашей машины. Таким образом, мы сохраним учетные данные git за пределами нашего образа.
Во-вторых, этот шаг будет закеширован в более поздних сборках, даже если наш репозиторий изменится. Это связано с тем, что строка с командой RUN остается неизменной, если вы не сломаете кеш на более раннем этапе. Хотя мы можем решить эту проблему, добавив параметр –no-cache в команду сборки docker .
Еще один небольшой недостаток заключается в том, что мы должны установить пакет git в наш контейнер.
4. Отображение объема
Третье решение, которое мы могли бы использовать, — это сопоставление томов . Это дает нам возможность монтировать каталоги с нашей машины в контейнер Docker. Это предпочтительный механизм хранения данных, используемый контейнерами Docker.
Мы можем сделать это, добавив следующую строку в наш Dockerfile:
VOLUME /build/ /project/
Это создаст каталог /project в контейнере и смонтирует его в каталог /build на нашем компьютере.
Отображение томов будет лучшим выбором, когда наш репозиторий Git используется только для процесса сборки. Сохраняя репозиторий вне контейнера, мы не увеличиваем его размер и не позволяем содержимому репозитория выходить за пределы жизненного цикла данного контейнера.
Одна вещь, которую мы должны иметь в виду, это то, что сопоставление томов дает контейнеру Docker доступ на запись к смонтированным каталогам. Неправильное использование этой функции может привести к некоторым нежелательным изменениям в каталоге репозитория git.
5. Подмодули Git
В тех случаях, когда мы храним Dockerfile и исходный код в отдельных репозиториях или для нашей сборки Docker требуется несколько исходных репозиториев, мы можем рассмотреть возможность использования подмодулей Git .
Во-первых, нам нужно создать новый репозиторий Git и поместить туда наш Dockerfile. Далее мы можем определить наши подмодули, добавив их в файл .gitmodules:
[submodule "project"]
path = project
url = https://github.com/foreach/tutorials.git
branch = master
Теперь мы можем использовать подмодуль как стандартный каталог. Например, мы можем скопировать его содержимое в наш контейнер:
ADD /build/ /project/
Помните, что подмодули не обновляются автоматически. Нам нужно запустить следующую команду git, чтобы получить последние изменения:
git submodule update --init --recursive
6. Обзор
В этом руководстве мы узнали несколько способов использования репозитория Git внутри Dockerfile. Как всегда, весь исходный код доступен на GitHub .