Ответы пользователя по тегу Yii
  • Как правильно создать конструктор сайтов?

    dubr
    @dubr
    пыхарь
    В этом сезоне модно создавать конструкторы вот так!

    Если серьезно - вы объясните, в чем проблема - в части devops, в смысле как БД создать / nginx перегрузить и т.д., или в части того, что на сайте будет и как юзер будет этим управлять? Если первое - надо понимать ваши масштабы, сколько сайтов, сколько серверов, размер бд, нагрузки. Если второе - то начать надо явно с тз и дизайна, а то ишь приноровились все на кодера сваливать )))

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

    Вообще алгоритм довольно тупой - сначала сделать все руками, а потом написать скрипт, который делает то же самое =)

    Для начала определитесь, будут ли все ваши сайтики работать на одной кодовой базе (скорее всего да, если нет - это уже ближе к шаред-хостингу). Дальше решите, нужен ли каждому свой персональный docroot - это зависит от того, как вы храните / раздаете статику. Если статика складывается куда-то далеко (типа на s3) - можно обойтись одним на всех, но ИМХО все-таки проще, когда он у каждого свой.

    Получится какая-то такая структура:

    app
    public
        1
            static
            index.php
            config.php
        2
        ...


    index.php подключает конфиг и запускает приложение.

    Дальше вам надо сделать, чтобы public/1 открывался по хосту типа 1.hosting.com - это nginx с регулярками.

    server {
        server_name   ~^(?<site_id>.+)\.hosting\.com$;
        root    /var/www/public/$site_id;
        ...
    }


    Кстати, если пыхе понадобится идентификатор сайта, его туда легко забросить:
    fastcgi_param SITE_ID $site_id;

    Есть нюанс с запуском PHP. По уму надо, чтобы на каждого был свой юзер, свой fpm-пул и т.д. Но у php-fpm в свое время не работал graceful reload, после добавления пула и перезапуска все клиенты получали 502. Я в итоге плюнул и стал всех обслуживать одним пулом, ограничившись open_basedir, но если у юзера есть хотя бы гипотетическая возможность добраться до кода (например какой-нибудь редактор шаблонов) - так делать не надо =) open_basedir передаем в конфиге нгинкса как-то так:

    fastcgi_param  PHP_ADMIN_VALUE "open_basedir = $document_root"


    Для подключения собственного домена юзайте map, он в нгинксе хороший =)
    map $http_host $site_id {
        site.com    1;
        site2.com  2;
    }

    Эту конструкцию можно вытащить в отдельный файл и генерить автоматом.

    С БД все просто: если можете сделать, чтобы все сидели в одной БД - так и делайте =) Если нет - делайте эталонный дамп и скрипт, который из него создает новую БД. И потом ломаем голову, как раскатывать миграции по куче баз и машин =)

    С управляющим скриптом поступаем так: фигачим сами скрипты (на чем удобно, пхп вполне справится) и http api к ним, когда юзер что-то делает на "главном" сайте, дергается этот api, это облегчит жизнь, когда перестанете влезать на один сервер.

    Для перезагрузки нгинкса и прочих стремных операций я завел отдельные sh-скрипты и засунул их в sudoers для того юзера, от которого работает api.

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

    В принципе все просто, но это конечно самодеятельность на коленке =) Мануала "пишем конструктор сайтов для чайников" я не нашел, да и вообще их живых не так много, опытом никто особо не делится. Мне больше всего помогло изучение работы шаред-хостингов, хотя и про инфы маловато.
    Ответ написан
    3 комментария