Как такового администратора нет, частично пока кое-что настраивает сторонняя компания (не хостер). Работаю с ISPmanager, есть удалённый доступ по SSH. В общем, сказали мне, что у меня на VPS установлена связка nginx + Apache. Только вот никаких следов nginx чего-то не могу найти. В частности, в папке /etc присутствует apache2, но нет ничего похожего на nginx.
Доброго времени суток, backend/frontend/full-stack/devops/qa/.. да какая разница, добро пожаловать, мой друг!
Начнем с архитектурных и функциональных отличий.
1. Метод обработки соединений с клиентами
Nginx состоит из master-процесса и нескольких дочерних процессов. Мастер процесс обычно один — он создает дочерние процессы (воркеры, загрузчик кеша и кеш менеджер), считывает конфигурацию и открывает порты. Воркеров обычно несколько, разработчики nginx советуют количество воркеров определять равным числу ядер машины. Эти дочерние процессы буду обслуживать все соединения с клиентами в неблокирующей манере. В nginx используется бесконечный цикл, который бежит по всем соединениями и отвечает на запросы клиентов. Когда соединение закрывается, оно удаляется из event loop. Это решение идеально подходит для проектов, которые обслуживающих 10к+ соединений одновременно. При этом, загрузка CPU и использование памяти обычно равномерны, без видимых пиков.
2. Отдаваемый контент
Apache — может генерировать как статический контент, так и динамический. С этим никаких проблем нет. Прекрасно подойдет тем, кто не хочет заморачиваться с проксированием и настройкой дополнительного инструмента для генерации динамики, ведь Apache — это готовое работающее решение.
Nginx — отдает только статику и из коробки генерировать динамический контент не умеет. Если вы используете nginx и хотите генерировать динамический контент на своем сайте, то вам придется проксировать запросы тому, кто это делать умеет (apache, php-fpm и др.). Поэтому, разработчикам придется настраивать дополнительную связку, которая усложняет архитектуру, например nginx+apache (кстати в этой связке, Apache называют бекенд сервером, а Nginx — фронтендом), nginx + phpfpm, nginx + python и др.
3. Конфигурирование
Nginx не поддерживает конфигурирование на уровне каталогов. Существует один конфигурационный файл на весь проект, который обрабатывает master. Если вы хотите обновить конфигурацию, то необходимо отправить сигнал SIGHUP мастеру, который в свою очередь перезагружает конфигурацию и плавно завершает работу воркеров.
4. Работа с модулями
Apache за долгое время существования обзавелся около 60 официальными модулями, и еще большим числом неофициальных. Модули динамически подключаются, не требуют сборки и перезагрузки веб-сервера.
Nginx имеет около 130 официальных модулей. В отличие от Apache, модули Nginx не могут быть динамически загружены на лету и требуют сборки. Это гораздо сложнее, но считается безопаснее.
5. Интерпретация запросов
Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки.
Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.
6. Работа со скриптовыми языками
В Apache есть один модуль mod_php и все хосты вынуждены работать с одной и той же версией php и одним конфигурационным файлом.
В случае с nginx, каждый виртуалхост будет выполняться в отдельном процессе и, соответственно, может использовать разные версии php (python/ruby/perl и др.). Каждый процесс может иметь свою собственную независимую конфигурацию.
Вообще, в высоконагруженных проектах удобнее держать раздельно nginx и php. По отдельности их проще мониторить, ловить баги или узкие места. «Все-в-одном» Apache+mod_php в этом плане менее удобен.
От основных архитектурных и функциональных отличий переходим к показательным отличиям, отличиям инфрастктуры и всего того, что также является не менее важным при выборе веб-сервера.
7. Скорость работы
Скорость работы веб-сервера обычно измеряют для 2-х случаев отдачи контента: для статики и динамики. На основе тестов производительности, Nginx примерно в 2.5 раза быстрее отдает статику, чем Apache. Это довольно-таки большое превосходство. Если вам необходимо обслуживать большое количество статического контента, Nginx — лучший выбор. Во время тестирования отдачи динамического контента, Apache и Nginx показывают примерно одинаковые результаты. С точки зрения памяти, оба сервера используют один и тот же объем ресурсов. (Подробнее о тестах скорости отдачи контента можно почитать здесь)
8. Поддержка ОС
Apache прекрасно работает на Unix-подобных операционных системах, также разработчики этого веб-сервера полностью поддерживают линейку Microsoft Windows, включая последние версии этой ОС.
Nginx также поддерживает работу на множестве Unix-подобных ОС и имеет некоторую поддержку Windows, которая не является полной. Но разве кто-то в наше время размещает веб-сервер на Windows?
9. Сообщество и поддержка
Apache на рынке с 1995 года, что очень немалый срок, обеспечивший инструменту огромное сообщество и поддержку с его стороны. Практически на все вопросы на Stack Overflow уже есть исчерпывающие ответы. Коммерческой поддержки нет.
Nginx веб-сервер более молодой, на рынке он с 2004 года, что также не помешало большому сообществу сформироваться и поддерживать друг друга. Nginx, в отличие от Apache, имеет коммерческую версию Nginx Plus, которая дополнена инструментами балансировки нагрузки, мониторинга, потоковой передачи медиа и др.
10. Документация и обучение
И у Apache и у Nginx присутствует доступная официальная документация.
Nginx предлагает платное обучение, включающее в себя онлайн курсы, практические занятия и экзамен. По окончании курса все участники получают сертификаты. Например, сдать экзамен по основам nginx и получить официальный сертификат обойдется в 49$ (подробнее здесь).
От себя хотелось бы отметить, что оба решения очень стабильны, безопасны и поддерживаемы. Выбирайте то, что подходит именно вам. Пробуйте, экспериментируйте, ошибайтесь и снова пробуйте. Всем добра и будьте здоровы!
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
🔥 Популярное
Что такое Active Directory и LDAP?
Погружение в Iptables – теория и настройка
Что такое API? Простая статья для вашей бабушки
👌 Похожее
Установка MySQL сервера на Windows 10
Gophish: проведение запланированной фишинг атаки в организации
Использование облачных технологий
Apache vs Nginx – сравнение и преимущества
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и Nginx. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент Nginx (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины, Nginx был введен для преодоления ограничений производительности веб-серверов Apache. Nginx, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут в качестве автономного веб-сервера и в качестве внешнего прокси-сервера для Apache и других веб-серверов. Прочитать про установку и настойку этих серверов можно в этой статье
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Краткий обзор Apache
Модель «один сервер делает все» стала ключом к раннему успеху Apache. Однако по мере увеличения уровня трафика и увеличения количества веб-страниц и ограничения производительности настройка Apache на работу с реальным трафиком усложнялась.
Краткий обзор Nginx
Nginx также имеет богатый набор функций и может выполнять различные роли сервера:
Apache против Nginx: сравнение их богатых наборов функций
Простота
Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех.
Nginx, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей Nginx должны быть очень осторожны, чтобы создавать эффективный и точный код, без сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций.
Производительность
Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим. Давайте посмотрим статистику по этому вопросу.
Статический контент
Nginx работает в 2,5 раза быстрее, чем Apache, согласно тесту производительности, выполняемому до 1000 одновременных подключений. Другой тест с 512 одновременными подключениями показал, что Nginx примерно в два раза быстрее и потребляет меньше памяти. Несомненно, Nginx имеет преимущество перед Apache со статическим контентом. Поэтому, если вам нужно обслуживать одновременный статический контент, Nginx является предпочтительным выбором.
Динамический контент
Результаты тестов Speedemy показали, что для динамического контента производительность серверов Apache и Nginx была одинаковой. Вероятная причина этого заключается в том, что почти все время обработки запросов расходуется в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов.
Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере, не полагаясь на внешние компоненты. Эти динамические процессоры могут быть включены с помощью динамически загружаемых модулей.
Nginx не имеет возможности обрабатывать динамический контент изначально. Чтобы обрабатывать PHP и другие запросы на динамический контент, Nginx должен перейти на внешний процессор для выполнения и дождаться отправки визуализированного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его издержки будут присутствовать только для динамического содержимого.
Поддержка ОС
Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. Nginx также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX.
Безопасность
И Apache, и Nginx являются безопасными веб-серверами. Apache Security Team существует, чтобы предоставить помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках.
Гибкость
Веб-серверы могут быть настроены путем добавления модулей. Apache долго загружал динамические модули, поэтому все модули Apache поддерживают это.
Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживаются обоими веб-серверами.
Поддержка и документация
Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был популярен так долго, поддержка сервера довольно распространена повсеместно. Для главного сервера и для основанных на задачах сценариев, связанных с подключением Apache к другому программному обеспечению, имеется большая библиотека документации первого и стороннего производителя.
Наряду с документацией многие инструменты и веб-проекты содержат инструменты для начальной загрузки в среде Apache. Это может быть включено в сами проекты или в пакеты, поддерживаемые отделом упаковки вашего дистрибутива.
Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности времени, в течение которого он был доступен.
В прошлом для Nginx было трудно найти исчерпывающую англоязычную документацию из-за того, что большая часть ранней разработки и документации была на русском языке. Однако на сегодняшний день документация заполнена, и на сайте Nginx имеется множество ресурсов для администрирования и доступной документации от третьих лиц.
Ngnix против Apache: Сравнение лицом к лицу
Подводя итог, вот табличное представление наборов функций:
Итак, что выберите? Apache или Nginx?
Как видно, Apache и Nginx являются мощными, гибкими и способными. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Настраиваем веб-сервер. Nginx как front-end к Apache
Начнем с теории
В формировании современного динамического контента принимают участие три основных службы: веб-сервер, сервер приложений и сервер СУБД. Если у вас проблемы с БД или не хватает производительности PHP, то никакая замена Apachе на Nginx вам не поможет. Но для чего тогда все продолжают ставить Nginx перед Apache? Давайте разбираться.
Начнем с Apache, с его сильных сторон. Это прежде всего отличная производительность сервера приложений (чаще всего PHP), который является модулем веб-сервера и работает в общем с ним адресном пространстве, снижая потери на взаимодействие между процессами. Затем следует простота настройки и администрирования. Пользователь может сам настраивать веб-сервер для своего сайта через инструкции htaccess, причем в случае какой-либо серьезной ошибки перестанет работать только его сайт или его часть, не затрагивая остальные, которые обслуживаются данным сервером.
Рассмотрим следующую схему:
В верхней ее части показан Apache, работающий в качестве самостоятельного сервера. Давайте посмотрим, что происходит, когда пользователь запрашивает веб-страницу. Прежде всего генерируется динамическое содержимое: запускается экземпляр Apache, его модуль mod_php собирает страницу и отдает пользователю. Но это только начало, каждая страница содержит ссылки на статическое содержимое: скрипты, стили, изображения и т.д. и т.п.
А теперь вспомним немного об особенностях протокола HTTP/1.1: для каждого получаемого от веб-сервера ресурса создается отдельное HTTP-соединение, т.е. запускается отдельный процесс веб-сервера. Это серьезно упрощенная модель, но вполне достаточная для понимания происходящих процессов. Проще говоря, для того, чтобы отдать пользователю картинку мы вынуждены каждый раз запускать достаточно ресурсоемкий Apache со всеми его модулями, которые в данный момент не нужны.
В реальности процесс обработки запросов Apache гораздо более сложен, но смысл от этого не меняется: для того чтобы отдать статическое содержимое мы запускаем весьма ресурсоемкий процесс, большинство возможностей которого при этом избыточно.
К чему это приводит? К тому что при некотором количестве активных клиентов у веб-сервера закончатся ресурсы, и он начнет тормозить или вообще перестанет отвечать на запросы. Это актуально для недорогих VPS c ограниченными ресурсами, особенно когда бюджет проекта не позволяет перейти на более дорогой тариф.
Nginx разрабатывался позже Apache, и его разработчик имел возможность учесть все проблемы связанные с эффективностью обработки запросов, что в итоге стало одной из сильных сторон данного веб-сервера. Действительно Nginx в пределах одного рабочего процесса может обрабатывать большое количество запросов, включая запросы от медленных клиентов, причем делать это предельно эффективно, с небольшим расходом ресурсов.
Однако Nginx не поддерживает динамическую генерацию контента и несовместим с директивами htaccess, поэтому в тех случаях, когда от Apache отказываться нежелательно, Nginx устанавливают перед Apache в качестве front-end.
Нижняя часть схемы как раз отражает такую ситуацию. Apache по-прежнему генерирует динамический контент, остаются рабочими директивы htaccess, но теперь его клиентом выступает не браузер, а Nginx, причем очень быстрым клиентом, это позволяет оперативно забрать у Apache результат его работы и освободить занимаемые им ресурсы. Браузер посетителя получает созданное Apachе содержимое уже у Nginx, как и всю статику.
Если ваш сервер до этого уже работал на пределе своих возможностей, то установив Nginx перед Apache вы скорее всего увидите увеличение производительности. Если же ресурсов хватало, то «на глаз» ничего не изменится, но производительность вашего сервера вырастет, что позволит отсрочить, иногда существенно, переход на более дорогой тариф и более производительный сервер.
Перейдем к практике
Здесь и далее мы будем подразумевать, что веб-сервер настроен по нашей статье Настраиваем веб-сервер на базе Apache в Debian / Ubuntu Server, в иных случаях, возможно, вам потребуется уточнить некоторые детали.
Начнем с Apache, откройте /etc/apache2/ports.conf и измените порты на которых принимает соединения веб-сервер, для этого
Теперь перейдите в /etc/apache2/sites-available и в настройках каждого виртуального хоста приведите директиву VirtualHost к виду:
Причем это нужно сделать и для отключенных сайтов, чтобы потом, подключив данный хост не получить неработающий сервер, так как Apache откажется перезагружаться из-за конфликта портов.
Проверяем правильность конфигурации командой:
Если ошибок нет, то переходим к следующему этапу, на котором мы установим и настроим Nginx.
Nginx можно установить из двух источников: репозиториев дистрибутива и репозиториев разработчиков, мы рекомендуем последний вариант, так вы получите последнюю версию веб-сервера с поддержкой всех современных технологий, в то время как версии из репозиториев дистрибутива могут существенно отставать.
Подключим репозитории разработчиков, для этого создадим в папке /etc/apt/sources.list.d файл nginx.list:
и внесем в него следующие записи.
Затем скачаем и установим PGP-ключ для проверки подлинности пакетов:
Затем обновим список пакетов и установим Nginx:
В процессе установки получим вполне закономерную ошибку: Nginx не сможет запуститься, так как 80-й порт продолжает занимать работающий Apache.
Конфигурацию Nginx в файле /etc/nginx/nginx.conf приведем к следующему виду:
Мы не будем подробно комментировать все перечисленные опции, так как подробно останавливались на них в статье: Настраиваем веб-сервер на базе Nginx + PHP-FPM в Debian / Ubuntu Server. Отметим лишь новую секцию upstream apache24.
Директива upstream позволяет описывать сервер (группу серверов), которым Nginx может передавать свои запросы, такая конструкция удобна прежде всего тем, что в конфигурациях виртуальных хостов не фигурирует адрес и порт вышестоящего сервера, в нашем случае Apache, а только его символьное имя. В опции server, как вы уже догадались, указываем адрес и порт, на котором работает Apache.
На первый взгляд конфиг Nginx может показаться излишне сложным, но на самом деле это не так и если вы настраиваете данный сервер в первый раз, то мы советуем вам пройти по ссылке выше и ознакомиться с той частью статьи, которая описывает настройки Nginx.
Чтобы не писать из конфигурации в конфигурацию хостов одно и то-же создадим шаблон apache24.conf в котором укажем все основные опции подключения к вышестоящему серверу и работы со статическим содержимым. Создадим файл:
И внесем в него параметры соединения с вышестоящим сервером:
Опция proxy_pass перенаправляет все запросы вышестоящему серверу, proxy_set_header нужным образом изменяют HTTP-заголовки страниц, последние три опции задают тайм-ауты соединения.
Ниже добавим секцию для работы со статическим содержимым:
Первая строка содержит список расширений, которые Nginx будет отдавать самостоятельно, список примерный и вы можете откорректировать его под свои потребности. Опция access_log off выключает логи доступа к статике, служит для уменьшения размера файлов лога, однако если ваш сайт находится в стадии разработки, то данная опция будет лишней, так как сделает отладку невозможной. Время кэширования на стороне браузера задается опцией expires, единого мнения на счет его значения нет, в любом случае стоит делать его достаточно большим, но без фанатизма.
Следующая секция задает правила работы со скриптами и стилями:
Ее содержимое аналогично предыдущей, кроме времени кэширования, оно установлено в 180 мин (3 часа), как разумный компромисс между снижением нагрузки на сервер и возможным изменением их содержимого.
Наконец запретим доступ к ht-файлам, в которых содержатся конфигурационные директивы Apache:
Если вы используете phpMyAdmin, то создайте еще один шаблон:
Внесите в него следующее содержимое:
Теперь, когда шаблоны готовы, можно перейти к описанию виртуальных хостов, для этого в папке /etc/nginx/sites-available создадим для каждого сайта свой конфигурационный файл, для примера мы используем домен example.com:
Внутри разместите следующий текст:
И в самом конце подключим шаблоны для работы с вышестоящим Apache и phpMyAdmin.
Обратите внимание, что приведенная настройка хоста будет обслуживать запросы как с www, так и без, если вы хотите использовать вариант только без www или наоборот, например, в целях SEO, то оставьте в директиве server_name только один хост:
А в конфигурационный файл сайта добавьте еще одну секцию server:
Данная конструкция осуществит редирект всех запросов с www, на страницы без www.
Сохраним и подключим файл конфигурации:
Проверим его правильность командой:
И, если все хорошо, перезапустим оба веб-сервера:
Как видим, мы установили Nginx в качестве front-end к Apache на работающем сервере без простоя последнего, спокойно все настроив и проверив правильность настройки. Остается последний вопрос: как проверить, что статическое содержимое отдает действительно Nginx?
Очень просто, если ваш движок принудительно не перехватывает страницы ошибок, то просто запросите несуществующий статический контент, скажем, изображение.
Как видим, установить Nginx перед Apache достаточно просто, несмотря на большой объем данной статьи. А имея некоторый опыт и готовые шаблоны данная операция вообще занимает несколько минут, в тоже время позволяя существенно повысить нагрузочную способность вашего сервера и в полной мере воспользоваться преимуществами каждого из веб-серверов.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Профиль | Отправить PM | Цитировать
В верхней ее части показан Apache, работающий в качестве самостоятельного сервера. Давайте посмотрим, что происходит, когда пользователь запрашивает веб-страницу. Прежде всего генерируется динамическое содержимое: запускается экземпляр Apache, его модуль mod_php собирает страницу и отдает пользователю. Но это только начало, каждая страница содержит ссылки на статическое содержимое: скрипты, стили, изображения и т.д. и т.п.
Конфигурацию Nginx в файле /etc/nginx/nginx.conf приведем к следующему виду:
Как видим, установить Nginx перед Apache достаточно просто, несмотря на большой объем данной статьи. А имея некоторый опыт и готовые шаблоны данная операция вообще занимает несколько минут, в тоже время позволяя существенно повысить нагрузочную способность вашего сервера и в полной мере воспользоваться преимуществами каждого из веб-серверов.
