Что мне нужно сделать сейчас, это указать эту папку /blog на этот экземпляр. Я полагаю, мы должны сделать это с помощью Amazon Route 53? Я даже пытался сделать это, но, очевидно, я мог бы создать CNAME для blog.myapp.com а не папку /blog . И мы действительно хотим, чтобы это было на www.myapp.com/blog . Должен ли я использовать что-то вроде .htaccess?
Короткий ответ.
Короче говоря, то, что вы описываете - как вы это описываете - не может работать. Хотя blog/ является каталогом / папкой / путем к главному экземпляру Amazon EC2 на сайте www.myapp.com , вы путаете концепцию серверов и путей к веб-URL; ака: каталоги, папки и пути.
Если вы запускаете новый экземпляр Amazon EC2, вы настраиваете совершенно новый сервер. И два сервера с одним и тем же базовым именем хоста www.myapp.com но только один имеет правильный путь /blog просто не могут быть.
Если вы хотите разделить этот сайт по серверам, лучше всего настроить новый экземпляр Amazon EC2 с поддоменом blog.myapp.com и просто перенаправить весь трафик с первого экземпляра на сайте www.myapp.com/blog на этот новый поддомен. / хост.
Более подробная информация ниже.
Более длинный ответ.
Итак, у вас есть два экземпляра Amazon EC2:
- EC2 Экземпляр 1: хостинг
www.myapp.com .
- Экземпляр EC2 2. Вы хотите разместить
www.myapp.com/blog .
Во-первых, это не имеет никакого отношения к Amazon Route 53, который является службой DNS Amazon. Все, что делает Amazon Route 53, - это управление записями DNS для таких вещей, как имена хостов и IP-адреса назначения. Простой способ понять это - что-нибудь слева от первого пути (/) в URL - это имя хоста. Итак, в вашем примере:
www.myapp.com/blog
Это имя хоста www.myapp.com .
Поэтому попытка «перенаправить» www.myapp.com/blog с экземпляра EC2 1 на экземпляр EC2 2 через CNAME никогда не произойдет. Технически это невозможно, и вот почему:
- Во-первых, запись DNS никогда не может быть установлена для данных пути справа от
/ в URL.
- Во-вторых, вы бы в основном заявили, что хотите, чтобы экземпляр EC2 1 и экземпляр EC2 2 имели одно и то же точное имя хоста
www.myapp.com то время как только экземпляр EC2 2 имел бы blog/ что технически невозможно в том смысле, в каком это подразумевает ваш вопрос.
Более реалистичным решением было бы настроить новый поддомен через Amazon Route 53, чтобы установка нового экземпляра Amazon EC2 была такой:
- EC2 Экземпляр 1: хостинг
www.myapp.com .
- EC2 Экземпляр 2: будет хостом
blog.myapp.com .
В таком случае вы можете настроить правило перезаписи Apache, чтобы все запросы трафика, направленные на www.myapp.com/blog переходили на blog.myapp.com . Очень жизнеспособно и легко сделать с помощью такой команды .htaccess :
RewriteEngine On
RewriteRule ^blog(/.*)?$ http://www.newdomain.com/ [R=301]
Вы просто поместите его в файл .htaccess расположенный в корне сайта www.myapp.com и он перенаправит весь трафик с экземпляра 1 EC2, идущего в blog/ на blog.myapp.com .
Еще одна вещь: плюсы и минусы использования обратного прокси-сервера Apache.
Таким образом, все вышесказанное говорит, что комментатор действительно использует потенциальные возможности настройки и обратного прокси- сервера Apache для передачи запросов, отправляемых по www.myapp.com/blog в экземпляре EC2 1 на blog.myapp.com в экземпляре EC2 2. Да, это технически позволило бы достичь целей, изложенных в первоначальном вопросе, но это открывает потенциальную червячную банку:
- Сложность настройки обратного прокси-сервера Apache. Теперь я не говорю, что концепция обратного прокси-сервера настолько сложна, что обычный пользователь не может научиться его использовать. Это на самом деле немного просто понять, как только вы это освоите. Но сложность возникает из-за необходимости настройки конфигураций Apache и управления ими в течение всего срока установки. Например, в некоторых магазинах веб-разработки это может считаться задачей DevOps. И некоторые разработчики могут не захотеть иметь дело с необычной задачей DevOps, подобной этой.
- Обратный прокси- сервер означает, что оба сервера получают трафик: поскольку обратный прокси-сервер является в основном «каналом», который направляет трафик от одного сервера к другому, трафик, предназначенный для экземпляра EC2, все равно должен будет проходить через экземпляр EC2 1. Если цель установки отдельных экземпляров Amazon EC2 состоит в том, чтобы убедиться, что один сервер не влияет на другой, обратный прокси-сервер может быть проблематичным. Скажем, тонны трафика - от реальных пользователей или атак - идут на
www.myapp.com/blog , что происходит? Главный сервер в EC2-экземпляре 1 получает этот трафик, а также EC2-экземпляр 2 ; поэтому оба сервера потенциально уязвимы. Напротив, простой RewriteRule для пересылки трафика на поддомен является легким / незначительным с точки зрения загрузки, и так как большинство пользователей в любом случае попадут в блог на поддомене blog.myapp.com , оба сервера изолированы / отделены от трафика, который получает каждый.
- Оба сервера недоступны для главного сервера. Сбои: очень просты для понимания. Если EC2 Instance 1 управляет трафиком для
www.myapp.com/blog а также основным контентом на www.myapp.com , если этот сервер не работает, оба сайта недоступны. Наличие субдомена, такого как blog.myapp.com означает, что даже если основной сервер на www.myapp.com выйдет из строя , blog.myapp.com по-прежнему будет доступен.
Тем не менее, если вы хотите изучить использование настройки обратного прокси-сервера Apache, у меня есть два ответа на сбой сервера - этот и этот, которые объясняют базовую конфигурацию и настройку.
Обратите внимание, что эти публикации посвящены Solr и другим приложениям Java/Tomcat, использующим порт 8080 и тому, как я использую Apache Reverse Proxy, чтобы упростить свою жизнь, поскольку Tomcat - это сложная задача для настройки / управления, по моему скромному мнению. Обратный прокси-сервер Apache позволяет мне использовать относительно простые для понимания конфигурации Apache для управления фронтальным веб-доступом сайта, вместо того, чтобы справляться с причудами Tomcat. Но общие концепции можно легко адаптировать из использования в настройке обратного прокси-сервера Apache-to-Apache.
