Должен ли .dockerignore обычно быть надмножеством .gitignore?

Question

Давайте сосредоточимся на сценарии, где в проекте используются и Docker, и Git. В этом случае удобно поддерживать файлы .gitignore и .dockerignore.

Я пытаюсь понять связь между этими двумя файлами. Подозрение моего новичка заключается в том, что .dockerignore должен быть надмножеством .gitignore и всегда содержать как минимум одинаковые элементы.

Я считаю, что если .dockerignore не перечисляет какой-либо файл, который .gitignored, тогда наш контекст сборки на компьютере разработчика будет включать этот файл, тогда как контекст сборки в среде Continuous Integration не будет (поскольку он работает только с файлами, присутствующими в репозитории git). Это может легко привести к ситуации, когда образ докера, созданный локально, работает, но сборка образа из того же кода на сервере сборки не работает, поскольку он работает с другими входными данными.

ЭтоВерно ли, что .dockerignore обычно должен быть надмножеством .gitignore? Если да, то действительно ли вы используете какой-либо инструмент для обеспечения этого отношения?

Answer 1

Я не думаю, что .dockerignore является надмножеством .gitignore. Docker игнорирует файлы contans, которые вы хотите игнорировать при сборке Docker, а в некоторых случаях это может быть и ваш исходный код. Возьмите пример Java-проекта, который вы строите с maven.

В этом случае при сборке контейнера Docker вас, вероятно, интересует только папка target, а не любая другая папка. Принимая во внимание, что .gitignore будет иметь целевую папку, поскольку вы не будете проверять в скомпилированных двоичных файлах (jar / war) исходный репозиторий.

Точно так же могут быть и другие файлы, созданные или загруженные во время вашей сборки, которыетребуется в контейнере, но не в репозитории. Таким образом, в двух словах, я не думаю, что это хорошая идея - применять правило superset, по крайней мере, не в общем всеобъемлющем виде.

Answer 2

Распространено довольно часто создавать приложение вне Docker и вставлять полученный бинарный файл. Наиболее распространенный пример, который я вижу в SO, - это приложения на основе Java. Формат файла класса Java разработан так, чтобы его можно было переносить между средами, и поэтому нет большой разницы, если файл .jar создан на рабочей станции разработчика или нет. Вы можете запустить

mvn build
docker build -t myapp .

FROM tomcat:9
COPY target/myapp.war /usr/local/tomcat/apps

. В этой настройке каталог target будет находиться в .gitignore (вы не хотите, чтобы артефакты сборки фиксировались для управления исходным кодом), но не были бы в .dockerignore(он должен быть доступен для изображения).

Некоторые другие шаблоны, в которых это может быть полезно, включают:

• На скомпилированном языке в среде разработчика с довольно длительным временем сборки,чтобы вы могли получить тестовое изображение, не тратя несколько минут на ожидание make в многоэтапной сборке
• Когда изображение должно содержать статические ресурсы, которые размещены где-то вне контроля источников, например Amazon S3
• Если есть наборы данных, которые генерируются во время сборки, они достаточно велики, чтобы не хотеть регистрироваться, но настолько малы, что их добавление к образу все еще практично (возможно, 5-500 МБ)

(я в основном игнорирую .dockerignore, но я также стараюсь четко указать, какие файлы я COPY добавляю в мои изображения.)