Как использовать общие службы для развертывания кода из стадии разработки в продакшн
Конвейеры с перекрестными учетными записями - довольно распространенный сценарий, рекомендованный AWS среди других в качестве передового опыта, но полную документацию о том, как это сделать с помощью CDK Pipelines, найти было невозможно. Итак, вот оно ...
Сценарий
Я использую AWS CDK для разработки и развертывания инфраструктуры и приложений в предпроизводственной и производственной средах. В частности, это:
- Учетная запись Dev (номер учетной записи: 111111111111), где код находится в репозиториях CodeCommit и где развернут код разработки. Разработчики имеют (почти) полный доступ к учетной записи и могут управлять кодом и развертывать приложения.
- Учетная запись UAT (Staging) (222222222222) - производственная среда, используемая для приемочного тестирования бизнеса. Инфра-команда управляет средой, разработчики имеют ограниченный доступ для устранения неполадок и тестирования.
- Аккаунт Prod (333333333333), очевидно, для производственного развертывания. Разработчики могут просматривать журналы и не более того.
- Учетная запись Tools (Shared Services) (444444444444), где CodePipeline будет использоваться для сборки и развертывания в Dev, UAT и Prod. Разработчики имеют ограниченный доступ для устранения неполадок и тестирования, а также могут просматривать конвейеры, но не управлять ими.
Вы можете ознакомиться с теорией, лежащей в основе этого, и о том, как настроить без использования CDK, в этом сообщении в блоге AWS.
Обратите внимание, что это то, что вы можете настроить для обучения и тестирования. Аккаунты в AWS ничего не стоят, поэтому настроить их все не составит труда. Если для вас это что-то новенькое, я бы также порекомендовал создать их в организации, как это и будет происходить в реальном мире.
В моем случае я запускаю три разных конвейера, по одному для каждой среды, и это то, что настраивают шаблоны. Также можно развернуть каждую среду как отдельные этапы из единого конвейера, если это лучше для вашего рабочего процесса - и при необходимости будет легко изменить шаблоны и процесс, указанные ниже.
Я использую Javascript для разработки CDK, но подготовительные части этой статьи актуальны для Python, Typescript и любых других языков, поддерживаемых CDK.
Подготовка учетной записи CDK
По различным причинам организации / безопасности часто невозможно использовать CDK для развертывания непосредственно в среде prod или pre-prod. Это обычное ограничение, особенно в производстве. Вместо этого нам нужно использовать CloudFormation для начальной загрузки сред. Даже если вы можете выполнить развертывание напрямую с помощью развертывания CDK, подготовка нескольких сред с использованием одного шаблона CloudFormation будет быстрее.
Каким бы способом это ни было сделано, мы должны использовать Синтез стека стилей по умолчанию для начальной загрузки CDK (а не устаревшую версию, которая используется по умолчанию). Перейдите по ссылке и настройте свою среду для использования нового синтеза стека - проще всего добавить флаг функции в cdk.json. Это необходимо для конвейеров CDK и позволяет развертывать системы с несколькими учетными записями.
Есть два других требования для CDK Bootstrap, которые не очевидны в документации AWS:
- Нам нужно указать любые другие учетные записи, которые будут развернуты в учетной записи, которую мы загружаем. В нашем случае это означает, что наша Учетная запись общих служб должна быть указана для всех остальных.
- Мы должны указать политику, которая будет прикреплена к роли выполнения CloudFormation, переданной в CloudFormation с помощью CodePipeline. В нашем случае мы собираемся использовать управляемую политику доступа администратора. Можно ввести более строгие ограничения, но это будет зависеть от того, что вы развертываете, и здесь я сохраню простоту.
Начальная загрузка с использованием командной строки CDK
Для начальной загрузки с помощью командной строки CDK (обратите внимание, если вы использовали флаг функции cdk.json для включения синтеза нового стека стека, тогда вам необходимо запустить команду из того же каталога, что и файл cdk.json):
cdk bootstrap 111111111111/ap-southeast-1 --no-bootstrap-customer-key --cloudformation-execution-policies 'arn:aws:iam::aws:policy/AdministratorAccess' --trust 444444444444 --trust-for-lookup 444444444444
Где 111111111111/ap-southeast-1 - это учетная запись (и регион), в которой вы выполняете развертывание, а --trust 444444444444 - ваша учетная запись в Инструментах. Обратите внимание, что здесь используется формат Bootstrap v6 с опцией trust-for-lookup. Обновите загрузочные среды до CDK v1.109 или выше, чтобы включить его.
Начальная загрузка с использованием CloudFormation
Если вы хотите выполнить развертывание с использованием CloudFormation, добавьте следующий флаг в указанную выше команду для экспорта шаблона:
--show-template > bootstrap-template.yamlИли, как я лично предпочитаю для сред разработки, просто используйте шаблон CloudFormation здесь и выполняйте развертывание, как вы обычно развертываете CloudFormation, обновляя следующие параметры:
- TrustedAccounts: номер учетной записи вашей учетной записи Tools.
- CloudFormationExecutionPolicies: arn: aws: iam :: aws: policy / AdministratorAccess
- Оставьте все остальное по умолчанию
Убедитесь, что вы назвали стек CloudFormation «CDKToolkit». Его можно переименовать, но вы сэкономите много времени, если воспользуетесь значением по умолчанию.
Bootstrap должен выполняться во всех четырех учетных записях.
Затем нам нужно подготовить учетные записи Dev и Tools с переадресацией событий и ролями между аккаунтами.
Подготовка кросс-аккаунта
Весь этот раздел можно пропустить, если вы используете GitHub или какой-либо другой внешний источник управления. Это требуется только при использовании CodeCommit и только в том случае, если CodeCommit находится в отдельной учетной записи для конвейера. Но в этом суть этой статьи, поскольку по ней я не смог найти никакой документации, так что поехали ...
Фаза сборки CodePipeline (с использованием CodeBuild) примет роль в учетной записи Dev для доступа к CodeCommit. Поскольку на этом этапе CodeBuild также потребуется доступ к сегментам S3 в учетной записи Tools, для роли в Dev также необходим доступ к сегментам и ключу KMS в инструментах.
Это может сбивать с толку, поэтому я объясню еще раз по-другому. CodeBuild может принимать только одну роль на этапе сборки. В течение этого времени ему необходимо получить доступ к коду в CodeCommit (учетная запись Dev) и сохранить все созданные активы в сегментах S3 в учетной записи конвейера (учетная запись Tools). Предполагаемая роль должна уметь делать и то, и другое.
Чтобы сделать его немного более сложным, роли требуется доступ к сегментам, которые создаются конвейерами CDK в инструментах, а конвейерам CDK требуется доступ к роли в разработке, иначе создание конвейера не удастся. Круговая зависимость, что всегда весело.
Кроме того, мы хотим, чтобы обновления кода в CodeCommit в Dev запускали CodePipeline в Tools. Это достигается за счет настройки пересылки событий в Dev и разрешения приема этих событий в Tools.
Чтобы обойти зависимости, я делаю следующее:
- Сначала запустите подготовительный стек инструментов, чтобы разрешить пересылку событий.
- Затем запустите стек подготовки разработчика, создав роль, но не включая политики корзины.
- Создайте конвейер (ы) с помощью развертывания CDK или CloudFormation (см. Ниже).
- Снова запустите стек подготовки разработчика, добавив сегменты и ключи, созданные на шаге 3, и создав политику.
Приведенные ниже подготовительные шаблоны предназначены для отдельных конвейеров для Dev, UAT и Prod. Если вы развернете их все сразу, то все, что вам нужно, - это вышеперечисленное. Если вы развертываете их отдельно, вам нужно будет повторить шаги 3 и 4 для каждого дополнительного конвейера, который вы добавите позже.
Если есть лучший способ, я бы хотел его услышать, но на данный момент он работает и нужен только как часть настройки.
Собирая все это вместе, мы получаем:
Создание конвейеров
К счастью, остальную тяжелую работу берет на себя компания CDK Pipelines.
Я не буду вдаваться в подробности, так как это можно найти в нескольких местах - это хорошее место для начала.
Или вы можете схитрить и клонировать мою рабочую демонстрацию здесь.
Надеюсь, что это поможет вам всем, оставьте комментарий, если у вас есть какие-либо вопросы или предложения.
Об авторе
Марк - ветеран ИТ-индустрии более 20 лет, обладающий техническими знаниями и предпринимательским опытом в различных областях. Уже много лет он страстно увлечен AWS и имеет сертификаты, в том числе Solution Architect Professional и Advanced Networking Specialty. Он хочет, чтобы вы знали, что он эксперт по инфраструктуре и архитектуре, который пишет код, а не профессиональный разработчик программного обеспечения - на случай, если вы заметите что-то странное.
Последние несколько лет Марк проработал в банковской сфере, где в настоящее время создает и возглавляет команду, ориентированную на использование бессерверных технологий AWS для снижения затрат и ускорения вывода на рынок новых услуг и продуктов.
Отметить также можно на:
GitHub - https://github.com/markilott
LinkedIn - https://www.linkedin.com/in/markilott/
Twitter - https://twitter.com/mark_ilott
Больше контента на plainenglish.io
