Страница AWS ELB «извините, сайт не работает»

У меня есть базовый сайт ELB v2. Нет кластеризации или еще что-нибудь. Я довольно неопытен с AWS.

Мой стек nginx / uwsgi / django + некоторые другие сервисы.

Мне было интересно, есть ли у кого-нибудь мысли о том, чтобы сделать извинение, веб-сайт в настоящее время не работает ... - стиль страницы (пользовательский текст, который я могу обновить, запланированное время простоя - бонус!), Когда есть время простоя по какой-либо причине и состояние здоровья экземпляр красный. Не похоже, что Amazon предлагает такую ​​возможность - я что-то упустил? Есть ли способ создать отдельный, супер-крошечный экземпляр, который обслуживается ТОЛЬКО, если основным является красный или что-то в этом роде?

Спасибо!

Простое и классное решение - поставить ELB позади CloudFront.

Если исходный сервер (в данном случае ELB) выдает ошибку 5XX (или 4XX, если хотите), CloudFront может вернуть пользовательскую страницу ошибки , которую можно настроить для CloudFront для выборки из корзины S3, создав второе начало, указывающее на ведро и создание кэша поведения маршрутизации (например) /errors/static/*в ведро.

Это работает лучше, чем аварийное переключение на Route 53 по важной причине ... фатальный недостаток, если хотите ... браузеры ужасно относятся к кешированию DNS-запросов гораздо дольше, чем вы ожидаете. DNS TTL не имеет значения.

По сути, когда у браузера есть запись DNS, он просто пытается ее использовать ... обычно, пока все окна браузера не закрыты.

Поэтому, если ваш сайт отключается для посетителя, который уже был на сайте, он вряд ли увидит альтернативный сайт.

Хуже того, если посетитель впервые заходит на ваш сайт, пока он не работает, он будет «прилипать» к странице обслуживания, пока не закроет все окна браузера.

Если вы используете отказоустойчивый DNS, это действительно хорошо, если целью восстановления после сбоя по-прежнему является ваше приложение, может быть, еще дальше.

Вы можете отключить кеширование CloudFront, если оно вам не нужно.

Вы также можете настроить ненадлежащее значение для кэширования ошибок CloudFront на ненулевое значение, если хотите, чтобы он прекратил работу вашего сайта, пока он не работал, и пытался восстановиться. Для данной страницы, которая выдает ошибку, он будет продолжать отображать страницу ошибки и не будет беспокоить ваш сервер дополнительными запросами на эту страницу, пока не истечет Error CachingTTL.

Используйте Route53 DNS и аварийную маршрутизацию . Вы должны быть в состоянии получить ведро S3, размещающее одностраничный статический веб-сайт. Я не думаю, что вы можете сделать это только с ELB.

Amazon есть сообщение в блоге , который говорит вам , как сделать это здесь .

Обновление: как говорит Майкл, существует недостаток в кэшировании DNS браузера, см. Его ответ для получения дополнительной информации. Маршрут 53, вероятно, является более простым вариантом, чем CloudFront, но CF имеет и другие преимущества, производительность и в некоторых случаях может снизить затраты.

Уже упоминалось несколько решений, включая CloudFront и Route53. CloudFront - отличное решение, и, по моему опыту, ничего не замедлило, но оно приносит дополнительные затраты. А в Route53 уже упоминались проблемы с кэшированием DNS.

Пока ALB не поддерживает настраиваемые страницы ошибок из коробки (что может случиться или не произойти), после недавнего объявления о фиксированных ответах ALB потенциально может быть новое решение , но это не точка и щелчок: вы можете настроить функцию Lambda, которая временно добавляет правило для вашего балансировщика нагрузки, предоставляющее фиксированный ответ с содержимым «страницы ошибки».

Помимо написания лямбды, вам нужно будет найти способ вызвать его «вкл» и «выкл», что может быть возможно с помощью проверки работоспособности Route53 или проверки состояния целевой группы балансировщика нагрузки (возможно, с помощью тревоги CloudWatch -> SNS - > Лямбда).

Это не совсем просто, но, вероятно, будет хорошо работать после настройки!

Как написали @Tim и @Micheal, у вас есть выбор использования Route53 DNS и маршрутизации отработки отказа или CloudFront с пользовательскими страницами ошибок . Оба метода имеют свои плюсы и минусы.

Если вы еще не используете Cloudfront, я думаю, что Route53 является более простым решением. Смотрите обновленную запись в блоге от AWS (которая теперь включает в себя более простой метод интеграции ELB).

CloudFront гораздо сложнее в настройке, и для каждого обновления потребуется около 15 минут. Cloudfront также кеширует (как и следовало ожидать), поэтому неясно, будет ли ответ медленнее, чем проблемы с кешем DNS на маршруте 53.

Обратите внимание: если ваш веб-сайт ELB отвечает только на SSL, вы не можете использовать простое решение S3, описанное в блоге AWS 3 . В этом случае вам придется добавить Cloudfront перед корзиной S3 для добавления SSL, что усложнит решение для маршрутизации сбоев DNS.