Apache & Nginx. Связаны одной цепью

    Как реализована связка Apache & Nginx в Timeweb

    Для многих компаний Nginx + Apache + PHP — очень типовая и распространенная связка, и Timeweb здесь не стал исключением. Однако разобраться, как именно она реализована, может быть любопытно и полезно.

    image

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

    Основные настройки Apache выполняются в конфигурационных файлах самого Apache, а настройки для клиентских сайтов происходят через файл .htaccess. .htaccess — конфигурационный файл, в котором клиент может самостоятельно настроить правила и поведение веб-сервера. Такая настройка будет относиться конкретно к его сайту. Например, благодаря функционалу Apache пользователи могут менять режим работы в рамках одной версии PHP с mod_php на mod_cgi; можно настраивать редиректы, оптимизацию для SEO, удобный URL, некоторые лимиты для PHP.

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

    Представим, что какой-то пользователь заходит на сайт нашего клиента. Сначала пользователь попадает на Nginx, который отдает статический контент. Это происходит мгновенно. Затем, когда дело доходит до загрузки PHP, Nginx перенаправляет запрос на Apache. И Apache совместно с PHP уже генерирует динамический контент.

    Особенности связки Apache & Nginx в Timeweb


    На нашем виртуальном хостинге реализованы 2 основные схемы работы Apache & Nginx: Shared и Dedicated.

    Схема Shared

    Эта схема используется для большинства пользователей. Ее отличает простота и ресурсоемкость: Shared-схема использует меньше ресурсов, поэтому и ее тариф дешевле. Согласно данной схеме на сервере запущен один Nginx, который позволяет обслуживать все пользовательские запросы, и несколько экземпляров Apache.

    Схема Shared совершенствовалась долгое время: постепенно мы исправляли недочеты. Удобно, что ее можно сделать без необходимости дорабатывать исходный код.


    схема Shared

    Схема Dedicated

    Dedicated требует больше ресурсов, поэтому ее тариф дороже для клиентов. В Dedicated-схеме для каждого клиента поднимается свой, отдельный Apache. Ресурсы здесь резервируются под клиента, они выделяются эксклюзивно. Как это работает: на сервере есть несколько версий PHP. Мы поддерживаем версии 5.3, 5.4, 5.6, 7.1, 7.2, 7.3, 7.4. Так, для каждой версии PHP запускается свой Apache.


    схема Dedicated

    Safe zone. Настройка зон в Nginx


    Ранее для Nginx мы использовали много зон разделяемой памяти (zone) — один блок server на один домен. Такая настройка требует большого количества ресурсов, так как для каждого сайта создается отдельная зона. Однако в настройках Nginx большинство сайтов однотипные, поэтому их удается поместить в одну зону благодаря использованию директив map в модуле ngx_http_map_module, которые позволяют задать соответствия. Например, у нас есть шаблон зоны, в которую мы должны поставлять переменные: путь к сайту, версию PHP, пользователя. Таким образом, ускорилось перечитывание конфигурации Nginx, то есть релоад.

    Подобная конфигурация сильно сэкономила ресурсы оперативной памяти и ускорила работу Nginx.

    Reload не пройдет!


    В Shared-схеме мы избавились от необходимости перезагрузки (релоада) Apache при изменениях в настройках сайтов. Ранее, когда один клиент хотел добавить домен или поменять версию PHP, требовался обязательный релоад Apache, что приводило к задержкам в ответах и негативно сказывалось на производительности сайтов.

    Мы избавились от релоадов путем создания динамических конфигураций. Благодаря mpm-itk (модулю Apache), каждый процесс выполняется от отдельного пользователя, что повышает уровень безопасности. Такой способ позволяет передавать из Nginx в Apache2 данные о пользователе и его document_root. Таким образом, Apache не содержит в себе конфигурации сайтов, он получает их динамически, и релоады больше не требуются.


    Конфигурация схемы Shared

    А как же Docker?


    Многие компании перешли на систему, основанную на контейнерах. Timeweb сейчас рассматривает возможность такого перехода. Безусловно, в каждом решении можно найти плюсы и минусы.

    Наряду с неоспоримыми преимуществами, в контейнерной системе пользователю предоставлено меньше ресурсов. В Timeweb, благодаря описанной схеме работы хостинга, у пользователя нет ограничения в оперативной памяти. Он получает больше ресурсов, чем в контейнере. Кроме того, у юзера может быть загружено больше модулей Apache.

    Timeweb обеспечивает работу около 500 000 сайтов. Мы несем большую ответственность и не вносим мгновенные, неоправданные изменения в сложную архитектуру. Связка Apache & Nginx надежна и проверена временем. Мы, в свою очередь, стараемся достичь максимальной производительности благодаря уникальным конфигурациям.

    Для качественной и быстрой работы большого количества сайтов требуется использовать шаблонную и динамическую конфигурацию Apache и Nginx. Она позволяет просто и быстро администрировать большое число однотипных серверов.
    Timeweb
    VDS, виртуальный хостинг, домены, серверы

    Похожие публикации

    Комментарии 50

      +8
      Извините, я правильно понял что единственная причина того что apache все ещё у Вас используется — это возможность редактирования htaccess пользователями?

      Просто за вычетом этой возможности, nginx давно уже сам с php взаимодействует
        +6
        я вот тоже думаю, зачем здесь Apache?
          0
          Здравствуйте!

          Apache используется, чтобы была возможность редактировать .htaccess. Это позволяет клиентам самостоятельно настраивать поведение веб-сервера.
          0
          Здравствуйте!

          Спасибо за вопрос. Да, всё верно: чтобы редактировать .htaccess. Так как это важно для наших клиентов.
            0

            Я уже сколько времени пытаюсь выяснить что ещё может дать связка nginx и apache, кроме .htaccess, чтобы имелся смысл тащить apache. Сам от shared-хостинга ушёл и взял дешёвую VDS, которой не достаточно. Раз свой сервер, то проще нужные правила .htaccess в настроках виртуального хоста прописать.
            Так. О чём это я? А!!! Кто знает ещё причины необходимости использования Apache?

              0

              Мод секюр иногда под него бывают специфичные правила.

              0
              Многие плагины для того же wordpress все так же работают посредством htaccess + многие cms не дают адекватного конфига для Nginx, а сразу отвечают на такой запрос — ставьте apache2… Л — лень.
                –4

                Да, тот же Битрикс (если сайт чуть сложнее чем одностраничная визитка) удобнее держать на связке nginx + apache. Кроме того если "не жалеть заварки" то особой выгоды от использования только nginx нет. Расшифрую — если оперативки хоть попой ешь то связка nginx + apache ничуть не "медленне" чем nginx + php-fpm если всё грамотно настроить. Если же с оперативной беда, то да прожорливый до неё apache стоит исключить.

                  0
                  На самом деле на бакенде apache+mod_php кушают примерно столько же, сколько php-fpm при одинаково настроенных пулах. Так что выбор того или другого бакенда — вопрос больше личных предпочтений.
                    0
                    на самом деле смысл не в озу, а смысл в самом Nginx, при тех же настройках для бекенда, wordpress на nginx Работает быстрее

                    как у вас я хз
                      –2

                      Где "быстрее"? В чём "быстрее" ?


                      nginx больше одновременных соединений удержит чем nginx+apache, но "быстрее" чтобы была заметная разница не будет !

                        0
                        Скорей всего за счет прямой отдачи статики. С апачем в зависимости от типа многопроцессной работы — prefork например — может требоваться дополнительное время для запуска нового воркера апача, даже если отдается статика. Причем процесс апача включает в себя и рнр, так что время на запуск требует дополнительных миллисекунд.

                        Nginx при правильной настройке просто отдает статику, что быстрее всего.
                          0

                          Вы описали prefork + mod_php а если prefork + mod_fcgid и не нужно запускать процесс на каждый запрос а в связке nginx+apache — статику отдаёт тоже nginx тогда разве будет столь уж ЗНАЧИТЕЛЬНАЯ разница в "быстроте" сайта?

                            0
                            я уже давно ушел от апача в сторону nginx, поэтому не следил за особенностями настройки уже примерно 10 лет. Скорей всего будет достаточно быстро.

                            Но в любом случае довольно часто рекомендуется прикрывать апач чем-то типа nginx/lighttpd чтобы бороться с медленными соединениями. У того же nginx на соединение кушаются считанные килобайты оперативной памяти, а вот апач кушает на обработку соединения побольше.
                              –1
                              Но в любом случае довольно часто рекомендуется прикрывать апач чем-то типа nginx/lighttpd чтобы бороться с медленными соединениями.

                              Разумеется так — и статья про nginx+apache и я именно про это отвечал а не про голый apache.


                              а вот апач кушает на обработку соединения побольше.

                              И с этим я тоже полностью согласен и про это тоже выше писал:


                              "Расшифрую — если оперативки хоть попой ешь то связка nginx + apache ничуть не "медленне" чем nginx + php-fpm если всё грамотно настроить. Если же с оперативной беда, то да прожорливый до неё apache стоит исключить."


                              Пришли к взаимопониманию? :)

                                0
                                Ну на самом деле я только предположил, почему апач не с оптимальными настройками мог оказаться в отдельных сценариях чуть медленнее :))
                    +1

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

                      0

                      Это уже другой, совсем не связанный с обсуждаемой темой вопрос.

                      +1

                      Чем больше оперативы тем дороже машина а попой ешь это сколько?

                        0
                        Чем больше оперативы тем дороже машина

                        Это так но выше я писал: "если "не жалеть заварки""


                        а попой ешь это сколько?

                        Столько что хватает всем процессам в пике нагрузки и ещё файловому кэшу остаётся с горкой :)
                        У меня так free -h:


                                      total        used        free      shared  buff/cache   available
                        Mem:            62G        2,3G         42G        2,3G         17G         57G
                        Swap:            0B          0B          0B

                        Временами buff/cache и до 25G доходит.

                          0

                          Ну таким "макаром" что Apache, что php-fpm, интересно сколько будет стоить такого рода машина например на AWS

                    0

                    У nginx есть директива include, которая отлично справляется с этой задачей. Можно подключить конфиг и из папки проекта и даже по маске типа *.conf
                    На счёт горячего апдейта совсем без перезапуска не уверен, но по документации service nginx reload и так делает перезагрузку без даунтайма. В общем это тоже решаемо.


                    Вердикт: наличие апача не обязательно

                      0
                      [01:59:31 boot@hosting:~]$ service nginx reload
                      Failed to reload nginx.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
                      See system logs and 'systemctl status nginx.service' for details.


                      И это ещё пользователю 'boot' многое позволено.

                      Если вдруг мой намёк непонятен: в посте речь идет о Shared хостинге, у пользователя хостинга минимальные права, а то и вообще может не быть шелла, только FTP, а Вы про «service nginx reload»…

                        0

                        Намек понятен) и я согласен с аргументами. Но я скорее предполагал в своем сообщении, что перезапуск будет не от юзера, а по триггеру на изменение файла конфига, например.


                        Честности ради скажу что так не делал, но беглый гуглинг (по запросу nginx auto reload config) подсказывает что это возможно.


                        В общем я не вижу прям сильного провода держать апач. Сейчас он только из-за .htaccess

                          0
                          Сейчас он только из-за .htaccess

                          Именно! Если кто-то напишет демона для nginx, который будет перечитывать пользовательские файлы .htaccess и сразу генерировать конфиги грубо говоря в /etc/nginx/sites-conf/sitename.conf и делать релоад при валидности конфигов… Вот тогда закапыватели Апача будут правы.
                            0
                            Уже сколько лет пытаюсь найти вменяемый конвертер .htaccess в конфиг для nginx'a, и в большинстве случаев приходится матерится и ставить apache. Ибо проще разобраться в правилах pf чем в той портянке которую генерят плагины вордпреса.

                            pf придумали марсиане. Из второго слева от создателей regexp'ов канала. (с)bash
                    +4

                    Давным-давно, когда деревья были выше, трава зеленее, а PHP выглядел далеко не так, php-fpm еще не существовал, а поэтому подружить быстрый nginx и php было очень не тривиальной задачей. Скорей всего именно поэтому и появился компромисс — статику отдавать быстрым nginx, а php дёргать из apache. Скорей всего именно из-за этого и появился эдакий бутерброд из двух слоёв хлеба.


                    Но недавно, к счастью, свершилось чудо!
                    Вышел в мир php-fpm и в новейшей версии php5.4 он был стабилизирован. Однако не все еще успели распробовать новинку… Ой, подождите, это же было в 2011 и с тех пор прошло уже 9 лет.


                    Возможно, нет никакой большой разницы между nginx + php-fpm и apache + mod_php, но есть значительная разница между nginx + php-fpm и nginx + apache + mod_php.

                      0
                      но есть значительная разница между nginx + php-fpm и nginx + apache + mod_php.

                      Большая разница в чём?
                      Число одновременных соединений первый вариант выдержит больше чем второй (ибо второй вариант быстрее всю оперативку сожрёт), но если просто "скорость" сайта то при грамотной настройке и большом запасе в оперативке никакой значительной разницы нет (грамотной это значит что вопреки всем мануалам по связке nginx+apache не отключать в apache KeepAlive а наоборот в nginx включить не только KeepAlive "наружу", но и к бекэнду — и т.д. и т.п.).
                      P.S.
                      Если реальные варианты рассматривать то лучше не nginx + apache (prefork + mod_php) а nginx + apache (prefok + mod_fcgid) — во многих cms так лучше будет в работе.

                        +1

                        В том, что апач не бесплатный, как и proxy_pass до него, а 1 + 1 + N всегда будет больше чем просто 1 + 1? Или это не очевидно из школьного курса математики?


                        во многих cms так лучше будет в работе.

                        Это приоткрывает завесу тайны над фанатичной любовью к апачу.
                        Не, я понимаю, что в случае с вордпресс/друпал/битрикс и всяким прочим, че уж там те накладные расходы — три с половиной rps они и есть, зато плагины могут гадить прямо в .htaccess. Удобно же.
                        Но мир php состоит далеко не из одних cms, да и те как-то обходятся и уживаются с nginx.
                        И в связи с этим здравый смысл задаёт нам два вопроса:


                        1. Зачем в принципе нужно лишнее звено в виде apache между nginx и php, если все отлично работает и так?
                        2. Зачем выбирать apache вместо nginx, если nginx + php-fpm имеют примерно одинаковую скорость работы с c apache + mod_php, но nginx быстрее обрабатывает статику и ssl, а в большинстве случаев (раз уж вы начали за cms, то в подавляющем) работа сервера будет заключаться и в обработке статики в том числе.

                        а nginx + apache (prefok + mod_fcgid) — во многих cms так лучше будет в работе

                        Так чем же nginx + apache будет лучше, чем просто nginx?

                          0
                          1 + 1 + N всегда будет больше чем просто 1 + 1? 

                          А я писал что это не так? Или Вы сами с собой разговариваете? Я писал что нет "ЗНАЧИТЕЛЬНОЙ" разницы !


                          Так чем же nginx + apache будет лучше, чем просто nginx?

                          А я нигде этого и не утверждал! Странно Вы выдёргиваете фразы собеседника видимо не понимая информацию изложенную в текстовом виде :(


                          Я писал что "nginx + apache (prefok + mod_fcgid) — во многих cms так лучше будет в работе" чем "nginx + apache (prefok + mod_php).


                          Зачем выбирать apache вместо nginx

                          Совершенно незачем и я никому так делать не советовал. Я всего лишь отметил что apache ВМЕСТЕ с nginx имеет право на существование так как ЗАМЕТНОЙ разницы с nginx + php-fpm нет. Только это — не выдумывайте пожалуйста за меня того что я не писал.

                            0
                            Чего у вас так подгорает и прет в сторону apache? Ибо это слегка выглядит не очень здраво…
                              +1

                              Да нет, же.


                              Блин — неужели я так плохо объясняю свою позицию? :(


                              Статья хостера о связке apache + nginx — и автор статьи объяснил что такой выбор обусловлен хотелками его клиентов. Ну наверное хостеру с большим кол-вом клиентов виднее как устраивать свой бизнес — разве нет ?


                              А набежали нескольско страдальцев суть сообщений которых — apache не нужен и пишут что с ним "значительно" хуже.


                              Я пишу не о том что без apache нельзя обойтись а то что бывает ситуации что с ним удобнее и о том что утверждение что связка nginx+apache ЗНАЧИТЕЛЬНО хуже чем nginx+php-fpm неверно.


                              Всё! Никаких "подгораний" :)

                              +1
                              Ну если там cms с ttfb далеко за 300, то, конечно, значительной разницы не будет.

                              Они имеют право на существование, но кроме возможности править .htaccess на лету apache не несет дополнительной пользы.
                              А все сравнения apache с nginx, в которых они идут наравне это с отключенным AllowOverride, с ним же apache бегает на каждый запрос по диску в поисках этого самого .htaccess и это уже и есть та самая кардинальная разница.

                              То есть либо apache не нужен вообще, потому что он просто труба, в которую в одну сторону влили, из другой вылилось и он просто кушает ресурсы чтоб ничего не делать.
                              Либо у нас AllowOverride включен, но apache уже не очень сопоставим по производительности с nginx. И вот тут появляется та самая значительная разница.
                                0

                                Не хотел из-за врождённой скромности но видимо придётся :(
                                В профиле у меня указан мой сайт.
                                Битрикс "тяжёлой" редакции "Эксперт", плюс хотя по внешнему взгляду не скажешь под капотом ещё куча самописных скриптов и фич облегчающих работу с сайтом помимо всего битриксова зоопарка.
                                AllowOverride включён. Nginx+apache (prefork + mod_fcgid).
                                Пробежитесь по сайту, померяйте чекерами "скорость", TTFB и т.д.
                                Если после это скажете что сайт "медленный" — бросьте в меня камень :)

                                  0
                                  Какой из этих 0?
                                  image
                                    0

                                    "Не виноватая я" — как раз за посты в этой теме получил минус 1 в карму а у "отхарбленных" выходит не видна ссылка :(


                                    Извините не знал.


                                    Надеюсь что сильно правил не нарушу указав прямую ссылку в сложившихся обстоятельствах:
                                    https://www.babai.ru

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

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

                                      я согласен, что у cms и битрикса есть своя ниша и они могут работать хорошо при тонкой настройке, но взгляните на большинство интернета — это грустно и «микрооптимизациями» занимаются крайне мало людей, можно же поставить волшебный плагин для кеша чтоб всё это хотябы не умирало.

                                      ну и плюс php это все-таки не только cms, у меня yii2 под нагрузкой отдает страницу за 10-15мс без вообще какого-либо кеша бд, прикрутить пусь редис и это будет 3-5мс, на фоне которых еще и апач добавит своих.
                                      и это будет уже заметно.
                        0
                        И снова в комментариях полно веганов, не понимающих зачем нужен apache, которым обязательно необходимо всему миру сообщить что они 10 лет уже не едят мясо не пользуются apache.
                        А те кто пользуются — просто злые из-за мяса тормозящих под apache сайтов.

                        Вы бы запустили свой хостинг, чисто с nginx + php-fpm. И объясняли бы каждому клиенту, что он просто тупой раз не может обойтись без apache.
                          0
                          У себя использую уже несколько лет исключительно dedicated схему с персональными апачами для каждого пользователя даже на самых минимальных тарифах. До этого поначалу также был один общий apache itk и самый главный недостаток это когда у кого-то из клиентов случается какой-то «затык» — приходит запрос, php что-то долго думает, либо вообще запрашивает что-то из вне, а этот внешний источник «лежит», процесс зависает. Следующий запрос обрабатывает следующий свободный процесс и вродебы более-менее работает до тех пор пока на тот проблемный зависающий скрипт не приходит запросов больше, чем maxrequestworkers. В итоге зависшими оказываются все процессы apache и новые запросы, даже если они от других клиентов и беспроблемные быстрые, они просто стоят в очереди и все сайты на сервере оказываются зависшими.

                          Ну и память opcache была естественно занята в основном скриптами тех сайтов, где больше траффика. А клиенты с 2 запросами в день получается были ущемлены и у их скриптов почти каждый раз выходит «холодный старт».

                          Поэтому сейчас только выделенные процессы каждому с его личной памятью.
                          Плюс аналогично сделано с mysql. Т.к. одна общая это также плохо как shared apache.

                          Однако на данный момент сделано чтобы было: 1 пользователь = 1 ветка apache/mod_php с одной версией php. Все прозрачно и понятно, 1 пользователь = какое-то макс число памяти и процессов. Кому нужно больше — берет тариф выше с бо́льшими лимитами и на другом сервере с меньшим числом соседей.

                          Но. Изредка возникают вопросы у пользователей, которые в пределах одного аккаунта хотят разные версии php для разных сайтов. Сейчас просто делается ему новый аккаунт под новую версию php. Опять же, логично, пользователь хочет еще один «блок» из памяти и числа процессов, извольте доплатить +1 тариф.

                          Да, можно было бы сделать как у вас: 1 пользователь = до 8 пар (число версий php) apache/mod_php под разные версии, но как тогда ограничивать память и процессы, но чтоб все по справедливости было? А не так что одни сайты под одной веткой занимали чего-то больше и ограничивали другие под другой. Либо без ограничения, но тогда потенциально пользователь сможет 8-кратно превысить лимиты своего тарифа.

                          image

                          По вашей картинке выходит, что у user 2 его единственному сайту доступно все по максимуму в пределах его тарифа. А у user 1 как? Apache 7.1 и 7.2 делят пополам макс. предел по процессам и памяти? Или не пополам, что один из сайтов может перетянуть все одеяло на себя и клиент не будет понимать почему второй сайт хуже работает? Т.е. теоретически если человек добавит 8 сайтов и все под разными версиями php, то каждый из них будет по сути в 8 раз более ограничен, чем если бы все сайты были под какой-то одной версией php. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.
                            0
                            А у user 1 как? Apache 7.1 и 7.2 делят пополам макс. предел по процессам и памяти? Или не пополам, что один из сайтов может перетянуть все одеяло на себя и клиент не будет понимать почему второй сайт хуже работает? Т.е. теоретически если человек добавит 8 сайтов и все под разными версиями php, то каждый из них будет по сути в 8 раз более ограничен, чем если бы все сайты были под какой-то одной версией php. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.


                            Здравствуйте!

                            Один мастер-процесс Apache2 с воркерами обслуживает все сайты одной версии PHP одного клиента. Каждый мастер-процесс имеет одинаковое количество ресурсов (ресурсы не режутся на количество сайтов). Получается, у user 1: сайт на Apache 7.1 имеет свой мастер-процесс, Apache 7.2 — свой. Таким образом, один сайт на PHP 7.1 будет иметь столько же ресурсов, сколько и два сайта на PHP 7.2 для одного клиента.

                            Ответили ли мы на Ваш вопрос?
                              0
                              Ну то есть по тарифу пользователя конфиги апача прописаны скажем на 10 процессов максимум и соотв. php под скажем 1гб памяти. Далее пользователь добавляет сколько-то сайтов и задействует все 8 версий php. Т.е. суммарно уже не 10, а 80 процессов, не 1, а 8гб памяти в его распоряжении. Так выходит? Подозреваю что нет и глобально весь пользователь всеж как-то урезается до тех же тарифных 10 процессов и 1гб. А следовательно сайты на одной из восьми веток довольствуются лишь 1/8 от возможного в подобной ситуации.
                                0
                                Да, выходит именно так, как Вы сказали. Если клиент задействует 1 версию PHP, то получит 1 ресурс; если две версии, то в 2 раза больше ресурсов. Например, пользователь хочет перевести свой сайт на другую версию PHP. В таком случае для пользователя это пройдет без проблем с нехваткой ресурсов. Когда клиенту мало ресурсов одной версии PHP под сайт (например, клиент хочет разместить много сайтов с большой нагрузкой), то чаще всего ему нужен отдельный сервер.

                                У нас есть тарифы с выделенными серверами, где у пользователя ограничены системные права (так же, как и на предыдущих тарифах), но работает админка в панели со всеми функциями управления сайтами, которые доступны и на других тарифах. Есть и тариф, где пользователю дается Dedicated с root правами и ipmi, но уже без админки.
                            0

                            Может стоило задуматься о написании модуля nginx для интерпретации htaccess как часть его конфига.

                              +1
                              Вы понимаете суть? Если сделать чтоб nginx делал тот же самое, что и apache, то он уже не будет таким быстрым.
                              Аналогично можно вместо .htaccess все правила в конфиг apache записывать и чтоб он считывался только при перезапуске, а не при каждом запросе. И тогда можно allowoverride выключить — один из самых замедляющих апач нюансов (поиск и чтение .htaccess'ов при каждом запросе).
                              Но как этим будут управлять пользователи?
                              Или по вашей схеме — исправит чел что-то в .htaccess своем и как nginx должен будет узнать об этом? Только перечитав этот файл. Но если он начнет также как апач искать, читать и выполнять все .htaccess'ы, то он точно также станет медленней работать. Где вообще логика?
                                +1
                                Никто вроде не мешает использовать связку inotify + epoll чтобы не перечитывать соответствующие файлы при каждом последующем запросе. Просто на Apache это натягивается аки сова на глобус в силу его внутреннего устройства, поэтому там такое вряд ли когда реализуют.
                                  0
                                  Согласны, пофантазировать с inotify epoll — любопытно!

                                  .htaccess можно разместить в любом каталоге любого сайта. Сложно представить стабильную рекурсивную работу inotify с несколькими терабайтами данных при 80 млн занятых inode. А если демон умрет и какие-то события будут пропущены? В конечном итоге, нас интересует не столько красивое, сколько стабильное решение, которое не создаст неудобств и подойдет большинству пользователей.

                                  По логике схемы, мы видим, что требуется делать Nginx reload при каждом изменении любого файла, с перечитыванием всех файлов .htaccess на всем сервере или где должны храниться временные данные.
                                    0

                                    Представить несложно. Трекинг, скажем, миллиона inotify дескрипторов — вполне реальная штука.
                                    Демон умрёт и пропустит события? Какой демон? Разгребанием должен заниматься тот же nginx, ну вот умер он у вас по какой-то причине, вы его перезапустили, он заново начинает эти файлы отслеживать. И что вы при этом могли пропустить логически? Ничего.
                                    Ну и при грамотном подходе reload всей конфигурации делать незачем — делать частичный для какого-то логически независимого кусочка не rocket science.
                                    В общем нет в таком варианте ничего нереального, просто писать придётся много, а никому пока что не нужно оно.

                              +1
                              Наряду с неоспоримыми преимуществами, в контейнерной системе пользователю предоставлено меньше ресурсов. В Timeweb, благодаря описанной схеме работы хостинга, у пользователя нет ограничения в оперативной памяти. Он получает больше ресурсов, чем в контейнере.

                              Простите, а с какого момента контейнеры стали автоматически означать ограничения в ресурсах, в частности оперативной памяти? Namespaces это одно, cgroups это другое и они совершенно ортогональны друг другу. Или я как-то не так понял вашу мысль?
                                0
                                Здравствуйте!
                                Спасибо за Ваш комментарий и вопрос.

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

                                Сравним контейнерную реализацию с shared-схемой. Например, у нас есть 10 клиентов и 10 Гб оперативной памяти на сервере. Мы гарантированно дали каждому по 1 Гб памяти. Вроде всё честно! Но в какой-то момент у одного клиента появилась нагрузка на 2 Гб памяти, и часть пользователей не смогла добраться до его сайта. А в shared-схеме у каждого из 10 пользователей есть доступ к 3 Гб памяти из 10 Гб памяти, но в режиме конкуренции. То есть каждый сайт может использовать много ресурсов в один момент времени. Когда конкуренция начинает негативно влиять на работу сайтов клиента или работу других пользователей, то сервер разгружается и пользователь получает столько ресурсов, сколько ему нужно, при этом имея разумные ограничения для обеспечения работы сайтов.
                                  0

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

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

                              Самое читаемое