У нас есть веб-сайт, который мы обслуживаем из Elastic Beanstalk (AWS), и все он отлично работает. Мы используем встроенный балансировщик нагрузки для обслуживания нашего сайта через HTTPS и т. Д. Наша база данных разделена через службу RDS, а не на тех же экземплярах EC2, что и наши веб-серверы. Пока мы довольны настройкой.
Теперь мы хотели бы создать блог WordPress в разделе «/ blog» в домене нашего сайта (а не в отдельном или субдомене по причинам SEO). Наш сайт представляет собой специально созданное PHP-приложение (с использованием фреймворка Laravel), и я бы предпочел не размещать приложение WP и наш сайт в одном месте.
Я считаю, что мы можем использовать CloudFront (CDN Amazon) для обслуживания только части / blog нашего сайта и перенаправления этих запросов на отдельную установку WP на разных инстансах EC2. Я использовал CloudFront, чтобы делать обычные вещи типа CDN (статические ресурсы), но я немного не понимаю, как настроить этот конкретный тип конфигурации.
Во-первых, это безумная идея или звучит нормально? Во-вторых, если это разумно, что мне нужно знать, чтобы это настроить?
Да, можно, если вы настроили весь сайт для работы за CloudFront. Затем вы можете настроить внутреннюю службу источника по умолчанию для сайта и вырезать исключение, чтобы выбрать другой путь для / blog.
Настройте новую раздачу CloudFront. Используйте в качестве источника имя хоста ELB или EB основного сайта. Настройте доменное имя сайта в качестве альтернативного доменного имени в CloudFront.
Затем добавьте второй источник с местом назначения, являющимся именем хоста, на котором может быть достигнуто развертывание WP. Создайте поведение с образец пути что соответствует /blog* и использует второе происхождение.
(Если / blog * соответствует чему-либо, что находится в корне сайта ... маловероятно, но скажем, что у вас есть другая страница в корне с именем / blogosphere, это будет неправильно сопоставлено, поэтому вам действительно нужно создать два шаблона, / блог и / блог / *).
Попался: обратите внимание, что при создании исходной точки есть поле для исходный путь. Вероятно, это не соответствует вашим ожиданиям. Если не уверены, оставьте поле пустым.
Путь к источнику - это префикс, который Cloudfront должен добавлять к запросу, который он отправляет источнику, даже если он не отображается в URL-адресе. Итак, если вы установите для этого параметра / test и запрос от браузера был для / blog, внутренний сервер увидит, что запрос поступает для / test / blog.
Путь к источнику позволяет вам добавить путь к запрашиваемому пути, в противном случае входящий путь будет отправлен в том виде, в котором он был получен от браузера. Это означает, что при установке WP корень содержимого должен находиться в /blog когда вы подключаетесь напрямую к серверу WP, а не в /. CloudFront в настоящее время не предоставляет никакого механизма для удаления компонентов из пути.
Не забудьте также включить пересылку строки запроса и файлов cookie в серверную часть WordPress в той мере, в какой это необходимо для работы WordPress по мере необходимости. То же самое, конечно, верно и для вашего основного сайта.
Вам может понадобиться белый список то Host: заголовок, если ваш сервер этого ожидает. Возможно, другие, в зависимости от того, какие заголовки должны видеть серверы, но, как правило, чем больше заголовков вы пересылаете, тем меньше кэширует CloudFront, потому что, если он пересылает заголовок источнику, он должен предполагать, что любой последующий запрос, в котором заголовок меняется, может получить другой ответ от сервера, поэтому запрос не может быть обработан из кеша, если не совпадают все перенаправленные заголовки.
В конечном итоге, после настройки и тестирования, вы укажете свое имя хоста конечной точке CloudFront, и все будет готово.