Как создать страницу обслуживания AWS, если ваши инстансы находятся за ELB?

Самый простой способ на AWS - использовать их службу DNS Route 53.

Вы можете использовать функцию Weighted Круговая система.

«Вы можете использовать WRR для запуска серверов, проведения A / B-тестирования или балансировки трафика между регионами или центрами обработки данных различного размера».

Дополнительную информацию см. В документации AWS по этой функции

РЕДАКТИРОВАТЬ: Route 53 недавно добавил новую функцию, которая позволяет DNS Failover на S3. Дополнительную информацию см. В их документации: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html

Я понимаю, что это старый вопрос, но, столкнувшись с той же проблемой сегодня (декабрь 2018 г.), похоже, что есть другой способ решить эту проблему.

Ранее в этом году AWS представила поддержку перенаправляет и фиксирует ответы балансировщикам нагрузки приложений. В двух словах:

• Найдите свой ELB в консоли.
• Просмотрите правила для соответствующего слушателя.
• Добавьте фиксированное правило ответа 503 для имени хоста вашего приложения.
• При желании предоставьте ответ text/plain или text/html (например, HTML-код страницы обслуживания).
• Сохранить изменения.

Как только правило распространяется на ELB (у меня это заняло ~ 30 секунд), когда вы попытаетесь посетить свой хост в своем браузере, вам будет показана страница обслуживания 503.

По завершении развертывания просто удалите добавленное правило.

Придумали еще одно решение, которое нам отлично подходит. Вот необходимые шаги, чтобы получить простой ответ 503 http:

1. Реплицируйте вашу среду EB, чтобы создать другую, например, назовите ее как-нибудь вроде app-environment-maintenance.
2. Измените конфигурацию автомасштабирования и установите минимальный и максимальный серверы на ноль. Это не будет стоить вам каких-либо серверов EC2, и среда станет серой и попадет в ваш список.

3. Наконец, вы можете использовать интерфейс командной строки AWS, чтобы поменять местами CNAME среды, чтобы перевести основную среду в режим обслуживания. Например:

   aws elasticbeanstalk swap-environment-cnames \
       --profile "$awsProfile" \
       --region "$awsRegion" \
       --output text \
       --source-environment-name app-prod \
       --destination-environment-name app-prod-maintenance
   

Это переведет вашу app-prod среду в режим обслуживания. Это приведет к тому, что ELB выдаст ошибку 503, поскольку нет запущенных экземпляров EC2, и тогда Cloudfront может поймать 503 и вернуть вашу настраиваемую страницу ошибки 503, если вы захотите, как описано ниже.

Дополнительная конфигурация для настраиваемых страниц ошибок с помощью Cloudfront:

Мы используем Cloudfront, как и многие люди для HTTPS и т. Д. Cloudfront имеет страницы с ошибками. Это требование.

1. Создайте новую корзину хостинга веб-сайтов S3 с вашими страницами ошибок. Рассмотрите возможность создания отдельных файлов для кодов ответов, 503 и т. Д. См. № 6 для получения информации о требованиях к каталогам и маршрутах.
2. Добавьте корзину S3 в свой дистрибутив Cloudfront.
3. Добавьте новое поведение в свой дистрибутив Cloudfront для маршрута типа /error/*.
4. Настройте страницы ошибок в Cloudfront, чтобы обрабатывать коды ответов 503 и указывать их на маршрут вашего сегмента S3, например /error/503-error.html

Теперь, когда ваш ELB выполнит ошибку 503, отобразится ваша пользовательская страница ошибки.

Вот и все. Я знаю, что есть довольно много шагов, чтобы получить пользовательские страницы ошибок, и я попробовал множество предлагаемых вариантов, включая Route53 и т. Д. Но у всех из них есть проблемы с тем, как они работают с ELB, Cloudfront и т. Д.

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

Route53 - не лучшее решение этой проблемы. Для истечения срока действия записей DNS требуется значительное время, прежде чем появится страница обслуживания (и затем такое же время проходит до их обновления после завершения обслуживания). Я понимаю, что триггеры Lambda и CodeDeploy не существовали в то время, когда был задан этот вопрос, но я хотел сообщить другим, что Lambda можно использовать для создания относительно чистого решения для этого, которое я подробно описал в сообщении в блоге: http://blog.ajhodges.com/2016/04/aws-lambda-setting-Contemporary.html

Суть решения состоит в том, чтобы подписать функцию Lambda на события CodeDeploy, которая заменяет вашу ASG микро-экземпляром, обслуживающим статическую страницу в вашем балансировщике нагрузки во время развертывания.

Насколько я мог видеть, мы оказались в ситуации, когда приведенные выше ответы неприменимы или не идеальны.

У нас есть приложение Rails, работающее под управлением Puma с Ruby 2.3, работающее на 64-битной Amazon Linux / 2.9.0, которое, похоже, поставляется с (классическим) ELB.

Так что использование ALB 503 не подходило.

У нас также есть множество аппаратных клиентов, которым я бы не стал доверять, чтобы всегда уважать TTL DNS, поэтому использование Route53 рискованно.

Что действительно хорошо работает, так это дополнительный порт на nginx, который поставляется с платформой.

Я добавил это как .ebextensions/maintenance.config

files:
  "/etc/nginx/conf.d/maintenance.conf":
    content: |
      server {
        listen 81;
        server_name _ localhost;
        root /var/app/current/public/maintenance;
      }

container_commands:
  restart_nginx:
    command: service nginx restart

И сбросил копию https://gist.github.com/pitch-gist/2999707 в public/maintenance/index.html

Теперь, чтобы установить обслуживание, я просто переключаю свои прослушиватели ELB так, чтобы они указывали на порт 81 вместо 80 по умолчанию. Никаких дополнительных экземпляров, сегментов s3 или ожидания клиентов на новый DNS.

Для применения beanstalk (вероятно, в основном, ожидая облачной информации в серверной части) требуется около 15 секунд или около того.

Наш процесс развертывания сначала запускает облачную информацию, чтобы запустить микро-экземпляр ec2 (экземпляр обслуживания), который копирует предварительно определенную статическую страницу из s3 в ec2. Cloudformation поставляется с elb, к которому подключен экземпляр micro ec2. Затем запускается сценарий (powershell или cli) для удаления веб-экземпляров (ec2) из ​​экземпляра elb, покидающего Maintenance.

Таким образом мы переключаемся на экземпляр обслуживания во время процесса развертывания.

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