Serverless CI/CD на AWS

Serverless CI/CD на AWS

Было бы круто, если бы развертывание в формате копи-пейст осталось в прошлом, но, увы, дела обстоят иначе. Бывает, разработчикам предпочтительней именно такой метод поставки. Хоть сейчас пиши статью о том, почему это не есть гуд, но вы и без меня все знаете. С тенденцией к бессерверной (serverless) архитектуре пайплайны CI/CD играют важную роль в поставке приложений. Я еще писал о них в статье «3 лучших совета для вашего следующего бессерверного проекта».

Темой CI и CD я интересуюсь давненько, а впервые столкнулся с ней несколько лет назад — благодаря TeamCity. В настоящее время TeamCity по-прежнему используется для большинства наших пайплайнов CI/CD. Работает TeamCity прекрасно, ничего против не имею, но я всегда стремлюсь улучшить работу. Например, было бы хорошо собирать пайплайны в виде кода — это одно из направлений, в которых TeamCity не так хорош.

Инструменты интеграции и поставки на AWS я изучил какое-то время назад, и, хотя мы используем CodeDeploy для другого проекта, который работает на EC2, бессерверный проект я с ними еще не развертывал. Ознакомившись с инструментами повторно, я обратил внимание вот на что: теперь есть встроенная функция интеграции для развертывания CloudFormation и Lambda, предположительно, на основе SAM AWS; мы используем serverless framework, — она генерирует шаблоны CloudFormation, но с инструментами AWS она “из коробки” не работает.

Подготовка

Я использую следующие службы AWS: EC2, Docker, ECR, S3, IAM, CodeBuild, CodePipeline, CloudWatch, CloudTrail. Чтобы не отставать, вам нужно хотя бы на базовом уровне понимать, что делает каждая из этих служб.

В основном я пишу код серверной части в .NET, на эту платформу опирается и данное руководство. Ни один из готовых образов CodeBuild не имеет среды выполнения .NET и NodeJS одновременно (NodeJS нужен для serverless framework). Если ваши функции Lambda написаны в NodeJS, настройка пайплайна развертывания значительно упрощается, ведь это — единственная среда выполнения, необходимая для установки в образе Docker (если случай ваш — смело пропускайте большую часть руководства). На секундочку, это был мой первый опыт знакомства с контейнерами, и я рад узнать что-то новое.

Смею предположить, что ваш код — в неком репозитории, например, git. Для руководства мы просто загрузим в S3 файл, содержащий пакет кода для развертывания; как вы его получите, зависит от вас. Взяв мою работу на основу, вы всегда можете пойти дальше, подключив свой пайплайн к таким репозиториям, как github или CodeCommit.

1. Создайте экземпляр EC2 и установите Docker

Запустите стандартный экземпляр AWS Linux 2 EC2 — это должно быть понятно без пояснений. Войдите в систему и установите Docker с помощью команд:

Еще нужно добавить пользователя ec2 в группу docker, чтобы выполнять команды Docker, не используя sudo:

Когда команда выполнена, выйдите из системы и снова войдите в свой экземпляр EC2, чтобы пользователь ec2 получал новые разрешения. Убедитесь, что пользователь ec2 запускает команды Docker без sudo:

Вывод команды docker info

2. Создайте образ Docker и поместите в ECR

Предположим, предыдущий шаг выполнен успешно; следующий этап — создание образа Docker, который помещается в ECR. AWS предлагает базовые образы для CodeBuild на github, и это упрощает создание собственного образа.

Я также опубликовал образ в github — на случай, если не захотите выполнять следующие действия для создания собственного: https://github.com/effectivedigital/serverless-deployment-image

Скопируйте образы и перейдите в каталог .NET Core 2.1:

Откройте Dockerfile в предпочтительном текстовом редакторе:

Добавьте команды для установки NodeJS и serverless framework в конце других команд, уже имеющихся в Dockerfile. Большинство этих команд я получил из образа NodeJS Docker в том же репозитории AWS:

Теперь собираем и тегируем образ:

Завершив сборку, запустите образ — убедитесь, что все работает, и что serverless framework установлена правильно:

Запуск sls -v внутри новенького контейнера

Затем создаем репозиторий в ECR с помощью AWS CLI. После запуска команды новый репозиторий будет отображаться в консоли AWS:

Ответ AWS CLI на создание репозитория в ECR

Теперь помечаем созданный ранее образ aws/codebuild/dot-net значением repositoryUri из предыдущего этапа:

Выполните команду get-login для получения командной строки аутентификации docker login для реестра контейнеров:

Выполните команду docker login, выданную при выполнении команды get-login во время последнего шага.

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

Docker на EC2 создает наш образ

Образ Docker в ECR

Потом доступ к образу из ECR сможем открыть кому угодно. Разрешение необходимо заблокировать в рабочей среде, но в данном примере мы его откроем. Перейдите на вкладку разрешений в консоли AWS, выберите «Изменить политику JSON» и вставьте в политику следующий элемент:

3. Создайте пайплайн

Настало время собрать пайплайн. Чтобы упростить процесс, сделать его многократно развертываемым и придерживаться трушной формы бессерверной архитектуры, я собрал пайплайн с помощью serverless framework. Того же результата можно добиться путем сборки в CloudFormation.

Не стану копировать весь источник из моего файла serverless.yml file — скопируйте его из github: https://github.com/effectivedigital/serverless-deployment-pipeline

Просмотрите бессерверный шаблон, чтобы точно понять, что он будет делать, но, если вкратце, он настраивает следующие элементы:

• 3 сегмента S3
• 1 политика сегмента
• 3 роли IAM
• 1 проект CodeBuild
• 1 пайплайн CodePipeline
• 1 событие CloudWatch
• 1 след CloudTrail

Потом обновите DockerImageArn для своего образа в ECR. Если хотите создавать пакеты развертывания с именем, отличным от Deployment.zip, то обновите еще и DeploymentFilename:

Вот и все, пайплайн готов к развертыванию. Выполните команду бессерверного развертывания и подождите, пока не настроится:

Созданный serverless framework стек CloudFormation

Созданный serverless framework пайплайн CodePipeline

Созданный serverless framework проект CodeBuild Project

4. Добавьте buildSpec.yml в свое приложение

Когда CodePipeline обнаружит изменение файла развертывания в S3, он сообщит CodeBuild, что нужно запустить и попытаться собрать и развернуть приложение. Тем не менее, CodeBuild должен также знать, какие команды должны выполняться для сборки и развертывания приложения, и buildSpec.yml содержит инструкции, которым будет следовать CodeBuild.

Я создал очень простое приложение «Hello world», включающее пример файла buildSpec.yml, который вы можете использовать: https://github.com/effectivedigital/serverless-deployment-app
Или создайте файл buildSpec.yml в существующих приложениях и заполнить его согласно инструкциям ниже:

5. Проверка пайплайна

Теперь все готово для первого запуска вашего пайплайна. Создайте пакет под названием Deployment.zip, он должен включать все файлы для вашего бессерверного приложения и файл buildSpec.yml.

Через несколько мгновений CloudTrail должен зарегистрировать событие PutObject и активировать правило событий CloudWatch, которое затем активирует запуск CodePipeline.

Deployment.zip загрузился в S3

CodePipeline запущен, сборка пошла

Если мы перейдем к деталям шага AWS CodeBuild, мы сможем увидеть процесс сборки и развертывания:

CodeBuild получит вывод от выполняющего сборку и развертывание образа Docker

Развертывание прошло успешно!

Новое приложение, развернутое нашим пайплайном, также отображается в CloudFormation:

Можно протестировать конечную точку API, созданную в нашем простом приложении (URL находится в выходе CodeBuild или в API Gateway) и убедиться, что приложение успешно работает:

Postman для вызова API

Краткие выводы

CodePipeline позволяет создать масштабируемый, гибкий и недорогой пайплайн CI/CD и помогает в решении некоторых проблем, связанных с традиционными пайплайнами, созданными на серверах.
Я хотел бы пойти дальше и добавить в смесь модульное тестирование после развертывания, но тема заслуживает отдельной статьи — и это повод читать нас в будущем!

Шаг 1. Определите, что мотивирует вас изучать Python

Прежде чем вы начнете изучать Python онлайн, стоит спросить себя, почему вы хотите его изучать. Это потому, что это будет долгий и иногда болезненный путь. Без достаточной мотивации вы, вероятно, не справитесь. Например, мы проспали уроки программирования в средней школе и колледже, когда нам нужно было запоминать синтаксис, а у нас не было мотивации. С другой стороны, когда нам нужно было использовать Python для создания веб-сайта для автоматической оценки эссе, мы не спали ночами, чтобы закончить его.

Выяснение того, что вас мотивирует, поможет вам определить конечную цель и путь, который приведет вас к ней без скуки. Вам не нужно раздумывать точный проект, просто общая область, которая вас интересует, когда вы готовитесь к изучению Python.

Выберите интересующую вас область, например:

• Наука о данных/машинное обучение
• Мобильные приложения
• Сайты
• Игры
• Обработка и анализ данных
• Оборудование/датчики/роботы
• Скрипты для автоматизации вашей работы

Определите одну или две области, которые вас интересуют, и вы готовы придерживаться их. Вы будете направлять свое обучение на них и в конечном итоге будете строить в них проекты.