Nginx — уходим на технические работы

[mifa]

Интересно, а насколько «дорого» будет проверка наличия файл при каждом запросе? Ведь если на сервер приходится, скажем, 1000 запросов / сек, то это еще 1000 дополнительных обращений к ФС?

[haskel]

нет.

[romy4]

ФС кеширует такие штуки, но это всё равно плохо. Если это только на время чтения конфига, то подходит решение.

[fzfx]

зависит от того, в каком месте иерархии ФС создавать триггер.
если мы имеем дело с *nix, то можно ведь создать файлик и в оперативке.

[VBart]

Это не избавит вас от лишнего сискола на каждый запрос.

Наиболее правильный и корректный способ закрытия на обслуживание — это релоад nginx-а с соответствующим конфигом.

p.s. imho закрытие сайта для проведения «работ» это какой-то каменный век вообще.

[startsevdenis]

Сегодня на хабре пол дня висело сообщение о проведении «работ»

[VBart]

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

[fzfx]

ну, всех проблем в мире не решить. если частота системных вызовов в 1 килогерц кого-то устраивает, то почему бы и нет, если про реакцию nginx'а на SIGHUP и SIGUSR1 прочитать не довелось.
да и потом, идея с проверкой файл-триггера хоть и ресурсоёмка, зато проста и понятна; а релоад пойди-ка ещё найди как правильно сделать. =)

[Evengard]

ЛОЛ. В Арче /etc/rc.d/nginx reload — это разве сложно?)

[anthonio]

или так: rc.d reload nginx

[TROODON]

service nginx reload

debian-like:

/etc/init.d/nginx reload

Если уж совсем потеряли исполяемый файл:

/find / -name nginx -type f -perm -o+rx

[maffei]

Глянул только что показатели по IO до и после модификации конфига. Разница меньше 0.1%. Но и загрузка сервера, конечно, на порядок меньше.

[sam002]

Может, просто делать rsync на другой сервер и на время работ через изменения записи DNS перенаправлять на него? Можно развить идею и для маломощного второго сервера вставить «всплывающее уведомление», ограничиться отдачей статики.

[maffei]

Я описал лишь один из способов решения проблемы. Ваш вариант также имеет право на существование.

[Klef]

ДНС, для всего мира, обновляет не мгновенно.

[Azy]

Если у вас 1000 запросов в секунду, то в любом случае жинкс как минимум тянет статитики на это количество соединений.
Так что 1000 обращений к ФС это не большая проблема, особенно если вынести файл в RAM

Второй вариант это использовать nginx.org/ru/docs/http/ngx_http_memcached_module.html
устанавливая ключ.

[zhovner]

Для этого специально придумали try_files.

Пример из документации:

location / {
    try_files /system/maintenance.html
              $uri 
 }

[seriyPS]

оно вернет не 503 а 200, на что поисковики болезненно реагируют.

[zhovner]

location / {
    try_files /system/maintenance.html
     
}

location /system/maintenance.html {
    return 503;     
}

[VBart]

Таким образом вы будете отдавать дефолтную 503 на любой запрос и в независимости от наличия/отсутствия /system/maintenance.html

[zhovner]

Наверное предполагается что try_files /system/maintenance.html не единственная строчка в директиве locataion / {}

[VBart]

Я не знаю, что вы предполагали. Последний параметр директивы try_files (а в вашем случае и единственный) всегда задает внутренний редирект.

[seriyPS]

Т.е. полный пример будет выглядеть как

location / {
    try_files /system/maintenance.html @backend;
     
}

location /system/maintenance.html {
    return 503;     
}

Если это работает то это офигенно!

[VBart]

В вашем примере /system/maintenance.html будет обработана в location / с кодом 200.
А на запрос /system/maintenance.html будет возвращена дефолтная 503я.

[zhovner]

Напишите как правильно.

[VBart]

#comment_4676665

[Hint]

Я делаю так:

location / {
error_page 503 /503.html;
return 503;
}

[le0pard]

Картинки то можно обслуживать даже при работах, да и на самой странице maintenance могут использоватся картинки с сервера:
set $maintenance 0;
if (-f $document_root/system/maintenance.html) { set $maintenance 1; }
if ($request_uri ~* (jpg|jpeg|gif|png|js|css)$) { set $maintenance 0; }
if ($maintenance) { rewrite ^(.*)$ /system/maintenance.html; break; }


[VBart]

Не надо программировать на конфигах nginx. Для всего этого есть специальные директивы.

[le0pard]

Так покажите как правильно такое сделать.

[VBart]

Много раз в рассылке обсуждалось.
mailman.nginx.org/pipermail/nginx/2011-November/030165.html

[le0pard]

спасибо

[karellen]

С 503-й еще не забывайте про заголовок Retry-After.

[karellen]

Рано отправил. Я обычно в своем рабочем конфиге держу в апстриме бэкенд специально для выдачи maintenance notice. Если надо уйти в maintenance, я помечаю текущий бэкенд как нерабочий. Заодно оно и само срабатывает, если с бэкендом что-то случилось. Почему именно бэкенд — предпочитаю считать и знать сколько и кто конкретно видел ошибки или maintenance период на сайте, для этого пользуюсь statsd + uid_module.

[xRemaLx]

А чем
sudo /etc/init.d/nginx reload
не устроил?
Вроде как он мягко вводит в силу новый конфиг — новые подключения на новом конфиге, старые отрабатывают и мрут.

[balaganski]

Поддерживаю.

Регулярно пользуюсь, никаких проблем не замечено.

[maffei]

С Вами полностью согласен. Подойдет как restart так reload.

[xRemaLx]

Рестарт выключает сервер, проверяет конфиг и запускает. Релоад в таком случаее лучше — проверка и потом перечитывание конфига.

[zhovner]

Еще проще killall -HUP nginx
И не нужно искать где лежать стартовые скрипты.

[xRemaLx]

Возьму на заметку ;)

[VBart]

Так вы отправите HUP-сигнал всем процессам nginx, полагаю ничего плохого от этого не будет, но лучше отправлять только мастеру. Правильный пример есть в документации: nginx.org/ru/docs/control.html

Ещё проще, nginx -s reload, опять же man nginx

[coolcold]

До кучи может задеть контейнеры(openvz,lxc)/jails

[Aux]

В FreeBSD всё лежит в одном стандартом месте. Как и в других деривативах.

[zhovner]

Да?

FreeBSD/OpenBSD:        /usr/local/etc/rc.d/
NetBSD:                 /usr/pkg/etc/rc.d/
Arch/Slackware:         /etc/rc.d/
Alt Linux:              /etc/rc.d/init.d/
Популярные rpm/deb-based: /etc/init.d

[bost84]

kill -HUP {pid root процесса}

[dmitriid]

sudo invoke-rc.d nginx restart ;)

вбивается по автодополнению в шелле. Но это в Убунту

[AlexWinner]

В Убунту вроде вообще sudo restart nginx

[mascmail]

reload и restart — разные вещи. reload перезагружает файл конфига, не перезапуская сервис.

[AlexWinner]

Я в курсе, отвечал на комментарий про restart, поэтому написал restart.
Действительно, как ниже написали, надо через sudo service. А вот с mongodb, например, и короткий вариант работает:
alexwinner@acer:~$ sudo restart mongodb
mongodb start/running, process 6765


[ha2bj]

sudo service nginx restart

[ha2bj]

т.е. reload

[disc]

У меня почему-то перестает работать rewrite правила, указанные в .htaccess при добавлении в конфиг такого условие, даже если оно пустое:

if (-f /path_to_file/maintenance.file) {
}

Вот что в конфиге location /

location / {
if (-f /etc/nginx/maint.file) {
set $tmp clo;
}
proxy_pass 192.168.1.100:8000/;
}

Без указанного условия работает все верно.
версия nginx/1.0.13
nginx проксирует запросы в apache, используется как фронтенд сервер.

Куда стоит копать?

[lncognito]

Оверхед на проверку существования файла — небольшой. Да и происходит он только при попадании в локейшн с динамикой (из конфига это, правда, однозначно не видно). Вариант с использованием geo и закрытии сайта только для мира также вполне себе кошерен. Вариант с проверкой файла хорош тем, что непривилегированный пользователь может сам «включать-выключать» свой сайтег и вы не хотите давать ему какие-то права. Данная схема с проверкой файлов вполне себе работоспособна (и даже используется на проекте из первой 10-ки рунета, но для немного иных целей). Как всегда, нужно понимать, как и для чего вы используете тот или иной инструмент.

[cadmi]

if в конфигах nginx — это плохо. Чем их меньше, тем лучше. if на каждый запрос — откровенно плохо.
Уж сколько раз твердили миру… Но нет, документацию не читают, почтовую рассылку тем более, Игоря Сысоева не слушают. И раз за разом появляются разнообразные хауту на какие угодно темы… С if-ами.

[seriyPS]

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

[cadmi]

Вы что-то путаете. Язык конфига nginx прекрасно продуман и с возложенными на него задачами [обычно] справляется. В том, что набигает похапешнеков, которые на нем пытаются «программировать» с тремя if-ами (пример выше), язык конфига не виноват. Виноваты те набигающие, которые пытаются утюгом гвозди ногебать.

Слова «почтовую рассылку» Вы, конечно, непредумышленно пропустили при чтении, сокрушаясь про авторские кейсы.

Кто хочет «запутаться», тот это непременно сделает. Пробежал глазами по диагонали и аляулю «о! иф есть, аааатлична, щас наворотим же!».

[seriyPS]

Почтовая рассылка это конечно хорошо, но там информация разрозненная и не всегда правильная, опять же. Я уверен что авторы многочисленных статей а ля «Как выкинуть апач и настроить Nginx за 5 минут» рассылки не читают, а потом такие статьи читают, копируют и пошло поехало.

По поводу очевиден/неочевиден простой аргумент: если значительная часть пользователей (действуя, зачастую, интуитивно) используют что-то неправильно и не по назначению то это что-то неочевидно.

Вот говорят if плохо… Но тут об этом не написано nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if (да, тут об этом сказано, ок wiki.nginx.org/Pitfalls)

Может я и не прав на самом деле, но не покидает ощущение что можно было сделать существенно лучше.

[VBart]

99% проблем возникают от того, что люди пытаются настраивать nginx также, как они настраивали апач, видят реврайт и давай в nginx тоже писать реврайт, и т. д. У тех, кто по какой-то причине не был испорчен апачем, как правило, таких проблем не возникает, при условии, что они читают документацию, а не всякие левые туториалы от таких же чайников. Настраивать сервер согласно не документации, а туториалам — это уж извините, просто профнепригодность. Представьте, что вы придете к врачу, а врач будет лечить вас по советам других пациентов.

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

[cadmi]

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

[cadmi]

Быстро, но глупо, откровенно хреново. Вплоть до SIGSEGV в перспективе. Но пофиг, что неправильно, главное — быстро.

Я повторяю и настаиваю. Есть люди, которые привыкли сначала читать и разбираться, потом делать. Для них информации достаточно. И есть, простите, олени, которые всегда найдут способ прострелить себе ногу, максимально быстро, удобно и наглядно, лишь бы не читать. Из-за наличия вторых обобщать первых до «все путаются» и «язык конфига недостаточно очевидный» — это ерунда. Этим оленям никто ничего не должен. На самом деле этим оленям и nginx никакой не нужен. Они повелись на моду («nginx эт куууул!»), они где-то услышали, что «сразу прям быстро все работать начинает» и «если ты не лох, ставь nginx». Этот шлак («вторые», «олени») мало кого интересует в экосистеме, которая построена «первыми»/«людьми».

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

В рассылке не всегда правильная информация? Ну да, конечно, особенно та, которая в письмах от Igor Sysoev. А какая тогда правильная? Благородные доны не уточняют.

В рассылке разрозненно, вот на сайте бы! Извольте, вот wiki, wiki.nginx.org/IfIsEvil и с кейсами, и с объяснением причин, почему нельзя, и с методиками, что делать вместо.

Ой, а чета по английски-то, где по-русски?

И далее по кругу. Большинство, которое действует интуитивно, не интересует никого, повторюсь.

[cadmi]

Кармы мало, парсер ссылку сьел. «Пример выше» — это про это: habrahabr.ru/post/139968/#comment_4676569

[maffei]

Описанный выше способ ни в коем случае не претендует на универсальность. В условиях проекта для которого разрабатывался — оправдан на 100%. Быстро, наглядно, не влияет общую на производительность, но «плохими» с if-ами.
Пользоваться им или нет — каждый должен оценивать, исходя из собственных реалий.

[cadmi]

Никак он не оправдан, ответ выше. Это только в девичьих мечтах он «на производительность не влияет». Потенциальные SISEGV вообще оправдать нельзя ничем, кроме общей криворукости и частной близорукости.

If-ы не просто «плохие», нечего тут кокетничать кавычками. Они имеют право на существование в конфиге, в некоторых случаях, которые к данному примеру отношения не имеют. И с определенными ограничениями.

В контексте тех примеров, что приводятся в статье, if-ы не просто плохи. Они отвратительны, как бы это ни было обидно автору. Просто примите это.

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

[maffei]

if-ы отвратительны. Принял. Без них сделать уход на мейнтенанс с соблюдением приведенных в начале статьи условий не смог, видимо по причине «общей криворукости и частной близорукости». Уверен, что существует сотня других способов — лучше этого. Но пока только так, извините.

[cadmi]

Да без проблем, особенно если сначала придумать себе искусственные ограничения («Перезагружать Nginx при проведении работ тоже нельзя, ни restart, ни reload»), а потом, героически разбив о них лоб, аппелировать к этому, как к последнему шансу на оправдание костылей.

[maffei]

Спасибо за понимание.

[cadmi]

Вы что-то путаете. Язык конфига nginx прекрасно продуман и с возложенными на него задачами [обычно] справляется. В том, что набигает похапешнеков, которые на нем пытаются «программировать» с тремя if-ами (пример выше), язык конфига не виноват. Виноваты те набигающие, которые пытаются утюгом гвозди ногебать.

Слова «почтовую рассылку» Вы, конечно, непредумышленно пропустили при чтении, сокрушаясь про авторские кейсы.

Кто хочет «запутаться», тот это непременно сделает. Пробежал глазами по диагонали и аляулю «о! иф есть, аааатлична, щас наворотим же!».

[cadmi]

Прошу прощения, не туда ответил, по ссылке из почты.