НАСТРОЙКА
У нас есть система управления веб-сайтами, похожая на webs / wix / etc, которую мы пытаемся использовать с CloudFront. Он имеет следующие домены и поддомены.
- ourdomain: наш основной сайт
- admin.ourdomain: интерфейс администрирования каждого веб-сайта, доступный через https
- images.ourdomain: корзина S3
- router.ourdomain: см. ниже
- [customersomething] .ourdomain: субдомены для наших бесплатных пользователей
- [customersomething.com]: домены для наших премиум-клиентов
Система работает таким образом, что большинство доменов имеют CNAME-d для router.ourdomain (потому что это был самый простой способ для наших клиентов с их различными регистраторами доменов и т. Д.), А router.ourdomain имеет A-псевдоним для нашего ELB, а затем PHP на наших EC2 обрабатывают сайты на основе значений HTTP_HOST, в то время как изображения поступают из S3.
НАШ ПЛАН
А теперь мы хотим поместить все это в CloudFront. Большая часть вещей тривиальна. Было легко поставить S3 позади CF. Было легко разместить каждый наш домен / *. (Js | css) за CF через поддомен asset.ourdomain. Приятно, что мы можем использовать * .images.ourdomain для сегментирования между поддоменами «на лету», уменьшая время загрузки на стороне клиента и т.д. в параметры CF.
ЭТА ПРОБЛЕМА
Но единственное, чего мы не можем понять, - это как разместить все динамически созданные PHP-сайты с пользовательскими доменами за CF. Напоминаем: это CNAME-d для router.ourdomain. Включение каждого домена в параметры CF не является вариантом, так как нам нужно иметь возможность обрабатывать десятки тысяч доменных имен, и нам нужно делать это без ручной настройки каждого из них.
Поэтому мы думали, что мы должны поместить router.ourdomain в конфигурацию CF как альтернативное доменное имя, указать router.ourdomain на CF на маршруте 53 и указать CF на наш ELB в качестве источника. Как мы выяснили, хороший способ получать это сообщение каждый раз: «ОШИБКА. Запрос не может быть удовлетворен. Неверный запрос. Создан облачным фронтом (CloudFront)». Фактически не каждый время, как www.ourdomain работает должным образом (это CNAMEd для router.ourdomain), но каждый другой поддомен дает указанную выше ошибку (* .ourdomain является CNAMEd для router.ourdomain, но то же самое происходит даже для тех поддоменов, которые CNAMEd to router. ourdomain по одному, кроме www и, конечно же, маршрутизатора). Так что прямо сейчас мы не просто не знаем, как нам решить эту проблему, мы даже не понимаем, почему это работает для www, если не работает для всех остальных, или наоборот.
Любые мысли и идеи будут оценены, спасибо.
Напоминаем: это CNAME-d для router.ourdomain
Да, вы упомянули об этом. Вот в чем дело:
Это не имеет значения.
Да, CloudFront называет альтернативные имена хостов CNAME. Да, DNS-запись CNAME - это типичный способ маршрутизации трафика данного сайта на CloudFront. Но нет, настройка имени хоста как CNAME, указывающего на ваш дистрибутив CloudFront, не имеет отношения к тому, что сейчас работает Cloudfront или HTTP в целом.
Когда браузер хочет подключиться к веб-серверу, он ищет IP-адрес в DNS. Если в пути есть CNAME, эта информация отбрасывается. Все, о чем заботится браузер, - это «к какому IP-адресу мне подключиться?»
Допустим, www.example.org был CNAME для webfarm.example.com. Браузер ищет www.example.org и получает IP-адрес webfarm.example.com.
Получив ответ, браузер устанавливает соединение с веб-сервером и отправляет запрос.
GET / HTTP/1.1
Host: www.example.com
В Host: Заголовок http-запроса, отправленного браузером, содержит имя хоста, как показано в адресной строке. Информация CNAME полностью недоступна и неизвестна ни браузеру, ни веб-серверу.
Итак, какое значение имеет CNAME для синтаксического анализа запросов и маршрутизации уровня 7? Не может быть. Цель CNAME используется только как путь для поиска IP-адреса для подключения.
Ваш дистрибутив - не единственный, кто использует эти IP-адреса в Cloudfront. Есть сотни или тысячи других. Все сводится к Host: заголовок.
Список "CNAME" (альтернативные имена хостов) - это набор имен хостов, которые CloudFront должен сопоставить во входящей Host: заголовок, чтобы определить, что запрос следует рассматривать как принадлежащий ваш распространение. Это список Host: заголовки, которые может отправлять браузер. До Host: заголовок соответствует настроенному значению в распределении, распределение, связанное с этим запросом, неизвестно и не определено.
Что делает Cloudfront, если он не может соответствовать входящему Host: заголовок с какой раздачей?
HTTP/1.1 400 Bad Request
Итак, поведение, которое вы видите, ожидаемое и правильное. Подстановочные знаки работают в конфигурации CloudFront, если они составляют единственный крайний левый элемент в строке конфигурации альтернативного имени хоста. Но это не имеет отношения к DNS.
Вы не можете избежать настройки других, принадлежащих клиентам доменных имен в CloudFront, если хотите, чтобы они использовались в вашем распределении.
Однако вы можете изменять их программно через API, а не вручную:
http://docs.aws.amazon.com/AmazonCloudFront/latest/APIReference/PutConfig.html
Существует ограничение в 100 таких псевдонимов на один дистрибутив, но вы можете запросить увеличение, отправив форму в службу поддержки AWS. По правде говоря, вы могли бы с таким же успехом разбить их на несколько дистрибутивов, потому что CloudFront не будет кэшировать объект по заданному пути с одним хостом в запросах esders и возвращать его как кешированный ответ для другого host, даже в том же дистрибутиве, если вы перенаправляете заголовок хоста на исходный сервер (что вам необходимо сделать, если исходный сервер должен иметь возможность отличить). Не может, потому что важный параметр в запросе изменился от одного запроса к другому.