AWS CodePipeline - как развернуть десятки ресурсов CloudFormation / Stackset / Lambda, не создавая вручную действие конвейера для файла

Каков наилучший способ развертывания десятков ресурсов, таких как шаблоны CloudFormation, наборы стеков и функции Lambda, с использованием Code Pipeline?

В AWS я использую архитектуру с несколькими учетными записями под управлением AWS Organization. Я хочу, чтобы конвейер работал в одной учетной записи. Этот конвейер будет развертывать шаблоны CloudFormation для одной или нескольких учетных записей в Организации.

Варианты, которые я нашел до сих пор:

• Есть этап конвейера или действие для каждого исходного файла. Это работает довольно хорошо, но означает, что каждый раз, когда вы добавляете исходный файл, вам нужно изменить свой конвейер, что выглядит как издержки, которые можно автоматизировать или устранить. Вы не можете развернуть Stack Sets с таким подходом. Кроме того, для развертывания требуется этап для каждого аккаунта, так что это нецелесообразно.

• Используйте вложенные стеки. Проблемы с этим: 1) Внутри мастер-стека я не знаю, какое соглашение об именах использовать для вызова других стеков напрямую из CodeCommit. Я мог бы обойти это, если бы CodeBuild скопировал все файлы на S3, но это кажется не элегантным. 2) Вложенные стеки труднее отлаживать, так как они разрушаются и удаляются в случае сбоя, поэтому трудно найти причину проблемы

• Попросите CodeBuild запустить скрипт bash, который развертывает все шаблоны с помощью интерфейса командной строки AWS.

• Пусть CodeBuild запустит Ansible playbook, чтобы развернуть все шаблоны.

• Пусть Lambda развернет каждый шаблон после его вызова CodePipeline. Это, вероятно, не лучший вариант, так как каждый вызов Lambda будет для одного шаблона, и не будет информации о том, на какую учетную запись развертывать. Отдельная лямбда-функция, которая выполняет все развертывания, может быть вариантом.

В идеале я хотел бы, чтобы CodePipeline развернул каждый файл с определенными расширениями в репозитории CodeCommit, или даже лучше развернул то, что указано в файле манифеста. Однако я не думаю, что это возможно.

Я бы предпочел избегать любых технологий или услуг, которые не нужны. Я также предпочел бы не использовать Jenkins, Ansible, Teraform и т. Д., Поскольку этот сценарий может быть развернут на нескольких сайтах клиентов, и я не хочу навязывать им какие-либо сторонние технологии. Если мне придется использовать стороннее приложение, я предпочел бы иметь что-то, что может работать в контейнере CodeBuild, чем запускаться в экземпляре, таком как Jenkins.

-

Опыт, так как я задал этот вопрос

• Написание сценариев Borne Shell (sh) в CodeBuild является сложным, болезненным и медленным.

• Должна быть некоторая логика вокруг создания или обновления StackSets. Если вы просто позвоните "создать стек", произойдет сбой при обновлении.

• Существует причина, по которой конвейер зоны приземления AWS является сложным и использует такие вещи, как пошаговые функции.

• Если бы существовал простой способ написания логики, такой как "если этот стек существует, то обновите его", все было бы намного проще. 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 таким образом, чтобы он мог выполнять все развертывание.