Системная история
История портальной
системы началась как обычно с папки в которой располагались файлы
библиотек, модули, конфигурационные файлы и скрипт установки. В таком
состоянии система развивалась какое то время. Установка нескольких
сайтов на сервер делалась копия файловой файловой системы для каждого
сайта. Регулярно возникала ситуация когда нужно было вносить изменения
в код уже установленных систем. Добавлять новые возможности и исправлять найденные ошибки. Чтобы системы не различались меду собой и работали с
один алгоритмом, приходилось копировать файлы с измененным содержимым в
папку каждого хоста. Когда количество хостов перевалило за несколько
десятков а количество изменений вносимых в код стало частым процесс
копирования файлов в каждый из хостов стал напрягать. Особенно сложно
было с сайтами хранящимися на других физических серверах. В то же время при замене
части кода козникла и другая задача связанная с изменением структуры базы данных в
соответсвии с новой версией скриптов. Получалось что со временем версии
сайтов различались все больше чем раньше был создан сайт. Оставаясь одной системой каждый сайт не был точной копией остальных, различаясь в деталях каждый из
них работал по своему, имел свои особенности работы и структуру базы данных. Помимо этого были и другие трудности. Так
как каждый хост имел свои незначительные особенности копирование файлов
с обновленным кодом вызывало различную реакции в системе на файлы последних версий. В одном случае достаточно было внести небольшие изменения, в другом различия были
серьезнее и синхронихировать версии становилось очень затруднительно.
В этот момент передо мной встали две задачи. Первая - создать механизм который обеспечивал применение сделанных изменений ко всем проектам одновременно, сколько бы их ни находилось на сервере. При этом безопасность при взаимодействии сайтов должна оставаться на приемлемом уровне. Все сайты расположенные на сервере должны обновляться при изменении одного файла. Задача вторая - обеспечить возможность применение изменений к каждому из хостов так, чтобы дописав на определенный сайт что то однажды, все вносимые изменения в базовой системе не влияли на данную часть кода. Это может быть сайт с уникальным модулем. В дальнейшем внесенные исправления всегда должны оставаться независимо от версий основной системы. Изменения в нетронутой части системы должны оставаться доступны на данном сайте. Все новые модули, блоки и шаблоны также должы быть доступны в любом из сайтов.
Испробовав разные варианты решений данных вопросов, я остановился на мой взгляд на самом простом и эффективном. Решение было следующим. В качестве директории сайта применялось две папки с файлами. Папки имеют разный приоритет на исполнение и разные права доступа на изменения. Одна из них содержим самую последнюю версию портальной системы, имеет наименьший приоритет на исполнение, и работает лишь в том случае если файлы основной системы отсутствуют. Данная директория доступна для чтения всем сайтам расположенным на сервере. Вторая уникальна для каждого сайта. Содержащая только изменения отличные от базовой системы, и доступная для записи администратору данного сайта. Возможность записи обеспечивает изменение как любых участков кода системы, так и всего движка в целом. Веб сервер апач в качестве папки для запуска использует основную систему. Запускается на все сайты один код. Основная система при подключении каждого файла проверяется наличие в директории даннохо сайта файлов. Такие файлы имеют более высокий приоритет перед файлами основной системой и при их наличае им передается управление. Система передает управление на файл не с базовой диретории, а с директории исполняемого сайта.
Сразу же после установки папка хоста для сайта пуста. Системе доступны файлы с основной директории и исполнение передается им. В случае необходимости внести изменения в работу произвольного участок кода мы копируем в директорию сайта файл содержащий код в который нужно внести изменения. В директории уже возможны изменения. Данный файл имеен более высокий приоритет перед остальными файлами системы и при передаче урпавления файлу будет исполняться измененная нами копия файла.
Тем самым была решена проблема обновления всех сайтов при этом доступна фиксация части кода сайта. При изменении кода в основной директории он стал доступен всем хостам. При копировании какого-то файла из основной директории в директорию хоста этот код фиксируется и исполняется только на данном сайта. Обновления файла с копии в основной системе становится не доступно для данного сайта.
А теперь приведу несколько задач и примеры их решения в системе.
Задача: написать уникальный блок для одного из сайтов.
Решение: в директории хоста создается директория в которой хранятся блоки /include/blocks/мойблок.php. В его код вносится нужный код.
Результат: Мы имеем блок который виден только в списке хоста в директории которого он создан. Для других сайтов этот блок не досупен.
Задача: Переделать чать кода уже существующего в системе.
Решение: Копируем нужный блок в директрию с сайтом. Испрвляем часть кода в соответствии с задачей.
Результат: Данный блок виден как в основной системе, так и на сайте в котором мы его изменили. Но работают они по разному. Для всех сайтов работает код блока основной директоии системы. Для сайта работае код находящийся в файле блока в директории сайта. Все дальнейшие изменения данного блока системы не повлияют на блок на данном сайте.
Задача: Поменять код движка системы не прерывая работы всех сайтов.
Решение: Создается новая папка для хоста на котором будем проводить изменения. В корень копируется файл движка системы. index.php. Движок сделан так что в первых строках проверяет существование движка в директории сайта. Если в папке есть файл движка то система передает на него управление прекращая дальнейшую работу. Так как эти копии движка системы используют одни файлы то становится возможным изменение кода движка в рамках одного хоста. После внесения нужных изменений и тестирования кода файл движка копируется обратно в основную систему.
Результат. Можно менять файлы не только частей системы но и самого движка в целом. При копировании важно было сделать чтобы файл как корректно передавал управление сам так и продолжал корректно работать после передачи на себя же управление. Поэтому в движке системы есть некоторые особенности. Так производится проверка на существование функций обьявляемых в движке. Это связано сработой предпроцессора. Перед началом испольнения кода файла пхп проходит по его коду и обьявляет функции. Поэтому функции получаются обьявленными в случае если управление не доходит до его обьявления.
Делю вывод. Наибольшую ценность в данной системе представляет не код, любая часть которого может быть изменена. Не движок который реализует возможности системы, а сам подход к разработке. Появилась возможность запустить сотни или даже тысячи сайтов на одной копии файловой системы. Обеспечито обновления всех файлов не делая при этом тысячи копирований. Обеспециваем экономию места. При данном подходе не приходится хранить сотни едентичных копий одной и той же версии портальной системы.
В своем проекте я реализовал подобный подход. Добавли возможность привязки системы к любым доменным именам настроенным на сетевой адрес сервера. На одной из страниц сайта можно получить доступ по фтп протоколу к файловой системе зарегистрированного хоста. Очень просто менять любую часть кода системы или движок в целом.
В этот момент передо мной встали две задачи. Первая - создать механизм который обеспечивал применение сделанных изменений ко всем проектам одновременно, сколько бы их ни находилось на сервере. При этом безопасность при взаимодействии сайтов должна оставаться на приемлемом уровне. Все сайты расположенные на сервере должны обновляться при изменении одного файла. Задача вторая - обеспечить возможность применение изменений к каждому из хостов так, чтобы дописав на определенный сайт что то однажды, все вносимые изменения в базовой системе не влияли на данную часть кода. Это может быть сайт с уникальным модулем. В дальнейшем внесенные исправления всегда должны оставаться независимо от версий основной системы. Изменения в нетронутой части системы должны оставаться доступны на данном сайте. Все новые модули, блоки и шаблоны также должы быть доступны в любом из сайтов.
Испробовав разные варианты решений данных вопросов, я остановился на мой взгляд на самом простом и эффективном. Решение было следующим. В качестве директории сайта применялось две папки с файлами. Папки имеют разный приоритет на исполнение и разные права доступа на изменения. Одна из них содержим самую последнюю версию портальной системы, имеет наименьший приоритет на исполнение, и работает лишь в том случае если файлы основной системы отсутствуют. Данная директория доступна для чтения всем сайтам расположенным на сервере. Вторая уникальна для каждого сайта. Содержащая только изменения отличные от базовой системы, и доступная для записи администратору данного сайта. Возможность записи обеспечивает изменение как любых участков кода системы, так и всего движка в целом. Веб сервер апач в качестве папки для запуска использует основную систему. Запускается на все сайты один код. Основная система при подключении каждого файла проверяется наличие в директории даннохо сайта файлов. Такие файлы имеют более высокий приоритет перед файлами основной системой и при их наличае им передается управление. Система передает управление на файл не с базовой диретории, а с директории исполняемого сайта.
Сразу же после установки папка хоста для сайта пуста. Системе доступны файлы с основной директории и исполнение передается им. В случае необходимости внести изменения в работу произвольного участок кода мы копируем в директорию сайта файл содержащий код в который нужно внести изменения. В директории уже возможны изменения. Данный файл имеен более высокий приоритет перед остальными файлами системы и при передаче урпавления файлу будет исполняться измененная нами копия файла.
Тем самым была решена проблема обновления всех сайтов при этом доступна фиксация части кода сайта. При изменении кода в основной директории он стал доступен всем хостам. При копировании какого-то файла из основной директории в директорию хоста этот код фиксируется и исполняется только на данном сайта. Обновления файла с копии в основной системе становится не доступно для данного сайта.
А теперь приведу несколько задач и примеры их решения в системе.
Задача: написать уникальный блок для одного из сайтов.
Решение: в директории хоста создается директория в которой хранятся блоки /include/blocks/мойблок.php. В его код вносится нужный код.
Результат: Мы имеем блок который виден только в списке хоста в директории которого он создан. Для других сайтов этот блок не досупен.
Задача: Переделать чать кода уже существующего в системе.
Решение: Копируем нужный блок в директрию с сайтом. Испрвляем часть кода в соответствии с задачей.
Результат: Данный блок виден как в основной системе, так и на сайте в котором мы его изменили. Но работают они по разному. Для всех сайтов работает код блока основной директоии системы. Для сайта работае код находящийся в файле блока в директории сайта. Все дальнейшие изменения данного блока системы не повлияют на блок на данном сайте.
Задача: Поменять код движка системы не прерывая работы всех сайтов.
Решение: Создается новая папка для хоста на котором будем проводить изменения. В корень копируется файл движка системы. index.php. Движок сделан так что в первых строках проверяет существование движка в директории сайта. Если в папке есть файл движка то система передает на него управление прекращая дальнейшую работу. Так как эти копии движка системы используют одни файлы то становится возможным изменение кода движка в рамках одного хоста. После внесения нужных изменений и тестирования кода файл движка копируется обратно в основную систему.
Результат. Можно менять файлы не только частей системы но и самого движка в целом. При копировании важно было сделать чтобы файл как корректно передавал управление сам так и продолжал корректно работать после передачи на себя же управление. Поэтому в движке системы есть некоторые особенности. Так производится проверка на существование функций обьявляемых в движке. Это связано сработой предпроцессора. Перед началом испольнения кода файла пхп проходит по его коду и обьявляет функции. Поэтому функции получаются обьявленными в случае если управление не доходит до его обьявления.
Делю вывод. Наибольшую ценность в данной системе представляет не код, любая часть которого может быть изменена. Не движок который реализует возможности системы, а сам подход к разработке. Появилась возможность запустить сотни или даже тысячи сайтов на одной копии файловой системы. Обеспечито обновления всех файлов не делая при этом тысячи копирований. Обеспециваем экономию места. При данном подходе не приходится хранить сотни едентичных копий одной и той же версии портальной системы.
В своем проекте я реализовал подобный подход. Добавли возможность привязки системы к любым доменным именам настроенным на сетевой адрес сервера. На одной из страниц сайта можно получить доступ по фтп протоколу к файловой системе зарегистрированного хоста. Очень просто менять любую часть кода системы или движок в целом.
