Хостинг приложения Angular - на S3 - и WordPress - на EC2 - в одном домене с WordPress в подкаталоге

Я создаю англоязычный веб-сайт, на котором также будет небольшая установка WordPress для группы маркетинга / продаж (для создания целевых страниц). наша маркетинговая команда твердо убеждена, что субдомены вредны для SEO и GA, и хотела бы, чтобы установка WordPress находилась в подкаталоге. например:

example.com/ <- угловой example.com/marketing/ <- WordPress

Angular установлен на S3, WordPress установлен на EC2 (за балансировщиком нагрузки), и все это скрыто за дистрибутивом Cloudfront! на данный момент у меня почти все работает example.com/marketing/ Правильно загружает сайт WordPress, и example.com/ НАГРУЖАЕТ Угловой (и example.com/some-random-path правильно вызывает /index.html Угловой фронт-контроллер). проблема у меня в том что example.com/marketing/some-random-path ТАКЖЕ призывает /index.html Угловой фронт-контроллер, т.к. example.com/marketing/some-random-path Ошибки 404. но для работы WordPress, 404 с /marketing/ надо вместо этого ударить /marketing/index.php Фронт-контроллер WordPress.

Я посмотрел на лямбда-функции Amazon, но я не был уверен, как заставить это работать должным образом в сочетании с WordPress .htaccess, может, решение всех моих проблем лежит там?

а может есть другой способ настроить эту "подделку" /marketing/ подкаталог. является ли это обязательным требованием и / или передовой практикой в ​​отношении Cloudfront? ни один из наших других сайтов WordPress не является.

может быть, есть какая-то супер хитрая DNS, которую я могу сделать, о которой я не знаю?

Я открыт для альтернативных конфигураций; тот, который я описал, просто тот, который мне удалось выяснить до сих пор.

еще одно примечание, если это уместно: наши доменные имена зарегистрированы сторонним регистратором (dnsmadeeasy), а не Amazon; У dnsmadeeasy (немного?) более быстрое разрешение DNS, от которого другие люди, работающие здесь, не хотят отказываться. Я не уверен, что это имеет отношение к этой проблеме, но это сделало конфигурацию немного более проблематичной для меня, так что при случайном шансе, который мог бы иметь отношение, я подумал, что упомяну это.

1 ответ

Я сопоставил субдомены для каждого отдельного приложения (один субдомен для s3 и один для wordpress), а затем ввел прокси-сервер в корневом домене для маршрутизации в логические подкаталоги, которые были перенаправлены в субдомены, которые я ранее отображал. Это также может теоретически работать с IP-адресами, но мне проще использовать субдомены при работе с S3 в качестве веб-сайта и с EC2/ElasticBeanstalk. ПРИМЕЧАНИЕ. Я использовал эту конфигурацию с более чем 20 сайтами S3, сопоставленными в качестве каталогов под настраиваемым прокси-сервером Java. В зависимости от ваших требований вы должны решить, хотите ли вы использовать один сервер для запуска вашего WordPress или вы будете заниматься любым его масштабированием (например, запускать несколько экземпляров за балансировщиком нагрузки). Если в будущем вы выберете конфигурацию балансировки нагрузки на WordPress, то вам следует реализовать отдельный экземпляр для работы в качестве прокси-сервера для маршрутизации путей к каждому исходному источнику приложения. Если вы ищете простоту без учета масштаба, вы можете реализовать несколько виртуальных хостов на экземпляре сервера WordPress, а затем настроить пути прокси-сервера для s3 и вашей установки WordPress для структуры виртуального каталога.

Другие вопросы по тегам