Например потому, что nginx-подобные продукты во многом лучше. И уж точно производительнее и устойчивее к пиковым нагрузкам, чем тот же Traefik. Не стоит так оголтело записывать админов большей части интернета и крупнейших компаний мира в "отставшие от жизни".
Разумеется у Traefik и Envoy есть свои плюсы. Все разработчики друг на друга смотрят и многие полезные фичи перенимают. Тут нет никакого однозначного лидера, но есть разные подходы и предпочтения в цвете фломастера.
Так всё модульное. Если какие-то модули не требуются, то можно их не собирать, но смысла в этом большого нет, т.к. влияние на производительность от наличия модуля в сборке - чаще всего неизмеримо мало. Мы динамически собираем в основном те модули, которые устанавливают дополнительные зависимости.
Но вообще на разработку "мало кому нужных фич" нет времени. Количество запросов от сообщества сильно больше, чем ресурсов. Плюс технологии развиваются и конкуренты тоже. Если ничего не делать, то какое-то время можно за счет запаса инерции оставаться в тренде, но рано или поздно уйдешь на задворки истории. Естественно никто не будет делать ту или иную фичу по одному-двум запросам - разработка вообще дорогая, поэтому это возможно только на коммерческой основе.
Тут в оценках главное не впадать в субъективизм. Когда работаешь в одной/нескольких компаниях, то имеешь определенное представление о том, что нужно и что не нужно в рамках кейсов, с которыми сам сталкивался. А когда работаешь в вендоре ПО, будь то NGINX, Inc. ранее и теперь Angie Software - то имеешь дело с тысячами компаний и их кейсами, которые зачастую богаче всех твоих фантазий.
В конце-концов, посмотрите какое большое количество сторонних модулей для nginx написало сообщество. Многие из них очень популярны. Не стоит недооценивать модульность и расширяемость - это тоже всегда был значимый критерий успеха и мы трепетно поддерживаем совместимость со сторонними модулями.
P.S. Но вообще, если хочется ставший в какой-то степени каноничным nginx, который существовал с 2011 по 2022 год, то порекомендую freenginx, который разрабатывается Максимом Дуниным. Долгие годы без его одобрения в nginx не попадало ничего, а когда в F5 на его мнение решили наплевать, то ему пришлось сделать свой форк. У нас с ним разные взгляды на развитие, но желаю Максиму успехов. Какие-то полезные изменения мы в том числе портируем из freenginx и за это ему большое спасибо, что неустанно продолжает своё дело.
Серьезно. У нас в телеграме уже больше тысячи подписчиков на новости и мы там выкладываем ссылки на статьи. Пользователи написали, что часть из них побанили после лайка нашей статьи.
P.S. Как по мне, то просто даже сама формулировка про "ошибочное представление, что продукты кому-то интересны" и "кружок с предвзятыми оценками" - это откровенное хамство.
Он не лучше по производительности. При этом возможности кэширования у него весьма ограничены, а кэширование играет важную роль в защите бекендов от DoS-атак.
Всем занимаются рабочие процессы. У мастера только одна функция: обеспечивать отказоустойчивость, т.е. перезагружать конфигурацию без потери соединений и восстанавливать рабочие процессы, если с ними что-то не так. Мастер процесс максимально упрощен и не умеет обслуживать соединения, у него даже полноценного цикла событий нет.
Доступ к сокету соответственно должен быть у пользователя от которого запускаются рабочие процессы.
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, но это уже отдельная задача.
Например потому, что nginx-подобные продукты во многом лучше. И уж точно производительнее и устойчивее к пиковым нагрузкам, чем тот же Traefik. Не стоит так оголтело записывать админов большей части интернета и крупнейших компаний мира в "отставшие от жизни".
Разумеется у Traefik и Envoy есть свои плюсы. Все разработчики друг на друга смотрят и многие полезные фичи перенимают. Тут нет никакого однозначного лидера, но есть разные подходы и предпочтения в цвете фломастера.
Так всё модульное. Если какие-то модули не требуются, то можно их не собирать, но смысла в этом большого нет, т.к. влияние на производительность от наличия модуля в сборке - чаще всего неизмеримо мало. Мы динамически собираем в основном те модули, которые устанавливают дополнительные зависимости.
Но вообще на разработку "мало кому нужных фич" нет времени. Количество запросов от сообщества сильно больше, чем ресурсов. Плюс технологии развиваются и конкуренты тоже. Если ничего не делать, то какое-то время можно за счет запаса инерции оставаться в тренде, но рано или поздно уйдешь на задворки истории. Естественно никто не будет делать ту или иную фичу по одному-двум запросам - разработка вообще дорогая, поэтому это возможно только на коммерческой основе.
Тут в оценках главное не впадать в субъективизм. Когда работаешь в одной/нескольких компаниях, то имеешь определенное представление о том, что нужно и что не нужно в рамках кейсов, с которыми сам сталкивался. А когда работаешь в вендоре ПО, будь то NGINX, Inc. ранее и теперь Angie Software - то имеешь дело с тысячами компаний и их кейсами, которые зачастую богаче всех твоих фантазий.
В конце-концов, посмотрите какое большое количество сторонних модулей для nginx написало сообщество. Многие из них очень популярны. Не стоит недооценивать модульность и расширяемость - это тоже всегда был значимый критерий успеха и мы трепетно поддерживаем совместимость со сторонними модулями.
P.S. Но вообще, если хочется ставший в какой-то степени каноничным nginx, который существовал с 2011 по 2022 год, то порекомендую freenginx, который разрабатывается Максимом Дуниным. Долгие годы без его одобрения в nginx не попадало ничего, а когда в F5 на его мнение решили наплевать, то ему пришлось сделать свой форк. У нас с ним разные взгляды на развитие, но желаю Максиму успехов. Какие-то полезные изменения мы в том числе портируем из freenginx и за это ему большое спасибо, что неустанно продолжает своё дело.
Серьезно. У нас в телеграме уже больше тысячи подписчиков на новости и мы там выкладываем ссылки на статьи. Пользователи написали, что часть из них побанили после лайка нашей статьи.
P.S. Как по мне, то просто даже сама формулировка про "ошибочное представление, что продукты кому-то интересны" и "кружок с предвзятыми оценками" - это откровенное хамство.
Он не лучше по производительности. При этом возможности кэширования у него весьма ограничены, а кэширование играет важную роль в защите бекендов от DoS-атак.
В первой версии скорее всего только php появится. В последующих поддержку других ЯП будем добавлять.
Если уволить по политическим соображениям всех ключевых разработчиков, включая лидера и идеолога проекта, то результат очевиден. =)
nginx сильно поплохело, а Unit загнулся совсем.
Протокол QUIC реализован не в ядре.
Через labels домен прикрутить сейчас нельзя.
Всем занимаются рабочие процессы. У мастера только одна функция: обеспечивать отказоустойчивость, т.е. перезагружать конфигурацию без потери соединений и восстанавливать рабочие процессы, если с ними что-то не так. Мастер процесс максимально упрощен и не умеет обслуживать соединения, у него даже полноценного цикла событий нет.
Доступ к сокету соответственно должен быть у пользователя от которого запускаются рабочие процессы.
Добавлю ещё, что мониторинга состояния кэша в open source версии nginx тоже никакого нет.
Открыл `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, но это уже отдельная задача.
Кстати, сам Игорь с вами не знаком. Что и не удивительно, оказалось такое же вранье, как и всё, что вы тут понавыдумывали.