Разширяване на уеб сървър с операционна система Linux, която ще използва Nginx, така и Apache.
Нека да има хардуерна платформа, която вече е инсталиран CentOS.
Ние се създаде един куп Apache + Nginx. За отпред (челен) са поставяне на светлина и висока производителност Nginx можех, които ще се справят с искания за статично съдържание (изображения, стилове, JS, и т.н.). В задния (обратно края) ще застрахова Apache, чиято задача е да осигури динамично съдържание (основно, PHP).
Разбира се, възниква въпросът дали не е възможно да се направи без Apache изобщо? Всъщност, нищо не пречи конфигуриране сътрудничество Nginx + PHP + MySQL (наричаме РНР в режим на FastCGI, като се използва PHP-FPM). Извършването на такава система ще бъде още по-висока. Но има един сериозен недостатък: повечето стандартни двигатели сайтове, насочени пряко върху работата под Apache (права за достъп до различни директории сайта са конфигурирани в .htaccess файла); и с оглед на факта, че Nginx не се занимава с .htaccess, такива обекти по Nginx няма да работят без промяна. Освен това, ако обработването на сайта е съвсем възможно технически проблем, поддържането на няколко места (особено чужди), тя се превръща в истински проблем.
Така че ние жертваме екстремна производителност, но запази подкрепата за .htaccess.
Инсталиране на Apache, MySQL, PHP. За да направите това, ще е необходим стандарт Yum хранилище.
Инсталиране на Nginx е малко по-сложно, че е необходимо да отидете на уебсайта на програмиста и прочетете метода на инсталация. За щастие, в съответствие с общите разпределения (CentOS и други подобни), разработчикът осигурява готови торбички.
Ние се създаде цялата банда:
- конфигурацията на MySQL
- конфигурацията на PHP
- конфигурация на Apache
- Конфигурация Nginx.
Сега гледам на всяка стъпка в детайли.
конфигурацията на MySQL
конфигурацията на PHP
Почти не се изисква, той е описан подробно в отделна статия. Основното нещо е да не се забравя за shorttag: short_open_tag = On.
конфигурация на Apache
Тъй като предната Nginx бихме могли да представи, това означава, че ще се движат по стандартния порт 80 и Apache ще се хареса на прокси сървър, чрез всеки друг порт. Аз избрах 8080.
Ние модифицирате файла глобалната настройки. Цитирам само най-важните параметри, които трябва да бъдат проверени:
Интересното е, че трябва да бъде забранено Keepalive (благодаря за върха Майк внимателен читател). Работата на системата ще се засили, ако процесът на уеб-, давайки на динамично съдържание, ще бъдат незабавно освободени.
Важно е да се направи на потребителя и групата, от която ще работи заедно две услуги: и Nginx можеше, и уеб-. Разбира се, това трябва да бъде един и същ потребител за уеб-, Nginx и да се избегнат конфликти! Използвах за този потребител и група Apache; в резултат на уеб-изчерпване на "своя" име, но Nginx е принудена да работи под чуждо име.
Така че е необходимо да се опишат всички виртуалния сървър. В допълнение, ние не трябва да забравяме файл vhost.conf. в които е необходимо да се постави стандартната конфигурация на сайта.
Сега десерт! Не регулирайте достатъчно Apache към нормална работа, трябва да се справят правилно заглавието на REMOTE_ADDR. За тези цели се инсталира и конфигурира RPAF (mod_rpaf съответства на първата версия на Apache, и mod_rpaf2 - втората).
Така REMOTE_ADDR заглавна отново има обичай IP! Например, за моите цели, това е изключително важно, тъй като ще трябва да гледате на потребителите и води подробни дневници за доклади.
Задайте RPAF модул, за които той ще трябва да се намери в Интернет на отделен пакет под наш разпределение. Налице е алтернативен начин: свързване на съхранение атомна репо и да използвате Yum. Тогава мелодия RPAF, създаване и редактиране на /etc/httpd/conf.d/mod_rpaf.conf:
След конфигурация е необходимо да рестартирате Apache.
конфигурация Nginx
Ние описваме глобалната конфигурационния файл / и т.н. / Nginx / nginx.conf:
Край. всички услуги са достатъчни, за да се рестартира и се уверете, че уеб сървърът работи!
Проследяване на достъп до реално време на сървъра:
Ако конзолата на браузъра се появява ERR_INCOMPLETE_CHUNKED_ENCODING (обикновено се случва, ако CSS файлове и JS генерирани "в движение"), проверете правата на собственика на директорията и / Var / кеш / Nginx / proxy_temp. Също така, че има смисъл да се отстранят тези две разширения на разрешените статични типове файлове за Nginx.
Ако се появи грешка дънер отговор нагоре се буферира до временен файл. трябва да бъде в глобален конфигурационен файл за добавяне на Nginx proxy_max_temp_file_size 0; в раздел HTTP.
Свързани статии