Назад | Перейти на главную страницу

Переход с Azure на AWS не имеет смысла в AutoScaling EC2 IIS и развертываниях

Итак, у нас был один сервер, и все было хорошо (в разработке). Но теперь пришло время настроить автоматическое масштабирование, и я немного потерялся. В настоящее время у нас есть настройка профилей публикации. Когда мы строим наш сервер сборки, у нас есть профиль публикации для публикации в нашем инстансе Amazon EC2 IIS. Отлично.

Но как вы справляетесь с автоматическим масштабированием? Второй экземпляр будет настроен автоматически на основе моих параметров, скорее всего, с некоторыми начальными сценариями для настройки пользователей, установки ролей, создания сайтов и т. Д., Но какова наилучшая практика для фактической «публикации» сайта во вновь созданном , застряли за балансировщиком нагрузки, экземпляром EC2 IIS?

Я скучаю по Azure ...

У вас есть два основных варианта:

  1. Предварительно запишите ваше приложение и конфигурацию в AMI, который ASG использует для запуска новых экземпляров.
  2. Использовать user-data Поле конфигурации запуска, чтобы экземпляр сам загрузил ваше приложение и настроил его как часть процесса загрузки.

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

Взгляните на использование AWS Elastic Beanstalk.

Если вы используете AWS Elastic Beanstalk, вы не будете выполнять развертывание непосредственно на своих экземплярах EC2. Вместо этого вы бы:

  1. Опубликуйте свой сайт из Visual Studio как пакет развертывания (ZIP),
  2. Загрузите этот ZIP-файл в AWS EB, затем
  3. Разрешить AWS EB развернуть этот ZIP-пакет на ваших экземплярах EC2 (за ELB или без него)

Инструменты AWS для Visual Studio также позволяют развернуть пакет развертывания непосредственно из Visual Studio в AWS EB.

Информация об AWS Elastic Beanstalk для .NET: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_NET.html