Архитектура АВС

Реплатформизация приложения ASP .NET Core на AWS Elastic Beanstalk

Развертывание в AWS из Azure с помощью конвейера Azure DevOps.

В этой статье будет показано, как легко переплатформить приложение ASP .NET Core с помощью существующих инструментов DevOps, таких как Azure Pipelines, чтобы заставить его работать в масштабе на AWS с помощью AWS Beanstalk.

На рисунке выше показан пример сценария и архитектуры, которую мы будем строить. У нас есть исходный код для приложения ASP .NET Core, находящийся в репозитории системы управления версиями, этот исходный код был развернут на веб-сервере IIS, работающем в устаревшей среде Windows. Что мы собираемся сделать, так это развернуть тот же исходный код, что и приложение AWS Elastic Beanstalk, с помощью Azure DevOps Pipelines. Результатом этого является высокодоступное, отказоустойчивое приложение ASP .NET Core с уменьшенными операционными издержками и сложностью управления.

Еще одна вещь, которую мы собираемся сделать, — это развернуть это приложение ASP .NET Core для работы в Linux, это не только для того, чтобы продемонстрировать, что это можно сделать, но и для достижения некоторой экономии эксплуатационных расходов, поскольку работа в Linux означает, что мы выиграли. не нести расходы на лицензирование Windows. AWS Elastic Beanstalk концептуально является управляемым сервисом развертывания, который создает среду для размещения рабочих нагрузок приложений, чтобы мы могли уделять больше времени фактическому коду. Сам Elastic Beanstalk является бесплатным, но вы платите за ресурсы, созданные для запуска вашего приложения Elastic Beanstalk. Итак, по существу: под прикрытием приложение Elastic Beanstalk работает на экземплярах EC2. Экземпляры Linux, как правило, дешевле в эксплуатации, чем экземпляры Windows.

Вот простой расчет с использованием региона ap-southeast-1 (Сингапур) в качестве примера: экземпляр Linux по требованию t3.medium стоит 5,28 центов в час, а экземпляр Windows по требованию t3.medium стоит 7,12 центов за час. час работы на основе того, что указано на странице с ценами на EC2 на момент написания. Это означает, что экземпляр Linux на 25% дешевле в эксплуатации.

Для целей этой статьи я использовал Azure Repos в качестве репозитория исходного кода. Ниже показан экран, показывающий приложение ASP .NET Core в репозиториях Azure.

Однако обратите внимание, что использовать Azure Repos не обязательно. Как мы увидим, мы собираемся использовать Azure DevOps Pipeline для развертывания приложения в AWS, а Azure DevOps Pipeline может работать с любым репозиторием Git, Bitbucket или Subversion. Если вы хотите приступить к работе и следовать инструкциям, но у вас нет кода или приложения ASP .NET Core, которое можно было бы опробовать, я рекомендую использовать Visual Studio для его создания, а затем добавить его в ваш любимый репозиторий исходного кода.

Учитывая приведенный выше контекст, нам нужно сделать следующее, чтобы переплатформить приложение ASP .NET Core:

  1. Подготовка AWS Elastic Beanstalk
  2. Установите и настройте AWS Toolkit для Azure DevOps (необязательно)
  3. Настройка конвейеров Azure DevOps

Подготовка AWS Elastic Beanstalk

Очевидно, что для развертывания в Elastic Beanstalk нам необходимо иметь приложение Elastic Beanstalk для развертывания. Приложение Elastic Beanstalk — это логическая коллекция компонентов Elastic Beanstalk, включая среды, версии и конфигурации среды.

Создать приложение Elastic Beanstalk очень просто. Просто перейдите в Elastic Beanstalk в консоли AWS (прямая ссылка https://console.aws.amazon.com/elasticbeanstalk/home#/gettingStarted), введите имя приложения и выберите платформу. Для этого сценария выберите .NET Core on Linux в качестве платформы. Для кода приложения пока используйте приложение Sample, потому что позже мы собираемся развернуть новую версию.

На этом этапе вы можете просто создать приложение со всеми настройками по умолчанию, нажав кнопку «Создать приложение», а затем настроить среду позже, или настроить дополнительные параметры, если вы хотите лучше контролировать конфигурации среды. Я выбрал больше вариантов. Теперь, чтобы реализовать архитектуру, изображенную в начале статьи, нам нужна среда с балансировщиком нагрузки, распределенная по 2 зонам доступности. Используйте предустановку конфигурации High Availability в качестве отправной точки, чтобы сделать нашу жизнь немного проще.

Прокрутите вниз до «Сеть», здесь мы хотим выбрать VPC для развертывания. Вы можете использовать VPC по умолчанию, но в реальном мире, скорее всего, у вас уже есть собственные VPC. В моем случае у меня уже есть VPC в нужном мне регионе с 6 подсетями, 3 из которых являются публичными подсетями, а остальные 3 — частными подсетями, по 1 для каждой зоны доступности.

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

Прокрутив вниз до следующего раздела, выберите частные подсети для экземпляра. Я также сделал то же самое для настроек базы данных, хотя в этом примере мое приложение ASP .NET Core не имеет уровня базы данных, мастер создания приложения будет жаловаться, если для базы данных не выбраны подсети.

Сохраните настройки сети, а затем перейдите в колонку Емкость и щелкните Изменить. Здесь мы указываем параметры масштабирования. Нам нужно сбалансировать нагрузку и распределить экземпляры по 2 зонам доступности. Поэтому я бы указал балансировку нагрузки для типа среды и начал как минимум с 2 экземпляров.

Не стесняйтесь изменять другие настройки по мере необходимости, но пока их можно оставить по умолчанию. Сохраните и создайте приложение. Это также создаст окружающую среду. Обратите внимание на имя приложения и имя среды. Мы будем использовать их позже в Azure DevOps Pipeline в качестве цели развертывания. На данный момент у нас уже есть следующая архитектура, настроенная в AWS, которая готова к развертыванию.

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

Мы отправимся в Azure DevOps, чтобы выполнить следующие шаги.

Установите и настройте AWS Toolkit для Azure DevOps (необязательно)

Для простоты я собираюсь настроить Azure DevOps для использования AWS Toolkit для Azure DevOps. На момент написания этого набора инструментов в Azure Pipelines была доступна 21 задача, начиная от конкретных задач развертывания, таких как развертывание в Elastic Beanstalk, Lambda, ECR Push, и заканчивая общими задачами, такими как выполнение команды AWS CLI.

Использование инструментария необязательно, но это значительно упрощает работу. Без этого инструментария обходным путем было бы использование задач PowerShell для запуска команд AWS CLI, это может быть немного сложно, а также означает, что нам придется инициировать агенты конвейера DevOps с помощью AWS CLI. До сих пор я не пробовал это с агентами, размещенными на Microsoft, поэтому я не могу посоветовать, возможен ли вообще этот подход, если вы пробовали его, мне было бы интересно узнать, поэтому, пожалуйста, оставьте комментарий ниже. Скорее всего, это будет означать, что вам нужно будет настроить свой собственный агент Azure Pipeline, для которого уже настроен интерфейс командной строки AWS, который вы можете разместить локально или в облаке, например на Amazon EC2 или виртуальной машине Azure. Настройка этого выходит за рамки этой статьи, но я рекомендую прочитать о том, как настроить агентов, размещенных на собственном сервере, и использовать EC2 в качестве агентов, размещенных на собственном сервере, в производственной среде. Вскоре мы также коснемся причин.

Добавить AWS Toolkit для Azure DevOps очень просто: просто зайдите в Visual Studio Marketplace и добавьте его в свою организацию. После добавления этого расширения нам нужно перейти к проекту, в котором мы собираемся создать наш Azure Pipeline, но сначала убедитесь, что вы выбрали 1 из 4 методов для установки учетных данных задачи, которые Azure DevOps будет использовать для развертывания в вашей среде AWS. . Есть 4 варианта:

  1. Подключение услуги
  2. Именованные переменные
  3. Стандартные переменные среды AWS в процессе агента сборки
  4. Агенты сборки EC2

Для первых 3 вариантов требуется пользователь IAM на AWS с необходимыми разрешениями, затем нам нужно сгенерировать ключ доступа для пользователя и настроить Azure DevOps с помощью этого ключа доступа и секретного ключа доступа. Пожалуйста, ознакомьтесь с этим руководством пользователя AWS для получения дополнительной информации. Для краткости демонстрации я решил использовать служебное соединение.

Хотя есть случаи, когда этого нельзя избежать, использование ключа доступа и секретного ключа доступа обычно не одобряется. Да, есть способы защитить эти методы, такие как обеспечение наименее разрешительной политики IAM, прикрепленной к пользователю, использование внешнего идентификатора, принятие роли IAM и т. д., но может быть лучше выбрать агент сборки EC2 в производственная среда. Это связано с тем, что агент сборки EC2 может автоматически получать учетные данные и информацию о регионе AWS из метаданных экземпляра, используя профили экземпляра EC2. По сути, вместо настройки Azure DevOps с помощью ключа доступа и секретного ключа доступа, связанных с пользователем IAM, мы настраиваем Azure DevOps для использования агента сборки EC2, который, в свою очередь, примет на себя роль IAM. Опять же, этот аспект выходит за рамки этой статьи, но если вы хотите, чтобы я осветил его, пожалуйста, подпишитесь на меня, оставьте комментарий / отзыв, и я буду более чем счастлив рассказать об этом в своих будущих статьях.

В любом случае ОК, чтобы пройти пошаговое руководство, вернуться к подключению к службе: настроить это довольно просто, просто перейдите к параметрам проекта в Azure DevOps (нижний левый угол) и выберите «Подключения к службе» в разделе «Конвейеры». Нажмите кнопку создания подключения к службе.

Затем найдите AWS, нажмите «Далее» и введите идентификатор ключа доступа и секретный ключ доступа, не забудьте указать имя подключения к службе и нажмите «Сохранить».

Теперь с этим набором мы можем перейти к Azure DevOps Pipeline и начать создавать конвейер, использующий задачу AWS Elastic Beanstalk Deploy Application, которая теперь будет доступна.

Настройка конвейеров Azure DevOps

Во-первых, нам нужно будет получить Azure Pipelines для создания нашего приложения ASP .NET Core. Я буду использовать классический редактор, который легче показать и отслеживать, а не YAML.

Я выберу репозитории Azure, в которых находится код ASP .NET Core. Следующим шагом будет выбор из шаблона. Если мы ищем по «ASP .NET», мы получаем несколько шаблонов, и важно выбрать правильный. Поскольку мы развертываем это в Linux, выберите ASP .NET Core или используйте YAML, если вам нужен лучший контроль.

Этот шаблон добавляет 5 задач в конвейер. Нам нужно выбрать агент Azure Pipelines. В этом примере я использовал агента, размещенного на сервере Microsoft, и выбрал Ubuntu-20.04, но на самом деле это не имеет значения, поскольку .NET Core является кроссплатформенным. Я также удалил артефакт публикации, так как не заинтересован в использовании Azure Artifacts для целей этой статьи.

Далее нам нужно убедиться, что наш код правильно упакован для Elastic beanstalk. По умолчанию задача «Публикация» создает ZIP-файл, но структура его папок несовместима с развертыванием Elastic Beanstalk. если вы не выполните следующие 2 шага, вы получите следующую ошибку при выполнении развертывания:

Your source bundle has a single .NET Core application. You must include a file with a ‘.runtimeconfig.json’ suffix. The deployment failed.

В задаче «Публикация» снимите флажки «Заархивировать опубликованные проекты» и «Добавить имя папки проекта в путь публикации», обратите внимание на значение — outputargument, так как оно понадобится вам на следующем шаге. По умолчанию задача публикации выводит в $(build.artifactstagingdirectory)

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

Теперь мы можем добавить задачу AWS Elastic Beanstalk Deploy Application после задачи архивного файла.

Задайте для региона AWS, имени приложения и имени среды точное соответствие с тем, что было настроено в AWS Beanstalk. Выберите ASP.NET Core Linux (sourceL dotnet publish) в качестве типа пакета развертывания и поместите расположение выходных данных задачи архивного файла, которое вы отметили ранее, в Путь опубликованного приложения.

Теперь трубопровод готов. Просто нажмите «Сохранить и поставить в очередь» и дождитесь запуска агента конвейера. Развертывание конвейера в AWS Elastic Beanstalk не должно занять много времени.

На этом этапе, если мы перейдем к AWS Elastic Beanstalk, мы сможем увидеть, что среда отображается как работоспособная, а в журнале последних событий указано, что среда была обновлена.

Если щелкнуть ссылку Перейти к среде в меню слева или под именем среды, откроется новая вкладка браузера, и мы определенно увидим, что наше приложение ASP .NET Core работает.

Поскольку наше приложение работает в AWS Elastic Beanstalk, мы можем легко перенастроить среду. Например, я могу настроить емкость для увеличения или увеличения масштаба, мы также можем настроить масштабирование по расписанию.

После того как я изменил конфигурацию емкости и увеличил минимальное количество экземпляров, среда будет обновлена.

После завершения обновления среды я отправился в EC2, чтобы убедиться, что приложение определенно запущено на 3 экземплярах.

В заключение: я надеюсь, что это поможет вам понять некоторые преимущества переплатформизации приложения ASP .NET Core для работы на AWS с использованием Elastic Beanstalk и то, как вы можете работать с существующими инструментами DevOps, такими как Azure DevOps, для развертывания приложений в AWS. без особых усилий.

Как всегда, цель этой статьи — предоставить вам базовую или отправную точку. Обратите внимание, что хотя Elastic Beanstalk прост в использовании и является очень полезным сервисом, перенастройка на него может не всегда соответствовать вашему контексту и обстоятельствам. Обратитесь к официальной документации AWS, чтобы оценить и подтвердить свой вариант использования и подойти к нему более внимательно.

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

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.