freenginx: комментарии от Макса Дунина
Простой 4 мин Open source *Системное администрирование *IT-инфраструктура *Nginx *Интервью Интервью
14-го февраля Максим Дунин анонсировал форк nginx — freenginx (freenginx.org). Максим — старейший сотрудник nginx и core‑контрибьютор nginx со времен Рамблера. Максим любезно согласился на интервью, вопросы задавал Алексей Рыбак (@rybakalexey), DevHands.io.
[АР] Почему ты решил форкнуть nginx и запустить проект freenginx? Почему ты делаешь акцент на свободе, в чём был несвободен nginx внутри F5?
[МД] Я в течении почти двух лет пытался избежать создания форка и безвозмездно занимался улучшением nginx — потому что считал и считаю, что создание форков не полезно для проекта. К сожалению, в F5 решили отказаться от наших договорённостей, и предпочли делать с проектом то, что они считают нужным, игнорируя как существующие политики проекта, так и мнение разработчиков, в том числе моё. Поэтому я создал отдельный проект, в котором позиция разработчиков гарантировано будет определяющей.
[АР] Ты будешь работать один или уже есть команда, кто будет работать над проектом? Есть ли у тебя понимание, чем ты займешься в первую очередь?
[МД] Сейчас я работаю один, однако приглашаю к сотрудничеству всех заинтересованных разработчиков. И в первую очередь буду рад видеть тех, кто давно занимается разработкой nginx’а. Что до задач, то понимание есть — но это, скорее, текущие задачи и давно напрашивающиеся улучшения, ничего сверхъестественного.
[АР] Пишут, что с момента закрытия офиса nginx в Москве ты работал «волонтером». Связывают ли тебя сейчас какие‑то контрактные обязательства с F5/nginx и накладывает ли это какие‑то ограничения на новый продукт?
Я перестал быть сотрудником после закрытия офиса, почти два года назад, и каких‑либо обязательств, накладывающих ограничения на новый проект, у меня нет.
[АР] На YCombinator пишут, что причиной возникновения freenginx стала какая‑то не очень понятная история со внесением в реестр CVE уязвимости в экспериментальном коде. Ты не мог бы рассказать подробнее, что там было, и почему вообще это важно?
[МД] История, действительно, не очень понятная, в том числе и мне самому. В экспериментальном коде HTTP/3 нашли ошибку, которая приводит к падению рабочего процесса при некотором поведении клиента. Существующая security‑политика проекта предполагает, что такие ошибки исправляются как обычные ошибки — потому что в экспериментальном коде бывает всякое, и в документации явно об этом написано. Роман, разработчик, занимавшийся исправлением ошибки, на всякий случай написал о ней в список рассылки проекта для обсуждения security‑проблем. Мы обсудили это, и все разработчики согласились с ожидаемым подходом — исправить как обычную ошибку.
Кто‑то в F5, однако, решил, что это security‑проблема, и разработчикам, работающим в F5, насколько я знаю, буквально приказали сделать security‑релиз, игнорируя и существующую политику, и мнение разработчиков.
С одной стороны — само по себе действие не то чтобы очень плохое, ну, лишний security‑релиз, от этого ещё никто не умирал. С другой — мне видится очень серьёзной проблемой сам тот факт, что кто‑то имеет возможность приказать разработчикам, что им делать, игнорируя мнение разработчиков, и этой возможностью пользуется.
Зачем было нужно затевать всю эту историю, фактически разорвав отношения со мной на ровном месте, я, честно говоря, не совсем понимаю.
Вот тут ещё я писал немного непосредственно про причины.
[АР] У nginx становится достаточно запутанная экосистема: Nginx от F5, nginx+, Nginx Unit, форк Angie, PPA (personal packages) с интересными дополнительными модулями типа поддержки brotli, теперь твой форк. Куда вообще всё идёт? Можно ли говорить о том, что F5 недостаточно внимания уделяет управлению и выращиванию экосистемы в целом?
[МД] Я надеюсь, что freenginx сможет всё это несколько упростить, став некоторой центральной точкой открытой разработки. Впрочем, xkcd #927 «Standards», конечно, никто не отменял.
xkcd #927 “Standards” (Randall Munroe)
[АР] Nginx занял прочное место фронта для обслуживания внешнего трафика от пользователей, но внутри инфраструктуры его активно теснят «cloud‑native» решения типа envoy. На твой взгляд, почему это происходит, плохо ли это, собирается ли freenginx (или может быть F5) что‑то с этим делать?
[МД] Сам nginx всегда разрабатывался в первую очередь для обслуживания внешнего трафика, так что не удивительно, что именно в этом качестве он наиболее популярен. Что до использования внутри инфраструктуры, то тут, конечно, часто есть, что улучшать. Не могу сказать, что есть какие‑то конкретные планы, но если есть предложения или проблемы — с удовольствием помогу.
[АР] Не хочешь податься с анонсом проекта на Хайлоад? Летом в Питер, например. Думаю, доклад примут на ура 😉
[МД] Не уверен, что у меня есть, что вот прям говорить про проект, он в целом не то чтобы очень нов.:))
[АР] «Не то чтобы нов»? Именно freenginx — ты его анонсировал вчера 😉 Последний вопрос: какая у проекта будет лицензия и какая предполагается модель развития? Есть ли источники финансирования?
[МД] В том смысле, что freenginx — по большому счёту не отличается от того, чем я занимался в рамках разработки nginx’а. Отличие лишь в отсутствии малопредсказуемого, как выяснилось, корпоративного контроля.
Я не планирую менять лицензию, лицензия BSD меня полностью устраивает. Что до финансирования, то сейчас, как и в прошедшие два года, я планирую развивать проект «на свои». Возможно, в будущем добавится контрактная разработка и/или возможность спонсорской помощи проекту.
Вопросы задавал Алексей Рыбак (@rybakalexey), DevHands.io (обучение для программистов: хайлоад‑буткемп, системный дизайн и вот это всё).
Теги:
- nginx
- freenginx
- f5
- максим дунин
Хабы:
- Open source
- Системное администрирование
- IT-инфраструктура
- Nginx
- Интервью