размещение приложения Angular - на S3 - и WordPress - на EC2 - в одном домене, с WordPress в подкаталоге
Я создаю веб-сайт Angular, на котором также будет небольшая установка WordPress для отдела маркетинга / продаж (для создания целевых страниц). наша маркетинговая команда непреклонна в том, что поддомены вредны для SEO и GA, и хотели бы, чтобы установка WordPress находилась в подкаталоге. пример:
example.com/ <- Угловой
example.com/marketing/ <- WordPress
Angular установлен в корзине S3, WordPress установлен на EC2 (за балансировщиком нагрузки), и все это скрыто за дистрибутивом Cloudfront ! на данный момент у меня почти все работает: example.com/marketing/ ДЕЙСТВИТЕЛЬНО загружает сайт WordPress, а example.com/ ДЕЙСТВИТЕЛЬНО загружает Angular (и example .com / some-random-path правильно вызывает /index.html фронт-контроллер Angular). проблема, с которой я сталкиваюсь, заключается в том, что example.com/marketing/some-random-path ТАКЖЕ вызывает /index.html фронт-контроллер Angular, поскольку 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, от чего другие люди, работающие здесь, не хотят отказываться. Я не уверен, что это актуально для этой проблемы, но это сделало настройку немного более сложной для меня, поэтому, если это может быть актуально, я подумал, что упомянул бы об этом.
Я сопоставил поддомены для каждого отдельного приложения (один поддомен для s3 и один для wordpress), а затем ввел прокси-сервер в корневом домене для маршрутизации в логические подкаталоги, которые были переданы прокси-серверу в поддомены, которые я ранее сопоставил. Теоретически это также может работать с IP-адресами, но мне проще использовать поддомены при работе с S3 в качестве веб-сайта и с EC2 / ElasticBeanstalk. ПРИМЕЧАНИЕ. Я использовал эту конфигурацию с более чем 20 сайтами S3, отображенными как каталоги на настраиваемом прокси-сервере Java. В зависимости от ваших требований вы должны решить, хотите ли вы использовать один сервер для запуска WordPress или будете ли вы участвовать в каком-либо масштабировании с его помощью (например, запуск нескольких экземпляров за балансировщиком нагрузки). Если в будущем вы выберете конфигурацию балансировки нагрузки на wordpress, вам следует реализовать отдельный экземпляр для работы в качестве прокси-сервера для маршрутизации путей к каждому источнику вышестоящего приложения. Если вам нужна простота без учета масштабирования, вы можете реализовать несколько виртуальных хостов на экземпляре сервера wordpress, а затем настроить пути прокси для s3 и вашей установки WordPress в соответствии со структурой виртуальных каталогов.