Розгортаємо веб-сервер під операційною системою Linux, який буде використовувати одночасно nginx і apache.
Нехай є апаратна платформа, на якій вже встановлений CentOS.
Налаштуємо зв'язку apache + nginx. На передову (front-end) виставляємо легкий і високопродуктивний nginx, який буде обробляти запити до статичного контенту (картинки, стилі, js і т.п.). В тилу (back-end) нас буде страхувати apache, завданням якого є надання динамічного контенту (в основному, PHP).
Безумовно, виникає законне питання, чи не можна обійтися без apache взагалі? Дійсно, нічого не заважає налаштувати спільну роботу nginx + php + mysql (викликаємо PHP в режимі 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 слід відключати (спасибі за наводку уважному читачеві Mike). Продуктивність системи буде підвищуватися, якщо процес httpd, віддавши динамічний вміст, буде тут же звільнятися.
Важливо завести користувача і групу, від яких будуть працювати в зв'язці дві служби: і nginx, і httpd. Природно, це повинен бути один і той же користувач як для httpd, так і для nginx щоб уникнути конфліктів! Я для цих цілей використовую користувача і групу apache; в результаті httpd працює з-під "свого" імені, а nginx змушений працювати під чужим ім'ям.
Таким чином необхідно описати всі віртуальні сервера. Крім того, треба не забути про файлик vhost.conf. в який треба помістити конфігурацію сайту за замовчуванням.
Тепер десерт! Мало налаштувати apache на звичайну роботу, необхідно коректно обробляти REMOTE_ADDR заголовка. Для цих цілей встановлюємо і налаштовуємо RPAF (mod_rpaf відповідає першій версії apache, а mod_rpaf2 - другий).
Таким чином заголовок REMOTE_ADDR знову має користувальницький IP! Наприклад, для моїх цілей це вкрай важливо, тому що доводиться спостерігати за користувачами і вести докладні логи для звітів.
Встановлюємо модуль RPAF, для чого його доведеться знайти в інтернеті окремим пакетом під наш дистрибутив. Є альтернативний шлях: підключити сховище Atomic repo і використовувати yum. Потім налаштовуємо RPAF, створюючи і редагуючи /etc/httpd/conf.d/mod_rpaf.conf:
Після конфігурації необхідно перезапустити Apache.
конфігурація nginx
Описуємо глобальний файл конфігурації / etc / nginx / nginx.conf:
Кінець. Досить запустити всі служби і переконатися, що веб-сервер працює!
Відстежуємо доступ до сервера в реальному часі:
Якщо в консолі браузера з'являється ERR_INCOMPLETE_CHUNKED_ENCODING (зазвичай це буває, якщо файли css і js генеруються "на льоту"), необхідно перевірити права і власника директорії / var / cache / nginx / proxy_temp. Також є сенс прибрати ці два розширення з дозволених статичних типів файлів для nginx.
Якщо в журналі помилок з'являється upstream response is buffered to a temporary file. слід в файл глобальної конфігурації nginx додати proxy_max_temp_file_size 0; в секцію http.