Open source проект – это не только код.

Когда мы говорим о проектах с открытым исходным кодом, то частенько, как само собой разумеющееся, опускаем тему инфраструктуры распространения дистрибутива проекта. Но сегодня, когда у нас есть вагон и тележка операционных систем и расширений к основному проекту, это и есть та самая подводная часть айсберга.

На примере веб-сервера Angie расскажу вам про инфраструктуру проекта с открытым исходным кодом в формате интервью, которое я взял у команды в режиме чайка менеджера в пятницу вечером. Пунктуация и правописание авторов – на совести авторов. С учетом того, что команда делает опен-сорс проекты последние 15 лет, получилось, как нам кажется, интересно.

Как выглядит наш процесс разработки?

Спросил ребят про организацию процесса разработки, модель ветвления при релизах и разработку функциональности. Тема – скучная :) Тут у нас ничего нового, всё как у всех. Интереснее то, как другие отделы компании влияют на работу с кодом (из неочевидного – юристы, тоже ведь “влиятельные” люди). Или, к примеру, вот такая загадка почему мы внутри используем mercurial как систему управления версиями кодовой базы? Ну и почему все же не МосХаб!? В общем, прошу к нашему шалашу.

Для начала давай про базовый процесс разработки

VBart: Одна ветка для разработки, в ней текущая разрабатываемая основная версия. Опционально появляются ветки под minor/bugfix релизы. Также есть ветки содержащие мастер-ветку freenginx и nginx, а также их тестов для удобного мерджа.

Для pro отдельный репозиторий, где логика та же, но в качестве доп веток мастер-ветка oss, опять же для мерджа изменений из oss в pro.

Разработка фич ведется в локальных репозиториях разработчиков, которые по готовности присылают патчи на ревью в reviewboard для последующего включения в основной репозиторий и параллельного покрытия в документации.

Другие отделы как-то влияют на работу с кодом? Юристы заставляют в шапке файла указывать копирайты?

VBart: Вот это головная боль, которую я до сих пор не понимаю зачем ввели, но мы постоянно забываем обновлять год в шапке файлов, а когда не забываем, то потом мердж на этом спотыкается.

За два года только на задачах обновлять каждый раз год в шапке файлов мы потратили сколько-то часов времени разработчиков.

Vladimir Kh: плюсую, копирайты завязанные на год в коде - это рак, порождающий кучу бессмысленных изменений и загромождающий историю изменений файла. С учётом того, что всё хранится в системе контроля версий. Я даже близко не понимаю, что юридически поменяется от того, что в файле кто-то забудет обновить год.

Anna: По закону знак охраны авторского права состоит из трех элементов: той самой латинской буквы "C" в окружности; имени или наименования правообладателя; года первого опубликования произведения. Копирайты мы будем расставлять правильно, указывая год первого опубликования произведения. Точка.

Rodion N: Слушайте, ну есть поинтереснее тема - а почему все-таки Mercurial, а не Git? Читал про их сравнение. Mercurial приглянулся, потому что репозиторий меньше места занимает, по сравнению с Git?

Vladimir Kh: исторически. на момент переезда с svn оно ещё было популярно, да и Макс Дунин принимал участие в разработке и знал внутренности.

Плюс не те у нас объёмы и не та модель, чтобы git был реально нужен. Линейная история, несколько бранчей, мало контрибьюторов.

Максим Дунин – один из ключевых разработчиков nginx, в феврале 2024 года создал свой форк freenginx

Sergey K: Ну наверное меркуриал, потому что так проще мержить с nginx, теперь еще и freenginx

Vladimir Kh: в целом, git это тот ещё монстр с зоопарком шелл-утилит под капотом общего и странного интерфейса. Особо не болит, в git и обратно конвертируется плюс-минус автоматом на наших объемах.

VBart: Десятилетие назад или даже чуть больше nginx жил на SVN ещё с тех времен, когда большинство жили на SVN или CVS, а git ещё не было. Так вот лет 10 назад встал вопрос на что бы такое современное перейти, гитхаб только появился и про него никто особо не знал, а популярность hg и git была плюс-минус одинаковая. И из этих двух предпочтение отдали hg, т.к. у него был простой удобный понятный пользователям SVN интерфейс и воркфлоу. Сам он цельный, написан на понятном языке программирования. А git в то время представлял из себя монструозный набор каких-то тулзов написанных на нескольких языках с какой-то своей собственной логикой работы с кодом (к которой сейчас большинство привыкло, но пользователю SVN взрывало мозг).

Я до сих пор думаю, что если бы не Github, то git не был бы столь популярен, а ограничивался бы в основном сообществом разработчиков ядра.

Были похожие на Github сервисы, но с mercurial. Проблема была только в том, что те были жадные и бесплатное использование у них было сильно ограничено, а потом они не привлекли на себя тысячи oss проектов. Github очень удачно выбрал бизнес-модель и таким образом захватил рынок.

С другой стороны, та же документация у нас ведется по принципам docs-as-code и целиком живет в Git-репозитории.

Вам CI вообще нужен? У вас раннеров хватает? Вы, если упало, на тачку лезете, зачем?

Vladimir Kh: плюсы OSS проекта: наш CI - весь интернет. Мы релизим – миллионы тестят. Через 15 минут после релиза в рассылку приходит человек и рассказывает что на китайском risc-v у него новый релиз не собирается. (это замечание относится в целом к OSS проектам. У закрытого продукта пользователей на ПОРЯДКИ меньше, поэтому и меньше возможностей на что-то наткнуться чисто статистически. В открытом интернете обязательно найдётся комбинация странного железа и операционной системы, кто-то будет собирать под экзотические архитектуры, у кого-то проявится допущенная ошибка. Конечно не сразу, но сообщение об ошибке до нас дойдёт и будет исправлено).

то есть вы сами не тестируете, а ломаете людям жизнь?

Vladimir Kh: это мы так шутим, но доля правды в этом есть - жизнь богаче любых стендов, и все комбинации ты никогда не проверишь. ( ERROR: Cant build with GCC4, nginx config test cannot pass if quic_bpf is enabled)

Sergey K: кстати, кажется, что немного не хватает ручного тестирования. Типа погонять всякие ситуации, что-нибудь специально криво настроить и посмотреть, что будет и т.д. Автоматическое тестирования - это супер, но оно в основном проверяет хорошие ситуации. Что вот настройка - и оно должно сработать. А реальные админы на местах действуют хитрее. :) Разработчики, конечно проверяют, что сделали - но взгляд замыленный уже.

Oleg M, вы кстати мониторите CI? лицо разработчика в грязь макаете?

Oleg M: Мы мониторим CI, чтобы он работал 🙂А про красные задачи узнают сами их запустившие.

VBart: По поводу процесса и чего не хватает, я буквально сегодня два тикета завел: Автоматизация сборки и тестирования патчей на ревью (отправлять патчи в angie-try на тестирование, чтобы любой pull-реквест проходил сборку и тестирование, а сборочница в соответствующем запросе отображает статус этого процесса). И интеграция ReviewBoard в Яндекс.Трекер (при создании запроса на ревью в RB будет автоматически заводить релевантный тикет в трекере, причем качественно заполненный, а действия по ревью в RB отражаться в трекере)

В какой момент запускаются наши анализаторы кода, они у нас есть?

VBart: у coverity есть ограничение до 3 раз в день можно.Поэтому коллеги настроили так, что в заданные часы три раза в день стартует задачка, которая проверяет – есть ли новые коммиты в репу с прошлого раза, если есть запускает сборку для анализа и шлет в коверити... Тот, получив новый билд и проанализировав – шлет письмо найдены ли новые дефекты с прошлой сборки или нет... или может какие-то наоборот, устранены

От него за всё время польза была?

VBart: да, конечно: https://hg.angie.software/angie/log?rev=Coverity

а чем история с PVS-Studio закончилась?

VBart: тем, что оно на фоне коверити менее полезное. И не нашли пользы в их анализе. https://pvs-studio.ru/ru/blog/posts/0246/

не говорите что ничего не изменилось с того времени

VBart: ну вот судя по нашему опыту с тех пор ничего не изменилось

Доступность к инфре разработки. У нас же закрыто всё? А где лежит, в России?

Oleg M: Да, все за vpn, в России.

Какие аспекты безопасной разработки мы используем? Кроме зоркого глаза

VBart: острый ум! Тесты, ревью, сборка с -Werror

Vladimir Kh: санитайзеры, статик аналайзеры

VBart: определенный стиль кода защищающий от ряда ошибок, как например if всегда со скобочками { }

Vladimir Kh: впиливаем wasm для сторонних модулей

VBart: архитектура с пулами памяти защищающая от утечек

Устранение уязвимостей

как процесс устранения уязвимостей ложится на процесс разработки?

VBart: отслеживаем информационное поле, следим за сообществами angie и nginx, оперативно портируем патчи при необходимости. Процесс от обычного релиза отличается только внеплановостью.

Ну и мы не делим фичи на экспериментальные и неэкспериментальные. Мы подходим одинаково серьезно к ошибкам в любой из фич, даже если она совсем новая.

Пример хронологии на последних патч-релизах?

Релиз Angie 1.4.1 сделали на следующий день после релиза nginx 1.25.4

Changes with nginx 1.25.4                14 Feb 2024
   *) Security: when using HTTP/3 a segmentation fault might occur in a
      worker process while processing a specially crafted QUIC session
      (CVE-2024-24989, CVE-2024-24990).

Angie 1.4.1, Дата выпуска: 15.02.2024
Безопасность: При использовании HTTP/3 в рабочем процессе во время обработки
специально созданной QUIC-сессии могла произойти ошибка сегментации 
(CVE-2024-24989); при этом Angie, начиная еще с версии 1.4.0, 
не подвержен уязвимости CVE-2024-24990.

VBart: ну там нечем гордиться особо, просто в процессе разработки HTTP/3 клиента Володя добавил проверок в одну из общих функций, тем самым сам того не подозревая закрыл одну из позднее найденных в nginx уязвимостей

Релиз Angie 1.5.2 в течение недели после релиза nginx 1.26.1

Changes with nginx 1.26.1                     29 May 2024
  *) Security: when using HTTP/3, processing of a specially crafted QUIC
     session might cause a worker process crash, worker process memory
     disclosure on systems with MTU larger than 4096 bytes, or might have
     potential other impact (CVE-2024-32760, CVE-2024-31079,
     CVE-2024-35200, CVE-2024-34161).

Angie 1.5.2, Дата выпуска: 03.06.2024.
Безопасность: При использовании HTTP/3 обработка специально созданной 
QUIC-сессии могла приводить к падению рабочего процесса, отправке клиенту
содержимого памяти рабочего процесса на системах с MTU больше 4096 байт 
и иметь другие последствия (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200,
CVE-2024-34161); исправление портировано из nginx 1.26.1.

Комментарий про freenginx?

Vladimir Kh: в плане того, что мы собираем полезное со всех форков и публикуем на благо общественности, причём забесплатно!

А это уже к Angie 1.6.1 можно отнести

Angie 1.6.1, Дата выпуска: 08.08.2024.
Обработка закэшированных ответов с заголовком X-Accel-Redirect могла приводить
к падению рабочего процесса. Спасибо Максиму Дунину (freenginx) и Иржи Сетничке.

VBart: а то, что мы выпустили раньше – это другая история, ещё про 1.3.1 https://angie.software/oss_changes/#angie-1-3-1

Angie 1.3.1, Дата выпуска: 18.10.2023.
Безопасность: Добавлены дополнительные ограничения при обработке потоков HTTP/2,
чтобы лучше противостоять DoS-атаке «HTTP/2 Rapid Reset» (CVE-2023-44487).

Изменения в nginx 1.25.3                          24.10.2023
   *) Изменение: улучшено детектирование некорректного поведения клиентов
      при использовании HTTP/2.

Где можно и нужно смотреть наш код

Основной код проекта у нас лежит на https://hg.angie.software/angie/

Почему github у нас не в фаворе? ну, кроме вашей любви к git

Vladimir Kh: а за что его любить-то? микрософт жи, да ещё американский. у нас тут свои суверенные сервера. и в чём выражается нелюбовь?

VBart: есть нерадостные истории взломов проектов на github и уязвимостей самого сервиса. В любой момент могут закрыть/ограничить доступ из РФ.

VBart: Плюс невозможно контролировать подлинность кода на стороннем сервисе. Будь я АНБ, то сидел бы в офисе гитхаба и когда нужно и кому нужно вставлял бы закладку незаметно. Все видят одну репу, а атакуемый скачивает другую

Ну а по мотивам сообщения у нас в чате `@angie_support`, чего мы на Gitflic и GitVerse не спешим? https://t.me/angie_support/3152

Vladimir Kh: а какие реальные проблемы это решит? у нас как-то особых проблем не наблюдается. уйти к каким-то чувакам чтобы что?

VBart: лучше на МосХаб!

Есть идея собирать проекты на одной площадке, чтобы развивалось сообщество

VBart: и поэтому сделали 10 разных площадок =)

Vladimir Kh: контрибуторы не заводятся сами как мыши в грязном белье от того, что кто-то склонировал код на ещё один сервис. Это как сколково: кто-то думает, что если сделать уютные офисы, то там самозародятся инновации и хайтек.

VBart: вдруг кто не в курсе, это реальная штука https://hub.mos.ru/ Поэтому и не там:

$ curl -sI https://hub.mos.ru/ | grep server
server: nginx

VBart: ах да, ревью на гитхабе - это трэш полный =) (по сравнению с ReviewBoard)

Инфраструктура распространения дистрибутива

Большинство ли проектов не парится своей инфраструктурой? про nginx что надо знать? его с радостью и так растаскивают вендоры ОС?

VBart: ну не совсем... в дистрах то, как правило, старые версии. А иной раз ещё и криво собранные. С доп уязвимостями. А даже если свежие и без уязвимостей, то всегда есть лаг между выпуском исправления авторами и попаданием в репозитории.

Заявляя такое, пруфы будем давать?

VBart: https://www.opennet.ru/opennews/art.shtml?num=45515 . Ну и одно время там вообще не было версии nginx в репе без парочки кривых сторонних модулей. Позже они там сделали nginx-light и ещё какие-то... nginx-*

Vladimir Kh: у вендоров свои взгляды на то, как собираться, патчить или нет и т.п. они говорят – нам лучше знать, с какими флагами собирать, у нас видение на 100500 наших пакетов. У нас свой релизный цикл и т.п. Наши юзеры хотят фичи икс или чтобы файлы лежали там-то, мы так привыкли. Авторы могут быть не согласны. У всех свои политики – кто-то упорот на безопасности, кто-то на скорости.

Когда Centos отказался от 7 версии, какого головняка добавилось у пользователей?

Dmitry G: Ну мы последнюю версию Angie собрали под 7. К нам приходят с 7-й тоже, но не часто. Лично я не в курсе какой головняк там у них и что они там будут делать.

куда мы хотели свой дистрибутив отправить и нам были не рады?

VBart: с freebsd тормоза. У них до сих пор 1.3.2 https://www.freshports.org/www/angie/. Уязвимости? да всё равно…

Про фряху вот тикет недавно был https://github.com/webserver-llc/angie/issues/91

Dmitry G: Alpine вроде https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/46435

VBart: там до сих пор история про добавление Angie с поддержкой ACME в список поддерживаемых клиентов Letsencrypt https://github.com/letsencrypt/website/pull/1677

Олег, расскажи подробнее, как устроены релизные циклы вендоров дистрибутивов ОС, почему мы не можем на них положиться?

Oleg M: Мы выпускаем релизы нашего ПО примерно раз в квартал (иногда бывает чаще). Естественно, что нам хочется, чтобы конечные пользователи получали обновления максимально оперативно. Не секрет, что в нынешних реалиях самостоятельно собирают софт из исходников только энтузиасты-любители и/или разработчики. Типичный же пользователь использует пакетный менеджер целевой операционной системы либо docker image. Пакетный менеджер, в свою очередь, может использовать репозитории конкретного дистрибутива и некоторое количество дополнительно подключаемых внешних (PPA).

Linux дистрибутивы, поддерживаемые по принципу релизных циклов неизменно пользуются высокой популярностью. Это связано с тем, что внутри жизненного цикла релиза в основном выпускаются только исправления пакетной базы, но не прочие обновления. Таким образом, пользователь может быть более или менее уверен, что ПО в его системе не только не подвержено уязвимостям, но и не изменит радикально свое поведение в результате обновления.

Как и любая форма стабильности, это и хорошо и плохо одновременно, все зависит от ожиданий и предпочтений 🙂
Идеально - когда есть выбор, какое-то ПО хочется видеть безопасным и неизменным, а какое-то - максимально актуальным.

Vladimir Kh: они выпускают промежуточные релизы, но софт они там обновлять не будут. вышла убунта с nginx-1.2, так она и через год с тем же 1.2 будет, разве что запатчат дыру какую или баг страшный. Ну и вендоров - десятки, ты к какому хочешь привязаться?

А наши минорные версии, вот 1.5 и 1.6 у нас, например?

Oleg M: Надо понимать, что система версионирования ПО у каждого автора – своя. Даже используя старый добрый semver нельзя быть уверенным ни в чем. Кто-то может гарантировать обратную совместимость в рамках мажорной версии, кто-то минорной, а кто-то, вообще о ней не задумывается. Поэтому в релизном дистрибутиве каждый мейнтейнер самостоятельно решает, какие версии ПО можно подтянуть в рамках текущего релиза, а какие не стоит. В последнем случае ему придется делать cherry-pick изменений в виде локальных патчей, чтобы устранить проблемы безопасности, но не сломать обратной совместимости пакета.

Еще один хороший пример проблематики - недавнее прекращение релизного цикла CentOS и переход дистрибутива на модель stream. Огромное количество пользователей, мягко говоря, были расстроены этим нововведением, и их можно понять.

И ты говоришь, что теперь у всех прибавилось головняка.

Oleg M: Да, интернет полон боли по этому поводу до сих пор 😀У дистрибутива сложился широкий круг пользователей, привыкших к его предсказуемому поведению. А теперь у них вынужденный выбор: использовать CentOS Stream, где в любой момент может приехать что-то новое (а у них, соответственно, сломаться что-то старое) или покупать RHEL или искать какие-то бесплатные альтернативы (Alma/Rocky/whatever), но их будущее пока туманно.

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

То есть мы с точки зрения обновления софта для вендора ПО к лучшей ситуации приходим?

Oleg M: С точки зрения оперативности доставки ПО до потребителя - да, rolling releases нам на руку. Но, тем не менее, лаг во времени может быть:

Значителен
Не подконтролен нам

Никто не гарантирует, что пакеты Angie в репозитории CentOS Stream будут появляться так оперативно, как хотелось бы нам. Можно только лишь надеяться, что они появятся там быстрее, чем в Debian, например 🙂

Хорошо. А при этом FreeBSD и Alpine?

Oleg M: В Alpine Linux новые релизы выходят раз в полгода, если я не ошибаюсь. Но там наш пакет не приняли и, если отбросить в сторону придирки по оформлению (тут мы полностью открыты для критики), то основной мотив прозвучал с порога: “Is it yet another fork of Nginx? Thanks but no.”

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

A FreeBSD?

Oleg M: Вот в FreeBSD нас приняли, но там возникла проблема с коммиттером портов, который принимал наши изменения. Время реакции было непрогнозируемо большим, иногда измерялось неделями, если не месяцами. В итоге это превратилось во взаимную головную боль. Пока мы ждали от него обратной связи или учитывали его пожелания, у нас выходил новый релиз, соответственно, наши патчи переставали быть актуальными и вся дискуссия зацикливалась.

Кроме того, во FreeBSD есть еще одна проблема, которая тоже не доставляет нам радости. Дело в том, что там не поддерживается подход, когда наши зависимости собираются и складываются непосредственно внутри нашего пакета (bundling). Этот подход не находит одобрения, а мы, к сожалению, не готовы полагаться на те зависимости, которые предоставляет репозиторий дистрибутива. Там бывают не все нужные нам порты или их версии нас не устраивают. Также, их версии могут измениться в непредсказуемые для нас моменты времени, и тогда у нас разваливается наша сборка. Такая вот грустная история.

В итоге, для того, чтобы нам оперативно поставлять ПО целевому пользователю на целом спектре платформ, нам необходимо делать свои репозитории для всех этих дистрибутивов. Только тогда у нас полностью развязаны руки как по выбору и фиксации версий зависимостей, так и по частоте выпуска обновлений.

А как дела с Docker?

Oleg M: Пакеты Docker распространяются по подобной модели. Например, Docker можно установить из репозитория Debian stable, но на практике так никто не делает, так как в репозитории дистрибутива он всегда в достаточно устаревшем состоянии (из-за длинного цикла поддержки релиза Debian). Меж тем новые релизы Docker выходят часто, бывает и несколько раз за месяц. Соответственно, единственный удобный путь - подключать репозиторий с docker.com и получать апдейты, минуя Debian stable.

Аналогичный подход предлагаем своим пользователям и мы.

В принципе, nginx.org использует аналогичный метод дистрибуции. Но, в отличие от nginx, мы решили сделать спектр операционок максимально широким. На текущий момент он у нас значительно больше.

Oleg M: Также, мы сразу же решили собирать под все эти платформы наиболее востребованные сторонние модули. Чтобы людям не приходилось самостоятельно скачивать, компилировать и при каждом апдейте основного пакета повторять эту всю не особо удобную и простую историю. На сегодня у нас в репозитории больше трех десятков third-party modules и мы постоянно смотрим, что бы еще полезного можно было добавить.

А насколько, по-твоему, проблемы производительности в Docker мешают распространению такому софта как nginx или PostgreSQL развиваться?

Oleg M: Да, какие-то проблемы существуют, но они мешают не всем, не везде и не всегда. Именно поэтому Docker-образа nginx и PostgreSQL были и будут очень широко востребованы.

Естественно, Docker имеет свои нюансы, но называть это проблемами с производительностью я бы все же не стал. Само по себе, приложение в контейнере работает практически без оверхеда (в отличие от, например, виртуализации).

Да, файловая система внутри контейнера это некий overlay, и, конечно, это не будет очень быстро. Но никто не заставляет, ее активно использовать, всегда можно пробросить внешние монтирования. Второе стремное место - сеть. Это виртуальные бриджи и магическая манипуляция netfilter rules. И первое и второе также имеет свою цену с точки зрения производительности. Но тут тоже есть пространство для маневра, если вы понимаете, что делаете и зачем.

Инфраструктура сборки сторонних модулей

Чтобы подобные модули установить для Nginx, я как пользователь, что должен проделать?

Oleg M: Перво-наперво - скачать исходный код самого модуля 🙂

Далее, если nginx был поставлен из бинарного пакета (что наиболее вероятно), то этот пакет был взят либо с nginx.org, либо взят непосредственно из дистрибутива. Начать придется с получения исходных текстов nginx той же самой версии, которая установлена. Скачать их можно либо с nginx.org, либо взять из source пакета вашего дистрибутива.

Далее обзавестись toolkit-ом для сборки и, возможно, установить зависимости, нужные для сборки самого модуля. Возможно, эти дополнительные зависимости потребуют подключения новых сторонних репозиториев. Это также надо будет сделать.

Наконец, запустить сборку модуля и путь к результирующему .so файлу указать в конфигурации nginx.

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

В случае с Angie, пользователь из нашего же репозитория (https://download.angie.software/) может скачать как пакет самого Angie, так и пакет динамического модуля. Конечно же, они будут согласованы по версиям. И когда пользователь сделает апгрейд, оба пакета проапгрейдятся в связке.

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

Oleg M: Добавление в сборочный фреймворк нового модуля всегда начинается с того, что мы фиксируем его версию и релизный тарбол исходников помещаем в локальное хранилище дистрибутивов. Таким образом, в момент сборки пакетов мы не зависим от доступности внешних ресурсов и полагаемся на доступность всех необходимых файлов внутри нашей инфраструктуры.

Подготавливая очередной релиз Angie, мы смотрим, что произошло во внешнем мире, какие модули получили апдейты, какие новые релизы вышли и, при необходимости, сохраняем новый тарбол. В итоге, у нас накапливается история всех сторонних исходников, которые мы когда-либо собирали.

Внутри каждого пакета динамического модуля есть соответствующий файл README, который в простой текстовой форме описывает, из чего именно этот модуль был собран. При установке пакета этот файл копируется в стандартный для дистрибутива каталог локальной документации.

Своих тестов для сторонних модулей мы не пишем, единственное, что проверяем в рамках CI - успешный запуск angie с загруженными модулями.

Если же у модуля есть свои тесты (есть и такие!), то эти тесты мы также прогоняем в нашей системе CI.

Я знаю, что у нас там на каждый релиз делается чуть ли не 1000 пакетов, если все перемножить в матрицу, получается много. Интересно, наверное, выходит релиз, сколько времени занимает в позитивном сценарии от начала до когда мы можем выпускать.

Oleg M: Лучший сценарий сборки релиза Angie OSS (если не возникло непредвиденных осложнений) - около полутора часов. Примерно аналогично - для Angie PRO.

Или, может, самые тяжелые модули, например, долго собираются?

Oleg M: Мы активно используем ccache, эта “маленькая хитрость” позволяет нам драматически ускорять сборку за счет кеширования объектного кода, порождаемого в результате компиляции C и C++ кода. Причем, актуальные версии ccache умеют использовать централизованное хранилище, обращаясь к нему по WebDAV. Это дает нам возможность разделяемого кеширования, что повышает эффективность кэша.

А то, что Володя тоже помогал оптимизировать?

Oleg M: После того, как мы внедрили ccache, следующим очевидным узким местом стало многократное выполнение скрипта configure. Дело в том, что он вызывается два раза для сборки каждого пакета, коих у нас в сумме почти четыре десятка на каждой платформе. Хотя результаты его работы всегда одинаковы и их можно безболезненно кешировать и переиспользовать.

Мы пришли к Володе с предложением этой оптимизации и Володя нам здорово помог - в настоящий момент скрипт configure умеет сохранять результаты своей работы.

И про архитектуру, во-первых, кратко, для нас есть какое-то отличие x86 и Arm? и про отечественные платформы как это приходит. Что мы тут делаем с точки зрения архитектур?

Oleg M: С точки зрения процесса сборки у нас практически нет каких-то весомых различий. Основная сложность - где взять аппаратные мощности для сборки. На сегодняшний день в России не так много предложений по аренде aarch64 серверов. В итоге, самым простым решением оказалось приобрести для этой задачи машины с Apple M1 Silicon.

Oleg M: Еще есть некоторые отличия в самих дистрибутивах Linux, например, иногда бывают редкие случаи, когда необходимая нам зависимость существует для x86_64, но по каким-то причинам её нет для aarch64. Но это, по счастью, редкость.

Байкал. У нас есть Байкал. Он работает еще?

Oleg M: Мы его активно эксплуатировали до того, как обзавелись собственными Apple M1. Сейчас он на заслуженном отдыхе, все же мобильному бюджетному процессору сложно тягаться с высокопроизводительными собратьями.

Заключение

Итак, зачем мы рассказали про нашу инфраструктуру – да потому что можем.

Для нас инфраструктура разработки и сборки дистрибутивов под множество платформ – быстрый способ доставки приложения в надлежащем виде пользователям. Сборка расширений в виде сторонних модулей – важная составляющая образа целостного продукта. Всё таки сегодня веб-сервер ценится в совокупности со своей экосистемой модулей. Ну а в связке с нашей технической поддержкой сообществу (а это и наш форум https://forum.angie.software, и телеграм группой https://t.me/angie_support) – это еще и способ убедиться, что пользователи получат положительный опыт от взаимодействия с веб-сервером.

Такая инфраструктура и процесс позволяют поддерживать репутацию отзывчивого вендора ПО. В частности выпускать оперативно обновления с исправлениями уязвимостей.

Open source проект – это не только код. Теперь вы знаете это – живите с этим.

С вами была команда Angie:

VBart – Валентин Бартенев, руководитель разработки
Vladimir Kh – Владимир Хомутов, разработчик
Sergey K – Сергей Каличев, разработчик
Rodion N – Родион Николов, разработчик
Oleg M – Олег Мамонтов, руководитель техподдержки и инфраструктуры
Dmitry G – Дмитрий Генгер, системный инженер
Anna – Анна Сарбукова, руководитель юридической службы

Копирайты – это рак, или инфраструктура разработки веб-сервера Angie