Несколько сайтов, работающих на одной кодовой базе?

Question

Мы разрабатываем приложение, которое будет предлагаться в качестве хост-решения. Я поражен пониманием того, как я могу использовать несколько сайтов с одним и тем же кодом без дублирования базового кода.

например: веб-сайт 1: www.example.com и веб-сайт 2: www.sample.com будут работать с одним и тем же кодом, но будут иметь разные параметры конфигурации и другую тему ... как мы запускаем собственные доменные имена в WordPress.

Я хочу знать, как я могу это сделать.

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

Пожалуйста, помогите мне.

[разъяснение] это не псевдоним домена. как ... это будет услуга. где разным клиентам будет предложено одно и то же приложение на собственном доменном имени с разной темой. что-то вроде того, что делает блоггер .. с собственными доменными именами, но с тем же приложением блога

[технологии] в частности, я смотрю, как использовать имя хоста, чтобы определить, какую конфигурацию использовать мы используем PHP и MySQL

Answer 1

Повторное использование кода определенно желательно. Из ваших постов трудно представить, насколько сайты будут отличаться друг от друга. Мы говорим о логотипах, цветовых схемах или другой функциональности?

Я начну с другого внешнего вида. Я также предполагаю, что это единственное приложение на сервере.

Я рекомендую тщательно спланировать структуру каталогов. Что-то вроде:

www-root/  
   / lib  
   / themes
        / domain1  
        / domain2  


index.php:

<?php
$host = $_SERVER['HTTP_HOST'];
$include_theme = "themes/" . $host . "/configuration.php";
//make sure the file exists
require_once($include_theme);

Это упрощенный подход, но кое-что интересное.

Answer 2

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

Как правило, если вы работаете с несколькими сайтами, у вас должен быть свой сервер для каждого.

Edit:

Прочитав комментарии к другому ответу, я немного лучше понимаю ваш вариант использования.

Если у вас есть большое количество сайтов, для которых вы хотите использовать этот набор, если вы правильно спроектировали архитектуру и внедрили какую-то схему распределения нагрузки для обработки больших пользовательских нагрузок, вы могли бы сделать это.

Подведем итог:

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

Answer 3

Это очень просто на самом деле.

Ваша кодовая база может и должна быть одиночной. Вы загружаете его на hosting1 и hosting2. При обслуживании, как только вы обновите код, загрузите его на оба хостинга.

Полагаю, так работает и этот сайт. Посмотрите на нижний колонтитул страницы. У вас есть stackoverflow, meta, superuser и serverfault. Если вы посмотрите, что прямо сейчас написано в комментарии внизу справа, это будет "svn revision: 5404". Тоже самое. Одна кодовая база опубликована на четырех сайтах. Базы данных, конечно, разные и содержат совершенно разный контент.

Итак, переменные части:

1. Конфигурация

2. Настройка

3. Данные

Те, которые вам нужно скопировать.

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

Answer 4

В целях безопасности вы можете рассмотреть:

A) установить отдельное ограничение open_basedir для каждого хоста, чтобы загруженные пользователем файлы не могли быть доступны для других веб-сайтов, например: / shared_library / Host1 / user_images / Host2 / user_images

В разрешенные пути можно включать общие и доменные каталоги.

B) подключаться к отдельной базе данных для каждого хоста, чтобы предотвратить случайный захват любых запросов в ваших базах данных данных другого веб-сайта и упростить масштабирование серверов баз данных (например, перенести занятые домены на другой сервер базы данных) *

Если у вас очень простое приложение, вам может понадобиться одна база данных.

В любом случае у вас должна быть стратегия развертывания, чтобы ни один из сайтов не ломался при внесении изменений.

Answer 5

Мы делаем это с около 15 000 уникальных доменов прямо сейчас. Это не сложно, но для правильной реализации требуются некоторые конструктивные решения.

Вы можете сделать это на одной базе кода и на сервере и, по сути, просто построить свой код, чтобы полностью зависеть от значения HTTP_HOST входящего запроса. Тогда все, что в вашей базе данных, отключено от этого значения как средство правильного разделения данных и ответа на запрос с соответствующими данными / html.