Как обновить nginx centos 7

Обновлено: 03.07.2024

Разработку Nginx начал в 2002 году Игорь Сысоев для Rambler. А в 2004 году он стал доступен широкому кругу пользователей . С 2011 года серверное программное обеспечение начала выпускать уже собственная фирма Игоря, которая спустя 2 года запустила расширенную платную версию продукта до Nginx Plus. Весной 2019 года Nginx была выкуплена крупным американским девелопером F5 Networks.

Он был выпущен в 2004 году под открытой лицензией BSD. Изначально приложение создавалось для решения проблемы масштабирования, известной как «10 тысяч соединений» (С10к). Это значит, что до Nginx web-сервер не был способен одновременно обрабатывать пользовательские запросы более чем с 10 000 подключений.

Сейчас Nginx обслуживает примерно 30,8% всех существующих сайтов мира, о чьих веб-серверах есть информация в открытом доступе. Понимание, что из себя представляет Nginx и как этот программный продукт можно применять на практике, помогает эффективно решать задачи во многих областях IT-индустрии.

2. Как работает Nginx?

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

В качестве интерператора PHP мы берется пакет PHP-FPM. Он специально разработан как прослойка между интерпретатором PHP и программным обеспечением, которое хочет работать с интерпретатором через FastCGI.

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

Внешне для нас это выглядит так: мы отправили код на php, а в ответ получаем текст-результат выполнения кода. Просто и прозрачно.

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

Практическое применение:

Отдельный порт/IP. При наличии большого количества статичного контента или файлов для загрузки, можно настроить на отдельном порту или IP, чтобы осуществлять раздачу. При большом количестве запросов рекомендуется ставить отдельный сервер и подключать к нему Nginx.
Акселерированное проксирование. В таком случае все пользовательские запросы на статичный контент: картинки, простой HTML, JavaScript, CSS-файлы поступают сначала на Nginx, а он их обрабатывает самостоятельно. При этом никаких изменений исходного кода не требуется.
Nginx и FastCGI. Если поддерживается технология FastCGI, Apache вообще можно не использовать. Но в таком случае может потребоваться модификация кодов скриптов.

3. Nginx vs Apache.

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

Поскольку широкий функционал Nginx требует и значительно больших ресурсов системы, постоянно применять полноценную связку «Nginx + Apache» нецелесообразно. Чаще оба web-сервера используются в симбиозе — Nginx отдает статику и перенаправляет обработку скриптов Apache.

Сильные и слабые стороны:

Оба серверы хорошо работают на системах типа Unix, но производительность Nginx на Windows заметно ниже.
При одновременной работе Nginx оказывается в два раза быстрее Apache и использует меньше памяти. С динамическим контентом скорость равна.
Для получения пользовательской поддержки можно обратиться на форум или почту компании, но у Apache Foundation есть с этим проблемы.
Apache хорошо справляется с хостингом нескольких сайтов сразу, но Nginx показывает лучшую «гибкость» и эффективность работы с динамическим контентом.

4. Репозиторий, установка и запуск nginx.

Банальный пример. Если ставить nginx из официального репозитория CentOS 8, настройка виртуального хоста по умолчанию будет прямо в основном файле конфигурации nginx.conf . Это не удобно, так как в этом файле хранится набор настроек без привязки к виртуальным хостам. Если установить nginx из официального репозитория, конфигурация хоста по умолчанию будет в отдельном конфигурационном файле default.conf .

Подключаем репозиторий nginx в CentOS 7. Лучшее использовать mainline версию. Она имеет все нововведения на борту и достаточно стабильна. Если вы хотите стабильную версию, то используйте репозиторий stable.

Создадим конфигурационный файл репозитория /etc/yum.repos.d/nginx.repo .

Теперь устанавливаем nginx на сервер.

Запускаем nginx и добавляем в автозагрузку.

Проверим старт nginx в системе:

Проверяем, запустился ли web-сервер.

Для этого идем по ссылке:

Вы должны увидеть стандартную страницу заглушку:

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

Для работы web-сервера требуется пробросить порт 80/tcp, порт 443/tcp порт через брандмауэр.

5. Модификация заглушки nginx.

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

Nginx – это популярный веб-сервер и обратный прокси-сервер с высокой производительностью. В этом руководстве речь пойдёт о том, как обновить исполняемые файлы Nginx, не теряя клиентских подключений.

Требования

Для выполнения руководства нужен не-root пользователь с правами sudo и предварительно установленный сервер Nginx.

Чтобы создать пользователя с правами sudo и установить Nginx, читайте:

Для Ubuntu 14.04:

Как обновляется Nginx?

Работа Nginx состоит в создании master-процессов при запуске сервисов. В свою очередь главный сервис запускает ещё один или больше рабочих процессов, которые обрабатывают клиентские подключения. Получая определенные сигналы от администратора, Nginx будет выполнять некоторый ряд действий. Именно эти сигналы администратора предоставляют возможность легко обновить сервер Nginx или его настройки, не теряя при этом клиентских подключений.

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

Для этого используются сигналы:

Обнаружение PID процесса Nginx

Чтобы отправлять сигналы различным процессам сервера, нужно знать PID (Process Identification Number, идентификатор) целевого процесса. Его можно узнать двумя способами.

Можно использовать утилиту ps, а затем найти в результате Nginx с помощью grep. Этот простой способ позволяет найти главные и рабочие процессы.

PID процессов находится во втором столбце. Красным выделен PIDискомого процесса. Последняя строка сообщает, что главный процесс Nginx выведен в первой строке.

Также PID главного процесса Nginx можно вывести из содержимого файла /run/nginx.pid.

cat /run/nginx.pid
10846

Если на сервере запущено два главных процесса Nginx, боле старый процесс будет перемещён в /run/nginx.pid.oldbin.

Запуск новых процессов Nginx

Чтобы приступить к обновлению исполняемого файла, нужно обновить двоичный файл. Метод обновления этого файла зависит от метода установки Nginx (с помощью менеджера пакетов или из исходного кода)

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

sudo kill -s USR2 10846

Примечание: Этот условный PID нужно заменить своим идентификатором.

Кроме того, обнаружить и использовать PID целевого процесса можно непосредственно во время отправки сигнала:

sudo kill -s USR2 `cat /run/nginx.pid`

Проверьте текущие процессы, чтобы убедиться, что второй набор процессов успешно запущен:

ps aux | grep nginx
root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 10847 0.0 0.1 47936 1908 ? S 13:26 0:00 nginx: worker process
root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process
user 11031 0.0 0.0 112640 960 pts/0 S+ 14:01 0:00 grep --color=auto nginx

Также можно видеть, что оригинальный файл /run/nginx.pid был перемещён в /run/nginx.pid.oldbin, а PID нового master-процесса записан в /run/nginx.pid:

tail -n +1 /run/nginx.pid*
==> /run/nginx.pid <==
11003
==> /run/nginx.pid.oldbin <==
10846

Теперь сигналы можно отправлять любому из этих главных процессов, указывая соответствующий PID.

На данный момент оба набора процессов работают и могут обслуживать запросы клиентов. Первый набор использует оригинальный исполняемый и конфигурационный файл Nginx, а второй набор использует более новые версии этих файлов. Они могут продолжать работать вместе. Теперь можно приступать к обновлению веб-сервеера Nginx.

Отключение старого набора процессов

Чтобы начать переход к новому набору процессов, сначала нужно остановить рабочие процессы оригинального главного процесса (то есть устаревший набор процессов). Оригинальные рабочие процессы закончат обработку всех своих текущих соединений, а затем остановятся.

sudo kill -s WINCH `cat /run/nginx.pid.oldbin`

Таким образом обработка клиентских запросов полностью перейдёт к рабочим процессам нового набора. Оригинальный главный процесс всё ещё будет запущен, но при этом у него не будет рабочих процессов:

ps aux | grep nginx
root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process
user 11089 0.0 0.0 112640 964 pts/0 R+ 14:13 0:00 grep --color=auto nginx

Это позволяет проверить новые рабочие процессы, поскольку сейчас они принимают соединения изолированно, оставляя возможность вернуться к старой версии исполняемого файла, если что-то пойдёт не так.

Результаты и дальнейшие действия

На данном этапе нужно проверить систему и убедиться, что не возникло никаких ошибок или проблем. Вы можете оставить конфигурации в этом состоянии до тех пор, пока на 100% не убедитесь в том, что новый исполняемый файл не содержит ошибок.

Дальнейшие действия полностью зависят от результатов проверки.

Завершение перехода

В случае успешного обновления завершите переход.

Если во время проверки не появились ошибки, можно отключить устаревший главный процесс. Для этого отправьте ему сигнал:

sudo kill -s QUIT `cat /run/nginx.pid.oldbin`

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

Восстановление старого бинарного файла

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

sudo kill -s HUP `cat /run/nginx.pid.oldbin`

Теперь на сервере снова запущены два набора процессов:

ps aux | grep nginx
root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root 11003 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process
nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process
user 19920 0.0 0.0 112640 964 pts/0 R+ 14:48 0:00 grep --color=auto nginx

Новые рабочие процессы связаны со старым главным процессом. Теперь клиентские соединения поступают на два набора процессов. Остановите более новый главный процесс, содержащий ошибку, и его рабочие процессы при помощи сигнала QUIT:

sudo kill -s QUIT `cat /run/nginx.pid`

Теперь все запросы полностью обрабатываются оригинальным набором процессов.

ps aux | grep nginx
root 10846 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process
user 19935 0.0 0.0 112640 964 pts/0 R+ 14:50 0:00 grep --color=auto nginx

PID главного процесса переместится в файл /run/nginx.pid.

Если предложенные выше инструкции не сработали по какой-либо причине, попробуйте послать новому главному процессу сигнал TERM, который инициирует его отключение.Это должно остановить новый master-процесс и все его рабочие процессы, автоматически возобновляя старый master-процесс и инициируя его рабочие процессы.

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

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

В итоге сам скачал файл и закинул его на сервер, а как обновить или установить не понятно.

Может кто сталкивался с таким и подскажет?

Простой 1 комментарий

А что Вы ожидали от той команды? Вы вроде собирались nginx обновить, а скачивали исходники. Умеете хоть из исходников билды делать?

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

В итоге решил проблему через sudo checkinstall, добрый человек подсказал, без всяких ссылок документаций.

Fnps, Это не копипестная документация, и не какое-то левое howto, а именно то, что надо внимательно прочесть, и понять.
Репозиториев где есть нужный вам nginx существенно более одного, и откуда именно брать это вопрос доверия к ним.

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

Борис Сёмов, Вы не поняли вопрос, не хочет nginx обновляться с репозитоториев, какой бы я не написал хоть самый левый и не проверенный. Дело тут отказалось в панельке ispmngr 5 она сама со своего зеркала обновляет его, а мои пути блочит. Даже тот же checkinstall в итоге не помог, тк панелька через день откатила все назад. Писал им в поддержку и получил ответ, что да так и есть, хотите обновить придется удалить панель.

Насчет документаций, чтобы получить ответ на элементарный вопрос, нужно прочитать целую тонну информации потратив день-неделю-год, которая пригодиться в жизни только каким сисадминам которые всю жизнь на это тратят и этим зарабатывают, мне не нужно знать, как там нейроны с протонами бегут и какие там квантовые поля, надо 1 раз чтобы включил -работает, если работает - не трогай и все, а не познавать азы линукса с 0, ответом может быть всего одна маленькая команда или какой универсальный конфиг, человек кто с таким сталкивался и компетентен знает это сразу и может сэкономить вам кучу времени, поэтому собственно вопросы и задаются. Документацию можно и без вопросов почитать и читают до вопроса, если не нашли ответ, то пишут вопрос, а там опять документацию кидают о/, это вообще универсальный ответ на все вопросы, умничать много ума не надо.

Можно отключить репозиторий isp, точнее nginx оттуда не обновлять используя exclude=nginx в конфиге репозитория.

Тонну информации нужно прочесть, чтобы понимать что делать, а не тупо нажать на подсказанную кнопку и получить совсем не тот результат, который ожидаете, что у вас и произошло.
Да и вообще, это так не работает - т.к. мало раз настроить, надо дальше эксплуатировать систему, а для этого надо понимать как. А если нет времени/желания изучить, хотя бы, основы, то может быть, не стоит заниматься этим вообще? Нанять кого-то и получить нормальный результат тоже выход.

Борис Сёмов, что кому делать, решает каждый сам, где-то он компетентен, а где-то нет. Поэтому и пишут вопросы, если бы все все знали , то и вопросов бы не было и сайт такой был бы не нужен.
Ответ по делу могут дать единицы, а умничать и тролить могут все. Зачем вообще писать кучу текста и пытаться с кем-то спорить? Если знаешь ответ и хочешь им поделиться, то пишешь "Можно отключить репозиторий isp, точнее nginx оттуда не обновлять используя exclude=nginx в конфиге репозитория, нажать там туда, вставить это." и все, зачем этот детский сад с нравоучениями разводить и тд. Или 2 вариант, просто плюнуть и пройти мимо. "Нанять кого-то и получить нормальный результат тоже выход." Тоже универсальный ответ не носящий полезной информации, не совета же прошу, а решение конкретного вопроса. Профдеформация(чсв) бывает у каждого, но все когда-то были новичками.

Если вы новичок, то мой совет обратиться к документации вам очень нужен. Чтобы научиться, надо учиться, а не пытаться получать всё готовое. И начинать надо с основ.
Если вам это не нужно, то вам полезен совет нанять кого-то компетентного. Ответа однозначного на начальный вопрос просто не было.
А проф деформация тут не при чём, вам просто надо понять, что то, чем вы пытаетесь заниматься совсем не так просто, и без базовых знаний, даже нормально вопрос не задать. Борис Сёмов, Ну не знаю, вроде ничего заоблачного не просил. Обновить обычную программу, такие вопросы обычно решаются в 1 команду за 5 сек на любой системе. Если это не так и для этого нужно прочитать тонны информации, а ответа просто нет, то это 1970-1980 года. Что я не особо верю, ведь есть много людей которые ничего не учили и пользуются спокойно на базовом уровне это называеться юзабилити и массадопшен на примитивном уровне, обновить программу это элементарное действие.
Ладно, эти споры уводят в другую сторону и несут 0 полезной информации и просто флуд, не нашел бы тут ответа, на зарубежном форуме спросил бы, там лояльнее. Но адекватный ответ на элементарный вопрос, всегда есть.

Fnps, Ваш начальный вопрос звучит, на самом деле, так: Я выполнил несколько не понятных мне команд из нескольких произвольных howto, не понимая области их применимости, моя система в каком-то произвольном состоянии, что мне делать? Вы думаете, есть простой ответ на него, серьёзно?

Т.к. вы не очень знакомы с предметом, вы не понимаете, что ваша задача далеко за рамками просто обновления софта, и за рамками действий, которые массово кому нужны. Те, кто "не учили", ставят панель, и ничего больше делать не пытаются, ну и наивно полагают, что они настроили таким образом сервер, заодно, что конечно не так.
А те, кто могут спокойно что-то менять в такой ситуации, как раз учили, и понимают, что это не тривиально, отнюдь. Собственно, именно поэтому техподдержка ispsystems вам и ответила, что нельзя это сделать в рамках их панели.

Для получения последней версии NGINX создаем файл с настройками нового репозитория:

И приводим его к следующему виду:

Обновляем систему и список пакетов:

* если система запросит подтверждение, отвечаем Y.

Устанавливаем NGINX следующей командой:

yum install nginx

firewall-cmd --permanent --add-port=80/tcp

firewall-cmd --permanent --add-port=443/tcp

Теперь добавляем NGINX в автозапуск при загрузке CentOS

systemctl enable nginx

И запускаем веб-сервер:

systemctl start nginx

Для проверки запустите браузер на другом компьютере и введите в адресную строку IP-адрес сервера, который был настроен. Должна загрузиться тестовая страница, наприимер:

NGINX + PHP + PHP-FPM

В чистом виде, веб-сервер NGINX используется редко. Настроим связку с PHP и его обработчиком — PHP-FPM.

Для начала, устанавливаеми тот и другой следующими командами:

yum install php

yum install php-fpm

Разрешаем автозапуск php-fpm и запускаем его:

systemctl start php-fpm

systemctl enable php-fpm

Настройка NGINX для работы с PHP и PHP-FPM

Открываем настройки сайта по умолчанию:

Редактируем секцию location:

location / root /usr/share/nginx/html;
index index.php;
>

* здесь мы поменяли index.html на index.php. Эта настройка позволит автоматически искать и запускать файл index.php, если путь к скрипту не указан явно.

Приводим к следующему виду секцию server:

\.php$ set $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
>

* где /usr/share/nginx/html — корневой путь по умолчанию для хранения сайта; 9000 — порт, на котором работает php-fpm.

Читайте также: