Пользователь
0,0
рейтинг
19 ноября 2012 в 03:40

Администрирование → Настройка Nginx + LAMP сервера в домашних условиях. Часть 1: Настройка frontend — backend


Здравствуйте. Недавно я задавал вопрос по поводу создания цикла статей. Вот первая статья.

В этом цикле статей вы узнаете как грамотно настроить LAMP сервер, аля «хостинг только мощней».
Мы будем использовать следующий стек: nginx — apache-mpm-itk — mod_php — mysql — linux/debian.

Буду освещать следующие темы:
  • Настройка frontend — backend
  • Расчет возможностей сервера, настройка mysql и backend
  • Рассказ об опыте на базе intel s3420gp

Совершенно уверенно могу сказать, что настройка LAMP сервера не ограничивается 6-10 командами установки и раскомментирования определенных строчек в файлах настройки.
Пример: по умолчанию nginx не дает возможности закачать на сервер тело запроса больше чем 1M. Если не настроить данный параметр, будет возникать ошибка 414 (Request-URI Too Large), при попытке добавления небольшой серии фотографий.
У apache совершенно противоположное: у него тело запроса по умолчанию не ограничено. Это делает возможным совершать пакости.

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

Мы узнаем о том какие бывают простые атаки и как от них защищаться. Сразу скажу, что при базовой конфигурации frontend в лице nginx — backend apache все равно остается уязвим.

Я практически уверен, что я не смогу уместить все в одну статью. Добро пожаловать под кат.



— Предисловие:
Так получилось, что недавно у нас начал падать сервер. Почему-то падал он c вечера на ночь, а днем вполне себе работал. Не скажу что на нем была огромная нагрузка. Во время падений обнаружил непонятно огромные скачки выделения оперативной памяти на apache, более 700 мегов на процесс, хотя у PHP максимально стояло 256M. Сервер уходил в своппирование, после чего падал. У сервака вначале было 8G RAM, после чего поставили 16G.

До этих падений сервер работал целый год и никаких проблем не знали. У него была жуткая конфигурация сделанная на коленках, ибо c хостинга нас уже гнали. Вот его конфигурация, все из дебинских репозиториев:
Apache2.2.16_mpm_itk + php5.3.0 висел в интернете за frontend и backend одновременно, без защит от возможных атак вообще. Мне удалось провести все атаки, упоминавшиеся на хабре =).
Mysql5.1 был настроен в базовой конфигурации с не оптимальным использованием RAM и все такое.

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


Начнем настройку


— Репозитории бывают разные:
Первая проблема которая встала, это обновление софта. Как известно, репозитории debian имеют достаточно устаревший софт. Говорят, что они хорошо тестированы, но они реально старые! К слову я сам удивился, когда нашел эту подборку софта.
Теперь репозитории LAMP я беру от сюда www.dotdeb.org
Вот инструкция по настройке www.dotdeb.org/instructions
Для тех кто в первый раз очень сухо (а ведь сам был таким однажды и некому было помочь, кроме гугла):
— Устанавливаем debian сразу ставим галку ставить SSH сервер (больше ничего!!!), далее узнаем IP сервера за VGA монитор больше не садимся, можете сдать сервер в датацентр.
— Коннектимся по SSH, советую putty под win.
— nano /etc/apt/sources.list вставляем туда по инструкции с dotdeb. (на заметку: вставка текста в консоль из буфера windows делается правой кнопкой мыши)
— выполняем другие вещи по инструкции
— выполняем большой блок команд которые я написал ниже
— работаем через MC как белые люди
— дальше все зависит от Вас! =)

На заметку, вот моя конфигурация железа: Intel s3420gp, xeon x3450, 16GB ECC RDIMM, 3*1Tb 3.5" SATA «WD BE» (2x-raid1(25G /, 20G swap, 100G /var, ~800G /home) + 1single(1Tb /mnt/unsafe)). На заметку новичкам: я жутко в свое время ступил, что поставил диски Black Edition — надо было ставить Raid Edition.

И так. Сейчас мы только что поделили диски, поставили операционную систему из минидиска debian (190Mb) и сделали настройки репозиториев. Теперь продолжим. Во время выполнения операций у вас будут вопросы от dpkg, надо на них ответить.
apt-get update
apt-get upgrade
apt-get install nginx apache2 apache2-mpm-itk php5 php5-apc php-pear php5-dev php5-gd mysql-server mysql-client php5-mysql postfix mc -y
apt-get install libapache2-mod-rpaf -y
echo all done!

nginx — фронтенд, apache2-mpm-itk — бэкенд, mod_php5.3 — язык, mysql5.5 — база данных, postfix — рассылка почты из PHP.


— Составляем архитектуру системы:
Всегда известно, что без наглядной картинки настраивать систему труднее чем, если бы она была. Вначале я сам не мог себе её представить и нарисовал её только после прочтения более половины основной документации по двум серверам и немного про апачи с mysql. Сейчас я её нарисовал для читателей сразу, что бы им было нагляднее и удобнее изучать конфигурацию. Думаю, что по данной картинке будет достаточно просто анализировать узкие части системы в будущем, что позитивно скажется на поддержке системы и, возможно, ее масштабирования. (Картинко кликабельно)

Все части картинки я буду пояснять в следующей статье. В этой статье мы раскроем настройки frontend — backend. Защита apache.


Frontend: настройка nginx


Настраивать nginx мы будем в режиме прокси. Этому есть несколько причин:
  • Защита сервера apache от атак
  • Сжатие и отдача статического контента на легковесном сервере
  • Сохранение мозгов сервера
  • Простота реализации
  • Apache mod_php работает (не намного || хуже) чем PHP FastCGI, при том, что настройка mod_php более понятна и стандартна

— Конфиги в студию!
Вот мои конфигурационные файлы которые я использую для прокси сервера
yadi.sk/d/w0SNSFIM0nyk1
То что поставилось вам от репозиториев надо безжалостно заменить на эти файлы, а так же добавить в mime расширения .docx, .pptx, .xlsx напротив соответствующих mime типов. Давайте немного посмотрим на устройство конфигов:
/nginx.conf - главный конфигурационный файл - собственно с него и начинается загрузка. В нем я оставил общие настройки сервера и импорт директорий.

/proxy_params - конфигурационный файл, для настройки nginx сервера в режима proxy. Там собраны все настройки касательно проксирования сгруппированные по группам: Базовые настройки, Защита от killapache.pl, Размер буферов, Кеширование, Другое.

/conf.d - директория в которой я сгруппировал конфигурации по каждому модулю. В частности я сгруппировал error-docs - страницы ошибок, ngx_http_core_module - базовые настройки сервера, ngx_http_gzip_module - настройки сжатия.

Я намеренно не объясняю значения параметров настроек, так как на то есть русская документация. Однако я хочу указать на некоторые из них и то, почему я выбрал именно такие параметры. Читателям же желаю подумать, какие настройки нужны для их целей, тем более искать их больше не нужно я их все сгруппировал.
  • client_max_body_size я увеличил до 64M, что бы можно было загружать на сервер разную мультимедиа — банально фотографии.
  • client_body_buffer_size — стандартный буфер я увеличил до 32k потому что по умолчанию явно не будет хватать. Часто приходится обрабатывать «большие данные (10-20к)» на входе. Вообще этот параметр должен определяться из того какой код будет выполняться на сервере. Если вы например твиттер — то вам больше 1к не нужно тратить (однако все равно надо ставить 8k что бы выронить по странице памяти 64х системы). Если вы хабрахабр, я бы поставил 8k (меньше чем значение по умолчанию), потому что там пишут комментарии часто выходящие за 1k, но в среднем меньше чем 8к (на вскидку, могу ошибаться). Что происходит, если этот параметр переполняется читать в документации.
  • large_client_header_buffers — я уменьшил тем самым сровняв с тем, что может принять остальная часть системы — apache+php.
  • worker_processes — рабочих процессов поставил по количеству ядер / 2.
  • worker_priority — поставил выше всех, что бы весь остальной бэкенд не тормозил отдачу сформированного контента.
  • server_tokens off; — не надо светить тем, что у тебя стоит =), можно попасть в беду.
  • proxy_read_timeout — я увеличил, до 300 + 20 секунд. Это чуть чуть больше чем timeout apache, который происходит через 300+10 секунд. Так сделано, что бы timeout происходил «из глубин» бэкенда, а не обрывался по непонятным причинам фронтендом. По умолчанию этот параметр 60 секунд, что порой бывает мало для тяжелых вычислений. Замечу, что php в такой конфигурации может выполняться до 300 секунд, до начала чреды таймаутов.
  • Прошу обратить внимание на директивы proxy_set_header — в файле proxy_params: они используются для того что бы установить заголовки для проксированного сервера. В частности проксированный сервер не видит какой IP адрес к нему обратился, потому что считает что к нему обращается локальный 127:0:0:1
  • Проксирую я на локальный порт 127.0.0.1:88, честно пытался найти сокеты либо костыли на основе них, но не получилось =(



Backend: настройка apache


Теперь приступим к настройке apache. Вот очередная пачка сгруппированных конфигурационных файлов: yadi.sk/d/ZqsisoDl0nzrl
В файлах апача я подписал каждый параметр, скопировав его из документации, что бы было удобнее настраивать. Опять же я отправляю вас к документации для настройки для ваших потребностей и расскажу про ключевые вещи:
  • файл ports.conf: прослушиваем порты 88 и 443.
  • дополнительно устанавливаем libapache2-mod-rpaf (уже сделали выше). Он служит для того, что бы расшифровывать заголовки, которые передает нам проксирующий сервер. Да те самые заголовки, которые мы устанавливали директивой proxy_set_header.
  • DeflateCompressionLevel 1 (файл /mods-enabled/deflate.conf) в defline я установил степень сжатия = 1, я решил сильно не жать. В любом случае, если у вас есть лишние рабочие руки на сервере, то почему бы не 9-ть?.
  • Я активировал модуль mod_headers и в файле conf.d/security зарезал некоторые заголовки для безопасности, для хостов висящих на 443-м порте. Подробности в конфигах. Не знаю зачем я этот порт оставил не проксированным, но это факт. Просто руки что-то не дошли, либо я побоялся, а потом уже руки не долшли. В любом случае обычным смертным запрещено к нему обращаться. Кстати с апачи версии >= 2.2.21 эту проблему решили специальной настройкой на уровне ядра.
  • ServerTokens Prod, ServerSignature Off — опять же не светим вкусными местами.
  • В файле secutiry в секции directory я описал максимально много разных настроек, что бы было меньше словоблудия в файлах виртульных хостов.
  • TimeOut 310 — уже писал почему 310 секунд.
  • RLimitMEM — интересная штука, советую почитать. Позволяет ограничивать память которую потребляет апач в целом. Так же интересны другие R* параметры
  • DefaultType application/octet-stream — если мы не знаем что отдаем, то пускай это будут бинарники.
  • AddDefaultCharset Off — лучше не включать, если вы не уверены в том, что у вас все в одной кодировке


С тем на что нужно обратить внимание я закончил. Теперь давайте перейдем к рассмотрению mpm-itk модуля выбранного для выполнения задач на хостинге.
Дело в том, что данный модуль удобен тем, что при каждом новом обращении к серверу создается новый процесс и он переключается на определенного пользователя, допустим на www-ru-example. То есть этот пользователь «запирается» в своем каталоге и никакие скрипты никуда попасть не смогут, при учете того что вы правильно настроили операционную систему. Замечу, что многие файлы настроек по умолчанию в debian открыты для чтения для всех!!!..
Интересна история этого MPM. Дело в том, что он был сделан на основе mpm prefork, это означает, что все настройки для prefork действуют и на itk. Соответственно в моем конфигурационном файле вы это можете прослеживать.
Прошу обратить внимание на MaxClients 150, эти те самые максимальные 150 пользователей, которые могут быть при обращении к бэкенду. Так же прошу обратить внимание MaxRequestsPerChild. По умолчанию он равен нулю. Советуется устанавливать его хотя бы ограниченным — это уменьшает возможность утечки памяти.

Еще одна важная вещь в mpm-itk это nice value. Это значение я установил равным -2. Я сделал именно так, потому что как только БД отдала результат, PHP должен моментально его до конца сформировать и отдать. Прошу заметить иерархию nice-value.
nginx = -5, apache = -2, mysql = 0. Это сделано для того, что бы максимально быстро формировать контент и отдавать пользователю. Операционная система должна вытеснить не приоритетные процессы на потом.

Хотелось бы сказать пару слов о базовой защите апачи.
Есть несколько типов атак, которые должен знать любой сисадмин: killapache.pl, slow post, slow lori. Все эти атаки очень просто производятся на открытый апач. От killapache.pl спасает mod_headers или nginx, где можно закрыть проблему запретив определенные заголовки. Говорят что killapache.pl это проблема самого протокола. slow post, slow lori это идентичные атаки, одна делается при передаче большого POST, с очень медленным каналом, другая делается передачей сгенерированного контента к клиенту очень медленным каналом. Эти атаки не страшны для сильного мускулистого и жилистого сервера nginx, которым мы прикрылись. Для апача это смертно подобно, например песочница PHP чистится после того как сервер отдал все данные, теперь представьте сколько можно сожрать памяти.

В конце хочу сказать, что в конфигурационных файлах я прислал просто файлы. Не забывайте создавать симулинки в частности для каталогов mods-enabled из mods-available, sites-* и др.

Спасибо за прочтение, надеюсь понравилась моя подборка конфигов. Многие другие вещи я попробую осветить в других топиках. Например настройка бэкенда (php — mysql) и расчет возможностей сервера. Если первая и вторая статья будет интересна, то я могу выкатить еще 2 статьи: «система учета пользователей», «опыт касательно выбора железа начального уровня», «разное про работу на сервере». В финале я могу разработать набор утилит для быстрой настройки сервера по указанным мною статьям.
Кривцов Артур @wartur
карма
1,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (78)

  • +3
    То есть этот пользователь «запирается» в своем каталоге и никакие скрипты никуда попасть не смогут, при учете того что вы правильно настроили операционную систему. Замечу, что многие файлы настроек по умолчанию в debian открыты для чтения для всех!!!..

    Было бы неплохо, если бы вы в статью добавили о запирании, и о том, как запретить чтение этих файлов настроек. Ибо простая установка apache2-mpm-itk просто заставляет apache работать с правами определенного пользователя, и не запирает его, собственно, никуда. Писать кроме разрешенных мест он не сможет, а вот погулять по серверу с доступом к чтению — запросто.
    • +1
      Я наверно не правильно выразился. Конечно же он никуда его не запирает, а именно «заставляет apache работать с правами определенного пользователя». Я могу написать о том, как надо настроить права доступа для ограничения.
      • +5
        Да, это было бы неплохо для комплекта.
  • +8
    Всё огонь, но возникает вопрос: в аннотации статьи звучит «в этом цикле статей вы узнаете как грамотно настроить LAMP сервер» а получается «вот вам мои правильные конфиги». Ну, может тогда всё в одной статье сложить или рассказать помедленнее, как и на основании чего выставлялись параметры, как вы мерили изменения в производительности, чем делали нагрузочные тесты и т.д. Иначе это получится куцый howtoforge.

    В любом случае, спасибо за «чужие конфиги», почитаю продолжение, а сейчас поищу про proxy_set_header range и жива ли эта уязвимость. Просим, просим.
    • +1
      Вот ссылка про Range. Про проблемы изложения я понял, будем корректировать.
      • +2
        Спасибо, я тоже это видел год назад, когда меня это не касалось. Я про другое. Все решается установкой версий 2.2.21 (2.0.65) и выше, а в репозиториях уже 2.4 нормально забирается не первый день. Если есть баг-фикс в виде костыля, не дурно почитать про него перед применением. 15 минут и у вас исчезнут лишние строки конфигов со всеми бонусами. Пилим дальше.)
  • +2
    А зачем устанавливается php-dev?
    • +1
      А почему вы спрашиваете? В нем лежит phpize без которого не будет счастья.
    • +2
      pecl-модули ставить.
      • +1
        Это некорректно. Правильно будет собрать пакет и поставить его.
        • –1
          pecl сам по себе уже является менеджером пакетом.
          • 0
            pecl это инструмент — скачать исходники и скомпилить.

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

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

            Также пакет тиражировать и деплоить удобнее. Десять и больше машин — вешалка.

            Также не всегда есть интернет. Зачем он на бекенде?

            Также пекловские штуки зачастую зависят от других, например request-control зависит от net-url. Эти зависимости не всегда очевидны и есть шанс зафакапиться после деплоя.

            Вот за что я руби не люблю, кстати, так это за вот такие вот кренделя типа джемов. Пекл туда же.

            • 0
              Что-то я явно, судя по вашему комменту делал не то, собирая и ставя расширения pecl'ом на «образцовой» системе, а потом из того что получилось делая .deb пакет для деплоя на других. Похоже совмещал недостатки pecl и dpkg
  • +8
    Зачем здесь Apache? Вы конечно привели две ссылки, одна двухгодичной давности для Wordpress, при этом обе не рассматривают работу через nginx вообще.
  • +1
    А можете рассказать про настройку своего named-сервера для LAMP'овой связки?
    • –1
      sudo vim /etc/hosts
      
      • +1
        Тогда уж:
        sudo vim /etc/namedb/named.conf
        sudo service named restart
        

        Но интересует более тонкая настройка, а, так же, как это прописать на своей машине, так чтобы она работала через LAMP'овый сервер. Пытался настроить named на FreeBSD, и прописать ip сервера в качестве DNS на Windows машине, но, почему-то, не захотел резолвить нормально домены.
    • +1
      Знаете. я в свое время заворачивался с bind9. Ничего тонкого я с ним не умею, ровно как и с другими DNS серверами. Единственное что я понимаю, что то за что отвечает каждая запись в корневой записи домена. Это все что я знаю.

      Теперь я понял, что гораздо стабильнее просто купить DNS серверы либо воспользоваться help.yandex.ru/pdd/hosting.xml

      > В случае на моем продакшн сервере, DNS проблемы решает сервера датацентра.

      > В моем домашнем случае на wartur.ru это решает хвостовая машина на windows server 2008R2 + secondary на nic.ru
  • +2
    У apache совершенно противоположное: у него тело запроса по умолчанию не ограничено. Это делает возможным совершать пакости.

    В дебиане 2Mb. Кроме того, там php с suhosin. Какие пакости?
  • 0
    Сам сижу настраиваю LAMP на FreeBSD только, используя разные истночники, в частности примерно по этой статье под CMS Joomla.
    Там правда в качестве web-сервера nginx, а я данный пункт пропускаю и ставлю apache.
    А тут в статье усмотрел что перед апачем еще и nginx выставили.
    Пока один раз статью прочитал, но пока не понял стоит ли изголятся так же. (про то что ресурсы меньше должно есть, я понял).
    Но что-то не дошло.
    Вообщем продолжаете писать, это как минимум интересно.
    И лучше как-то попонятнее.
    Спасибо
    • +1
      nginx нужно настраивать не на тупое проксирование запросов к Apache, а на избирательное — с отдачей статики он справляется куда лучше последнего, а Apache должен обрабатывать только динамику… Вопрос cтоит поставить так: есть ли смысл поднимать Apache, раз уж подняли nginx. Реальный плюс для многих — .htaccess файлы сторонних или унаследованных движков работают «из коробки», да и php скрипты могут быть рассчитаны на какие-то особенности Apache. других плюсов не знаю. По крайней мере в том что касается работы как «запускалки» php/
      • 0
        Вот я тоже подумал что пока не знаю «особенностей» использования CMS Joomla в связке с веб-сервером Apache не ставить пока nginx. Как-нить попробую поставить ее только с nginx
        • 0
          Я писал о том, стоит ли вставлять Apache между nginx и php. nginx стоит ставить всегда (ну, в типичных случаях точно), вопрос нужен ли после него Apache как запускалка php-скриптов или можно довериться php-fpm, возможно переписав .htaccess согласно синтаксису и духу (немаловажно) nginx. Для Joomla думаю, найти идеальные конфиги для nginx труда найти не составит.
          • 0
            Претензий нет. Понял. Только не ругайся
  • +2
    Спасибо за начало цикла статей. Очень интересно будет почитать. Очень обрадовали DotDeb.
  • +2
    Для тех, кто всё-таки думает, что апач у нас тут лишний: github.com/garex/puppet-module-nginx
    Кто англицкий не знает — копируйте в гугл-транслейт (он не хочет https переводить, подлец).

    Апач, он конечно молодец, но пенсионный возраст ему уже подошёл, а держать апач только за ради php — расточительно ИМХО.
    • +1
      Многие держат apache не только из-за php но и из-за mod_rewrite
      • +1
        … Не холивара ради, а токмо волею пославшея мя жены…

        nginx.org/ru/docs/http/ngx_http_rewrite_module.html#rewrite

        Я в своё время с апачевскими рерайтами тоже не с ходу разобрался — что те, что эти не особо очевидны. Но есть некие сервисы, которые чудесным образом превращают рерайты апача в нгинкса. Естественно, что это всё не факт, что оптимально, но далее уже человеку разобраться можно.

        Апач ведь развращает .htaccess`ами, а потом диски стонут от миллиардов stat`ов (кто без .htaccess`ов всё делает, а include`ами — тот молодец).
        • +1
          Главное при этом на забыть AllowOverride None прописать, тогда на .htaccess-ы внимание сервера тратиться не будет.

          Правда, нагрузка от stat-ов не душит особо, есть же кеш ФС, а вот отработка их — это, да, проблема, так что — include наше все :)
          • +1
            Дык. Но это тогда lurkmore.to/Пчёлы_против_мёда

            Я вообще думаю, что д.б. некий принцип тов. Паретто — 80% задач решать nginx`ом, а если 20% оставшихся может решить апач (какие-нить хитрые модули в сложной инфраструктуре), то тогда его туда и ставить. Если всё можно повесить на nginx — вешаем смело.

            Опять же зависит от нашей лени. Но лень — это хорошо, ибо она наш двигатель.
  • +5
    Ну пока ничего особенного не увидел в статье.
    Не совсем понятно только, зачем изголяться с репами по Debian, если есть сам по себе неплохой уже Ubuntu Server?
    • –8
      Потому что Ubuntu сервер — это испорченный дебиан. Сколько с ним не имел дела, столько и плевался. ИМХО, конечно.
      • +5
        Что конкретно там испорчено? Тезисами. С приведением примеров.
      • +5
        Очень странно. Потому как никаких проблем с ним ни разу не было. Поставил недавно как раз 12.10 на роль вэб-сервера, смотрел что вырезать лишнего — ничего особо и не выпилил. А в плане свежести репозитариев и удобства настройки никаких нареканий.
      • +1
        Правильный дебиан — это устаревшие на три года пакеты и половина системы пересобрать, чтобы что-то вышедшее погода назад поставить? нуну
        • 0
          Если для вас новизна это приоритет, то вы можете сами собирать деб пакеты и ставить, либо fetchinstall юзать.
          ИМХО стабильность частенько становится важнее нежели новизна пакетов в котором еще есть баги.
          У меня опыт работы на оборот, от ubuntu server головной боли больше было чем от debian
          • 0
            Но в статье-то все равно упоминается репозиторий со свежими пакетами для дебиана. В чем разница тогда с ubuntu сервер?
            • 0
              я за общую ситуацию говорю. При холиваре Ubuntu vs Debian в качестве аргументов тыкают пальцев в устаревшие пакеты в репах. В CentOS тоже пакеты старые, но это же не повод в продакшине использовать Fedora :)
              • 0
                Одна сторона в устаревшие, другая в непроверенные временем ?)
          • +1
            Все почему-то хвалят стабильность дебиана, а сами при этом пользуют дотдеб, уиззи. И самосборное, с глибц из тестинга, протобуфом из альфы дебиана и прочее. В том то и дело, что надо полсистемы обновить, чтобы собрать что-то мало-мальски серьезное в дебиане.

            Хайлоад мы делаем на убунте. Стабильность без нареканий.

            Есть проблемы, конечно, но быть на самой грани разработки и использовать новейшие версии софта — дает профит куда больше.

            Да и глюки там такие же консервативные, как и хваленая стабильность. Например, груб, который при установке затупляет, когда дисков больше чем один.
      • +4
        Дайте впечатляющих примеров. Никакой беды от Ubuntu Server на продакшене пока не встретил. Более свежий софт — бедой не считаю.
    • +1
      Данный реп идет по версиям наравне с 12.10, а на сервера сейчас ставят обычно 12.04.
  • +1
    evr1ka
    Конечно оно того стоит, как минимум — это уменьшение нагрузки на выдачу статического контента, и возможности по его кешированию.
    Как второй из возможных аргументов — отсутствие атак связанных с «медленным» клиентом.
    И как третий, — иногда можно использовать чистый ngnix без apache, но это уже актуально на собственных проектах.
  • +1
    Ничего не хочу сказать, но LAMP — это Linux + Apache + MySQL + PHP. У Вас же связка чуть сложнее, за счет nginx. Отразите это, пожалуйста, в заголовке: искать станет проще (и тот, кому надо Nginx + LAMP, найдет эту статью), а люди, которым именно LAMP и нужен, не станут и пробовать.

    За статью спасибо за то, что разрисовали поток объемов данных, для многих начинающих это хороший повод задуматься.
  • +2
    Статья устарела еще до написания.
    • +1
      Был бы рад прочитать «обновленную».
      • 0
        Апач убрать, php-fpm поставить для начала? Ну сколько можно-то. LAMP уже давно вчерашний день.
        • 0
          Подумаю. Если чего соображу напишу «обновленною» статью =). Но сейчас я уже наметил цель, поэтому давайте сначал её выполним. Fпач убрать будет наверняка просто, я практически уверен.

          У меня такой вопрос. Дайте почитать, как сделать переключение пользователей ака MPM-ITK. Я буду очень благодарен вам.
          • +1
            Акей. Это действительно второй разумный аргумент, после реврайтов. Сколько у вас там пользователей? И так ли оно надо — выполнять все штуки из под разных? Ну действительно, в реалиях 5.3-5.4?

            nginx действительно не умеет запускать пэхэпешэчку от разных uid-gid, но там есть пулы, которые умеют.

            И я еще за свою жизнь очень мало видел задач, где это действительно необходимо. Зато 99% времени я больше не парюсь про память. Апач меня заставлял мало спать и много переживать, а иногда даже ездить в датацентр.
            • 0
              Тут вообще интересно все. Я общаюсь с сервисами, которые жмут 1500-10000 рпс. Фактически без проблем.
              Апача сколько там выдаст?

              И я еще помню, как мы корячили апача поверх апача над апачем, чтобы хоть как-то оно работало. Не помогло ))

              Аргументов как было два, так и осталось. Реврайты и пресловутый php под разными uid-gid. Реврайты уже неактуально. А разные uid-gid? Если только совсем на безбашенном шаредхостинге.
              Ну не знаю. Выгода-то где. Есть она вообще?

              Зато на nginx можно программировать и показывать чудеса, если собрать с правильными модулями. async, nonblocking highload и ничего никуда не течет и очень предсказуемо.
              • 0
                Мои личные эксперименты на реальных php-скриптах показали, что mod_php и php-fpm привносят минимальный и примерно одинаковый оверхид. Если одинаковое количество воркеров и оперативки хватает с запасом, то примерно одно количество запросов будет в секунду обрабатываться. Другое дело, что mod_php требует несколько больше памяти, а значит при прочих равных при php-fpm можно поднять несколько больше воркеров (не всегда имеет смысл) или просто отдать освободившуюся память под различные кэши.

                В общем в пользу Apache+mod_php простота деплоя сторонних и унаследованных скриптов, где в .htacces хитрые настройки, а в пользу php-fpm некоторая экономия оперативки и чувство, что не плодишь сущности сверх необходимого. Последнее для меня важнее даже кэшей и простоты :)
                • 0
                  Это если нет нагрузки и в синтетических тестах. В реалиях с нагрузкой apache неконтролирируем, жрет память и в итоге забирает с собой сервер, на который даже залогиниться не получится.
                  А если внутри присутствует говнокод, например древняя пэхэпешечка, спортированная на новую версию, с непофикшенными депрекейтедами и варнингами, то апач просто так кошмарит, даже без нагрузки. У меня есть несколько проектов, которые мы до сих пор не можем смигрировать на nginx+php-fpm, это сплошная головная боль.

                  Хотя, знаю шаредхостинги, где все хорошо.

                  Простите, я уже привык думать в первую очередь про нагрузку и много серверов, в таком мироощущении апачу точно не место ))
                • 0
                  Не знаю как насчет экономии памяти — у нас ситуация получилась обратная:

                  Сравнивали на реальной нагрузке (40-50 разных сайтов на php) nginx + php-fpm + xcache и nginx + apache + mod_php + xcache, настройки пулов worker в apache и php-fpm одинаковые.
                  Да при старте php-fpm занимает в памяти меньше места, но через некоторое время догоняет и обгоняет apache. У apache больше памяти остается разделяемой между процессами.
                  Разница в использовании памяти не велика (в пределах 7-10%), но она сесть.

                  Производительность php-fpm по сравнению с apache + mod_php меряли на синтетических тестах (ab), на том же наборе сайтов — php_fpm на 2-4% быстрее apache. Причем на apache стоит mod_security, который явно не ускоряет процесс…

                  С учетом того что часть сайтов не наши и необходимо для них конвертировать rewrite apache в nginx — остались на связке nginx + apache
          • +1
            Не разбирался как сделано в MPM-ITK, но с php-fpm делается примерно так: для каждого, утрируя, сайта (а в принципе вплоть до отдельных location nginx с одной стороны, и групп сайтов с другой) поднимаем свой сокет (сетевой на отдельном порту или unix) и для него организуем пул воркеров. Этот пул может запускаться от произвольного пользователя и группы, использовать chroot и chdir, использовать индивидуальные настройки php, в общем кастомизироваться. Есть некоторый оверхид в виде невозможности (кажется) динамически сбалансировать нагрузку в целом, то есть для каждого сайта (пула) должен быть минимум один воркер, даже если на этот сайт раз в неделю заходят, а максимальное количество воркеров которые могут подняться можно только (кажется) посчитать, сложив максимальное количество воркеров для каждого пула, но для варианта типа «основной сайт + личные поделки» вполне приемлемо.
            • 0
              Спасибо.
  • 0
    Хорошо, то хорошо. Только mod_rpaf совсем больной.
    Вместо него лучше использовать mod_extract_forwarded который тащит за собой еще mod_proxy.
    • 0
      А чем болен mod_rpaf, простите за ламерство?
      Я в курсе, что в комплекте идет конфиг с ошибкой — но вроде бы одну строчку поправить не проблема…
      • 0
        В том, что он как минимум неверно возвращает X-Real-IP и X-Forwarded-For модулю mod_rewrite. Решения предлагаемые адептами rpaf умиляют своей инвалидностью — с таким успехом тогда проще уще переписывать все рулесы вручную под nginx.
        Насколько я знаю баг зарепорчен разработчику, уже сто лет в обед а воз и ныне там. mod_realip и его производные больны той же детской болезнью.

        Поэтому таки mod_extract_forwarded.
        • 0
          Спасибо за инфу.
  • +1
    Я бы все таки посоветовал логи не отключать.
    • 0
      Знаете. Я тоже согласен. Просто я решил немного диск оптимизировать.
      Дело в том, что я чрезвычайно редко в них заглядываю. Так что только место на диска /var потребляют. Я подумал, что когда начнутся проблемы, я их буду снова все активировать. А на что бы вы обратили внимание, касательно логов, какие есть подводные камни?
  • 0
    Ситуации разные бывают, будут у Вас 500, 504 ошибки вываливаться, 1 раз из 100, это уже плохой знак.
    • 0
      ааа. Ну я на бкенде поставил логи на ошибки.
  • 0
    Спасибо за старания, буду ждать продолжения.

    Подход у вас системный, вот было бы интересно в вашей интерпретации рассмотреть разность в производительности чистого LAMP и nginx+php-fpm по каких-то конкретных тестах. Стало бы ясно: насколько овчинка выделки стоит.
    • 0
      Чистый LAMP проигрывает и LEAMP, и LEMP в реальных условиях (то есть когда на один php-скрипт куча статики), а вот между LEAMP и LEMP особой разницы не заметил, кроме повышенного потребления оперативки в первом случае.
      • 0
        А что в данном случае обозначает E в аббревиатуре LEAMP/LEMP? LNMP — знаю, про LEAMP/LEMP не подсказала даже Википедия.

        Что проигрывает — я так и думал, потому что постоянно об этому слышу и потому что иначе бы никто с альтернативными веб-серверами не морочился. Но вот интересно: а насколько проигрывает в реальном проекте?
        • 0
          (E)ngin(e) X Не знаю насколько корректно такое сокращение, но пару раз на глаза попалось и понравилось :)

          Точных цифр не помню, да и железо тогда не сильно сейчас актуальное было, но в разы точно, если не на порядок. Был шокирован тормозами Apache при отдаче статики, не говоря о потреблении памяти.
          • +1
            Мне стало интересно. Я проведу тестирование в конце цикла статей.
            • 0
              Только следует учесть, что на голом php скрипте разница будет не сильно заметна, нужно эмулировать не просто GET /index.php, а и запрос всех файлов стилей, JS и картинок обычно идущих к нему в нагрузку, пускай даже сервер (Apache или nginx) будет отвечать на них Not Modified по etag или if-modifeied-since
  • 0
    Не ради троллинга, а из любопытства и с целью просвещения (ведь реально могу не знать чего-то важного)…

    Вопрос к автору и к опытным администраторам: какие есть критические причины, кроме привычки, для того, чтобы не использовать на продакшене Ubuntu Server вместо Debian с dotdeb?
    • +1
      Я использую Ubuntu Server и dotdeb :) А вообще Debian славится стабильностью софта в своих репах, а сервер ведь это не только PHP, но и куча чисто системного софта, начиная с ядра. Чисто субъективно вероятность того что с сервером будут проблемы из-за кривого, скажем, sshd пришедшего при очередном обновлении ниже в debian, чем в ubuntu.
      • 0
        Теоретически я с вами согласен, да. Но практически не слышал за 1,5 года и двух новостей о том, что какой-то из пакетов Ubuntu Server оказался дырявым в то время, как аналогичный дебиановский — устоял.

        А dotdeb на Ubuntu Server из-за чего используете? Там ещё свежее пакеты, чем в не-LTS? Когда-то там вроде бы был более свежий nginx, но сейчас — не слежу.
        • 0
          Ну вот сейчас на dotdeb PHP 5.3.18 и 5.4.8, в репе 12.04 (LTS) — 5.3.10, в 12.10 и даже 13.04 — 5.4.6
      • 0
        Согласен. Поэтому и ставлю.

        Дополнительный аргумент — он менее всего перегружен. К примеру, если я захочу sudo на сервере, я его поставлю, а в ubuntu он по умолчанию, равно как и многое другое, что раздражает. Я люблю чистые ОСи с минимум софта на старте.
    • 0
      в принципе — нет, скорее наоборот:
      Ubuntu LTS имеют более долгий жизненный цикл (5 лет против ~2 года у Debian)
      мы в своей компании например долгое время использовали Debian, но сейчас все новые сервера — Ubuntu Server
  • 0
    worker_processes — рабочих процессов поставил по количеству ядер / 2
    Почему пополам? Обычно рекомендуют по количеству ядер.

    DeflateCompressionLevel 1
    Сжимайте nginx'ом, а не апачем.

    почему бы не 9-ть?
    Потому что ресурсов потребляет больше, чем 5. А выигрыша по размеру практически нет.
    • 0
      > Почему пополам?
      Рекомендуют да, но на самом деле пока и так справляется.

      > Сжимайте nginx'ом, а не апачем.
      Аааа. Вот с этим не соглашусь. Это особый феншуй. Сжатие apache позволяет меньше данных передавать через сеть между бэкендом и фронтендом, соответственно тратить меньше ресурсов на операцию копирования памяти. Почитайте, везде советуют сжимать на бэкендах сразу же.

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