Nginx перезапустить: Установка Nginx в CentOS 7

Установка Nginx в CentOS 7

Nginx (или Engine X) — это бесплатный, свободный и мощный HTTP- и прокси-сервер с открытым исходным кодом и архитектурой на основе обработки событий. Он написан на языке программирования С и может работать как в Windows, так и в Unix-подобных системах.

Кроме функции веб-сервера, программа может работать в качестве обратного прокси, прокси для TCP/UDP или почты, а также в качестве балансировщика нагрузки. Nginx используется для обеспечения работы огромного количества сайтов в сети интернет, а также известна, как самый высокопроизводительный веб-сервер. В этой статье мы рассмотрим, как выполняется установка Nginx CentOS 7, а также как выполнить первоначальную настройку программы.

Содержание статьи:

Установка Nginx в CentOS 7

Веб-сервер Nginx есть в официальных репозиториях дистрибутива, та версия уже устарела, и если вы хотите получить новую версию с современными возможностями, вам придётся использовать репозиторий EPEL. Для его добавления в систему выполните:

yum install epel-release

Затем можно установить Nginx:

yum install nginx

Чтобы запустить сервис Nginx, выполните:

systemctl start nginx

Затем необходимо добавить программу в автозагрузку:

systemctl enable nginx

Далее надо разрешить трафик для веб-сервера в брандмауэре системы:

firewall-cmd --zone=public --permanent --add-service=http
firewall-cmd --zone=public --permanent --add-service=https

И перезагрузить брандмауэр:

firewall-cmd --reload

Если все было сделано правильно, то, открыв адрес сервера, на который вы устанавливали Nginx, вы увидите страницу по умолчанию:

Настройка расположения файлов сайта

Установка Nginx CentOS 7 завершена, теперь будет рассмотрена настройка Nginx. Нам нужно сообщить Nginx, где будут находится файлы нашего сайта. В конфигурационном файле /etc/nginx.conf, уже настроен один виртуальный хост. Его мы и будем использовать. Здесь указана опция default_server, поэтому он будет открываться для всех запросов к Nginx:

Сначала нужно создать само расположение файлов. Создайте папку /var/www/html/default, в которой будут храниться наши файлы сайтов, и дайте на неё права пользователю nginx:

mkdir /var/www/html/default
chown nginx:nginx /var/www/html/default

Также можно создать файл index.html в этой папке для теста веб-сервера с таким текстом:

vi /var/www/html/default/index.html

<h3>It words!</h3>

Этот файл тоже должен принадлежать пользователю Nginx. Далее в конфигурационном файле /etc/nginx/nginx.conf найдите секцию server и замените значение параметра root на /var/www/html/default:

vi /etc/nginx/nginx.conf

Теперь Nginx будет брать файлы сайта из этого каталога при всех запросах. Перезапустите Nginx:

systemctl restart nginx

Затем откройте снова адрес сервера в браузере, чтобы посмотреть, работает ли наше расположение файлов. Если всё было сделано правильно, вы увидите сообщение it works:

Если возникает ошибка, убедитесь, что у Nginx есть права для доступа к этому файлу, а также, что SELinux отключён или правильно настроен.

Настройка PHP-FPM Nginx CentOS

Если вам нужен Nginx, то скорее всего, вам нужно также настроить его для работы с интерпретатором PHP. Дальше будет разобрана настройка php-fpm Nginx CentOS 7. Прочитать более подробно про установку PHP 7 в CentOS можно в отдельной статье, а в этой статье мы будем работать с версией, доступной в официальных репозиториях. Для Nginx нам необходимо установить пакет php-fpm:

yum install php-fpm

Затем запустите службу php-fpm командой:

systemctl start php-fpm

Откройте конфигурационный файл php-fpm, который находится по адресу /etc/php-fpm. d/www.conf и посмотрите, на каком порту ожидает соединений запущенная служба. По умолчанию это 9000:

Далее нам осталось только связать Nginx с новой службой. Для этого в секцию server добавьте такой код:

vi /etc/nginx/nginx.conf

location ~ \.php$ {
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
include fastcgi_params;
}

Здесь очень важно значение этого параметра:

fastcgi_pass 127.0.0.1:9000

Оно должно соответствовать тому, которое мы видели в файле /etc/php-fpm.d/www.conf. Это адрес и порт на котором ожидает подключения служба php-fpm. Всё остальное можно оставить как есть и модифицировать при необходимости. Затем перезагрузите Nginx:

sudo systemctl reload nginx

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

vi /var/www/html/default/phpinfo.php

<?php phpinfo ?>

Затем откройте адрес сервера на который был установлен Nginx плюс phpinfo.php в браузере:

Теперь вы увидите, что php-fpm nginx настроен полностью и корректно работает.

Обратите внимание, что секция location для php — это регулярное выражение и если у вас будут более общие регулярные выражения, то эта секция должна находиться перед ними, потому что Nginx не будет проверять все регулярные выражения и искать самое подходящее, а выберет первое, которое совпадёт.

Выводы

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

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Оцените статью:

Загрузка…

Как часто вы перезапускаете службу ngnix на веб-сервере Linux?

Эта статья в блоге будет посвящено различным путям перезапуска Nginx в системе Linux через командную строку и Nginx, запущенном в контейнере докер.

Я рассмотрел этот момент как на сервере Systemd, так и на системе SysV init / Upstart.

Откройте терминал и войдите в систему с помощью пользователя root / sudo для запуска нижеприведенных команд.

Перезапустить HTTP-сервер Nginx

CentOS 7, Ubuntu 18.04 и Ubuntu16.04 являются systemd операционной системой.

Чтобы перезапустить службу nginx, вам нужно использовать инструмент командной строки systemctl.

Рекомендуется проверить синтаксис перед перезагрузкой службы nginx,

$ sudo nginx -t
$ sudo systemctl restart nginx

Если вы перезагружаетесь после изменения файла конфига nginx, вам необходимо сначала перезагрузить systemd

$ sudo systemctl daemon-reload

Затем перезапустите nginx

$ sudo systemctl restart nginx

Если вы хотите перезагрузить конфигурацию без перезапуска службы, то для поддержания текущих сеансов используйте

sudo systemctl reload nginx

Перезапуск Nginx в системе Upstart / SysV init

Если вы используете систему с upstart или системой SysV init. например, Ubuntu 14.04, CentOS 6, вам необходимо управлять службой nginx с помощью service

$ sudo service nginx restart

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

sudo /etc/init.d/nginx restart

Перезапуск Nginx внутри контейнера Docker

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

docker exec <nginx-container-name-or-id> nginx -s reload

Если вы должны перезапустить процесс nginx, рассмотрите возможность перезапуска контейнера с помощью команды:

$ docker restart <container name|id>

Пример:

$ docker restart nginx

Где nginx — это имя контейнера nginx.

Перезапуск nginx — это простой процесс, но вы должны быть осторожны, чтобы гарантировать, что внесенное изменение имеет правильный синтаксис, чтобы избежать сбоя во время перезапуска.

Команда, используемая для проверки синтаксиса конфигурации, — nginx -t

Поделитесь статьей:

Nginx Fastcgi pass, безопасность при использовании php-fpm

Передача всех без исключения клиентских запросов FastCGI не только нежелательна, но и опасна поскольку может привести к выполнению на сервере стороннего (часто вредоносного)  кода.

Проверка запросов до их передачи приложению

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

Существует несколько решений, выбор следует делать в зависимости от используемой конфигурации системы и от того работают ли Nginx и менеджер процессов FastCGI на одном сервере или же на разных.

Основное правило — не позволять передавать менеджеру процессов все пользовательские запросы. Для злоумышленника не представляет особого труда передать исполняемый скрипт на уязвимый сервер замаскировав его, например, под изображение.

Позволяя загружать изображения следует убедиться в том, что запрос никогда не доберется до FastCGI.

В спецификации CGI говорится, что файлы, содержащие после «/» дополнительную информацию могут  выполняться как скрипты. Это позволяет злоумышленнику сформировать URI так, что «дополнительной информации» будет предшествовать некий файл, как скрипт не выглядящий, который фактически им будет являться.

Пример:

/test.jpg/index.php

Если конфигурация сервера позволяет выполнять все файлы с расширением .php без проверки FastCGI попытается выполнить переданный запрос. index.php будет расценен как дополнительная информация, test.jpg будет выполнен.

Файл при этом может не быть изображением фактически. Здесь основная угроза.

Самый простой выход из ситуации — выключить возможность использования добавочных путей в настройках РНР.

mcedit /etc/php5/fpm/php.ini

Находим опцию cgi.fix_pathinfo, раскомментируем и устанавливаем ее значение равным  «0»

gi.fix_pathinfo=0

После этого перезапускаем PHP-FPM

/etc/init.d/php5-fpm restart

Описанная ранее ситуация теперь станет невозможна, если файл index.php не существует менеджер процессов вернет ошибку не предпринимая попыток выполнить test.jpg.

Если FastCGI и Nginx работают на одной машине:

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

В конфиге Nginx реализация решения выглядит так:

location~ \.php$ {

try_files $uri = 404;

    . . .

}

Если в приложении задана необходимость обрабатывать подобные запросы обрабатывать их нужно, но необходимо производить проверку до передачи бэкенду.

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

location ^~ /uploads {

}

Внутри каталога можно запретить выполнение PHP файлов:

location ^~ /uploads {

location~* \.(.+?\.php)(.*)$;

set $orig_path $fastcgi_path_info;

try_files $fastcgi_script_name = 404;

fastcgi_pass unix:/var/run/php5-fpm.sock;

fastcgi_index index.php;

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME $request_filename;

fastcgi_param PATH_INFO $orig_path;

fastcgi_param PATH_TRANSLATED $document_root $orig_path;

}

В nginx fastcgi pass отвечает за проксирование запросов — в данном случае в FPM, за счет fastcgi_split_path_info запрос разделяется.

Путь здесь разделяется на $orig_path и $fastcgi_path_info, также за счет try_files файлы проверяются на существование.

Чтобы это работало в конфигурации PHP значение  cgi.fix_pathinfo должно быть установлено в «1».

Также для правильной работы приведенного фрагмента конифга в php-fpm.conf следует задать запрет на использование  security.limit_extensions.

Наименее безопасный способ выполнять серверные скрипты через Apache — запуская их в режиме CGI, опасность вызвана тем, что скрипты требуют права на исполнения. Тем не менее, если скрипты хорошо написаны или работают в изолированном окружении — это самый простой способ.

Как перезапустить Nginx » Tapen.ru

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

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

Как перезапустить Nginx

Первое что вам нужно — это получить доступ по ssh к серверу, но если вы уже меняли там какие-либо настройки, то, скорее всего, доступ у вас есть, так что этот момент упустим. Другой момент, это система управления процессами, сейчас большинство, если не все популярные дистрибутивы, используют systemd. Поэтому я буду описывать работу именно с ней. И еще, вам нужен именно VPS, или сервер, на хостинге такое сделать у вас не получится, даже если есть ssh доступ.

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

nginx -t

Если это производственный сервер, то пользователи вообще не должны заметить что был перезапуск Nginx, а если будут проблемы то после установки веб-сервер не запустится и будет лежать пока вы их не решите. Только теперь можно перезапустить Nginx:

systemctl restart nginx

Если нужно только перечитать конфигурационные файлы выполните:

systemctl reload nginx

Есть еще один путь, можно передать команду перезапуска самому сервису nginx с помощью опции -s:

nginx -s reload

В случае если обычная перезагрузка не помогла, можно попытаться остановить сервис, а затем снова его запустить:

systemctl status nginx

systemctl stop nginx

systemctl start nginx

Перезапуск Nginx с помощью ISPManager

Панель управления VPS ISPManager довольно популярна среди пользователей и если вы используете ее на своем сервере, то можете перезапустить Nginx с помощью нее. Для этого авторизуйтесь в панели, перейдите на вкладку «Система», «Службы», а затем найдите там пункт «Nginx», выделите его и нажмите кнопку «Перезапуск»:

Готово, теперь Nginx перезапущен.

Выводы

В этой небольшой статье мы рассмотрели как перезапустить Nginx на вашем сервере. Если у вас остались вопросы, спрашивайте в комментариях!

Конференция HighLoad в которой рассказывается что нового в Nginx:

как его установить и настроить

В этой статье будем учиться, как правильно устанавливать и настраивать основные части конфигурации NGINX на примере ОС Linux Debian.

Представьте ситуацию: вы создали веб-приложение и теперь ищете подходящий веб-сервер для его размещения. Ваше приложение может состоять из нескольких статических файлов – HTML, CSS и JavaScript, бэкэнда API-сервиса или даже нескольких веб-сервисов. Использование NGINX может быть тем, что вы ищете, и для этого есть несколько причин.

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

Существует два способа установки NGINX – либо использовать установку из пакетов, либо компилировать из исходников.

Первый способ быстрее и проще, но компиляция из исходников дает возможность подключать сторонние библиотеки и модули, что делает NGINX еще более мощным инструментом. Такой способ позволит настроить все “под себя” и для нужд приложения.

Чтобы установить веб-сервер из пакета в ОС Debian, нужно всего лишь:

sudo apt-get update
sudo apt-get install nginx

По завершении процесса установки вы можете проверить, что все в порядке, выполнив приведенную ниже команду, которая выведет на экран установленную версию NGINX.

sudo nginx -v
nginx version: nginx/1.6.2

Ваш веб-сервер будет установлен в директорию /etc/nginx/. Если перейти в эту директорию, можно увидеть несколько файлов и папок. Наиболее важные из них – это файл nginx.conf и папка sites-available.

Основной файл настроек NGINX – это файл nginx.conf, который по умолчанию выглядит так:

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;

	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	gzip on;
	gzip_disable "msie6";

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/x-javascript text/xml 
          application/xml application/xml+rss text/javascript;

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

Файл состоит из директив. Первая из них – events, а вторая – http. Структура из этих блоков создает основу всей конфигурации. Параметры и свойства родителей наследуется всеми дочерними блоками, и могут быть переопределены при необходимости.

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

• worker_processes: эта настройка описывает число рабочих процессов, которые сервер будет использовать. Поскольку NGINX является однопоточным, это число обычно эквивалентно количеству ядер процессора.
• worker_connections: максимальное число одновременных подключений для каждого worker_processes, оно сообщает, сколько людей одновременно NGINX сможет обслужить. Чем это число больше, тем больше запросов пользователей сможет обработать веб-сервер.
• access_log & error_log: это файлы, которые сервер использует для логирования всех ошибок и попыток входа. Эти логи нужно в первую очередь проверять при возникновении проблем и при поиске неисправностей.
• gzip: это свойство устанавливает настройки сжатия GZIP для NGINX ответов. Если включить его в сочетании с другими параметрами, производительность ресурса может значительно вырасти. Из дополнительных параметров GZIP следует отметить gzip_comp_level, который означает уровень компрессии и бывает от 1 до 10. Обычно, это значение не должно превышать 6 т. к. при большем числе прирост производительности незначительный. gzip_types – это список типов ответов, к которым будет применяться сжатие.

Ваш установленный сервер может поддерживать больше одного сайта, а файлы, которые описывают сайты вашего сервера, находятся в каталоге /etc/nginx /sites-available.

Файлы в этом каталоге не являются «живыми» – у вас может быть столько файлов, описывающих сайты, сколько вы хотите, но веб-сервер ничего не будет с ними делать, если они не будут привязаны символической ссылкой на папку /etc/nginx/site-enabled.

Это дает вам возможность быстро помещать сайты в онлайн и отправлять их в автономный режим без фактического удаления каких-либо файлов. Когда вы будете готовы перевести сайт в онлайн – делайте символическую ссылку на sites-enabled и перезапускайте процесс.

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

Теперь создайте новый файл для своего веб-приложения или отредактируйте дефолтный. Типичный конфиг выглядит так:

upstream remoteApplicationServer {
    server 10.10.10.10;
}

upstream remoteAPIServer {
    server 20.20.20.20;
    server 20.20.20.21;
    server 20.20.20.22;
    server 20.20.20.23;
}


server {
    listen 80;
    server_name www.customapp.com customapp.com
    root /var/www/html;
    index index.html

        location / {
            alias /var/www/html/customapp/;
            try_files $uri $uri/ =404;
        }

        location /remoteapp {
            proxy_set_header   Host             $host:$server_port;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_pass http://remoteAPIServer/;
        }

        location /api/v1/ {
            proxy_pass https://remoteAPIServer/api/v1/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_redirect http:// https://;
        }
}

Этот файл имеет похожую структуру на nginx.conf – все та же блочная иерархия (и все они также вложены внутри HTTP-контекста nginx.conf, поэтому они также наследуют все от него).

Блок server описывает специфику работы виртуального сервера, который будет обрабатывать запросы пользователей. У вас может быть несколько таких блоков, и веб-сервер сам будет выбирать между ними на основании директив listen и server_name.

Внутри блока сервера мы определяем несколько контекстов location, которые используются для определения того, как обрабатывать клиентские запросы. Всякий раз, когда приходит запрос, сервер будет пытаться сопоставить свой URI с одним из этих определений location и обрабатывать его соответствующим образом.

Существует много важных директив, которые могут быть использованы, среди них:

• try_files: указывает на статический файл, находящийся в root-директории.
• proxy_pass: запрос будет отправлен на указанный прокси-сервер.
• rewrite: переписывает входящий URI основываясь на регулярном выражении, чтобы другой блок обработал его.

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

После того, как все настройки завершены и сайт перемещен в нужную директорию, мы можем запускать наш веб-сервер следующей командой:

sudo service nginx start

После какого-либо изменения в файле конфигурации, мы должны заставить процесс NGINX перечитать конфиг (без перезагрузки) такой командой:

service nginx reload

И наконец, мы можем проверить состояние процесса командой:

service nginx status

Даже имея огромное количество настраиваемых параметров, NGINX может стать отличным вариантом для управления приложением, или быть использованным в качестве HTTP прокси, или балансировщика нагрузки для веб-сервера. Понимание как работает веб-сервер, и как он обрабатывает запросы, позволит гибко настроить и сбалансировать нагрузку ваших приложений.

Ошибки Nginx и их устранение

502 Bad Gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache,Memcached, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его).

Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в /etc/php-fpm.d/www.conf прописаны правильные права

listen = /tmp/php5-fpm.sock  
listen.group = www-data  
listen.owner = www-data  

504 Gateway Time-out

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

При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения

server {  
... 
   send_timeout 800;
   proxy_send_timeout 800;
   proxy_connect_timeout 800;  
   proxy_read_timeout 800;  
... 
}

Также, причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.

Здесь тоже можно увеличить время ожидания таймаута

location ~ \.php$ {  
   include fastcgi_params;
   fastcgi_index index.php; 
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
   fastcgi_pass unix:/tmp/php5-fpm.sock;  
   fastcgi_read_timeout 800;
}

413 Request Entity Too Large

Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку

client_max_body_size 1m;  

и заменить значение на нужное. Например, мы увеличим размер загружаеамых файлов до 30Mb

client_max_body_size 30m;  

Также, можно отключить проверку тела ответа полностью значением ноль:

client_max_body_size 0;  

После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx

Как перезагрузить nginx

Для перезагрузки NGINX используйте restart или reload.

Команда в консоли:

service nginx reload  

либо

/etc/init.d/nginx reload

либо

nginx -s reload  

Эти команды остановят и перезапустят сервер NGINX.

Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:

nginx -s reload  

Проверить правильность конфигурации можно командой

nginx -t  

В чём разница между reload и restart

Как происходит перезагрузка в NGINX:

• Команда посылается серверу

• Сервер анализирует конфигурационный файл

• Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу

• Если конфигурация содержит ошибки, то при использовании

• restart процесс перезагрузки сервера прерывается, сервер не запускается

• reload сервер откатывается назад к старой конфигурации, работа продолжается

restart обрывает работу резко, reload делает это плавно.

Перезапуск приложений — Nginx — Пассажирская библиотека

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

В этом руководстве объясняется, как перезапускать приложения на Passenger.

Содержание

Зачем нужны перезагрузки

Passenger не запускает приложение с нуля при каждом запросе. Вместо этого Passenger запускает один или несколько экземпляров приложения (процессы приложения) и сохраняет их для обработки множества запросов. Поскольку эти процессы сохраняются, обновления приложения не вступают в силу, пока приложение не будет перезапущено.

Методы перезапуска приложения

Passenger предлагает несколько способов перезапуска приложения, работающего в Passenger.

приложение-перезагрузка конфигурации пассажира

Предпочтительный метод перезапуска приложения — это средство пассажира-config restart-app . Этот инструмент может работать в интерактивном или неинтерактивном режиме.

Интерактивный вызов

Если вы вызываете пассажир-config restart-app без аргументов, оно спросит, какое приложение вы хотите перезапустить. Вот пример:

 $ приложение для перезагрузки конфигурации пассажира
Пожалуйста, выберите приложение для перезапуска.Совет: повторно запустите эту команду с --help, чтобы узнать, как ее автоматизировать.
Если меню отображается неправильно, нажмите '!'

 ‣ / Пользователи / phusion / testapp / public (разработка)
     Отмена 

Используйте клавиши со стрелками вверх и вниз для перемещения по меню. Нажмите Enter, и это перезапустит выбранное приложение.

Неинтерактивный вызов

Вы также можете указать пассажиру-config restart-app перезапустить конкретное приложение вместо запроса меню. Команда принимает префикс пути приложения в качестве первого аргумента.Если он задан, он перезапустит все приложения, путь которых соответствует заданному префиксу.

Например, предположим, что ваше приложение находится в / Users / phusion / testapp . Вы должны сказать Пассажиру перезапустить приложение следующим образом:

 $ пассажира-config-перезапуск-приложение / Пользователи / phusion / testapp
Перезапуск / Пользователи / phusion / testapp / public (разработка) 

Есть еще более короткий путь. Вы можете указать Пассажиру перезапустить все приложения, которые он в настоящее время обслуживает, указав / в качестве аргумента.Это связано с тем, что все пути приложений начинаются с /.

 $ пассажира-config-перезапуск-приложение /
Перезапуск / Пользователи / phusion / testapp / public (разработка) 

Безопасность

В версиях Passenger до 5.0.10 приложение перезапуска пассажира-config должно запускаться от имени того же пользователя, от имени которого запущен основной процесс Passenger. Поскольку это обычно root, пассажира-config restart-app обычно нужно запускать с sudo (или rvmsudo , если вы используете RVM).

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

Дополнительная информация

Средство перезапуска приложения для настройки конфигурации пассажира является самодокументированным. Чтобы узнать больше об этом, выполните следующее:

  приложение-перезагрузка конфигурации пассажира --help
  

перезапуск.txt

Другой способ перезапустить приложение — прикоснуться к файлу restart.txt в подкаталоге tmp каталога приложения. Как только Пассажир заметил, что временная метка файла изменилась, он перезапустит приложение.

Многим этот механизм может показаться немного странным, но он был введен не просто так. Passenger был изначально разработан в эпоху, когда был популярен виртуальный хостинг. В то время самые популярные общие хостеры предоставляли только FTP-доступ, но не SSH.Невозможно было запустить такую ​​команду, как cabin-config restart-app , но даже с помощью FTP можно было изменить временную метку файла. Таким образом, restart.txt был введен как способ.

В отличие от приложения-клиента-config restart-app, касание файла restart.txt не приводит к немедленному перезапуску приложения. Пассажир проверяет изменение метки времени при каждом запросе, но с учетом ограничения производительности по соображениям производительности.

Перезапуск Nginx

Вы можете перезапустить все приложения, которые обслуживает Passenger, перезапустив Nginx.

Иногда вам может потребоваться перезапустить Nginx без перезапуска всех приложений, обслуживаемых Passenger, например чтобы обновить конфигурацию. Если да, попробуйте режим «Летающий пассажир».

Блокирующий перезапуск против перезапуска с нулевым временем работы (скользящий перезапуск)

Если вы используете приложение-пассажира-config restart-app или restart.txt или перезапускаете приложение, тогда Passenger никогда не отбрасывает запросы во время перезапуска.

Однако Passenger по умолчанию выполняет перезапуск , блокирующий .Passenger завершит все процессы для этого приложения и создаст новое. Создание нового процесса приложения может занять некоторое время (может достигать 30 секунд для приложения Rails среднего размера на загруженном сервере). Любые запросы, поступающие в это время, не будут отброшены, но будут заблокированы до тех пор, пока не будет запущен этот первый процесс приложения. Посетители могут расценить это как «простой».

В версии Passenger для предприятий предусмотрена функция непрерывного перезапуска, которая решает эту проблему.Если включен непрерывный перезапуск, Passenger Enterprise перезапускает приложение в фоновом режиме, чтобы посетители никогда не испытывали никаких задержек и не испытывали ухудшения работы пользователя. Дополнительные сведения см. В разделе «Обновление и перезапуск приложений с нулевым временем простоя».

Устойчивость к ошибкам развертывания

С перезапусками с нулевым временем простоя тесно связана функция Enterprise Устойчивость к ошибкам развертывания. Предположим, вы обновили свое приложение и подали команду на его перезапуск, но обновление приложения содержит ошибку (например.грамм. синтаксическая ошибка или ошибка конфигурации базы данных), которая не позволяет Passenger успешно запустить процесс. Пассажир обычно отображает сообщение об ошибке посетителю в ответ на это.

Включив защиту от ошибок развертывания, Passenger Enterprise «замораживает» список процессов приложения. Существующие процессы приложения (принадлежащие предыдущей версии) будут сохранены для обслуживания запросов. Ошибка регистрируется, но посетители не видят сообщений об ошибках. Passenger сохраняет старые процессы, пока администратор не примет меры.Таким образом, посетители минимально пострадают от ошибок развертывания.

Дополнительные сведения об этой функции см. В руководстве «Устойчивость к ошибкам развертывания».

Перезапуск приложений против изменений конфигурации Nginx

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

Настройка веб-сервера Nginx на macOS — Сильвен Дюран

15 ^th декабрь 2017 г.

В поисках удовлетворительного решения для создания локального веб-сервера для программирования в macOS с PHP и MySQL, я был разочарован тем, что готовые решения далеко не соответствовали WAMP, который может существовать в Windows.

Но я забыл, что macOS — это система Unix, и, в отличие от Windows, вполне возможно создать собственный локальный сервер с некоторыми пакетами.

Мы увидим, как установить Nginx , PHP-FPM и MariaDB (MySQL) на macOS High Sierra благодаря диспетчеру пакетов Homebrew .

Домашнее пиво

HomeBrew — менеджер пакетов для macOS, позволяющий легко устанавливать различные приложения Unix.

Для установки просто выполните команду, указанную на официальном сайте:

  / usr / bin / ruby ​​-e "$ (curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
  

Если у вас их еще нет, macOS предложит вам сначала установить инструменты командной строки Xcode.

Nginx

Хотя Apache изначально включен в macOS, мы предлагаем здесь установить Nginx , особенно легкий и легко настраиваемый.

Установка

Для установки и запуска Nginx при запуске мы используем:

  brew установить nginx
sudo brew services запускает nginx
  

Хотя мы не должны использовать sudo с brew install , необходимо использовать его для запуска Nginx , если мы хотим использовать порт по умолчанию 80.

Конфигурация

Мы хотим сохранить наш веб-сайт в выбранной нами папке и получить доступ к URL-адресу http: // localhost / .Для этого отредактируйте файл конфигурации:

  нано /usr/local/etc/nginx/nginx.conf
  

Для начала нам нужно предоставить Nginx разрешение на доступ к нашим файлам и избежать неприятной ошибки 403 Forbidden . Для этого изменим первую строку, где <пользователь> — ваше имя пользователя:

Затем, чтобы добавить новый веб-сайт, мы добавим новый раздел в директиву http :

  сервер {
  слушать 80;
  server_name localhost;
  root / Users / <пользователь> / Documents / путь / к / вашему / сайту;
  index index.html index.htm;
}
  

Затем перезапускаем Nginx , чтобы учесть эти изменения:

  sudo brew services перезапуск nginx
  

PHP

Чтобы использовать PHP с Nginx , мы будем использовать PHP-FPM.
Здесь мы будем использовать PHP 7.2, но вы легко можете выбрать любую другую версию:

  brew установить php72
  

Затем мы повторно редактируем файл конфигурации:

  нано / usr / локальные / и т.д. / nginx / nginx.(. + \. php) (/.+) $;
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32 КБ;
}
  

Чтобы избежать Файл не найден. , нам также нужно предоставить правильные разрешения для PHP. В следующем файле:

  нано /usr/local/etc/php/7.2/php-fpm.d/www.conf
  

Измените следующий параметр на:

  пользователь = <пользователь>
группа = персонал
  

Наконец, перезапускаем Nginx , чтобы изменения вступили в силу, и не забываем запустить PHP, чтобы избежать 502 Bad Gateway :

  sudo brew services перезапуск nginx
sudo brew services запускает php72
  

MySQL

Теперь мы установим и запустим MariaDB:

  brew install mariadb
пивоваренные услуги начать мариадб
  

Наконец, завершите установку, выбрав пароль root для MySQL:

  mysql_secure_installation
  

Вот идеальная установка МАМП!

Документы — Nginx — RunCloud

Базовая команда

Поскольку мы запускаем собственный Nginx, мы изменили имя Nginx, чтобы предотвратить конфликт из основного репозитория Ubuntu, на nginx-rc .

Вам не нужно запускать какие-либо из этих команд, если вы управляете своим сервером через панель RunCloud

  # Start
systemctl запустить nginx-rc

# Стоп
systemctl остановить nginx-rc

# Перезагрузить
systemctl перезагрузить nginx-rc

# Начать сначала
systemctl перезапустить nginx-rc

# Запускаем nginx после перезагрузки
systemctl включить nginx-rc

# Отключить автоматический запуск nginx после перезагрузки
systemctl отключить nginx-rc

# Тест конфигурации
nginx-rc -t
  

Расположение Nginx

  # Место установки
/ RunCloud / Пакеты / nginx-rc

# Местоположение конфигурации
/ и т.д. / nginx-rc / nginx.conf
  

Конфигурация веб-приложения

Не изменяйте эту конфигурацию вручную, так как она будет перезаписана RunCloud

  # Если имя вашего веб-приложения myapp, конфигурация будет находиться внутри
/etc/nginx-rc/conf.d/myapp.conf
  

Пользовательская конфигурация Nginx

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

Например, если имя вашего веб-приложения runcloud-blog , вы можете найти конфигурацию nginx внутри / etc / nginx-rc / conf.d / runcloud-blog.d / main.conf и содержимое файла будет следующим:

  # Не редактировать этот файл
# Редактирование этого файла вручную может сломать систему RunCloud
# Если вы считаете, что это ошибка, свяжитесь с нами по <нашему электронному письму об ошибке>

имя_сервера blog.runcloud.io;
server_tokens выключен;
error_log /home/runcloud/logs/nginx/runcloud-blog_error.log;
access_log /home/runcloud/logs/nginx/runcloud-blog_access.log основной буфер = 16k;
журнал_доступа / var / журнал / nginx-rc / runcloud-blog_traffic.буфер трафика журнала = 16k;

client_max_body_size 256 м;

включить /etc/nginx-rc/conf.d/runcloud-blog.d/headers.conf;

root / home / runcloud / webapps / runcloud-blog;
index index.php index.html index.htm;

location ~ /.well-known/acme-challenge {
    позволять все;
    log_not_found off;
    корень / opt / RunCloud / letsencrypt;
}

место расположения / {
    включить /etc/nginx-rc/extra.d/runcloud-blog.location.root.*.conf;
    включить /etc/nginx-rc/proxy.conf;
}

расположение ~ / \. {
    все отрицать;
    access_log off;
    log_not_found off;
}

расположение = / favicon.ico {
    log_not_found off;
}

location = /robots.txt {
    позволять все;
    log_not_found off;
}

расположение ~. (ico | css | gif | jpe? g | png | gz | zip | flv | rar | wmv | avi | css | js | swf | png | htc | mpeg | mpg | txt | otf | ttf | eot | woff | svg | html) $ {
    истекает 1M;
    включить /etc/nginx-rc/conf.d/runcloud-blog.d/headers.conf;
    add_header Cache-Control "общедоступный";
    включить /etc/nginx-rc/extra.d/runcloud-blog.location.static.*.conf;
    try_files $ uri @proxy;
}

местоположение ~. (html) $ {
    истекает через 24 часа;
    включить / etc / nginx-rc / conf.d / runcloud-blog.d / headers.conf;
    add_header Cache-Control "общедоступный";
    включить /etc/nginx-rc/extra.d/runcloud-blog.location.html.*.conf;
    try_files $ uri @proxy;
}

включить /etc/nginx-rc/extra.d/runcloud-blog.location.main.*.conf;

location @proxy {
    включить /etc/nginx-rc/proxy.conf;
}
  

В конфигурации вы заметите следующие строки:

  include /etc/nginx-rc/extra.d/runcloud-blog.location.root.*.conf;
включить /etc/nginx-rc/extra.d/runcloud-blog.location.static.* .conf;
включить /etc/nginx-rc/extra.d/runcloud-blog.location.html.*.conf;
включить /etc/nginx-rc/extra.d/runcloud-blog.location.main.*.conf;
  

Пример ниже покажет вам, как разрешить вашему IP-адресу доступ к URL-адресу / admin, в то время как другие люди не смогут получить к нему доступ.

Создайте дополнительный файл:

  touch /etc/nginx-rc/extra.d/runcloud-blog.location.main.admin-access.conf
vi /etc/nginx-rc/extra.d/runcloud-blog.location.main.admin-access.conf
  

Вставьте конфигурацию ниже:

  location ~ / admin {
    разрешить 192.168.1.0; # Это нужно заменить на ваш IP-адрес
    все отрицать; # запретить всем доступ к этому URL
}
  

Обратите внимание, что я изменил * на admin-access .