На мой взгляд, второй вариант является наиболее разумным - вы можете изменить Dockerfile при изменении кода репозитория, чтобы вы могли запустить конвейер CI одним нажатием. Здесь на CI вы также хотите строить контейнеры. Кроме того, Dockerfile - это ресурс, к которому вы часто хотите, чтобы команды DevOps и Dev имели доступ и часто работали над ними вместе.

Кроме того, если у вас есть интеграция с CI, вы хотели бы запускать конвейер после каждого изменения в Dockerfile, что было бы значительно проще, если бы он находился в одном месте с кодом.

Затем у вас также есть все файлы Kubernetes / Helm в другом (одном) репозитории, чтобы вы могли управлять ими и комбинировать их, когда это необходимо для разных микросервисов (если у вас более сложные развертывания). Здесь в CI вам просто нужен линтинг для диаграмм / файлов.

Я думаю, что имеет больше смысла помещать Dockerfiles и его файлы развертывания (k8s YAML) в одно и то же репозиторий своей службы, это упрощает сборку и развертывание службы, поскольку инструмент CI / CD может просто извлекать новый код, создавать образ, а затем разверните. Вы также можете пойти по пути Helm и закрыть все файлы развертывания из репозиториев служб, и они могут быть все вместе в одной диаграмме управления. Путь Helm позволяет легко увидеть приложение в целом. Вам следует использовать Дистанционное присутствие, если вы не хотите запускать все службы на машине разработчика.

Я бы порекомендовал №3. Все компании, с которыми я работал до сих пор, так и остаются.

С точки зрения Kubernetes

Некоторые Собственные инструменты разработки Kubernetes, такие как DevSpace (https://github.com/covexo/devspace) и проект (https://github.com/Azure/draft) рекомендуют также помещать определения ресурсов Dockerfile и Kubernetes (или файлы диаграмм Helm) в репозиторий, содержащий код.

Из Перспектива DevOps

Используя №3, разработчики смогут лучше воспроизводить производственную среду для исправления ошибок, а инструменты CI / CD обычно настраиваются для работы с определениями, подобными инфраструктуре как коду, которые содержатся в том же репозитории, что и код.

Есть исключения, например Инструмент GitLab Auto DevOps CI / CD. Он очень разработан для работы с Kubernetes и работает с внешним чартом. Однако они делают это, потому что хотят упростить настройку конвейера CI / CD для Kubernetes и хотят абстрагироваться от базовой диаграммы Helm. Однако они также позволяют самостоятельно определять диаграмму Helm и подразумевают, что она находится в том же репозитории, что и код.

Из перспектива управления версиями

№3 благоприятен, потому что вы можете быть уверены, что всегда можете запускать повторяемые сборки при объединении кода и определений «инфраструктуры». Допустим, вы хотите вернуться в прошлое и использовать старую версию своего кода. Какую версию другого репозитория, не имеющего отношения к делу, вы бы использовали? Наличие всего в одном репо позволит вам проверить любую ревизию или ветку и всегда быть уверенным, что вы можете собрать и создать свой код.

Пример: вы изменили свой инструмент управления зависимостями и вам нужно запустить другую команду для установки зависимостей. Это изменение заставит вас соответствующим образом изменить свой Dockerfile. Имея оба вместе, code + k8s + Dockerfile, вы убедитесь, что вы по-прежнему можете создавать экземпляры более старых версий, использующих старый инструмент управления зависимостями.