Как сохранить Cloudfront пользовательская ошибочная страница в S3?
Мне включили Cloudfront на подсистеме балансировки нагрузки AWS.
Я видел в документации AWS, что могу настроить Cloudfront пользовательские ошибочные страницы. Я пытался сохранить эти ошибочные страницы в S3, как он рекомендуется в документе AWS, но он не работает. В документации говорится:
We recommend that you store custom error pages in an Amazon S3 bucket even if you're using a custom origin. If you store custom error pages on an HTTP server and the server starts to return 5xx errors, CloudFront can't get the files that you want to return to viewers because the origin server is unavailable.
Моя ошибочная страница находится в S3 с путем 'my-app-bucket/errorpage.html'.
Я пытался связать этот файл в конфигурации Cloudfront, но у меня есть следующая ошибка:
Если я пробую значение /my-app-bucket/errorpage.html, Cloudfront перенаправляет запрос к моему источнику ELB, и я получаю 404.
Кто мог объяснить меня, как я могу реализовать эту конфигурацию?
Это подсказки с http://blog.celingest. com/en/2013/12/12/ Cloudfront-configuring-custom-error-pages/
- Нужно добавить еще один CloudFront, указывающий на ведро, где находится ваша страница ошибки
- Поведение кэша нового... Созданное начало должно иметь Path Pattern, указывающую на папку (в ведре страницы ошибок), где находятся страницы ошибок
- Вы можете использовать этот путь в Response Page Path при создании Custom Error Response config
Для этого есть намного более простой способ, чем тот, который рекомендован f01. Включите статический хостинг веб-сайтов в S3, укажите страницу с ошибкой в S3, а затем используйте статический URL-адрес хостинга веб-сайтов в качестве источника для вашей корзины Cloudfront. Никаких особых проблем с путями, никакой настраиваемой конфигурации ответа на ошибку. Это просто работает. Очень просто.
Вот учебное видео, которое я сделал:
Этот ответ является расшифровкой отличного видео mbarlockers, так как это внешняя ссылка, которая может исчезнуть, я расшифровал ее здесь.
Это отличное видео, но оно снова страдает из-за того, что оно является внешней ссылкой. Я собрал все видео здесь:
- Создайте корзину в s3 с именем, совместимым с DNS (пока не используйте точки)
- Make ведро общедоступное
- Загрузите свою страницу, оставьте разрешения для объектов по умолчанию
- Выберите стандартное хранилище
- Без шифрования
- Протестируйте с использованием URL-адреса ведра, просмотрите сбой
- Протестируйте с использованием полного URL-адреса объекта, просмотрите сбой
- Go в политику корзины и создайте политику, позволяющую всем читать ваши объекты с помощью GetObject.
- Игнорировать предупреждение общедоступной политики.
- Попробуйте еще раз указать URL-адрес объекта. Должно сработать.
- Включите хостинг статических веб-сайтов в настройках корзины в свойствах.
- Заполните поля индексного документа и страницы с ошибкой, нам не нужны перенаправления, сохраните
- Проверьте URL-адрес, сгенерированный статическим веб-хостингом, и используйте его, а также протестируйте с использованием несуществующего пути, и вы увидите свой 404
- Зайдите в облачный фронт и создайте дистрибутив.
- Назовите имя источника как появившуюся ссылку корзины.
- Оставьте все параметры, кроме кэширования, и установите значение 1 день.
- Сохраните и дождитесь развертывания облачного дистрибутива.
- Теперь выполните тестирование с помощью URL-адреса облачной службы, а также проверьте и отслеживайте сбои.
- Вернитесь к распространению облачной службы, перейдите в раздел пользовательских страниц ошибок и создайте ответ на пользовательской странице ошибок.
- Укажите 403 Forbidden в качестве кода ошибки HTTP
- 300 секунд TTL
- Настройте ответ на ошибку
- установите путь страницы ответа к /error.html (или как там называется ваша страница ошибки)
- Изменить ответ код 404 не найден
- Вернитесь в браузер и повторите попытку с неверным URL-адресом. Будет показана страница ошибки.