Хостинг нескольких веб-сайтов на одном сервере

Question

У меня есть куча разных сайтов, в основном случайных проектов выходных дней, которые я хотел бы оставить в Интернете, потому что они все еще мне полезны. Они не видят более 3-5 ударов в день между всеми из них, поэтому я не хочу платить за сервер за каждого из них, когда я, возможно, поместил их все на одном экземпляре EC2 micro. Это возможно? Все они убегают от разных веб-серверов, поскольку я предпочитаю экспериментировать с большим количеством новых технологий. Я думал, что каждый веб-сервер может обслуживать другой порт, а затем отправлять входящие запросы app1.com до app1.com:3000 и запрашивать app2.com, чтобы получить маршрут до app2.com:3001 и так далее, но я не знаю, как бы я решил настроить это ,

Answer 1

Я хотел бы предложить, что вы ищете является reverse web proxy,, который обычно включает в себя среди его особенностей способность понимать части запроса на слой 7, и направлять входящий трафик на соответствующий набор одной или нескольких комбинаций ip/port на основе того, что наблюдается в заголовках запроса (или других аспектах запроса).

Apache, Varnish и Nginx имеют эту емкость, как и HAProxy, что является подходом, который я использую, потому что он кажется очень быстрым и легким в памяти и, следовательно, подходит для использования на микро-экземпляре ... но это вовсе не означает, что это как-то более «правильно» использовать, чем другие. Принцип один и тот же с любым из этих вариантов; только детали конфигурации различны. Одна служба слушает порт 80 и на основе запроса передает его на соответствующий серверный процесс, открывая TCP-соединение с соответствующим пунктом назначения, связывая концы двух труб вместе и, в большинстве случаев, оставаясь вне путь.

Вот один из способов (среди нескольких альтернатив), что это может выглядеть в HAproxy конфигурационного файла:

frontend main 
    bind *:80 
    use_backend app1svr if { hdr(host) -i app1.example.com } 
    use_backend app2svr if { hdr(host) -i app2.example.com } 

backend app1svr 
    server app1 127.0.0.1:3001 check inter 5000 rise 1 fall 1 

backend app2svr 
    server app2 127.0.0.1:3002 check inter 5000 rise 1 fall 1 

Это говорит прослушивает порт 80 всех локальных IP-адреса; если заголовок «Host» содержит «app1.example.com» (-i означает нечувствительность к регистру), используйте конфигурацию брандмауэра «app1» и отправьте запрос на этот сервер; сделать что-то подобное для app2.example.com. Вы также можете объявить default_backend для использования, если ни один из ACL не соответствует; в противном случае, если нет совпадения, он вернет «503 Service Unavailable», что и будет возвращено, если запрошенный сервер не работает в настоящий момент.

Вы также можете настроить конечную точку статистики, чтобы показать текущее состояние и статистику трафика ваших интерфейсов и бэкэндов в таблице HTML.

Поскольку браузер не подключается непосредственно к веб-серверу, вам необходимо настроить и использовать заголовок X-Forwarded-For, вставленный в заголовки запроса, чтобы определить IP-адрес браузера, и есть другие способы, которыми вашим приложениям, возможно, придется учитывать прокси-сервер, но эта общая концепция заключается в том, как обычно масштабируются веб-приложения, поэтому я не вижу в этом существенного недостатка.

Примечание эти примеры используют «Анонимные списки ACL,» из которых документация говорит:

Это, как правило, не рекомендуется использовать эту конструкцию, потому что это намного проще , чтобы оставить ошибки в конфигурации, когда написано, что путь. Однако для очень простых правил, соответствующих, например, только одному исходному IP-адресу, он может использовать смысл , чтобы использовать их, чем объявлять списки ACL со случайными именами.

^{— http://cbonte.github.io/haproxy-dconv/configuration-1.4.html}

Для простых правил, как эти, эта конструкция имеет больше смысла для меня, чем явно объявляя ACL, а позже с помощью этого ACL, чтобы вызвать действие, которое вы хотите, потому что он ставит все вместе на одной линии.

Я использую это, чтобы решить другую проблему с корнем, которая имеет те же симптомы - несколько сайтов для проектов разработки/тестирования, но только один возможный внешний IP-адрес (который по определению означает, что «порт 80» может перемещаться только в одном месте). Это позволяет мне «запускать» проекты разработки и тестирования на разных портах и ​​платформах, все за единственным внешним IP-адресом моей домашней DSL-линии. Единственное различие в моем случае состоит в том, что разные сайты иногда находятся на одной машине, такой как haproxy, и в других случаях это не так, но приложение выглядит иначе идентичным.

Answer 2

Изменение маршрута в пути, которое вы показываете, зависит от ОС, на которой размещается ваш сервер. Для linux вы должны использовать iptables, для окон вы можете использовать брандмауэр Windows. Вы должны установить все входящие подключения к порту 80, чтобы быть перенаправлены сделать нужный порт 3000

Но вместо порта, вы можете использовать другое имя хоста для каждого сервиса, как
app1 .apps.com
приложение2 .apps.com
и так далее. Вы можете настроить его с перенаправлением на свой DNS-хостинг, для apps.com
ИМХО это лучшее решение, если бы я получил вас правильно.

---

Кроме того, вы можете настроить один хост для перенаправления всех других сайтов, как
app1.com:3001 -> apphost1.com
app1.com:3002 -> apphost2.com
Тейк в этом случае весь трафик будет проходить через app1.com.

Answer 3

Вы можете легко сделать это. Настройте другое имя хоста для каждого приложения, которое вы хотите использовать, создайте запись DNS, указывающую на ваш экземпляр micro, и создайте запись виртуального хоста на основе имени для каждого приложения.

Каждая запись виртуального хоста должна выглядеть примерно так:

<VirtualHost *> 
    ServerName app1.example.com 
    DocumentRoot /var/www/html/app1/ 
    DirectoryIndex index.html 
</VirtualHost>