MTU минус IP/TCP/TLS/HTTP заголовки, т.к. там в сумме набегает ~500B.
Открыл `google.com` - он мне выдал заголовков на 1,4 КБ, не даром же сжатие для них начали делать в HTTP/2. У некоторых на сайтах только одних кук на несколько килобайт набирается, какие уж там 500 байт...
каждый ресурс сжимается независимо от другого, а агрегация происходит на уровне стрима, так что если ваш ресурс меньше 1KB вы просто потратите процессорное время, а данные будут пересылаться так же как и без сжатия.
Не очень понял мысль этого заявления. Предположим, что у нас в пакет помещается с учетом всех оберток около 1200 байт ответов. Если каждый ответ по 1Кб в несжатом виде и около 600 Байт в сжатом, то при запросе двух ресурсов - оба они могут поместиться в 1 пакет в сжатом виде или в 2 пакета в несжатом. Поэтому всё же нет, не так же.
Подгонять min_length строго под размер MTU - не имеет смысла, т.к. ответ состоит не только из самих сжимаемых данных, но и служебных данных от разного рода протокольных оберток, как тех же HTTP-заголовков, фрейминга, чанков и TLS-записей. В случае с HTTP/2 - все ещё гораздо сложнее, т.к. в один пакет могут паковаться данные сразу от нескольких ответов на разные запросы, а потому там в принципе чем меньше ответы - тем лучше, тем больше их поместится разом.
Скорости компрессии и декомпрессии сильно зависят от вычислительных мощностей на сервере и клиенте, а скорость передачи от пропускной способности канала. Тут нет универсальных решений.
А если каждый порт - в отдельную docker-сеть? (этот случай - это уже что-то сложное, я не ожидаю что вы это поддерживаете, но интересно).
Такое скорее всего сейчас не получится настроить. Но я завтра уточню у автора функциональности.
Как в конфиге управлять роутингом на разные порты сервиса? location /abc/ на порт 8080, а location /xxx/ на порт 9090 - так можно?
Вот в примере выше адреса добавятся в разные группы upstream с названиями: web и mqtt, причем даже разных модулей - http и stream. Можно добавить в разные upstream-группы в http, а там уже должны на них смотреть разные location.
А можно задавать конфигурацию сервисов не через labels, а через конфиг? hot reload поддерживается же, так что можно конфиг подсовывать наживую.
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Потому, что Docker API работает по HTTP-протоколу. И чтобы прочитать какой-то ответ из сокета - туда сперва нужно записать запрос. Но даже если бы было иначе, то в Linux просто даже для подключения к Unix-сокету уже нужны права на write.
В директиву - нет. Но авторизация поддерживается уже сейчас. Через настройки блока client {} можно добавить какие угодно заголовки авторизации к запросу или даже клиентский сертификат, пользуясь обычными директивами модуля http proxy.
Самым нормальным способом была бы возможность в самом докере создавать дополнительные unix-сокеты с перенастроенным ограниченным доступом к API.
Такие сообщения регулярно в телеграм чате поддержки и комментариях в разных местах. Там просто не о чем писать: "поставили Angie, добавили пару директив, все работает автоматически, спасибо большое" - в таком духе. Пример: https://t.me/angie_support/7987 Если вдруг не работает, то обращаются за помощью и помогаем разобраться почему не работает.
Как поддержку добавили, я сам у себя на сервере удалил Certbot, добавил пару директив и работает с тех пор. Какой плюс? Избавился от лишнего компонента, которым забываешь как пользоваться через несколько месяцев и приходится вспоминать, когда нужно очередной домен завести. В конфиге веб-сервера его так или иначе нужно прописывать и теперь для этого достаточно просто добавить домен в server_name, сделать релоад конфига и всё. Не знаю как из этого выжать целую статью.
А тут коллега детально описал самый комплексный случай настройки, который только можно придумать, разобрался с OctoDNS и другими инструментами, которыми может кто-то захотеть воспользоваться, всё протестировал, написал скрипт и AFAIK никаких промптов. Людям теперь везде ИИ мерещатся. =)
зашёл узнать, насколько удобнее angie, чем связка nginx+dehydrated именно для получения сертификатов с http-авторизацией (т.е., условно говоря, я добавляю новый server {}, а сертификаты для него получаю автоматически).
А чем в таком случае не устроила официальная документация?
Традиционный путь - это держать где-то список доменов, и иногда перестраивать конфиги вебсервера из списк и запрашивать сертификаты. Но мне кажеся, это каким-то сложным, кривым путем. Вроде бы Caddy умеет так делать. Про Angie не знаю, я вот о нем только услышал.
Вам в любом случае придется хранить список доменов и проверять по нему, прежде чем выпустить сертификат. Попробую объяснить почему.
Представим, что такого списка нигде нет. В SNI, как и в заголовке Host, клиент может указать вообще всё, что угодно, абсолютно любой домен. Таким образом злоумышленник сможет вывести ваш сервер из строя, начав запрашивать произвольные домены. Попытка выпустить сертификат на такой произвольный домен не увенчается успехом, однако вы попадете в черный список у ACME-сервера и не сможете получить сертификат для реального нужного домена.
Ок, вы скажите, что ACME клиент должен перед тем, как идти получать сертификат на новый домен - сам попытаться его отрезолвить. А я отвечу, что ничего не мешает злоумышленнику зарегистрировать какой-то домен и прописать для него IP-адрес вашего сервера. И ваш сервер даже получит на него сертификат, но при определенном количестве таких запросов у того же Let's Encrypt сработает лимит и получение новых сертификатов на какое-то время будет далее невозможно, что опять приведет к DoS.
Т.е. так или иначе, перед тем, как идти получать сертификат на какой-то домен с которым пришел клиент - неплохо бы проверить его по списку.
Те, кто использует Caddy таким образом в проде, сильно рискуют, если они не поставили перед ним ещё какой-то прокси, который умеет фильтровать TLS-подключения по SNI и таким образом фильтруют их по списку, либо используют механизм проверки домена внешним запросом к хранилищу, который предоставляет Caddy. Т.е. так или иначе, список доменов где-то есть и по нему происходит сверка.
Потенциально такой режим можно добавить и в Angie с соответствующими предупреждениями и инструкциями, как это безопасно настроить. Но какая-то проверка по списку доменов все равно будет, просто этот список будет храниться вне конфигурации сервера.
Еще, почему-то веб-сервера не умеют сами подбирать сертификаты. Мне кажется немного тупостью, что нужно для каждого виртхоста прописывать, где ему искать файлы с сертификатом и ключам - лишние хлопоты, громоздкий конфиг, лишние ошибки.
Абсолютно с вами согласен. Поэтому в свое время в NGINX Unit я реализовал это иначе. Там сертификат и ключ автоматически выбирается по SNI исходя из тех доменов, что прописаны в сертификате.
nginx и многие сервера появились задолго до того, как появился SNI, отсюда и такая настройка. Можно подумать над тем, как это переделать в Angie, чтобы было проще и удобнее чем механизм, унаследованный от nginx, но это уже отдельная задача.
рановато заявлять о плюсе который ещё не в проде..
Тут я скорее о том, что в принципе технически нормально не реализовать в случае отдельной утилиты, т.к. требует вмешательства в сам процесс TLS-хендшейка.
ну nginx/angie это всё же не для пользователей а для тех кто делает этим пользователям сервисы.
Мы пользователями привыкли называть тех, кто пользуется нашим ПО, т.е. устанавливает и занимается его настройкой. =)
пользователям свойственно ошибаться, если вы утверждаете что так лучше для пользователя то снова вопрос: "чем?"
Они по этой причине уходят на кадди, и не ощущают, что ошиблись. Опять же, кому не нужно и кто считает это ошибкой - может просто не пользоваться данным модулем и вообще его не собирать. Тем не менее, отставание от конкурентов в этом плане приводит только к потере пользователей. Кажется, это весомый аргумент, чтобы не отставать, если хочешь разрабатывать действительно популярное решение, а не что-то сугубо нишевое.
не вижу почему бы из коробки у меня бы не заработал lego/certbot/acme.sh/etc. меньше сил это когда ты добавляешь в свой ansible/puppet/etc проект ещё один хост с его варсами и запускаешь сто раз проверенный плейбук
Значит у вас уже есть какой-то плейбук, вы в этом однажды разобрались и его написали. Это не из коробки. Это не поставил apt install angie, а дальше добавил две директивы и всё работает, причем добавил в парадигме конфигурационного файла, который и так нужно изучать, чтобы пользоваться nginx/Angie.
потому что она провереная временем, эта догма строится на базе того что человек не всесилен и ему свойственно допускать ошибки, и на том как уменьшить возможное кол-во ошибок не более.
Да, и ошибки он допускает при настройке двух разных инструментов. Тратит время на изучение дополнительного инструмента, написание плейбука и пр. пр. Зачем этим заниматься, если можно воспользоваться встроенным решением, которое уже раз разработали те, кто разобрались в вопросе глубже, чем просто настройка Certbot и реализовали это автоматически.
Тут нужно понимать, что в статье рассмотрен довольно комплексный и сложный случай настройки. В простейшем виде вся настройка заключается в добавлении пары директив в конфиг из документации:
acme_client example https://acme-v02.api.letsencrypt.org/directory;
server {
acme example;
...
При этом обновление сертификатов происходит без перезагрузки процессов веб-сервера. Для тех, у кого доменов и сертификатов очень много, необходимость чаще перезапускать процессы - становится отдельной проблемой.
Вот вы спорите, а мы регулярно получаем благодарность от пользователей, которые пишут, что поддержка ACME в Angie - это стало для них одним из ключевых факторов, чтобы перейти с nginx и они очень довольны, благодарят за эту функциональность чаще, чем за многую другую.
Это же не вот вдруг нам заняться было нечем. Это был нескончаемый поток просьб встроить поддержку ACME в веб-сервер, т.к. по той или иной причине пользователи не хотят возиться с отдельным Certbot/Acme.sh и др., предпочитая вместо этого даже сменить веб-сервер на такой, где поддержка ACME уже встроена. Можно конечно сидеть и заявлять, что такие пользователи ошибаются, не должен этим заниматься веб-сервер, но это странный способ кому-то что-то доказать, весьма не конструктивный в плане развития и популяризации проекта.
В конце статьи есть ответ на вопрос чем лучше. Самое банальное - не нужно поддерживать список доменов в двух разных местах. Из небанального, что никогда в принципе не сможет скрипт на bash делать, так это выполнять ALPN-челендж, поддержку которого уже в ближайших версиях добавим.
люди забыли принцип "утилита должна выполнять только одну задачу, но делать это хорошо"
Сколько я работаю в индустрии, то постоянно сталкиваюсь, что реальные пользователи чаще всего хотят обратного, а именно, чтобы всё работало из коробки и желательно тратить на это как можно меньше сил. И в целом, в этом нет ничего плохого... есть в индустрии другие задачи, чем как сопряжение отдельных разрозненных компонентов между собой каждый раз.
Так для чего повторять когда-то десятилетия назад выдвинутую догму, когда задачи и масштабы были совсем другие, снова и снова? Тем более, что тут возникает коллизия в том, а что есть утилита в части веб-сервера... должен ли он хорошо обрабатывать HTTPS трафик? Современному веб-серверу без этого никуда, а если да, то входит ли в эту задачу работа с сертификатами? Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
Форк создан большинством бывших разработчиков nginx. Среди них Хомутов, Ермилов, Бартенев.
Сысоев не занимается разработкой nginx примерно с 2012 года. Не знаю, с кем вы там знакомы, но мы вместе с ним работали над NGINX Unit вплоть до его увольнения из F5. =)
Мы отслеживаем найденные уязвимости в nginx и других форках, оперативно выпускаем исправления, иногда даже раньше, чем это делают сам nginx. Прецедентов нахождения уязвимостей в функциональности самого Angie ещё не было.
Кроме того, у нас есть ряд улучшений, направленных на дополнительное повышение безопасности и защиты от DoS-атак, в том числе портированных из freenginx.
Ещё было бы круто где-то найти полный список отличий в конфигах nginx/angie, чтобы можно было выполнять проверки конфигураций на предмет небезопасных настроек.
Вы можете взять конфиг от nginx и запустить с ним Angie - будет работать также. Rutube, например, так и делает, им так удобнее. У нас же есть руководство по миграции.
Если вы не используете новую функциональность, которая была добавлена только в Angie, то отличий в директивах конфигурации нет за одним незначительным исключением.
Список фич есть на странице документации: https://angie.software/angie/docs/#index-features-oss - если преобразовать это в табличку, то будет просто более громоздко. Или требуется какой-то более расширенный список?
Аналогичная история. Разумеется никакую симку не менял и в Т-Мобайл отрицают то, что какую-либо информацию об этом направляли.
В итоге в Альфе по телефону стояли на своем и сказали приходить с паспортом в отделение. Но обновил страницу в интернет-банке и там появилась вверху плашка "В банк поступила информация о смене сим карты... бла-бла необходимо подтвердить" и кнопка "Подтвердить". Нажал кнопку - появилась табличка "Подтверждения не требуется" и все заработало.
Мое понимание заключается в том, что nginx из коробки не должен проигрывать haproxy в разы. Указанное число RPS для сервера с 32 CPU - это вообще крайне мало... и выглядит очень подозрительно.
Жаль, если вы не хотите разобраться в причинах наблюдаемого явления. Даже если я попрошу воспроизвести коллег, то с большой вероятностью у нас не получатся такие же цифры, т.к. не получится точно повторить указанный стенд.
Вопрос, у вас HTTPS соединения keepalive или на каждый запрос новое? А если на каждый запрос новое соединение, то используется ли возобновление TLS-сессий и каким механизмом? Полный хендшейк - это весьма CPU-нагруженная операция, и лишь разница в настройках TLS-сессий может полностью перевернуть картину между серверами. Опять же, каждая настройка хороша под конкретный стенд, поэтому выравнивать сервера по настройкам, тем более таким критичным, как TLS - необходимо, иначе будет просто необъективный результат, который применим только к конкретному стенду, а на другом стенде будет совсем другим. Так вы протестировали сервера на то, как их настройки по умолчанию подходят для вашего стенда и это будет иметь мало общего с производительностью в реальности, даже на тех же настройках - просто в силу того, что клиенты обычно не ведут себя как отдельно взятый тестовый стенд.
У haproxy, кстати, по умолчанию включен кэш SSL-сессий, а у nginx он выключен. И если клиент, например, не умеет в сессионные тикеты, то вот и разница - тогда в одном случае вы считаете полные хендшейки, а в другом возобновления сессий.
Какие ошибки в логах? Во всех тестах, что мы проводили на моей памяти, haproxy оказывался чуть хуже nginx, да в общем-то неоткуда там разнице особой взяться, тем более в разы - архитектура очень похожа. Поэтому есть все основания полагать, что что-то фундаментально не так с конкретной установкой nginx. Что все же в логах ошибок? И сам nginx, кстати, откуда? Из официального репозитория на `nginx.org`?
И кстати, ни один из серверов сам не обрабатывает TLS - эту задачу решают TLS-библиотеки. Учитывая, как изменились результаты с настройкой ssl_ciphers, возможно вы на самом деле протестировали производительность сборок конкретных библиотек. Для равноценного теста с участием TLS - сервера должны быть собраны с одной и той же библиотекой.
Если интересно все же разобрать в причинах, я бы предложил попробовать повторить тест без TLS в принципе. Если результаты nginx и haproxy окажутся в этом случае близки, то дальше нужно будет разбираться, а что не так с TLS.
И обращаю также внимание на то, что у nginx по умолчанию включен `access_log`, а у того же haproxy, насколько я помню, его нужно включать принудительно.
> Затем и включили, что без него только хуже)
По вашим данным с выключенным multi_accept число успешных запросов больше:
checks_succeeded...................: 30.91% 312910 out of 1012194 checks_failed......................: 69.08% 699284 out of 1012194
против с включенным:
checks_succeeded...................: 25.90% 244664 out of 944528 checks_failed......................: 74.09% 699864 out of 944528
или я неправильно интерпертирую данные?
Но должно быть вообще 100%. То, что nginx теряет запросы - это что-то ненормальное, в error_log должны быть причины этому.
Если проект перестанет делать заявления, от которых откажется буквально через пару месяцев, то я с радостью попытаюсь придумать где взять деньги.(видите, это в обе стороны может работать)
Перестанет и заявления во множественном числе предполагает, что мы их продолжаем делать. Можете указать пожалуйста, какие ещё заявления мы делали? Это важно, т.к. я не в курсе этого и меня это беспокоит.
Иван Полуянов давно уже больше не является представителем компании и у нас не работает. Могу лишь принести за него извинения от себя лично за его прошлую ошибку и введение в заблуждение. Это его собственное высказывание - откровенный бред, ибо PRO версия уже была и, в том числе, на момент конференции уже более 4 месяцев в репозитории PRO велась разработка довольно значительной фичи - конфигурационного Rest API для изменения списка проксируемых серверов, которая появилась в августе того же года в рамках 1.2.0.
У меня нет разумных объяснений почему он это сказал. Этого не было в его докладе, это не было согласовано с нами, он отвечал на вопрос из зала от себя. К сожалению, люди допускают ошибки.
Открыл `google.com` - он мне выдал заголовков на 1,4 КБ, не даром же сжатие для них начали делать в HTTP/2. У некоторых на сайтах только одних кук на несколько килобайт набирается, какие уж там 500 байт...
Не очень понял мысль этого заявления. Предположим, что у нас в пакет помещается с учетом всех оберток около 1200 байт ответов. Если каждый ответ по 1Кб в несжатом виде и около 600 Байт в сжатом, то при запросе двух ресурсов - оба они могут поместиться в 1 пакет в сжатом виде или в 2 пакета в несжатом. Поэтому всё же нет, не так же.
Подгонять min_length строго под размер MTU - не имеет смысла, т.к. ответ состоит не только из самих сжимаемых данных, но и служебных данных от разного рода протокольных оберток, как тех же HTTP-заголовков, фрейминга, чанков и TLS-записей. В случае с HTTP/2 - все ещё гораздо сложнее, т.к. в один пакет могут паковаться данные сразу от нескольких ответов на разные запросы, а потому там в принципе чем меньше ответы - тем лучше, тем больше их поместится разом.
Скорости компрессии и декомпрессии сильно зависят от вычислительных мощностей на сервере и клиенте, а скорость передачи от пропускной способности канала. Тут нет универсальных решений.
Правильно ли я понял, что это как если бы в блоке upstream в директивах server вместо IP-адреса можно было бы имена контейнеров указать?
Да, вот выше в новости, как раз, предпоследним пунктом в списке изменений.
Да
Ок. Добавим.
GET /version
GET /vX.Y/containers/json"
GET /vX.Y/containers/ID/json"
GET /vX.Y/events?filters=...
Подписываемся на события.
В текущей версии не поддерживается. Добавим ли поддержку позже - да, возможно.
Добавить метки с портами, которые будут добавляться в разные usptream-группы.
Пример:
- "angie.http.upstreams.web.port=80"- "angie.stream.upstreams.mqtt.port=1883"Такое скорее всего сейчас не получится настроить. Но я завтра уточню у автора функциональности.
Вот в примере выше адреса добавятся в разные группы upstream с названиями: web и mqtt, причем даже разных модулей - http и stream. Можно добавить в разные upstream-группы в http, а там уже должны на них смотреть разные location.
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Потому, что Docker API работает по HTTP-протоколу. И чтобы прочитать какой-то ответ из сокета - туда сперва нужно записать запрос. Но даже если бы было иначе, то в Linux просто даже для подключения к Unix-сокету уже нужны права на write.
В директиву - нет. Но авторизация поддерживается уже сейчас. Через настройки блока client {} можно добавить какие угодно заголовки авторизации к запросу или даже клиентский сертификат, пользуясь обычными директивами модуля http proxy.
Самым нормальным способом была бы возможность в самом докере создавать дополнительные unix-сокеты с перенастроенным ограниченным доступом к API.
Так чем простейший пример в документации плох: https://angie.software/angie/docs/configuration/acme/#http - зачем ждать, пока где-то в каком-то блоге появится какая-то заметка, цитирующая документацию? =)
Такие сообщения регулярно в телеграм чате поддержки и комментариях в разных местах. Там просто не о чем писать: "поставили Angie, добавили пару директив, все работает автоматически, спасибо большое" - в таком духе. Пример: https://t.me/angie_support/7987 Если вдруг не работает, то обращаются за помощью и помогаем разобраться почему не работает.
Как поддержку добавили, я сам у себя на сервере удалил Certbot, добавил пару директив и работает с тех пор. Какой плюс? Избавился от лишнего компонента, которым забываешь как пользоваться через несколько месяцев и приходится вспоминать, когда нужно очередной домен завести. В конфиге веб-сервера его так или иначе нужно прописывать и теперь для этого достаточно просто добавить домен в server_name, сделать релоад конфига и всё. Не знаю как из этого выжать целую статью.
А тут коллега детально описал самый комплексный случай настройки, который только можно придумать, разобрался с OctoDNS и другими инструментами, которыми может кто-то захотеть воспользоваться, всё протестировал, написал скрипт и AFAIK никаких промптов. Людям теперь везде ИИ мерещатся. =)
А чем в таком случае не устроила официальная документация?
Вам в любом случае придется хранить список доменов и проверять по нему, прежде чем выпустить сертификат. Попробую объяснить почему.
Представим, что такого списка нигде нет. В SNI, как и в заголовке Host, клиент может указать вообще всё, что угодно, абсолютно любой домен. Таким образом злоумышленник сможет вывести ваш сервер из строя, начав запрашивать произвольные домены. Попытка выпустить сертификат на такой произвольный домен не увенчается успехом, однако вы попадете в черный список у ACME-сервера и не сможете получить сертификат для реального нужного домена.
Ок, вы скажите, что ACME клиент должен перед тем, как идти получать сертификат на новый домен - сам попытаться его отрезолвить. А я отвечу, что ничего не мешает злоумышленнику зарегистрировать какой-то домен и прописать для него IP-адрес вашего сервера. И ваш сервер даже получит на него сертификат, но при определенном количестве таких запросов у того же Let's Encrypt сработает лимит и получение новых сертификатов на какое-то время будет далее невозможно, что опять приведет к DoS.
Т.е. так или иначе, перед тем, как идти получать сертификат на какой-то домен с которым пришел клиент - неплохо бы проверить его по списку.
Те, кто использует Caddy таким образом в проде, сильно рискуют, если они не поставили перед ним ещё какой-то прокси, который умеет фильтровать TLS-подключения по SNI и таким образом фильтруют их по списку, либо используют механизм проверки домена внешним запросом к хранилищу, который предоставляет Caddy. Т.е. так или иначе, список доменов где-то есть и по нему происходит сверка.
Потенциально такой режим можно добавить и в Angie с соответствующими предупреждениями и инструкциями, как это безопасно настроить. Но какая-то проверка по списку доменов все равно будет, просто этот список будет храниться вне конфигурации сервера.
Абсолютно с вами согласен. Поэтому в свое время в NGINX Unit я реализовал это иначе. Там сертификат и ключ автоматически выбирается по SNI исходя из тех доменов, что прописаны в сертификате.
nginx и многие сервера появились задолго до того, как появился SNI, отсюда и такая настройка. Можно подумать над тем, как это переделать в Angie, чтобы было проще и удобнее чем механизм, унаследованный от nginx, но это уже отдельная задача.
Кстати, сам Игорь с вами не знаком. Что и не удивительно, оказалось такое же вранье, как и всё, что вы тут понавыдумывали.
Тут я скорее о том, что в принципе технически нормально не реализовать в случае отдельной утилиты, т.к. требует вмешательства в сам процесс TLS-хендшейка.
Мы пользователями привыкли называть тех, кто пользуется нашим ПО, т.е. устанавливает и занимается его настройкой. =)
Они по этой причине уходят на кадди, и не ощущают, что ошиблись. Опять же, кому не нужно и кто считает это ошибкой - может просто не пользоваться данным модулем и вообще его не собирать. Тем не менее, отставание от конкурентов в этом плане приводит только к потере пользователей. Кажется, это весомый аргумент, чтобы не отставать, если хочешь разрабатывать действительно популярное решение, а не что-то сугубо нишевое.
Значит у вас уже есть какой-то плейбук, вы в этом однажды разобрались и его написали. Это не из коробки. Это не поставил apt install angie, а дальше добавил две директивы и всё работает, причем добавил в парадигме конфигурационного файла, который и так нужно изучать, чтобы пользоваться nginx/Angie.
Да, и ошибки он допускает при настройке двух разных инструментов. Тратит время на изучение дополнительного инструмента, написание плейбука и пр. пр. Зачем этим заниматься, если можно воспользоваться встроенным решением, которое уже раз разработали те, кто разобрались в вопросе глубже, чем просто настройка Certbot и реализовали это автоматически.
Тут нужно понимать, что в статье рассмотрен довольно комплексный и сложный случай настройки. В простейшем виде вся настройка заключается в добавлении пары директив в конфиг из документации:
При этом обновление сертификатов происходит без перезагрузки процессов веб-сервера. Для тех, у кого доменов и сертификатов очень много, необходимость чаще перезапускать процессы - становится отдельной проблемой.
Вот вы спорите, а мы регулярно получаем благодарность от пользователей, которые пишут, что поддержка ACME в Angie - это стало для них одним из ключевых факторов, чтобы перейти с nginx и они очень довольны, благодарят за эту функциональность чаще, чем за многую другую.
Это же не вот вдруг нам заняться было нечем. Это был нескончаемый поток просьб встроить поддержку ACME в веб-сервер, т.к. по той или иной причине пользователи не хотят возиться с отдельным Certbot/Acme.sh и др., предпочитая вместо этого даже сменить веб-сервер на такой, где поддержка ACME уже встроена. Можно конечно сидеть и заявлять, что такие пользователи ошибаются, не должен этим заниматься веб-сервер, но это странный способ кому-то что-то доказать, весьма не конструктивный в плане развития и популяризации проекта.
В конце статьи есть ответ на вопрос чем лучше. Самое банальное - не нужно поддерживать список доменов в двух разных местах. Из небанального, что никогда в принципе не сможет скрипт на bash делать, так это выполнять ALPN-челендж, поддержку которого уже в ближайших версиях добавим.
Сколько я работаю в индустрии, то постоянно сталкиваюсь, что реальные пользователи чаще всего хотят обратного, а именно, чтобы всё работало из коробки и желательно тратить на это как можно меньше сил. И в целом, в этом нет ничего плохого... есть в индустрии другие задачи, чем как сопряжение отдельных разрозненных компонентов между собой каждый раз.
Так для чего повторять когда-то десятилетия назад выдвинутую догму, когда задачи и масштабы были совсем другие, снова и снова? Тем более, что тут возникает коллизия в том, а что есть утилита в части веб-сервера... должен ли он хорошо обрабатывать HTTPS трафик? Современному веб-серверу без этого никуда, а если да, то входит ли в эту задачу работа с сертификатами? Ведь если он не сможет обновлять сертификаты, то хорошо обрабатывать HTTPS трафик тоже не получится. Какая-то неполноценная утилита тогда выходит, не справляющаяся со свой задачей.
Форк создан большинством бывших разработчиков nginx. Среди них Хомутов, Ермилов, Бартенев.
Сысоев не занимается разработкой nginx примерно с 2012 года. Не знаю, с кем вы там знакомы, но мы вместе с ним работали над NGINX Unit вплоть до его увольнения из F5. =)
Мы отслеживаем найденные уязвимости в nginx и других форках, оперативно выпускаем исправления, иногда даже раньше, чем это делают сам nginx. Прецедентов нахождения уязвимостей в функциональности самого Angie ещё не было.
Кроме того, у нас есть ряд улучшений, направленных на дополнительное повышение безопасности и защиты от DoS-атак, в том числе портированных из freenginx.
Вы можете взять конфиг от nginx и запустить с ним Angie - будет работать также. Rutube, например, так и делает, им так удобнее. У нас же есть руководство по миграции.
Если вы не используете новую функциональность, которая была добавлена только в Angie, то отличий в директивах конфигурации нет за одним незначительным исключением.
Список фич есть на странице документации: https://angie.software/angie/docs/#index-features-oss - если преобразовать это в табличку, то будет просто более громоздко. Или требуется какой-то более расширенный список?
"Встроенный DNS‑резолвер NGINX не поддерживает fallback на TCP" - это неправда, как и множество других ошибок и неточностей в статье
Аналогичная история. Разумеется никакую симку не менял и в Т-Мобайл отрицают то, что какую-либо информацию об этом направляли.
В итоге в Альфе по телефону стояли на своем и сказали приходить с паспортом в отделение. Но обновил страницу в интернет-банке и там появилась вверху плашка "В банк поступила информация о смене сим карты... бла-бла необходимо подтвердить" и кнопка "Подтвердить". Нажал кнопку - появилась табличка "Подтверждения не требуется" и все заработало.
Какой-то у них сбой.
Мое понимание заключается в том, что nginx из коробки не должен проигрывать haproxy в разы. Указанное число RPS для сервера с 32 CPU - это вообще крайне мало... и выглядит очень подозрительно.
Жаль, если вы не хотите разобраться в причинах наблюдаемого явления. Даже если я попрошу воспроизвести коллег, то с большой вероятностью у нас не получатся такие же цифры, т.к. не получится точно повторить указанный стенд.
Вопрос, у вас HTTPS соединения keepalive или на каждый запрос новое? А если на каждый запрос новое соединение, то используется ли возобновление TLS-сессий и каким механизмом? Полный хендшейк - это весьма CPU-нагруженная операция, и лишь разница в настройках TLS-сессий может полностью перевернуть картину между серверами. Опять же, каждая настройка хороша под конкретный стенд, поэтому выравнивать сервера по настройкам, тем более таким критичным, как TLS - необходимо, иначе будет просто необъективный результат, который применим только к конкретному стенду, а на другом стенде будет совсем другим. Так вы протестировали сервера на то, как их настройки по умолчанию подходят для вашего стенда и это будет иметь мало общего с производительностью в реальности, даже на тех же настройках - просто в силу того, что клиенты обычно не ведут себя как отдельно взятый тестовый стенд.
У haproxy, кстати, по умолчанию включен кэш SSL-сессий, а у nginx он выключен. И если клиент, например, не умеет в сессионные тикеты, то вот и разница - тогда в одном случае вы считаете полные хендшейки, а в другом возобновления сессий.
50k RPS для nginx - это вообще пустяки, но вот криптография, которой занимается TLS-библиотека - она может стать лимитирующим фактором. К примеру, вот такой sizing guide для nginx plus: https://www.f5.com/pdf/deployment-guide/Sizing-Guide-for-Deploying-NGINX-Plus-on-Bare-Metal-Servers-2019-11-09.pdf - он уже старенький, ещё от 2019 года, но можно заметить, что на 32 CPU легко может быть 1 000 000 RPS, но всего около 50к полных хендшейков.
Какие ошибки в логах? Во всех тестах, что мы проводили на моей памяти, haproxy оказывался чуть хуже nginx, да в общем-то неоткуда там разнице особой взяться, тем более в разы - архитектура очень похожа. Поэтому есть все основания полагать, что что-то фундаментально не так с конкретной установкой nginx. Что все же в логах ошибок? И сам nginx, кстати, откуда? Из официального репозитория на `nginx.org`?
И кстати, ни один из серверов сам не обрабатывает TLS - эту задачу решают TLS-библиотеки. Учитывая, как изменились результаты с настройкой
ssl_ciphers, возможно вы на самом деле протестировали производительность сборок конкретных библиотек. Для равноценного теста с участием TLS - сервера должны быть собраны с одной и той же библиотекой.Если интересно все же разобрать в причинах, я бы предложил попробовать повторить тест без TLS в принципе. Если результаты nginx и haproxy окажутся в этом случае близки, то дальше нужно будет разбираться, а что не так с TLS.
И обращаю также внимание на то, что у nginx по умолчанию включен `access_log`, а у того же haproxy, насколько я помню, его нужно включать принудительно.
> Затем и включили, что без него только хуже)
По вашим данным с выключенным multi_accept число успешных запросов больше:
checks_succeeded...................: 30.91% 312910 out of 1012194 checks_failed......................: 69.08% 699284 out of 1012194против с включенным:
checks_succeeded...................: 25.90% 244664 out of 944528 checks_failed......................: 74.09% 699864 out of 944528или я неправильно интерпертирую данные?
Но должно быть вообще 100%. То, что nginx теряет запросы - это что-то ненормальное, в error_log должны быть причины этому.
Перестанет и заявления во множественном числе предполагает, что мы их продолжаем делать. Можете указать пожалуйста, какие ещё заявления мы делали? Это важно, т.к. я не в курсе этого и меня это беспокоит.
Иван Полуянов давно уже больше не является представителем компании и у нас не работает. Могу лишь принести за него извинения от себя лично за его прошлую ошибку и введение в заблуждение. Это его собственное высказывание - откровенный бред, ибо PRO версия уже была и, в том числе, на момент конференции уже более 4 месяцев в репозитории PRO велась разработка довольно значительной фичи - конфигурационного Rest API для изменения списка проксируемых серверов, которая появилась в августе того же года в рамках 1.2.0.
У меня нет разумных объяснений почему он это сказал. Этого не было в его докладе, это не было согласовано с нами, он отвечал на вопрос из зала от себя. К сожалению, люди допускают ошибки.