Подтвердить что ты не робот

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

Как вы размещаете страницу обслуживания в AWS, когда вы хотите развернуть новые версии своего приложения за ELB? Мы хотим, чтобы трафик маршрута ELB использовался в экземпляре обслуживания, в то время как новые экземпляры с автоматическим масштабированием приближаются, и только "перевернуться" в новые экземпляры, как только они полностью встанут. Мы используем автомасштабирование, чтобы привести существующие экземпляры вниз и новые экземпляры, у которых есть новый код, вверх.

Сценарий, который мы пытаемся избежать, заключается в том, что ELB обслуживает оба трафика для новых экземпляров EC2, одновременно обслуживая страницу обслуживания. Поскольку мы не включаем липкие сеансы, мы хотим, чтобы пользователь не переключался между страницей режима обслуживания и приложением, развернутым в экземпляре EC2. Мы также не можем просто увеличить масштаб (скажем, от 2 до 4 экземпляров, а затем вернуться к 2), чтобы представить новые экземпляры, потому что изменения кода могут включать изменения базы данных, которые будут нарушать изменения для старого кода.

4b9b3361

ОТВЕТЫ

Ответ 1

Самый простой способ использования AWS - использовать Маршрут 53, свою службу DNS.

Вы можете использовать функцию Weighted Round Robin.

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

Дополнительная информация в Документация AWS по этой функции

ИЗМЕНИТЬ: Маршрут 53 недавно добавил новую функцию, которая позволяет отказоустойчивости DNS на S3. Проверьте их документацию для получения более подробной информации: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html

Ответ 2

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

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

Ответ 3

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

  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 и т.д.

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

В нашем случае у нас есть два локтя, один для внешнего и другого внутреннего. Во время этого процесса наша внутренняя лощина не будет обновляться, и мы закончили развертывание post prod smoke test. Как только тестирование завершено, мы запускаем еще один script, чтобы привязать веб-экземпляры к elb и удалить стек Maintenance.

Ответ 6

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

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

Поэтому обработка ALB 503 не была возможной.

У нас также есть множество аппаратных клиентов, которым я бы не доверял, чтобы всегда уважать DNS TTL, поэтому 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.

Может потребоваться ~ 15 секунд или около того, чтобы бобовый стебель (вероятно, в основном ожидает формирования облачной среды в бэкэнде) для применения.