Необходимо ли выносить docker окружение в отдельный репозиторий?

Question

[Old Kitty]

Добрый день!

Возник вопрос:
Есть ли смысл выносить docker/vagrant/%tool_name% окружение в отдельный репозиторий или стоит держать всё вместе с кодом, что бы стартовало "с одной кнопки" в одной папке?

Есть сомнения, что имеет смысл все хранить в одной репе, когда на проде docker/vagrant/%tool_name% окружение не используется.

По моему мнени, в пользу разделения говорит тот факт, что в теории можно в разных ветках хранить dev и prod конфигурации окружения, соотв не засорять ветки кодовой репы.

Было бы интересно узнать как всё таки правильнее.

Answer 1

[Сергей П]

Правильно - хранить код в одном репозитории.
На проде не требуется даже иметь гит или что там у вас в качестве системы контроля версий.
Нужно настраивать CI/CD так, чтобы в контейнер на прод выкатывались только нужные файлы и каталоги, ничего лишнего.
Очень удобно, когда в девелоперском окружении код работает без докера, но сопутствующие вещи вроде БД и прочих сервисов удобно держать в контейнерах и на девелоперской машине. Так проще развёртывать среду разработки и быстрее вводить сотрудников в процесс. Технически нет особых проблем, чтобы настроить удалённую отладку прямо внутри контейнера. так можно приблизить девелоперское окружение к продовой конфигурации.

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

Храните всё, что нужно для CI/CD в том же репозитории где код. Там же у вас лежат тесты (не нужные в продакте), вспомогательные скрипты, артефакты тулинга и прочее.
Поищите, в гитхабе есть много так называемых "КукиКаттеров". Это инструмент, для шаблонизации проектов на разных стеках. Как правило в созданной по такому шаблону заготовке проекта уже есть всё не обходимое для CI/CD.

Comments

[Roman K]

Окей, а если докер используется не ради докера, а действительно по нужде? Вот у меня прямо сейчас, например, инфра из 30+ разных сервисов на разных языках, разных версиях этих языков, кучей зависимостей, в т.ч. системных, сервисы разрабатывают совершенно разные команды и деплоят в разное время. У кода сервисов (репозиториев), конечно же, разные права доступа. На проде кубер, локально docker-compose. Где прикажете хранить docker-compose.yml? В одном из проектов, чтобы это было максимально неочевидно?

[Алексей Уколов]

Roman Kitaev, ну ясно же написано, что это не единственно верное решение:

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

Но начинать всё же нужно с него, а разделять уже тогда, когда появляется потребность.

[Roman K]

Алексей Уколов, дык самый простейший веб-сервис сегодня уже состоит минимум из двух сервисов: фронтенд (nginx + компилят от реакта) и бэкенд (условный питон). А скорее всего, их будет даже три: nginx + SSR на ноде + бэк. Наверное, на первых порах это можно хранить рядом. Но, мне думается, если проект ориентирован на долгое развитие, то лучше сразу сделать хорошо, чем потом разделять.

[Сергей П]

Roman Kitaev, сразу хорошо вы не угадаете, зато рискуете согрешить преждевременной оптимизацией. Большие вон компании вроде гугла, яндекса, фейсбука двигаются, а кто-то уже приехал, в сторону эпических размеров моно-репозиториев. Это 1 (один) репозиторий на всю компанию. И это не спроста. А вы, как я понял, один продукт хотите заранее заблаговременно распилить на отдельные репозитории по принципу "девопсу - девопсово, девелоперу - девелоперово". Резать имеет смысл по складкам минимальной связности. Обычно линия реза идёт между продуктами. Если продукты связные между собой, то, вон, кто-то в монорепы двигает, кто-то трахается с версионированием, обратной совместимостью, адом циклических зависимостей...

В рамках продукта всё, мне кажется, понятно:
На проде стоит развёрнутый дистрибутив и ничего лишнего.
Если прод размазан по контейнерам, то в контейнерах отдельные куски дистрибутива.
Если прод разлит по кубам, то там тоже свои кусочки и ничего лишнего.
Все исходники (дистрибутивов, CI/CD, докерфайлы, композ-файлы, хелм-файлы, кастомные тулзы, шаблоны, мейк-файлы) лежат в системе контроля версий в одном репозитории продукта или группы связанных продуктов.

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

[Сергей П]

простейший веб-сервис сегодня уже состоит минимум из двух сервисов: фронтенд (nginx + компилят от реакта) и бэкенд (условный питон). А скорее всего, их будет даже три: nginx + SSR на ноде + бэк.

Roman Kitaev, а в чем, собственно, проблема? Каталоги экономите?
Изолированные вещи можно не держать в монорепе, если вам не нужна прям вот свежатинка и API у вас достаточно стабильны. Скажем вы соцсеточку пилите и сделали свою библиотеку ватермаркинга, поскольку у других готовых всех есть один фатальный недостаток. Это изолированный продукт? Если да - то делайте его отдельным продуктом в отдельной репе. А вот конфигурации nginx, юнит-тесты, скрипты деплоя, фикстуры... обычно если вы их отрежете, то проклянёте всё из-за постоянной необходимости держать совместимость и контролировать версии.

[Old Kitty]

Большое спасибо за развернутый ответ!

Проекты у меня небольшие, но поводу этого момента меня терзали смутные сомнения и желание блудливой преждевременной оптимизации.

Answer 2

[Дмитрий]

Dockerfile очень зависит от путей, хранить в другом репозитории неудобно.