Должен ли код инфраструктуры храниться в том же хранилище, что и код приложения?

Question

Я настраиваю инфраструктуру для поддержки WebApp. В одном из моих репозиториев есть вся сетевая инфраструктура (VPC, подсети, NAT, Bastion и т. Д.). В WebApp есть Route 53 + ALB + AutoScalling Group + EC2 Instances. Все они были закодированы в шаблонах Cloudformation. Мой вопрос заключается в том, должны ли шаблоны WebApp Cloudformation храниться в том же хранилище, что и приложение? Есть ли лучший метод разделения инфраструктуры и кода приложения?

Answer 1

As a general rule you should keep your infrastructure next to the application code. So, yes you should have it in the same repository.

Of course you might be in the case in which some resources are shared between different projects. In this case I suggest you to have a separate repository containing only the shared piece of infrastructure. What I would do here would be the following:

• one repository for shared infrastructure: VPC, public and private subnets, dns root zones.
• one repository with your webapp and its relative infrastructure.

This gives you the benefit to implement pipelines that build artifacts and apply new infrastructure at the same time.

Answer 2

Это действительно вопрос мнения, но я думаю, что тенденция состоит в том, чтобы все необходимое для вашего приложения / службы оставалось вместе с кодом. С учетом сказанного, у вас часто будут общие вещи (например, VPC), которые часто оказываются в отдельном репо (в зависимости от того, как вы организуете свой код; в наши дни, похоже, есть толчок к монорепозиториям).

CloudFormation Best Practices содержит полезную информацию об организации ваших стеков, но не отвечает на ваш вопрос.

Answer 3

Предлагаю следующую пищу для размышлений:

Кажется, что естественным прогрессом было бы включение кода IaC, и по мере роста проекта вы разделяете его, когда сталкиваетесь с такими препятствиями, как:

• Развернутый проект теперь включает несколько исходных проектов/репозиториев.
• Защита/предотвращение случайных изменений кода IaC в зависимости от того, у кого есть доступ к репозиторию.
• Желательна чистая история коммитов для наблюдения за изменениями в инфраструктуре и развертываниях.

Я лично предпочитаю идти по пути наименьшего сопротивления при работе над чем-то — когда это один разработчик, и вы быстро создаете прототип для проверки концепции, безусловно, есть преимущества, когда ваши файлы TF и ​​конвейеры ci-cd находятся в одном месте. Как только вы поделитесь своей кодовой базой и вступят в силу более строгие стандарты, наступит время усовершенствовать ваши стандарты.

В зависимости от вашего опыта и от того, знаете ли вы, что проекту в конечном итоге это понадобится, может иметь смысл включить множество лучших практик с самого начала (агрегированное ведение журналов, SAST/DAST, линтинг кода и опубликованные рекомендации по вкладу). Но если вы все еще впервые знакомитесь со всеми этими концепциями, вероятно, имеет смысл подождать, пока они не станут проблемой. Вид технического долга против YAGNI.