В течение последних нескольких лет во многих проектах, над которыми я работал, использовался TeamCity для CI / CD, однако в последнее время я решил создавать новые конвейеры CI / CD с использованием AWS Code Pipeline. В рамках некоторых других изменений в одном из проектов, над которыми я работал, я решил, что нам также следует перенести этот конвейер с TeamCity на CodePipeline.

TeamCity - отличный инструмент, но я перенес проекты из TeamCity в CodePipeline по нескольким причинам:

  • Нам приходилось управлять базовыми серверами EC2, поддерживая актуальность зависимостей и общность между серверами, что стало болезненным.
  • Серверы TeamCity начали становиться узкими местами в наших процессах развертывания по мере увеличения количества проектов.
  • Отсутствует система шаблонов для TeamCity, что затрудняет повторное развертывание конвейеров между этапами. Графический интерфейс требовал слишком большого количества щелчков мышью, что могло привести к человеческой ошибке.

На диаграмме ниже в общих чертах показано, как выглядел предыдущий процесс развертывания; он разделен на два основных компонента - наш бессерверный бэкэнд, построенный на API Gateway и Lambda, и интерфейс, построенный с помощью комбинации .NET MVC и React, который работает на EC2. После того, как TeamCity скомпилировала наш код для серверной части и внешнего интерфейса, CloudFormation выполняет оркестровку развертывания наших API-интерфейсов и внутреннего интерфейса лямбда-функций, а CodeDeploy обрабатывает интерфейс .NET.

В то время как CodePipeline берет на себя оркестровку всего процесса, CodeBuild является основным сервисом, который взял на себя основную часть работы, которую выполняла TeamCity. Одна интересная особенность этапов CodePipeline заключается в том, что несколько действий на этапе могут выполняться параллельно, что помогает сократить общее время, необходимое для выполнения вашего конвейера.

После небольшого количества проб и ошибок наш конвейер теперь выглядит примерно так, как показано ниже (мы также пробрались через миграцию GitHub из внутреннего репозитория).

Вы можете подумать, где же здесь могут быть межрегиональные действия и зачем кому-то их использовать? В случае этого проекта целевая клиентская база - австралийская, поэтому все ресурсы развернуты в ap-southeast-2 - имеет смысл использовать CodePipeline и в ap-southeast-2. Помните, я упоминал, что интерфейс - это приложение .NET MVC? Одна маленькая деталь, которую я упустил, - это платформа .NET Framework, а не .NET Core. Это означает, что мне нужно было использовать образ Windows Docker на CodeBuild, который на момент написания статьи недоступен в ap-southeast-2. Чтобы обойти эту проблему, на помощь приходят межрегиональные действия!

Межрегиональные действия позволяют CodePipeline выполнять действия в разных регионах, где находится ваш конвейер. Если вы пройдете через мастер в Консоли AWS, вы заметите, что на этапах сборки и развертывания у вас есть возможность выбрать не только поставщика развертывания, но и регион, в котором вы хотите выполнить это действие. Полезно в моем случае, когда мне нужно использовать функцию в CodeBuild, которая недоступна в моем регионе, но также может использоваться для параллельного развертывания в нескольких регионах.

Попробуем!

Во-первых, нам нужны сервисы, с которыми будет взаимодействовать CodePipeline. Поскольку наш конвейер развертывания будет содержать три основных компонента; источник, сборка и развертывание, нам нужно будет убедиться, что у нас есть:

  1. Репозиторий GitHub или CodeCommit или корзина S3, настроенная с помощью нашего кода
  2. Проект CodeBuild в другом регионе, чем наш Pipeline
  3. Приложение и группа CodeDeploy настроены - вам также нужно будет куда-то развернуться!

CodeBuild

Пока я собираюсь создать свой общий конвейер в Сиднее, мой проект CodeBuild будет создан в Северной Вирджинии, чтобы я мог использовать образы Windows. Если вы никогда раньше не изучали CodeBuild, он основан на Docker и может использовать либо готовые образы Docker, либо создавать свои собственные через ECR. Об этом стоит прочитать перед тем, как начать.

Ваша конфигурация для среды должна выглядеть примерно так, как показано ниже, все остальное должно быть довольно простым, но убедитесь, что вы не выбрали артефакты ввода или вывода, поскольку CodePipeline поможет в этом. Также не забудьте заполнить buildspec некоторыми командами (подойдет даже простое эхо).

CodeDeploy

После того, как CodeBuild завершит сборку моего приложения, мы можем вывести его артефакт сборки (скомпилированный код) в виде пакета, который будет использоваться CodeDeploy. CodeDeploy - отличный способ организовать изменения в вашем приложении либо путем постепенного развертывания, либо путем выполнения сине-зеленых обновлений.

Хотя CodeDeploy теперь поддерживает множество различных целевых сервисов, я собираюсь использовать EC2 в качестве целевого для моего приложения и группы. При развертывании в EC2 необходимо будет включить файл appspec, чтобы предоставить CodeDeploy инструкции по управлению развертыванием.

Первая часть настройки CodeDeploy - это настройка приложения. Поскольку это всего лишь пример, я назову его TestApplication, но вы можете назвать его в честь приложения или службы, работающей в этой конкретной инфраструктуре.

Далее нам нужно создать группу развертывания. Группа развертывания содержит параметры и конфигурации, которые в случае развертывания EC2 связаны с поиском экземпляров, в которых должно быть развернуто приложение, которые также могут быть нацелены на группы автомасштабирования и позволяют подключаться к вашему балансировщику нагрузки для обеспечения непрерывности на протяжении всего процесса. развертывание.

CodePipeline

Все будет объединено с помощью CodePipeline, который на высоком уровне является оркестратором CodeBuild, CodeDeploy и многих других сервисов. Конфигурация конвейеров может быть несколько стадий; т.е. источник, сборка, тестирование, утверждение, развертывание, и каждый этап может содержать несколько действий, поэтому вы можете выполнять сборки параллельно для нескольких частей вашего приложения, если это необходимо.

Этот пример конвейера будет намного проще и будет состоять всего из трех этапов (исходный код, сборка, развертывание) с одним действием на каждом.

Начните с создания конвейера, предоставления ему некоторой базовой информации и настройки исходного кода.

Следующие два шага позволят вам добавить этап сборки и развертывания - вы можете пропустить любой из них, но необходимо настроить как минимум один этап сборки или развертывания. Поскольку мы собираемся использовать уже существующий проект CodeBuild, который мы создали ранее, выберите регион, в котором он был создан (в моем случае, Северная Вирджиния), и проект.

А теперь перейдем к стадии развертывания, вернемся для этого в Сидней, но мы также можем выбрать развертывание в CodeDeploy в разных регионах, если захотим.

После просмотра и создания конвейера будет предпринята первая попытка пройти весь конвейер. Предполагая, что ваш источник, buildspec и appspec настроены правильно - и ваш код готов к сборке - процесс должен быть успешным. В противном случае и CodeBuild, и CodeDeploy содержат подробное ведение журнала, которое позволяет детализировать, какая ошибка могла возникнуть.

За кулисами

За кулисами, в дополнение к роли IAM и конвейеру, также были созданы два сегмента S3, один в регионе, в котором в основном работает ваш конвейер, а другой в регионе, где живет действие сборки - ваши артефакты сборки затем реплицируются между этими S3 ведра для вас.

Глядя на YML нашего конвейера (если бы вы создавали его с помощью CloudFormation), теперь есть ссылки на регион, в котором находятся различные компоненты вашего конвейера, если он находится за пределами региона по умолчанию.

Заключение

Межрегиональные конвейеры отлично подходят для таких крайних случаев или для помощи в развертывании в нескольких регионах с помощью одного конвейера. Они могут быть немного неудобными, поскольку я обнаружил, что не все входы и выходы подробно документированы, но при небольшом настойчивости это сработает.

Если вы хотите глубже погрузиться в развертывание конвейера с использованием кода, я загрузил набор шаблонов, созданных на бессерверной платформе, в GitHub. Их можно легко преобразовать в собственный CloudFormation, если вы не хотите использовать бессерверную структуру.