Мы растем как компания, наши продукты расширяются, а также расширяются наши действия и усилия, связанные с DevOps - мы перешли с Bamboo на более гибкий и настраиваемый Jenkins, используя конвейеры развертывания и другие плагины; переключился на Ansible и начал использовать Docker тут и там внутри.
Все эти вещи требуют некоторого уровня кодирования или конфигурации - скрипты Ansible и конфиги, скрипты Jenkins groovy, конфиги Dockerfiles и YAML.
В настоящее время, мы создали отдельные «опа» репозиторий с каталогами высокого уровня для jenkins, ansible, dockerи other(что это страшное название, но сейчас все автоматизации «другие» DevOps есть).
Наш подход не выглядит правильным и может не масштабироваться, но каковы наилучшие практики и рекомендации для сохранения кода, связанного с DevOps, в репозитории или репозиториях кода?
Ответы:
Текущая организация кода и конфигурации, которую вы описываете, структурирована с помощью технических решений. Это плохой дизайн, который добавит много накладных расходов на нашу деятельность по обслуживанию и добавит много ловушек на нашем пути. Вместо этого эта организация должна быть построена вокруг артефактов, которые мы разворачиваем.
Причина этого заключается в том, что мы хотим рассматривать артефакты ( например, образ докера или программный пакет) как объекты следующих глаголов:
рассмотреть минимальный набор автоматизированных задач, которые мы хотим выполнить. Если мы хотим что-то изменить в том, как реализован тестовый глагол, легко посетить папку, соответствующую этому артефакту, в соответствующем репозитории, а затем обнаружить специфичные для jenkins элементы автоматизации, которые необходимо обновить. Вместо этого, если рецепты автоматизации структурированы вокруг технических решений, то нам нужно выяснить, что Дженкинс участвует в процедурах тестирования, и найти там элементы автоматизации, связанные с артефактами. В сложных ситуациях организация вокруг технических решений делает обновления очень трудными, потому что мы должны априори знать все технические решения, вовлеченные в некоторую услугу, чтобы обновить их соответственно.
Например, репозиторий, содержащий код для веб-сайта и микросервис «а», может иметь следующие подкаталоги, предназначенные для операций:
каждый из которых имеет три сценария называется
build,testиdeploy. Теперь, когда организация элементов автоматизации как-то прояснена, давайте обратим наше внимание на конфигурацию.Основные условия и требования к организации конфигурации устанавливаются
deployглаголом при применении к сервисоподобному артефакту.deployГлагол должен иметь следующие параметры:С оперативной точки зрения эта разбивка параметризации соответствует естественным степеням свободы проблемы развертывания - помимо учетных данных, которые могут быть связаны с конфигурацией времени выполнения, но лучше разделить их, чтобы избежать их небрежного распространения.
источник
Я могу ответить на вопрос о docker, одна из лучших практик использования docker - хранить файл docker и файлы compose в одном и том же хранилище проекта, поэтому, где бы вы ни клонировали проект, вы можете создать образ docker, и это хорошо для например, сохраните несколько версий файлов составления Docker (prod, staging, dev), чтобы вы могли создать образ и запустить контейнер с определенной опцией для каждого env, например, для машины dev вы можете использовать определенную сеть и запускать контейнер дополнительных зависимостей или любой другой.
источник
Код каждого инструмента идет в свой репо. например
Это поможет вам лучше масштабироваться с точки зрения управления процессами и поддержки различных веток для каждой среды
Это даст вам более детальный контроль и перегрузит все ваши издержки управления версиями в системы контроля версий. Также создайте отдельные ветви для каждой среды и пометьте код для каждого производственного выпуска (как мы делаем для базы кода приложения). Думайте Инфра и обрабатывайте в терминах кода. (Любое изменение в процессе должно быть кодифицировано и отправлено в QA, SIT, UAT, а затем в PROD) аналогично приложению.
Например, у вас может быть V2.1 Ansible, работающий в Production (основная ветка), но V2.0 Docker-контейнеров, работающий в Prod (главная ветка)
Точно так же храните ваши скрипты БД / скрипты bash в своих собственных репозиториях, и, возможно, вы можете настроить файл проверки работоспособности (JSON / YAML) для отображения версий всех инструментов / частей в каждом развернутом URL-адресе для целей отслеживания и автоматизации. (Так что ваши webhooks читает URL и автоматизирует развертывания)
источник
Различение между Ops, Dev и DevOps способствует изоляции и формирует мышление «брось через стену». Для расширения сотрудничества между командами необходимо поместить в репозиторий все необходимое для сборки и развертывания проекта.
Сказав это, ответ на вопрос:
в том, что если для запуска проекта требуется config, его следует поместить в тот же каталог.
источник