Как лучше всего развернуть десятки ресурсов, таких как шаблоны CloudFormation, наборы стека и функции Lambda, с помощью Code Pipeline?
В AWS у меня есть архитектура с несколькими аккаунтами, в которой работает организация AWS. Я хочу, чтобы конвейер работал в одной учетной записи. Этот конвейер будет развертывать шаблоны CloudFormation для одной или нескольких учетных записей в Организации.
На данный момент я нашел следующие варианты:
Создайте этап конвейера или действие для каждого исходного файла. Это работает довольно хорошо, но означает, что каждый раз, когда вы добавляете исходный файл, вам нужно изменять конвейер, что кажется накладными расходами, которые можно автоматизировать или устранить. Вы не можете развернуть StackSets с таким подходом. Вам также понадобится этап для каждого шаблона для каждой учетной записи для развертывания, поэтому это непрактично.
Используйте вложенные стеки. Проблемы с этим: 1) В главном стеке я не знаю, какое соглашение об именах использовать для вызова других стеков непосредственно из CodeCommit. Я мог бы обойти это, если бы CodeBuild скопировал все файлы на S3, но это кажется неэлегантным. 2) Вложенные стеки сложнее отлаживать, так как они разрываются и удаляются в случае сбоя, поэтому трудно найти причину проблемы.
Используйте CodeBuild для запуска сценария bash, который развертывает все шаблоны с помощью интерфейса командной строки AWS.
Попросите CodeBuild запустить Ansible playbook для развертывания всех шаблонов.
Пусть Lambda развернет каждый шаблон после того, как будет вызван CodePipeline. Это, вероятно, не лучший вариант, поскольку каждый вызов Lambda будет для одного шаблона, и не будет информации о том, какую учетную запись следует развернуть. Вариантом может быть одна функция Lambda, которая выполняет все развертывания.
В идеале я бы хотел, чтобы CodePipeline развертывал каждый файл с определенными расширениями в репозитории CodeCommit или, что еще лучше, развертывал то, что указано в файле манифеста. Однако я не думаю, что это возможно.
Я бы предпочел избегать любых технологий или услуг, в которых нет необходимости. Я также предпочел бы не использовать Jenkins, Ansible, Teraform и т. Д., Поскольку этот сценарий можно развернуть на нескольких сайтах клиентов, и я не хочу навязывать им какие-либо сторонние технологии. Если мне нужно использовать стороннюю организацию, я бы предпочел иметь что-то, что может работать в контейнере CodeBuild, чем запускать на экземпляре, таком как Jenkins.
-
Опыт с тех пор, как я задал этот вопрос
Написание скриптов Borne Shell (sh) в CodeBuild - сложный, болезненный и медленный процесс.
При создании или обновлении StackSets должна быть логика. Если вы просто вызовете "create stackset", обновление завершится ошибкой.
Есть причина, по которой конвейер AWS Landing Zone сложен из-за таких вещей, как пошаговые функции.
Если бы существовал простой способ написать логику, например «если этот набор стеков существует, обновите его», все было бы намного проще. ASW CDK - одно из возможных решений этой проблемы, поскольку он позволяет создавать инфраструктуру AWS с использованием Java, .Net, JavaScript или TypeScript. Сторонние инструменты, такие как Teraform и другие, также могут помочь, но я недостаточно знаю о них, чтобы комментировать.
Я собираюсь оставить этот вопрос открытым на тот случай, если кто-то найдет отличный ответ.
-
Информация из службы поддержки AWS
AWS дал следующий совет (я перефразировал его, отфильтровав свое понимание, любые ошибки - мои собственные, а не неправильные советы от AWS):
CodePipeline может развернуть только один артефакт (например, шаблон CloudFormation) на одно действие.
CodePipeline не может напрямую развернуть StackSet, который позволит развертывать шаблоны в разных учетных записях. StackSets можно развернуть, вызвав CodeBuild / Lambda.
CodePipeline можно развернуть в других учетных записях, указав роль в этой другой учетной записи. Это развертывается только в одной учетной записи за раз, поэтому вам потребуется одно действие для каждого шаблона для каждой учетной записи.
CodeBuild, запущенный как часть CodePipeline, работающий в контейнере, дает большую гибкость, вы можете делать здесь все, что вам нравится
CodePipeline может запускать Lambda, что очень гибко. Если вы запускаете Lambda из действия CodePipeline, вы получаете URL-адрес одного ресурса, который может быть ограничивающим. (Я предполагаю) Вы, вероятно, можете вызвать Lambda таким образом, чтобы он мог выполнить все развертывание.
Я бы посмотрел на развертывание всех шаблонов через один Ansible playbook. в playbook.yml у вас может быть много задач, по одной на шаблон CFN, давать каждому шаблону необходимые параметры, передавать выходные данные из одного стека в другой и т. д. Также Ansible идемпотентен, поэтому при повторном запуске playbook он (повторно) развертывает только то, что было изменено.
Все это может быть одним шагом в CodePipeline.
Теперь, как его запустить? CodePipeline может выполнять CodeBuild, CodeDeploy, ECS Task или Elastic Beanstalk. Я бы, вероятно, выбрал CodeBuild с изображением докера Ansible. Почему вы не хотите использовать CodeBuild?
Если вы действительно хотите выполнить развертывание CodePipeline с помощью метода CloudFormation, вы, вероятно, можете создать некоторый настраиваемый ресурс, который выполняет доступную playbook, но это кажется довольно запутанным.
Мой выбор было бы CodePipeline ➜ CodeBuild ➜ Ansible playbook ➜ развертывание множества стеков CloudFormation.
Кстати для отладки сбои вложенных шаблонов вы всегда можете изменить Фильтр в консоли, чтобы Не смогли или Удалено и изучите там события сбойных стеков. Когда они удаляются, они исчезают только из представления по умолчанию, но детали остаются там.
Однако мне не нравятся сложные вложенные шаблоны, мне труднее управлять и обновлять, чем с помощью Ansible.
Надеюсь, это поможет :)