Pull to refresh
69.96
Слёрм
Учебный центр для тех, кто работает в IT

Serverless CI/CD на AWS

Reading time 7 min
Views 7.6K
Original author: Gavin Lewis



Было бы круто, если бы развертывание в формате копи-пейст осталось в прошлом, но, увы, дела обстоят иначе. Бывает, разработчикам предпочтительней именно такой метод поставки. Хоть сейчас пиши статью о том, почему это не есть гуд, но вы и без меня все знаете. С тенденцией к бессерверной (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 с помощью команд:


sudo yum update -y
sudo amazon-linux-extras install docker
sudo service docker start

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


sudo usermod -a -G docker ec2-user

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


docker info


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


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


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


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


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


git clone https://github.com/aws/aws-codebuild-docker-images.git
cd aws-codebuild-docker-images
cd ubuntu/dot-net/core-2.1/

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


nano Dockerfile

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


# Install Node Dependencies
ENV NODE_VERSION="10.14.1"
# gpg keys listed at https://github.com/nodejs/node#release-team
RUN set -ex \
 && for key in \
 94AE36675C464D64BAFA68DD7434390BDBE9B9C5 \
 B9AE9905FFD7803F25714661B63B535A4C206CA9 \
 77984A986EBC2AA786BC0F66B01FBB92821C587A \
 56730D5401028683275BD23C23EFEFE93C4CFFFE \
 71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 \
 FD3A5288F042B6850C66B31F09FE44734EB7990E \
 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 \
 C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 \
 DD8F2338BAE7501E3DD5AC78C273792F7D83545D \
 4ED778F539E3634C779C87C6D7062848A1AB005C \
 A48C2BEE680E841632CD4E44F07496B3EB3C1762 \
 ; do \
 gpg - keyserver hkp://p80.pool.sks-keyservers.net:80 - recv-keys "$key" || \
 gpg - keyserver hkp://ipv4.pool.sks-keyservers.net - recv-keys "$key" || \
 gpg - keyserver hkp://pgp.mit.edu:80 - recv-keys "$key" ; \
 done
RUN set -ex \
 && wget "https://nodejs.org/download/release/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.gz" -O node-v$NODE_VER$
 && wget "https://nodejs.org/download/release/v$NODE_VERSION/SHASUMS256.txt.asc" -O SHASUMS256.txt.asc \
 && gpg - batch - decrypt - output SHASUMS256.txt SHASUMS256.txt.asc \
 && grep " node-v$NODE_VERSION-linux-x64.tar.gz\$" SHASUMS256.txt | sha256sum -c - \
 && tar -xzf "node-v$NODE_VERSION-linux-x64.tar.gz" -C /usr/local - strip-components=1 \
 && rm "node-v$NODE_VERSION-linux-x64.tar.gz" SHASUMS256.txt.asc SHASUMS256.txt \
 && ln -s /usr/local/bin/node /usr/local/bin/nodejs \
 && rm -fr /var/lib/apt/lists/* /tmp/* /var/tmp/*
RUN npm set unsafe-perm true
CMD [ "node" ]
# Install Serverless Framework
RUN set -ex \
 && npm install -g serverless

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


docker build -t aws/codebuild/dot-net .

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


docker run -it --entrypoint sh aws/codebuild/dot-net -c bash
sls -v


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


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


aws ecr create-repository --repository-name codebuild-dotnet-node


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



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


docker tag aws/codebuild/dot-net <ACCOUNTID>.dkr.ecr.ap-southeast-2.amazonaws.com/codebuild-dotnet-node

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


aws ecr get-login --no-include-email


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


docker login -u AWS -p eyJwYXlsb2FkIjoiNGZnd0dSaXM1L2svWWRLMmhJT1c0WWpOZEcxamJFeFJOK2VvT0Y5[...] https://<ACCOUNTID>.dkr.ecr.ap-southeast-2.amazonaws.com

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


docker push <ACCOUNTID>.dkr.ecr.ap-southeast-2.amazonaws.com/codebuild-dotnet-node


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



Образ Docker в ECR


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


{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "EnableAccountAccess",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:DescribeImages",
        "ecr:DescribeRepositories",
        "ecr:GetAuthorizationToken",
        "ecr:GetDownloadUrlForLayer",
        "ecr:GetRepositoryPolicy",
        "ecr:ListImages"
      ]
    }
  ]
}

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:


DockerImageArn: <ACCOUNTID>.dkr.ecr.ap-southeast-2.amazonaws.com/codebuild-dotnet-node:latest
DeploymentFilename: Deployment.zip

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


sls deploy -v


Созданный 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 в существующих приложениях и заполнить его согласно инструкциям ниже:


version: 0.2
phases:
  pre_build:
    commands:
      - chmod a+x *
  build:
    commands:
      - ./build.sh
  post_build:
    commands:
      - sls deploy -v -s $STAGE

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 и помогает в решении некоторых проблем, связанных с традиционными пайплайнами, созданными на серверах.
Я хотел бы пойти дальше и добавить в смесь модульное тестирование после развертывания, но тема заслуживает отдельной статьи — и это повод читать нас в будущем!

Tags:
Hubs:
+14
Comments 4
Comments Comments 4

Articles

Information

Website
slurm.io
Registered
Founded
Employees
51–100 employees
Location
Россия
Representative
Антон Скобин