Проекты на AWS

Разработка современного интернет‑приложения

Развертывание интернет‑приложения, подключение к базе данных и анализ поведения пользователей

Модуль 2. Размещение приложения на веб-сервере

В этом модуле вы создадите новый микросервис, размещаемый с помощью AWS Fargate.  

Обзор

В этом модуле вы создадите новый микросервис, размещаемый с помощью AWS Fargate, для обеспечения интеграции вашего веб-сайта Mythical Mysfits с сервером приложения.

AWS Fargate – это функция развертывания в Amazon Elastic Container Service (ECS), позволяющая развертывать контейнеры, не управляя кластерами или серверами. Для сервера нашего сайта Mythical Mysfits мы будем использовать Python и создадим приложение Flask в контейнере Docker на базе Network Load Balancer. Так мы сможем создать сервер микросервиса для интерфейса веб-сайта.

Почему мы выбрали Fargate?

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

Кроме Fargate, клиенты также могут использовать для вычислений AWS Lambda. Хотя Lambda – такой же бессерверный продукт, как Fargate, он отлично подходит для приложений, управляемых данными, которые должны в режиме реального времени реагировать на изменения в данных, состоянии системы либо на действия пользователей. Мы поговорим о Lambda подробнее в пятом модуле, когда будем использовать этот продукт для анализа поведения клиентов на сайте.

Инструкции по внедрению

Чтобы создать сервис с помощью AWS Fargate, выполните пошаговую инструкцию ниже. Из-за большого объема мы разделили этот модуль на три подмодуля. В модуле 2a вы настроите базовую инфраструктуру для развертывания сервиса. В модуле 2b вы развернете сервис с помощью AWS Fargate. И, наконец, в модуле 2c вы настроите автоматическое развертывание с помощью сервисов AWS Code.

Модуль 2A. Настройка базовой инфраструктуры

Прежде чем создать сервис, сначала необходимо создать базовую инфраструктурную среду, включающую сетевую инфраструктуру в Amazon VPC и роли AWS Identity and Access Management, которые определят разрешения для контейнеров ECS и наших контейнеров на базе сервисов AWS.

Для этого мы будем использовать AWS CloudFormation. AWS CloudFormation – это сервис, который с помощью программных средствам предоставляет ресурсы AWS, указанные вами в файлах JSON или YAML (также известных как шаблоны CloudFormation), обеспечивая передовое использование инфраструктуры как кода.  

  • Мы предоставили шаблон CloudFormation для создания всех необходимых ресурсов для сети и обеспечения безопасности: /module-2/cfn/core.yml. Шаблон позволит создать указанные ниже ресурсы.

    • Amazon VPC: сетевая среда, в которую входят четыре подсети (две публичные и две частные) в частном IP-пространстве 10.0.0.0/16, а также все необходимые конфигурации таблицы маршрутизации. Подсети для этой сети создаются в отдельных зонах доступности AWS, чтобы обеспечить высокую доступность в нескольких физических объектах в регионе AWS. Подробнее о том, как зоны доступности обеспечивают высокую доступность.
    • Два шлюза NAT (по одному на каждую публичную подсеть) позволят контейнерам, которые мы развернем в наших частных подсетях, взаимодействовать с Интернетом для скачивания необходимых пакетов и т. д.
    • Адрес VPC DynamoDB . Наш сервер микросервиса будет интегрирован в Amazon DynamoDB для обеспечения постоянного хранения сессии (в рамках модуля 3).
    • Группа безопасности. Позволяет контейнерам Docker получать трафик на порт 8080 из Интернета через Network Load Balancer.
    • Роли IAM. Создаются роли Identity and Access Management. Они будут использоваться на протяжении всей программы обучения, чтобы созданные вами сервисы или ресурсы AWS получали доступ к другим сервисам AWS, например DynamoDB, S3 и т. п.

    Чтобы создать эти ресурсы, запустите указанную ниже команду в терминале Cloud9 (создание стека займет ~10 минут).

    aws cloudformation create-stack --stack-name MythicalMysfitsCoreStack --capabilities CAPABILITY_NAMED_IAM --template-body file://~/environment/aws-modern-application-workshop/module-2/cfn/core.yml

    Проверить статус создания стека можно с помощью консоли AWS или запустив команду:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack

    Запускайте команду описания стеков, пока не увидите статус StackStatus: "CREATE_COMPLETE".

    описание стеков

    (Нажмите, чтобы увеличить.)

    Когда вы получите этот ответ, CloudFormation завершит выделение всех указанных выше базовых ресурсов сети и безопасности. Работу можно продолжить. Подождите, пока не появится статус CREATE_COMPLETE для указанного выше стека.

    Вы будете использовать значения выходных данных этой команды на протяжении всей программы обучения. Чтобы вывести указанную выше команду описания стеков непосредственно в новый файл в IDE, который будет сохранен под именем cloudformation-core-output.json, запустите указанную ниже команду:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack > ~/environment/cloudformation-core-output.json

Модуль 2B. Развертывание сервиса с помощью AWS Fargate

Далее, вы создадите образ контейнера Docker со всеми кодами и настройками, которые необходимы для запуска сервера веб-сайта Mythical Mysfits как API микросервиса, созданного с помощью Flask. Мы создадим образ контейнера Docker в Cloud9 и передадим его на Amazon Elastic Container Registry, где его можно будет получить после создания нашего сервиса с помощью Fargate.

Схема архитектуры

браузер – балансировщик нагрузки – Fargate
  • A. Создание образа Docker

    Код, необходимый для запуска сервера сервиса, хранится в каталоге репозитория, который вы клонировали в Cloud9 IDE (module-2/app/). Если необходимо просмотреть код Python, в котором используется Flask для создания API сервиса, просмотрите файл /module-2/app/service/mythicalMysfitsService.py.

    Docker уже установлен на созданном вами Cloud9 IDE. Чтобы создать образ Docker локально, все, что необходимо сделать, – запустить в терминале Cloud9 указанные ниже команды.  

    Сначала замените каталог на ~/environment/module-2/app

    cd ~/environment/aws-modern-application-workshop/module-2/app

    Идентификатор аккаунта и регион по умолчанию можно узнать в выходных данных предыдущего CloudFormation ** описание стеков

    Чтобы создать образ docker с помощью файла Dockerfile, в котором содержатся инструкции Docker, в указанной ниже команде замените REPLACE_ME_ACCOUNT_ID на идентификатор вашего аккаунта, а REPLACE_ME_REGION – на регион по умолчанию. Команда с помощью параметра -t присваивает образу Docker теги в определенном формате, чтобы позже образ можно было передать в сервис Amazon Elastic Container Registry.

    Узнав идентификатор аккаунта, можно создавать образ docker:

    docker build . -t REPLACE_ME_AWS_ACCOUNT_ID.dkr.ecr.REPLACE_ME_REGION.amazonaws.com/mythicalmysfits/service:latest

    Вы увидите скачивание docker и установку всех пакетов зависимостей, необходимых нашему приложению, и вывод тега для созданного образа. Скопируйте тег образа на будущее. Ниже представлен пример тега: 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    Successfully built 8bxxxxxxxxab
    Successfully tagged 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest
    B. Локальное тестирование сервиса

    Давайте протестируем наш образ локально в Cloud9, чтобы убедиться, что все работает как надо. Скопируйте тег образа, который появился в результате предыдущей команды, и запустите указанную ниже команду, чтобы развернуть контейнер «локально» (на самом деле, в нашей облачной среде Cloud9 IDE в AWS!).

    docker run -p 8080:8080 REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    В результате вы увидите сообщение Docker о том, что ваш контейнер развернут и работает локально:

     * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

    Чтобы протестировать наш сервис с помощью локального запроса, мы откроем встроенный веб-браузер в Cloud9 IDE, который можно использовать для предварительного просмотра приложений, работающих в инстансе IDE.

    Чтобы открыть веб-браузер для предварительного просмотра, в строке меню Cloud9 выберите Предварительный просмотр > Предварительный просмотр запущенного приложения:

    preview-menu

     

    Откроется еще одна панель в IDE с веб-браузером. Добавьте /mysfits в конце URI в адресной строке браузера для предварительного просмотра и нажмите ENTER:

    address-bar

    В случае успеха вы увидите, что сервис возвращает документ JSON: `/aws-modern-application-workshop/module-2/app/service/mysfits-response.json`

    Чтобы остановить работу сервиса после завершения тестирования, нажмите CTRL-c на ПК или Mac.

    C. Передача образа Docker в Amazon ECR

    Успешно выполнив тестирование сервиса на локальном уровне, можно создать репозиторий для образа контейнера в Amazon Elastic Container Registry (Amazon ECR) и передать в него наш образ. Чтобы создать реестр, запустите указанную ниже команду. В результате новый репозиторий будет создан в стандартном реестре AWS ECR для вашего аккаунта.

    aws ecr create-repository --repository-name mythicalmysfits/service

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

    Запустите указанную ниже команду, которая вернет команду login, чтобы извлечь учетные данные для клиента Docker, а затем автоматически ее выполнит (команда должна быть полной, включая знак $ ниже). Если команда выполнена успешно, появится сообщение: Login Succeeded.

    $(aws ecr get-login --no-include-email)

    Затем передайте созданный образ в репозиторий ECR, использовав скопированный выше тег. С помощью указанной ниже команды Docker передаст образ и все образы, от которых он зависит, в Amazon ECR.

    docker push REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Чтобы увидеть, что переданный образ Docker сохранен в репозитории ECR, запустите команду ниже:

    aws ecr describe-images --repository-name mythicalmysfits/service
  • A. Создание кластера AWS Fargate

    Теперь нам доступен образ в ECR, который мы можем развернуть на сервисе, размещенном в Amazon ECS, с помощью AWS Fargate. Сервис, который вы тестировали на локальном уровне с помощью терминала в Cloud9 в прошлом модуле, теперь будем развертывать в облаке и в открытом доступе под защитой Network Load Balancer.

    Во-первых, создадим кластер в Amazon Elastic Container Service (ECS). Это кластер «серверов», на которых будут развернуты контейнеры сервиса. Слово «серверы» указано в кавычках, потому что вы будете использовать AWS Fargate. Fargate позволяет указать, чтобы контейнеры были развернуты на кластере, при этом у вас нет необходимости самостоятельно выделять серверы или управлять ими.

    Чтобы создать новый кластер в ECS, запустите следующую команду:

    aws ecs create-cluster --cluster-name MythicalMysfits-Cluster
    B. Создание группы AWS CloudWatch Logs Group

    Далее мы создадим новую группу журналов в AWS CloudWatch Logs. AWS CloudWatch Logs – это сервис для сбора и анализа журналов. Журналы, создаваемые вашим контейнером, будут автоматически передаваться в AWS CloudWatch Logs в этой группе. Это особенно важно при использовании AWS Fargate, поскольку у вас не будет доступа к инфраструктуре сервера, на которой работают контейнеры.

    Чтобы создать новую группу журналов в CloudWatch Logs, запустите следующую команду:

    aws logs create-log-group --log-group-name mythicalmysfits-logs
    C. Регистрация определения задачи ECS

    Теперь, когда мы создали кластер и определили группу журналов, в которую будут передаваться наши журналы контейнеров, мы готовы зарегистрировать определение задачи ECS. Задача в ECS – это набор образов контейнеров, которые должны быть назначены все вместе. В определении задачи указывается такой набор контейнеров, а также необходимые для них ресурсы и конфигурация. Вы будете использовать интерфейс командной строки AWS, чтобы создать новое определение задачи, в котором будет указано, как необходимо назначить новый образ контейнера только что созданному кластеру ECS.

    Вам предоставлен файл JSON, являющийся входным файлом для команды CLI.

    В IDE откройте ~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json.

    Замените указанные значения соответствующими значениями из созданных вами ресурсов.

    Эти значения будут получены из скопированного раннее ответа CloudFormation, а также из тега образа docker, который вы ранее передали в ECR, например REPLACE_ME_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    После замены значений в файле task-defintion.json сохраните его. Чтобы зарегистрировать новое определение задачи в ECS, выполните следующую команду:

    aws ecs register-task-definition --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json
  • A. Создание Network Load Balancer

    Зарегистрировав новое определение задачи, мы готовы выделить инфраструктуру, необходимую в стеке нашего сервиса. Вместо того, чтобы передать сервис непосредственно в Интернет, мы сначала будем использовать Network Load Balancer (NLB). Это позволит обеспечить связь кода интерфейсного веб-сайта с одним DNS-именем, при этом наш серверный сервис сможет эластично масштабироваться в зависимости от спроса или в случае сбоя и необходимости выделить новые контейнеры.

    Чтобы сформировать новый NLB, запустите указанную ниже команду в интерфейсе командной строки в терминале Cloud9 (извлеките идентификаторы подсетей из сохраненных вами выходных данных CloudFormation).

    aws elbv2 create-load-balancer --name mysfits-nlb --scheme internet-facing --type network --subnets REPLACE_ME_PUBLIC_SUBNET_ONE REPLACE_ME_PUBLIC_SUBNET_TWO > ~/environment/nlb-output.json

    После успешного выполнения этой команды в IDE будет создан новый файл с названием lb-output.json. В дальнейшем мы будем использовать элементы DNSName, VpcId и LoadBalancerArn.

    B. Создание целевой группы для балансировщика нагрузки

    Далее используйте интерфейс командной строки для создания целевой группы для NLB. Целевая группа позволяет ресурсам AWS регистрироваться в качестве целевых объектов для запросов, которые балансировщик нагрузки получает для перенаправления. Контейнеры сервиса автоматически зарегистрируются в этом целевом объекте, чтобы получать трафик из NLB, когда они будут выделены. В этой команде будет необходимо заменить одно значение – vpc-id. Его можно найти в ранее сохраненных выходных данных MythicalMysfitsCoreStack, возвращенных из CloudFormation.

    aws elbv2 create-target-group --name MythicalMysfits-TargetGroup --port 8080 --protocol TCP --target-type ip --vpc-id REPLACE_ME_VPC_ID --health-check-interval-seconds 10 --health-check-path / --health-check-protocol HTTP --healthy-threshold-count 3 --unhealthy-threshold-count 3 > ~/environment/target-group-output.json

    Выходные данные будут сохранены в файле target-group-output.json в IDE после ее выполнения. В следующем шаге вы будете использовать значение TargetGroupArn.

    C. Создание прослушивателя балансировщика нагрузки

    Далее, используйте интерфейс командной строки, чтобы создать прослушиватель балансировщика нагрузки для NLB. Он информирует балансировщик нагрузки о том, что определенный порт получил запросы и что их необходимо перенаправить в целевые объекты, зарегистрированные в вышеуказанной целевой группе. Не забудьте заменить два указанных значения на соответствующие ARN из TargetGroup и NLB, сохраненные в предыдущих шагах:

    aws elbv2 create-listener --default-actions TargetGroupArn=REPLACE_ME_NLB_TARGET_GROUP_ARN,Type=forward --load-balancer-arn REPLACE_ME_NLB_ARN --port 80 --protocol TCP
  • A. Создание связанной с сервисом роли для ECS

    Если в прошлом вы уже использовали ECS, можете пропустить этот шаг и перейти к следующему. Если вы никогда не использовали ECS, необходимо создать **связанную с сервисом роль** в IAM, которая дает сервису ECS разрешения на выполнение запросов API ECS в рамках вашего аккаунта. Это необходимо, поскольку когда вы создадите сервис в ECS, он будет выполнять вызовы API в вашем аккаунте, чтобы, например, получать образы Docker, создавать новые задачи.

    Если роль не будет создана, сервис ECS не получит разрешения для выполнения необходимых действий. Чтобы создать роль, выполните следующую команду в терминале:  

    aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com

    Если команда выше возвращает ошибку с сообщением, что роль уже создана ранее, ее можно игнорировать, поскольку она указывает, что роль была автоматически создана в вашем аккаунте в прошлом.

    B. Создание сервиса

    Теперь, когда создан и настроен NLB, а сервис ECS получил необходимые разрешения, мы можем создать сам **сервис** ECS, в котором наши контейнеры будут работать и регистрироваться в балансировщике нагрузки для получения трафика. В качестве входных данных интерфейса командной строки мы добавили файл JSON: `~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json`. В этом файле собраны все настройки для создания сервиса, в том числе указание, что сервис должен быть запущен с помощью **AWS Fargate**. Это значит, что у вас нет необходимости выделять серверы в целевом кластере. Контейнеры, назначенные в рамках используемой в этом сервисе задачи, будут работать вместе с кластером, полностью управляемым AWS.

    Откройте файл ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json в IDE и замените указанные значения REPLACE_ME. Сохраните его и запустите указанную ниже команду для создания сервиса.

    aws ecs create-service --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json
    C. Тестирование сервиса

    Скопируйте DNS-имя, которое вы сохранили во время создания NLB, и отправьте к нему запрос, используя браузер для предварительного просмотра в Cloud9 (или просто любой веб-браузер, поскольку в этот раз наш сервис доступен в Интернете). Попробуйте отправить запрос к ресурсам веб-сайта Mysfits:

    http://mysfits-nlb-123456789-abc123456.elb.us-east-1.amazonaws.com/mysfits

    Если ответ совпадает с ответом JSON, полученным нами ранее во время локального тестирования контейнера Docker в Cloud9, то ваш Flask API заработал на AWS Fargate.

    Примечание. Этот Network Load Balancer поддерживает только HTTP-запросы (http://), поскольку на нем установлены сертификаты SSL/TLS. Для прохождения данного обучения отправляйте запросы, используя протокол http://. Запросы https:// не будут работать как надо.

  • A. Замена адреса API

    Далее необходимо объединить наш веб-сайт с новым сервером API вместо того, чтобы использовать жестко заданные данные, которые мы ранее отправили в S3. Следующий файл необходимо обновить, чтобы использовать тот же URL-адрес NLB для вызовов API (не указывайте путь /mysfits path): /module-2/web/index.html

    Откройте файл в Cloud9 и замените выделенную область между кавычками ниже на URL-адрес NLB.

    before-replace

    После этого строка должна выглядеть следующим образом:

    after-replace
    B. Отправка в S3

    Чтобы отправить этот файл на свой веб-сайт, размещенный в S3, еще раз используйте имя корзины, созданной в первом модуле, и запустите следующую команду:

    aws s3 cp ~/environment/aws-modern-application-workshop/module-2/web/index.html s3://INSERT-YOUR-BUCKET-NAME/index.html

    Откройте веб-сайт с тем же URL-адресом, который вы использовали в конце первого модуля, чтобы увидеть свой новый веб-сайт Mythical Mysfits, извлекающий данные JSON из Flask API в контейнере Docker, развернутом в AWS Fargate!

Модуль 2C. Автоматическое развертывание с помощью сервисов AWS Code

Теперь, когда сервис заработал, можно подумать об изменениях, которые вы хотели бы внести в код в сервисе Flask. Скорость разработки была бы невысокой, если бы вам приходилось выполнять все вышеуказанные шаги для развертывания каждой новой функции в сервисе. Для этого можно воспользоваться непрерывной интеграцией и непрерывной доставкой (CI/CD).

В этом модуле вы создадите полностью управляемый стек CI/CD, который будет автоматически передавать все вносимые вами изменения в коде в базу кода в сервисе, созданном в предыдущем модуле.

Схема архитектуры

создание архитектуры динамического веб-сайта – cloud9, средства для работы с кодом, fargate
  • A. Создание корзины S3 для артефактов конвейера

    Нам понадобится создать еще одну корзину S3 для хранения временных артефактов, создаваемых во время работы конвейера CI/CD. Для этих артефактов выберите новое имя корзины и создайте ее с помощью следующей команды в интерфейсе командной строки:

    aws s3 mb s3://REPLACE_ME_CHOOSE_ARTIFACTS_BUCKET_NAME

    Далее для этой корзины требуется политика, которая определит разрешения для сохраненных в ней данных. В отличие от доступной всем корзины нашего веб-сайта, к этой корзине должен иметь доступ только ваш конвейер CI/CD. Мы предоставили файл JSON для политики: ~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json.

    Откройте файл и внутри замените несколько строк на имена ARN, созданные ранее в MythicalMysfitsCoreStack,а также на только что созданное имя корзины для артефактов CI/CD.

    Когда вы измените и сохраните этот файл, запустите указанную ниже команду, чтобы предоставить доступ к этой корзине в конвейере CI/CD.

    aws s3api put-bucket-policy --bucket REPLACE_ME_ARTIFACTS_BUCKET_NAME --policy file://~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json
    B. Создание репозитория CodeCommit

    Вам понадобится место для передачи и хранения кода. Создайте **репозиторий AWS CodeCommit**с помощью интерфейса командной строки:

    aws codecommit create-repository --repository-name MythicalMysfitsService-Repository
    C. Создание проекта CodeBuild

    Кроме репозитория для хранения кода и корзины S3 для артефактов CI/CD, давайте дополним стек CI/CD средством для выполнения сборки сервиса. Это можно выполнить, создав проект AWS CodeBuild. При каждом запуске выполнения сборки AWS CodeBuild будет автоматически выделять сервер сборки для нашей конфигурации, выполняя шаги, необходимые для создания образа Docker и передачи его новой версии в созданный нами репозиторий ECR (а затем останавливать сервер по завершении сборки).

    Шаги по сборке (упаковке нашего кода Python и созданию/передаче контейнера Docker) указаны в файле: ~/environment/aws-modern-application-workshop/module-2/app/buildspec.yml. Вы создадите файл buildspec.yml, чтобы указать CodeBuild, какие шаги необходимы для выполнения сборки в рамках проекта CodeBuild.

    Чтобы создать проект CodeBuild, необходимо в еще один входной файл интерфейса командной строки внести параметры для ваших ресурсов. Путь к файлу: ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json. Замените значения в этом файле так же, как вы это делали ранее из MythicalMysfitsCoreStackOutput. Сохраните изменения и запустите следующую команду в интерфейсе командной строки, чтобы создать проект:

    aws codebuild create-project --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json
    D. Создание конвейера CodePipeline

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

    Конвейер в CodePipeline сделает то, что описано выше. При каждой передаче изменение кода в репозиторий CodeCommit CodePipeline будет доставлять новый код в проект AWS CodeBuild для выполнения сборки. Когда CodeBuild успешно выполнит сборку, CodePipeline выполнит развертывание в ECS с помощью самого нового образа контейнера, который был передан ECR во время работы CodeBuild.

    Все эти шаги указаны в предоставленном файле JSON, который вы будете использовать в качестве входных данных в интерфейсе командной строки AWS для создания конвейера. Путь к этому файлу: ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json. Откройте его, замените в нем требуемые атрибуты и сохраните.

    После этого создайте конвейер в CodePipeline с помощью следующей команды:

    aws codepipeline create-pipeline --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json
    E. Активируйте автоматический доступ к репозиторию образов ECR

    Остался последний шаг для обеспечения успешной комплексной работы конвейера CI/CD. Благодаря конвейеру CI/CD больше не надо передавать образы контейнера в ECR вручную. Теперь новые образы будет передавать CodeBuild.

    Используя политики репозитория ECR*, необходимо дать CodeBuild разрешение на выполнение действий над вашим репозиторием образов. Политику необходимо обновить с учетом конкретного ARN для роли CodeBuild, созданного в MythicalMysfitsCoreStack. Путь к документу: ~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json.

    Обновите и сохраните этот файл, а затем запустите следующую команду, чтобы создать политику:

    aws ecr set-repository-policy --repository-name mythicalmysfits/service --policy-text file://~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json

    Когда она будет создана, у вас появится работающий комплексный конвейер CI/CD для автоматической доставки изменений кода в ваш сервис в ECS.

  • A. Использование Git вместе с AWS CodeCommit

    Чтобы выполнить тестирование нового конвейера, необходимо настроить Git в Cloud9 IDE и интегрировать с репозиторием CodeCommit.

    AWS CodeCommit предоставляет вспомогательное приложение учетных данных для git, которое мы будем использовать для облегчения интеграции.

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

    git config --global user.name "REPLACE_ME_WITH_YOUR_NAME"
    git config --global user.email REPLACE_ME_WITH_YOUR_EMAIL@example.com
    git config --global credential.helper '!aws codecommit credential-helper $@'
    git config --global credential.UseHttpPath true

    Далее с помощью терминала замените каталоги в IDE на каталог среды:

    cd ~/environment/

    Теперь мы готовы клонировать наш репозиторий с помощью следующей команды в терминале:

    git clone https://git-codecommit.REPLACE_REGION.amazonaws.com/v1/repos/MythicalMysfitsService-Repository

    В результате мы получим сообщение, что наш репозиторий пуст! Давайте это исправим, скопировав файлы приложения в каталог нашего репозитория с помощью следующей команды:

    cp -r ~/environment/aws-modern-application-workshop/module-2/app/* ~/environment/MythicalMysfitsService-Repository/
    B. Передача изменения кода

    Теперь выполненный код, который мы использовали для создания сервиса Fargate во втором модуле, сохранен в локальном репозитории, клонированном из AWS CodeCommit. Прежде чем зафиксировать наши изменения, давайте внесем изменение в сервисе Flask, чтобы продемонстрировать, что созданный нами конвейер CI/CD работает. В Cloud9 откройте файл: ~/environment/MythicalMysfitsService-Repository/service/mysfits-response.json. Измените возраст одного из существ и сохраните файл.

    После сохранения файла замените каталоги на каталог нового репозитория:

    cd ~/environment/MythicalMysfitsService-Repository/

    Затем запустите указанные ниже команды git, чтобы передать изменения в ваш код.

    git add .
    git commit -m "I changed the age of one of the mysfits."
    git push

    После передачи изменений в репозиторий можно открыть сервис CodePipeline на консоли AWS, чтобы просмотреть изменения по мере их прохождения по конвейеру CI/CD. После фиксации изменения кода развертывание изменений в сервис, работающий в Fargate, займет около 5–10 минут.

    В течение этого времени AWS CodePipeline организует инициирование работы конвейера после внесения изменений в репозиторий CodeCommit, заставит проект CodeBuild начать новую сборку, извлечет образ docker, переданный в ECR с помощью CodeBuild, и выполнит автоматическое обновление сервиса ECS, чтобы остановить ранее созданные и работающие в сервисе контейнеры и заменить их на новый образ. Чтобы просмотреть внесенные изменения, обновите свой веб-сайт Mythical Mysfits в браузере.

    Процесс изменения кода можно посмотреть на консоли CodePipeline здесь (не предпринимайте никаких действий, просто наблюдайте за автоматизацией!): AWS CodePipeline

    На этом мы завершаем модуль 2.

Далее – хранение данных о бездомных существах.