Наши разработчики создали немало Open Source-решений разного масштаба. Например, CLI-инструмент werf, который входит в CNCF, его сопутствующие утилиты trdl, kubedog, Nelm и так далее. Также CE-редакция нашей Deckhouse Kubernetes Platform (DKP) является открытой. А ещё у нас есть такие Open Source-проекты, как K8s-image-availability-exporter (экспортер Prometheus для Kubernetes), glaball (CLI-инструмент для управления несколькими самостоятельными экземплярами GitLab одновременно), shell-operator (для запуска скриптов, управляемых событиями, в кластере K8s) и прочие.
Для нас Open Source — это не просто красивая идеология. Мы живем ею и считаем важным вносить в неё вклад. Поэтому мы не только создаём свои Open Source-решения, но и приносим патчи в сторонние инструменты с открытым исходным кодом. Этим мы приносим пользу и сообществу, и разработчикам проектов, и себе. В последнем случае это производственная необходимость: мы хотим, чтобы сообщество тоже развивало код, который мы написали. Так мы экономим свои ресурсы. Особенно это ощущается при работе с крупными фичами.
В статье мы объясним, зачем создаём проекты с открытым кодом, в какие решения контрибьютим и какая ценность в этом для разработчиков.
Варианты работы с Open Source-проектами
Во «Фланте» отношения с Open Source строятся в двух парадигмах.
У нас есть продукты и процессы, построенные на Open Source-решениях. Та же DKP как раз деплоит единый унифицированный набор Open Source-компонентов в кластеры, которые мы обслуживаем. Посмотреть, какие компоненты мы используем, можно в README на GitHub. Конечно, поверх Open Source-компонентов мы делаем много доработок, но разработка платформы в отрыве от инструментов с открытым исходным кодом была бы очень сложной.
Также с помощью открытости кода стараемся вызвать у пользователей большее доверие к нашим инструментам, и любой из них может внести свой вклад в его улучшение. Все предложения пользователей вносятся в общий флоу и обсуждаются командой, ответственной за продукт. Если мы видим, что проблема действительно важная и её можно решить предложенным способом, то ею будут заниматься в первую очередь.
Мы вносим свой вклад в сторонние Open Source-инструменты. Так сообщество замечает нас и поддерживает наши изменения, а мы повышаем свою ценность в мире ИТ и экономим ресурсы за счёт сообщества, которое продолжает развивать код, который мы предложили.
Обычно мы вносим вклад в Open Source-продукты, которые используются в решениях компании «Флант», например в качестве модулей к Deckhouse Kubernetes Platform.
Разберём подробнее, в какие основные проекты мы контрибьютим и как наши изменения помогли улучшить эти продукты и поднять рейтинг «Фланта» в международном сообществе.
Наши Open Source-проекты
Расскажем о наших основных Open Source-решениях.
CE-редакция Deckhouse Kubernetes Platform — версия предназначена для свободного использования и предоставляет пользователям возможность развёртывать и управлять кластерами Kubernetes без дополнительных затрат.
werf — это CLI-инструмент для реализации полного цикла CI/CD в Kubernetes. Он интегрируется с вашей CI-системой и использует знакомые и надёжные технологии, такие как Git, Dockerfile, Helm и Buildah. Мы разработали эту утилиту в 2016 году, чтобы помочь командам быстро и эффективно управлять жизненным циклом приложений, включая сборку контейнеров, тестирование и развёртывание. В 2022 году проект передали в фонд CNCF (Cloud Native Computing Foundation) с целью поддержки и развития Open Source-проектов и их интеграции в более широкую экосистему облачных технологий.
Shell-operator — инструмент, предназначенный для запуска скриптов, управляемых событиями, внутри кластера Kubernetes. Проект является открытым исходным кодом и лицензируется по Apache License 2.0 с подробной документацией, доступной для пользователей, желающих внедрить или узнать больше о его функциях.
Kubedog — это библиотека, предназначенная для отслеживания и наблюдения за ресурсами Kubernetes в CI/CD-пайплайнах. Она используется в инструменте werf для контроля ресурсов во время процесса развёртывания.
Addon-operator — система для управления дополнительными компонентами кластера Kubernetes простым, последовательным и автоматизированным способом, которая сочетает в себе Helm-чарты с хуками и хранилищем значений, чтобы преобразовывать чарты в умные модули, которые настраивают себя и реагируют на изменения в кластере.
Lockgate — это библиотека для языка Go, предназначенная для реализации распределённой блокировки. Она поддерживает как локальные файловые блокировки, так и распределённые блокировки, основанные на Kubernetes или HTTP-сервере блокировок.
Nelm — альтернатива Helm 3, которая используется в качестве движка развёртывания в werf. В будущем Nelm будет иметь собственный CLI для тех, кто не нуждается во всех возможностях werf.
trdl — это решение с открытым исходным кодом, предназначенное для безопасной доставки обновлений программного обеспечения из репозитория Git конечным пользователям. Этот инструмент обеспечивает надёжный канал для обновлений, используя концепцию The Update Framework (TUF).
k8s-image-availability-exporter (или просто k8s-iae) — это Prometheus-экспортер, который заранее предупреждает о недоступных образах контейнеров, определённых в объектах Kubernetes (например, в поле image Deployment). k8s-iae совместим с Kubernetes 1.15+ и реестрами контейнеров, совместимыми с Docker Registry V2.
Glaball — CLI-инструмент для управления множеством самостоятельно размещённых экземпляров GitLab одновременно. Был открыт для публичного использования в марте 2021 года.
ovpn-admin — это простой веб-интерфейс для управления пользователями OpenVPN, их сертификатами и маршрутами в Linux. Бэкенд написан на Go, а фронтенд основан на Vue.js. Изначально проект был создан для наших внутренних нужд и использовался в течение многих лет, а затем был обновлён и открыт для публичного использования в марте 2021 года. В ноябре 2024 года ovpn-admin был передан компании Palark.
Контрибьютинг от инженеров «Фланта»
Вклад в Kubernetes
Пожалуй, самое большое достижение — это то, что мы на протяжении многих лет являемся главным российским контрибьютором в Kubernetes. По миру мы входим в топ-200 контрибьюторов за последние пять лет существования K8s.
В Kubernetes есть понятие SIGs — это вроде аналога подкомитетов в сообществе разработчиков ядра Linux. Мы являемся участниками подкомитета Authentication, который отвечает за аутентификацию, авторизацию и политики доступа. Например, недавно архитектор DKP Максим Набоких довёл до stable свой первый Kubernetes Enhancement Proposal (KEP), то есть полноценную фичу. А сейчас уже принят наш второй KEP — крупнейшее обновление в аутентификации за последние годы (Structured Authentication Config).
Подробности о новой системе аутентификации в K8s можно прочитать в нашем блоге. А ещё Максим Набоких рассказал, почему появился Structured Authentication Config и когда он полезен.
Помимо этих KEP, у нас есть большое количество PR и отправленных issues. Также мы руководим переводом документации Kubernetes на русский язык.
Вклад в другие открытые проекты
Перечислим другие проекты, в которые наши инженеры вкладывались особенно активно.
В Ingress NGINX Controller мы сделали большое количество мелких фиксов, а также приносили важные исправления безопасности: закрывали дыры, которые потенциально позволяли людям случайно получать доступ к ресурсам, которого у них не должно быть. Примеры наших изменений:
Обновление nginx до версии 1.25.5 и добавление модуля HTTP/3. При этом мы сопровождаем добавление поддержки самого HTTP/3, расписав для этого шаги.
Добавление новой метрики в метке пространства имён, которое указывает на местонахождение контроллера. Это изменение направлено на улучшение оповещения NGINXCertificateExpiry, в котором теперь отображается информация о пространстве, где был создан ingress, и имени секрета, что более удобно для понимания, где искать неисправный секрет с сертификатом.
Исправление потенциальной проблемы с безопасностью, относящейся к обработке конфигурации для контроллера.
В Prometheus Operator мы тоже приносили немало исправлений. В том числе контрибьютили в него со стороны kube-state-metrics, который относится к проекту Kubernetes. Например, предложили добавить лейблы локальных хранилищ в kube_persistentvolume_info. Или исправили баг, связанный с VPA. А ещё добавили возможность настройки отдельного релейблинга для каждого экземпляра Alertmanager в кластере, что позволяет более гибко управлять уведомлениями и улучшает их маршрутизацию.
В Grafana приносили важные фичи, связанные с концепцией IaC (инфраструктура как код). Например, там есть такая штука, как provisioning: ты кладёшь файлы на диск, Grafana их оттуда считывает, загружает к себе в базу и строит на их основе дашборды, Data Sources и прочее. Мы сделали так, чтобы в виде файлов таким же методом можно было деплоить и настройки Grafana.
Проект CNCF Dex. Это провайдер идентификации OpenID Connect и OAuth 2.0, сделанный компанией CoreOS. В какой-то момент её поглотил Red Hat, и этот сервер остался без поддержки. Тогда мы вместе с Cisco взялись за него и теперь являемся мейнтейнерами проекта. Можно смело сказать, что жизнь Dex — наша заслуга (ссылка на все PR’ы от Максима Набоких). Например, мы:
добавили параметры для настройки ротации и срока действия токенов обновления;
добавили новый коннектор для сервера управления идентификацией Atlassian Crowd;
сделали завершение работы Dex корректным.
Ещё мы активно вкладываемся в проект Vector — написанный на Rust доставщик логов. Когда-то Vector был самостоятельной компанией, но позже её купил Datadog. В Vector мы контрибьютим не на Go, а на Rust. Например, совсем недавно в ходе расследования одного инцидента мы отправили PR в библиотеку, относящуюся к Vector.
Также мы вносим заметный вклад в следующие проекты:
Trivy Operator. Один из PR’ов, связанный с установкой заголовка User-Agent для запросов к container registries.
Rook. Например, добавление метрик для flexvolume driver или добавление динамического расширения flexvolume.
Участники команды werf по возможности контрибьютят в используемые Open Source-решения. К примеру:
в Helm мы принесли политику before-hook-creation для helm.sh/hook-delete-policy и множество фиксов, связанных с проблемами при развёртывании (#10085, #5579, #4871 и другие). Также приложили много усилий, чтобы наши наработки в контексте трекинга и логирования выкатываемых ресурсов были доступны всем пользователям Helm;
в upstream Argo CD Image Updater мы пытаемся довести поддержку OCI Helm-чартов.
При использовании Docker мы столкнулись с несколькими проблемами при программном использовании клиента. Одно решение, связанное с прокидыванием сборочного контекста и Dockerfile, уже находится в upstream: docker/cli/#2885. Вторая проблема, касающаяся логирования BuildKit (коммит), пока ещё не в upstream, но будет, так как поддержка собственного форка не входит в наши планы.
Ценность вклада в Open Source для разработчика
У вклада в инструменты с открытым кодом есть много плюсов.
Расширение сети контактов
Вот что об этом говорит руководитель разработки Deckhouse Kubernetes Platform Максим Набоких:
«Мне участие в Open Source-проектах дало много классных знакомств. А недавно я съездил на KubeCon и встретил там вживую много людей, с которыми я уже несколько лет разрабатываю один и тот же софт. Наконец-то у нас появился шанс посмотреть друг на друга офлайн, потому что я даже не представлял, как они выглядят. Там были и ребята из Kubernetes, Cisco и других крутых команд».
Развитие навыков
Участие в Open Source позволяет разработчикам накапливать опыт, который можно указать в резюме. Это особенно важно для новичков или тех, кто не может делиться информацией о своих рабочих проектах. Также это позволяет разработчикам учиться новым технологиям и улучшать свои навыки, что делает их более конкурентоспособными на рынке труда.
Преимущество в трудоустройстве
Работы в Open Source доступны для просмотра, что позволяет потенциальным работодателям оценить навыки и достижения кандидатов. Это может увеличить шансы на трудоустройство, так как вас могут легко найти и проанализировать вклад разработчика.
Если у компании есть Open Source-проекты, кандидат может оценить, с чем ему примерно предстоит работать. Например, весь код DKP CE открыт и лежит на GitHub — его можно почитать и посмотреть, как мы его собираем, что пишем, что у нас в планах. Когда собеседуют ребят в нашу команду и они спрашивают, какими задачами им предстоит заниматься, можно просто открыть GitHub и показать: вот такие задачи у нас в плане, вот такой код мы пишем, вот так у нас всё организовано, вот такой флоу. То есть не надо заморачиваться насчет NDA или что-то скрывать — всё прозрачно и понятно.
Заключение
Разработка собственных продуктов с открытым исходным кодом и активный вклад в сторонние Open Source-проекты не только являются ключевыми принципами и философией компании «Флант», но и дают нам практическую пользу. Мы хотим, чтобы нам доверяли и принимали участие в развитии наших продуктов. Также мы ценим партнёрство со сторонними проектами, ведь вклад в них способен повысить качество и функциональность нашего ПО.
Кроме того, от активного участия в Open Source-сообществе можно получить личную и профессиональную выгоду. Это приносит знакомства и повышает известность в сообществе.
P. S.
Читайте также в нашем блоге:
