Re: Статика с поддомена
Добрый день.
Симлинки в sites-enabled сделали?
28.10.2014 13:12, Zarus пишет:
Здравствуйте , пробую сделать раздачу статики с поддомена , не получаеться в
чем может быть ошибка ? Спасибо
в sites-available создал
static.mysite
server {
server_name static.mysite.ru;
location / {
root /home/www/public/images;
}
}
mysite
server {
set $mysite_root /home/www/mysite/public;
listen mysite.ru;
server_name mysite.ru;
root $mysite_root;
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,254340,254340#msg-254340
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
smime.p7s
Description: Криптографическая подпись S/MIME
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статика с поддомена
Да симлинк в sites-enabled сделан , права выставленны Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254340,254342#msg-254342 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статика с поддомена
On Tuesday 28 October 2014 07:12:16 Zarus wrote:
Здравствуйте , пробую сделать раздачу статики с поддомена , не получаеться в
чем может быть ошибка ? Спасибо
Что именно не получается?
[..]
mysite
server {
set $mysite_root /home/www/mysite/public;
listen mysite.ru;
server_name mysite.ru;
root $mysite_root;
}
Не надо так делать.
Правильно:
root /home/www/mysite/public;
--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статика с поддомена
После конфигурации , static.mysite.ru/image.png . не доступно Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254340,254344#msg-254344 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx environment directives
Hello! On Tue, Oct 28, 2014 at 04:21:53AM +0300, S L wrote: Mon, 27 Oct 2014 19:23:17 +0300 от Maxim Dounin mdou...@mdounin.ru: Hello! On Fri, Oct 24, 2014 at 03:11:03PM +0400, S L wrote: где это опция сборки? В апаче? вот что это за опция... и она на запуск, а не на сборку. -D name : define a name for use in IfDefine name directives Если вы передаёте -DOPENSSL_NO_HEARTBEATS Апачу при запуске - то оно ничего полезного не делает, кроме как позволяет проверить соответствующее имя конфигах. Если вопрос на самом деле про то, как сделать в nginx'е конфигурацию, зависящую от переменных окружения, т.е. какой-либо аналог директивы IfDefine в Апаче, то ответ - использовать любимый шаблонизатор, например make + sed. Если вопрос про то, как защититься от атак в связи с уязвимостью Heartbleed, то ответ - обновить OpenSSL. (В крайнем случае - пересобрать OpenSSL с соответствующей опцией, но лучше так не делать, ибо и других дырок хватает.) Если вопрос про то, как запретить OpenSSL'ю использование расширения Heartbeat (на всякий случай, вдруг там ещё где грабли), то ответ - собрать OpenSSL с соответствующей опцией. А если у меня бинарный дистрибутив, то опцию никак нельзя выключить? Никак. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статика с поддомена
On Tuesday 28 October 2014 08:26:00 Zarus wrote: После конфигурации , static.mysite.ru/image.png . не доступно Что понимается под не доступно? Ничего не возвращается? Возвращается ошибка? Если ошибка, то какая? Что в логе ошибок при этом? -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx-1.7.7
Изменения в nginx 1.7.7 28.10.2014 *) Изменение: теперь nginx учитывает при кэшировании строку Vary в заголовке ответа бэкенда. *) Добавление: директивы proxy_force_ranges, fastcgi_force_ranges, scgi_force_ranges и uwsgi_force_ranges. *) Добавление: директивы proxy_limit_rate, fastcgi_limit_rate, scgi_limit_rate и uwsgi_limit_rate. *) Добавление: параметр Vary директив proxy_ignore_headers, fastcgi_ignore_headers, scgi_ignore_headers и uwsgi_ignore_headers. *) Исправление: последняя часть ответа, полученного от бэкенда при небуферизированном проксировании, могла не отправляться клиенту, если использовались директивы gzip или gunzip. *) Исправление: в директиве proxy_cache_revalidate. Спасибо Piotr Sikora. *) Исправление: в обработке ошибок. Спасибо Yichun Zhang и Даниилу Бондареву. *) Исправление: в директивах proxy_next_upstream_tries и proxy_next_upstream_timeout. Спасибо Feng Gu. *) Исправление: nginx/Windows не собирался с MinGW-w64 gcc. Спасибо Kouhei Sutou. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Корректная работа с tomcat deploy
Привет всем, Каким образом можно корректно работать с tomcat-upstream, который используется для java-приложения, deploy которого занимает несколько минут? Среда: На входе стоит nginx proxy, в котором настроено n апстримов в режиме round-robin с max_fail=1. За ним - n серверов приложений, на которых работает Apache Tomcat, в котором работает java-приложение. Если падает один из серверов приложений - все прекрасно, nginx стучится к нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное время и рероутит запрос на другой апстрим. Пользователь проблемы не видит. Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy (либо мы сами стартовали re-deploy) - возникает проблема. Проблема: Деплой java-приложения в случае краша или обновления занимает несколько минут (в особо злом случае - до десяти). Томкат, сволочь, в это время принимает входящие соединения на свой порт, но не обслуживает их, а вешает на холд до момента завершения деплоя приложения. Nginx принимает коннект от пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока бэкэнд не поднимется. В итоге пользователь видит белый экран или частично загрузившуюся страницу (как повезет раунд-робином), хотя в живых есть куча других апстримов, которые могли бы обслужить его запрос. Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго думать или отдавать много данных и решить проблему в лоб, урезав proxy_read_timeout до нескольких секунд - нельзя. Меня может что-то спасти? -- With best regards, differentlocal (www.differentlocal.ru | differentlo...@gmail.com), System administrator. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Корректная работа с tomcat deploy
On Tuesday, October 28, 2014 10:31:11 PM Никита Кардашин wrote:
Привет всем,
Каким образом можно корректно работать с tomcat-upstream, который
используется для java-приложения, deploy которого занимает несколько минут?
Среда:
На входе стоит nginx proxy, в котором настроено n апстримов в режиме
round-robin с max_fail=1. За ним - n серверов приложений, на которых
работает Apache Tomcat, в котором работает java-приложение.
Если падает один из серверов приложений - все прекрасно, nginx стучится к
нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное
время и рероутит запрос на другой апстрим. Пользователь проблемы не видит.
Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy
(либо мы сами стартовали re-deploy) - возникает проблема.
Проблема:
Деплой java-приложения в случае краша или обновления занимает несколько
минут (в особо злом случае - до десяти). Томкат, сволочь, в это время
принимает входящие соединения на свой порт, но не обслуживает их, а вешает
на холд до момента завершения деплоя приложения. Nginx принимает коннект от
пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока
бэкэнд не поднимется.
В итоге пользователь видит белый экран или частично загрузившуюся страницу
(как повезет раунд-робином), хотя в живых есть куча других апстримов,
которые могли бы обслужить его запрос.
Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго
думать или отдавать много данных и решить проблему в лоб, урезав
proxy_read_timeout до нескольких секунд - нельзя.
Меня может что-то спасти?
--
With best regards,
differentlocal (www.differentlocal.ru | differentlo...@gmail.com),
System administrator.
Привет.
Может быть, добавить в ваш скрипт прикрытие порта фаерволлом на время деплоя?
По принципу:
try {
iptables -A … -j REJECT
} finally {
iptables -D … -j REJECT
}
--
Best regards,
Styopa Semenukha.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Корректная работа с tomcat deploy
Hello!
On Tue, Oct 28, 2014 at 10:31:11PM +0500, Никита Кардашин wrote:
Привет всем,
Каким образом можно корректно работать с tomcat-upstream, который
используется для java-приложения, deploy которого занимает несколько минут?
Среда:
На входе стоит nginx proxy, в котором настроено n апстримов в режиме
round-robin с max_fail=1. За ним - n серверов приложений, на которых
работает Apache Tomcat, в котором работает java-приложение.
Если падает один из серверов приложений - все прекрасно, nginx стучится к
нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное
время и рероутит запрос на другой апстрим. Пользователь проблемы не видит.
Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy
(либо мы сами стартовали re-deploy) - возникает проблема.
Проблема:
Деплой java-приложения в случае краша или обновления занимает несколько
минут (в особо злом случае - до десяти). Томкат, сволочь, в это время
принимает входящие соединения на свой порт, но не обслуживает их, а вешает
на холд до момента завершения деплоя приложения. Nginx принимает коннект от
пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока
бэкэнд не поднимется.
В итоге пользователь видит белый экран или частично загрузившуюся страницу
(как повезет раунд-робином), хотя в живых есть куча других апстримов,
которые могли бы обслужить его запрос.
Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго
думать или отдавать много данных и решить проблему в лоб, урезав
proxy_read_timeout до нескольких секунд - нельзя.
Меня может что-то спасти?
Если процедура проходит в штатном режиме, то правильно - убрать
обновляемый сервер из блока upstream{}, после обновления - вернуть
обратно.
Если говорить о нештатных ситуациях, то имеет смысл посмотреть в
сторону балансировщика least_conn. В отличие от round-robin'а он
сразу заметит большое количество соединений, ждущих ответа, и
перестанет направлять запросы на плохой бекенд.
Ну и в nginx-plus есть некоторое количество более других решений,
таких как активные health check'и и реконфигурация
upstream-серверов на лету. Но это уже реклама.
--
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Корректная работа с tomcat deploy
28 октября 2014 г., 20:31 пользователь Никита Кардашин megal...@gmail.com написал: Привет всем, Каким образом можно корректно работать с tomcat-upstream, который используется для java-приложения, deploy которого занимает несколько минут? Среда: На входе стоит nginx proxy, в котором настроено n апстримов в режиме round-robin с max_fail=1. За ним - n серверов приложений, на которых работает Apache Tomcat, в котором работает java-приложение. Если падает один из серверов приложений - все прекрасно, nginx стучится к нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное время и рероутит запрос на другой апстрим. Пользователь проблемы не видит. Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy (либо мы сами стартовали re-deploy) - возникает проблема. Проблема: Деплой java-приложения в случае краша или обновления занимает несколько минут (в особо злом случае - до десяти). Томкат, сволочь, в это время принимает входящие соединения на свой порт, но не обслуживает их, а вешает на холд до момента завершения деплоя приложения. Nginx принимает коннект от пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока бэкэнд не поднимется. В итоге пользователь видит белый экран или частично загрузившуюся страницу (как повезет раунд-робином), хотя в живых есть куча других апстримов, которые могли бы обслужить его запрос. Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго думать или отдавать много данных и решить проблему в лоб, урезав proxy_read_timeout до нескольких секунд - нельзя. Меня может что-то спасти? Помечать неработающие бекенды как down - nginx reload - deploy - убираем down - nginx reload ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.7.7
Изменения в nginx 1.7.7 28.10.2014 *) Изменение: теперь nginx учитывает при кэшировании строку Vary в заголовке ответа бэкенда. Где можно почитать подробности влияния Vary, на кеширования в Nginx? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,254366,254384#msg-254384 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Корректная работа с tomcat deploy
Помечать неработающие бекенды как down - nginx reload - deploy - убираем down - nginx reload И так на всех фронтах... Решение с добавлением блокировки через файрвол в процедуру деплоя выглядит несколько более простым. только надо проследить, чтобы блокировка не DROP, а REJECT (в терминах iptables) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.7.7
On Tue, Oct 28, 2014 at 03:15:01PM -0400, S.A.N wrote: Изменения в nginx 1.7.7 28.10.2014 *) Изменение: теперь nginx учитывает при кэшировании строку Vary в заголовке ответа бэкенда. Где можно почитать подробности влияния Vary, на кеширования в Nginx? Какие-то подробности будут в документации, которая ещё не обновлена. Какие-то останутся в коде. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Корректная работа с tomcat deploy
28 октября 2014 г., 22:17 пользователь Daniel Podolsky onoko...@gmail.com написал: Помечать неработающие бекенды как down - nginx reload - deploy - убираем down - nginx reload И так на всех фронтах... Решение с добавлением блокировки через файрвол в процедуру деплоя выглядит несколько более простым. только надо проследить, чтобы блокировка не DROP, а REJECT (в терминах iptables) Если вы уверены что на том томкате нет других приложений, которые вы конечно не собирались отключать,ага. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
