Внутренняя платформа разработки (IDP) с открытым исходным кодом, построенная на основе Kubernetes, GitOps, и более чем 20 CNCF-инструментов, — безопасная, масштабируемая и удобная в использовании.
Примечание: Узнайте, как Choreo создала полностью бесплатформенную IDP с открытым исходным кодом, используя более 20 облачных инструментов, таких как Argo, Flux CD, Cilium, Envoy, Kyverno и т. д. Глубокое погружение в то, что происходит за кулисами, не лишенное юмора и эмпатии.
Если вы планируете посетить KubeCon EU 2025, обязательно загляните на стенд Choreo (S703)! Я могу только сказать, что если вас интересует IDP, то это мероприятие будет для вас очень интересным.
Введение: Kubernetes — это прекрасно… до определенного момента
Давай будем честными: всем нравится идея Kubernetes. Автоматическое масштабирование, самовосстановление, декларативность — что в этом не любить?
Но все меняется, когда ваша команда пытается реализовать это на практике. В результате вы сталкиваетесь с YAML, кишащими CVE Docker‑образами, и тем самым «временным» костылем, который каким‑то образом пережил уже три зимы. Внезапно этот замечательный инструмент для управления контейнерами превращается в ощутимый источник дополнительной работы.
Именно в этот момент многие компании начинают раздумывать о бесплатформенных (platformless) решениях, когда разработчики просто вводят код, и все происходит само собой. И вот на KubeCon SLC 2024 я наконец обнаружил нечто, что, возможно, наконец‑то сможет воплотить эту мечту в жизнь: Choreo от WSO2.
Но прежде чем мы углубимся в детали того, как это работает, давайте обсудим, что на самом деле означает «бесплатформенность».
Бесплатформенность: Миф или современная магия?
Обещание бесплатформенности кажется заманчивым:
«Просто наймите разработчиков. Никакой инфраструктуры. Никаких операций. Никакой головной боли.»
Если вы видели такие платформы, как Heroku, то вам знакома идея — разработчики пушат изменения на Git, и, вуаля, приложение уже обновлено и работает. Но давайте посмотрим правде в глаза.
Иллюзия 
:
-
Нет инфраструктурного подразделения
-
Нет DevOps
-
Нет YAML
-
Только поставка нового функционала и ничего лишнего
Вот как это выглядит в рекламе от поставщика услуг:
Реальность 
:
Даже в условиях «бесплатформенного» сетапа кто‑то должен управлять инфраструктурой. Просто это не вы, а ваш провайдер (например, Heroku или, в данном случае, Choreo). Это означает, что вы по‑прежнему тратитесь на инфраструктуру — только в виде ежемесячного счета.
А в регулируемых средах Heroku может быстро стать плохим вариантом из‑за следующих недостатков:
-
Нет стабильных исходящих IP‑адресов
-
Нет поддержки VPN
-
Отсутствие контроля над сетевым взаимодействием
-
Ограниченные гарантии соответствия (например, ISO 27 001, BSI C5 Typ II, EU Cloud Code of Conduct, и т. д.)
Реальность иная: подразделение разработчиков платформы и инфраструктуры по‑прежнему присутствует — они просто предоставляются поставщиком или гиперскейлером, таким как AWS, Azure или GCP.
Вы по‑прежнему платите за это через лицензии и использование. И это совершенно нормально, но давайте будем честными, это не совсем бесплатформенный подход.
Эти решения по‑прежнему актуальны, иначе они не стали бы такими популярными. Однако дух инженера во мне не может принять некоторые из них, особенно Heroku.
Честно говоря, Heroku — отличный продукт. Но с точки зрения проектирования для конечного пользователя это настолько закрытый черный ящик, что я нахожу его не только скучным, но и неподходящим для 99% моих европейских клиентов — в основном из‑за нормативных требований и ограниченного контроля над сетевой интеграцией.
Итак, что делать, если вам нужно удобство Heroku, но с контролем как в Kubernetes и комплаенсом корпоративного уровня? Ответ — Choreo! Позже я объясню, чем он отличается от Heroku.
Откройте для себя Choreo: Настоящая жемчужина, о которой вы должны знать
Сначала я почти не обратил внимания на Choreo. Я подумал, что это просто очередная SaaS‑платформа. Но затем я заглянул под капот и обнаружил нечто удивительное.
Choreo — это полностью опенсорсная внутренняя платформа разработки (IDP) с Kubernetes‑майндсетом, построенная на более чем 20 CNCF‑инструментах. Давайте рассмотрим некоторые из них:
-
Argo Workflows для CI/CD
-
Buildpacks.io для создания образов контейнеров
-
Harbor в качестве реестра контейнеров
-
Cilium + eBPF + Envoy для сетей и безопасности
-
Kyverno для политик
-
KEDA для автоматического масштабирования
-
Flux CD для GitOps
-
Prometheus, Thanos, OpenSearch… для удобного наблюдения
-
и многое другое…!
И что самое удивительное? Все это объединено в приятный UI, который придется по душе как программистам, так и разработчикам платформ.
До тех пор, пока у вас нет сильной команды с выработанным видением, это просто камешек с обочины. Но придайте ему нужное давление, и он превратится в бриллиант… или, по крайней мере, в прекрасный инструмент.
Еще в ноябре 2024 года, на KubeCon в SLC, несмотря на то, что я был впечатлен тем, как элегантно была построена Choreo, у меня все еще оставались сомнения. В то время она была доступна только как SaaS, и ее питч гласил: «Вам больше не нужно подразделение разработчиков платформы».
Это сильно беспокоило меня. Не потому, что я переживаю за свою работу (это не так), а потому, что большинство разработчиков, с которыми я работаю, просто не заботятся о безопасности, комплаенсе, FinOps… ну, знаете, всех этих «интересных» корпоративных штучках.
Однако ситуация изменилась к лучшему. В рамках своего SaaS‑предложения Choreo теперь предлагает специализированный интерфейс для подразделений платформы и DevOps, что делает возможным создание удобных самообслуживаемых порталов. И это только начало…
Я имел честь присутствовать на WSO2CON2025 в Барселоне, где принял участие в сессии «Birds of a Feather» и смог заглянуть за кулисы того, что нас ждет дальше
Но прежде чем мы перейдем к этому, позвольте мне рассказать вам, почему я считаю, что эта платформа так элегантно спроектирована.
Боль разработчика: безопасность начинается (и нарушается) в процессе разработки
Давайте будем откровенны — почти в каждом проекте, к которому я присоединялся, первоначальная система безопасности оставляла желать лучшего.
И дело не в том, что люди были беспечны. Просто от разработчиков требуют выполнять всего и сразу, а безопасность контейнеров — задача не из простых и по сей день.
Устаревшие зависимости, раздутые образы, небезопасные базовые слои, отсутствие SBOM, отсутствие подписи — все это помноженное на споры о том, что же на самом деле является «лучшими практиками». Многоступенчатые сборки? Отказ от дистрибутивов? UBI? Подписанные реестры?
Если уж совсем начистоту, то большинство разработчиков, которых я знаю, хотят только одного:
так называемые «golden path» и «guardrails», чтобы сосредоточиться на поставке функционала, исправлении ошибок и достижении целей спринта, а не на решении проблем с YAML и возни в кроличьих норах комплаенса.
Представьте себе мир, в котором разработчик коммитит код, а платформа заботится обо всем остальном:
-
Конвейеры сборки запускаются автоматически
-
Выполняются тесты и CVE‑сканирование
-
Создается наиболее подходящий образ контейнера
-
Этот образ помещается в реестр
Никаких Dockerfiles, никаких сложных настроек CI, никакой возни с kubectl.
Это именно то, что делает Choreo. Пушите код → Получаете готовый к продакшену безопасный контейнер.
Но подождите, а как же YAML… Конечно, одного контейнера недостаточно для полноценного развертывания. Для этого необходимы манифесты:
Даже для «простого» веб‑приложения требуется более 6 объектов Kubernetes, настроенных с учетом безопасности, масштабируемости и комплаенса.
Теперь представьте, что разработчикам приходится самостоятельно определять все эти параметры (SecurityContext, ресурсы, автоматическое горизонтальное масштабирование и т. д.). И еще писать бизнес‑логику. Нет, спасибо.
Вот где раскрывается сила Choreo. Она позволяет разработчикам определять только рабочий процесс: как приложение должно перемещаться между средами (Dev → QA → Prod).
Платформа берет на себя все остальные задачи: от создания манифеста до применения политик и развертывания.
Это включает в себя:
-
Дефолты безопасности (RBAC, mTLS и т. д.)
-
Сетевая безопасность с помощью Cilium
-
Развертывания на основе GitOps
-
Изоляция посредством пространств имен
-
и многое другое…
Таким образом, разработчики могут сосредоточиться на написании кода, в то время как платформа обеспечивает комплаенс, безопасность и надежность, заложенные в архитектуре. Отлично, приложение развернуто! Но вот тут‑то все и становится по‑настоящему интересным.
Потому что даже управляемый Kubernetes не всегда безопасен по умолчанию. Как правило, в стандартной комплектации вы не получаете сетевые политики, необходимые уровни RBAC, механизмы взаимодействия между сервисами и, конечно, инструменты разработки политик, такие как Kyverno, для соблюдения лучших практик и отраслевых стандартов.
Кто‑то должен взять на себя заботу обо всем этом — и желательно так, чтобы не мешать работе разработчиков. Это непростая задача, особенно в рамках модели общей ответственности.
Именно тогда я осознал: Choreo не просто автоматизирует Kubernetes — он делает его безопасным по умолчанию, даже в условиях общей ответственности.
Давайте теперь посмотрим, из чего на самом деле состоит Choreo.
Так что же из себя представляет это Choreo?
По своей сути, Choreo от WSO2 — это полностью управляемая внутренняя платформа разработчиков (IDP) корпоративного уровня, предназначенная для оптимизации как доставки программного обеспечения, так и его разработки. Особое внимание уделяется безопасности, простоте и скорости разработки и проверенным передовым практикам.
Она сочетает в себе два ключевых аспекта:
-
Поставка программного обеспечения: масштабируемая сборка, развертывание, запуск приложений и управление ими.
-
Разработка программного обеспечения: управление API, модульные сервисы, наблюдаемость и повторное использование — все встроено.
Choreo полностью построена на облачных инструментах с открытым исходным кодом из экосистемы CNCF. Эти компоненты не просто собраны случайным образом — они тщательно отобраны для создания законченной, готовой к использованию платформы с минимальной сложностью.
Некоторые из ключевых инструментов:
-
и многие другие…
Все эти инструменты вместе формируют основу надежного и по умолчанию защищенного IDP Choreo.
На следующей диаграмме представлена полная архитектура Choreo, начиная от CI/CD и заканчивая многопользовательскими кластерами Kubernetes.
На первый взгляд, эта схема может показаться сложной, но при более детальном рассмотрении все приобретает смысл. Давайте разделим архитектуру на две части.
В левой части диаграммы вы видите перспективу разработчика, как было описано ранее.
Что здесь примечательно, так это то, что конвейер работает на Argo Workflows, что делает его независимым от конкретного поставщика Git, будь то GitHub или GitLab.
Тем не менее, ваш исходный код по‑прежнему хранится в ваших собственных репозиториях, будь то GitHub, GitLab или любая другая поддерживаемая система.
Слева мы также видим сторону, ориентированную на разработчика:
-
Git push запускает сборку с помощью Argo Workflows
-
Контейнеры создаются с помощью Buildpacks
-
Образы загружаются в реестр Harbor
Если посмотреть на правую часть диаграммы, то на первый взгляд она может показаться немного запутанной. Однако, если сосредоточиться на ключевых компонентах, все начинает обретать смысл.
Вы можете заметить, что Flux CD используется для установки компонентов Choreo непосредственно в Kubernetes. Другие компоненты, такие как Cilium, Prometheus, Redis и т. д., развертываются с помощью Argo CD — по крайней мере, насколько я могу судить, изучив систему.
Что делает эту настройку столь элегантной, так это то, что по умолчанию используется микросервисная облачная архитектура, созданная специально для Kubernetes. Она обеспечивает безопасность, наблюдаемость, масштабируемость и изоляцию.
Когда пользователь создает Project + Stage в Choreo, это сопоставляется с выделенным пространством имен в Kubernetes, также известным как «сота» (cell).
Любые рабочие нагрузки, развернутые в этой соте, полностью изолированы от остальных.
Если вам необходимо установить связь между различными проектами или сотами, вам нужно явно предоставить API. Это воздействие осуществляется с помощью Cilium, eBPF и Envoy, которые обычно маршрутизируются с через Egress Gateway, например, для доступа в интернет.
Kubernetes не способен обрабатывать правила на основе DNS, такие как iits‑consulting.de для egress‑политик, из коробки. Однако благодаря eBPF (через Cilium) это больше не является препятствием.
Для внутренней связи (между сотами) трафик направляется через внутренний шлюз API, где сетевые политики строго регулируют доступ.
И вот что примечательно: этот сетап позволяет использовать mTLS между службами (при необходимости), а также обмениваться данными с учетом идентификационных данных и проверять токены на шлюзе API — все это без дополнительных настроек. Вы даже можете назначать сервисам уникальные идентификаторы и проверять их во время обмена токенами. Это мощный, гибкий и безопасный способ организации взаимодействия между различными компонентами вашей системы.
В итоге, с Choreo вы получаете современную и безопасную платформу Kubernetes, которая обладает следующими возможностями:
-
Реализует сеть с нулевым уровнем доверия (по умолчанию все запрещено)
-
Поддерживает динамическое масштабирование через KEDA
-
Обеспечивает безопасное управление API (например, с использованием шлюза WSO2… при необходимости)
-
Централизует логи, метрики и события
-
Использует GitOps для всех развертываний
-
И обеспечивает строгую изоляцию проектов
Признаюсь, поначалу мне было сложно понять, как работает эта архитектура. Все это кажется слишком API‑ориентированным, и часто используются термины, такие как Northbound, Southbound, East‑West трафик, которые распространены в сложных интеграционных архитектурах, подобных тем, что создает WSO2.
Однако, как только вы увидите следующую диаграмму, все станет на свои места:
Условные обозначения:
-
North‑South: Разработчик → Control Plane (например, пуш кода, запуск развертывания)
-
Southbound: Control Plane → Data Plane (развертывание рабочих нагрузок в облачных средах)
-
East‑West: API ↔ INT ↔ Пользовательский интерфейс (сервисы, взаимодействующие внутри одной среды)
-
Northbound: Data Plane → Control Plane (отправка логов, метрик и обновлений состояния)
Чтобы понять, почему WSO2 построили Choreo именно таким образом, мне нужно обратиться к их истории.
WSO2 — это опенсорсная технологическая компания с открытым исходным кодом, которая существует уже много лет и наиболее известна своими мощными решениями для управления API, интеграции и идентификации и контроля доступа (CIAM). Их платформы помогали предприятиям предоставлять безопасные, масштабируемые и облачные цифровые услуги задолго до того, как эти термины стали популярными в отрасли.
Поэтому неудивительно, что Choreo с самого начала был сосредоточена на API и безопасности. Это не случайность, а неотъемлемая часть их сущности.
Теперь давайте перейдем к практической части.
Научиться автоматизировать управление инфраструктурой и приложениями, внедрить CI/CD и обеспечить стабильность с Kubernetes можно на онлайн-курсе «GitOps».
Вертим в руках демо Choreo (SaaS)
Если вы зарегистрируетесь на https://console.choreo.dev, вы получите доступ к пяти бесплатным компонентам. Этого более чем достаточно для экспериментов или даже для размещения небольшого приложения..
Зайдя в пользовательский интерфейс, вы сможете настроить свою организацию и проект, которые будут соответствовать внутренней структуре Choreo.
В верхней части интерфейса всегда отображается решение SaaS в качестве плоскости управления (Control Plane) (концепция Choreo), а ниже — плоскость данных (Data Plane), которая представляет кластер Kubernetes. Похоже, что Choreo использует службу Azure Kubernetes Service (AKS) для рабочих нагрузок — по крайней мере, так это выглядит.
1. Первый шаг: Создайте организацию и проект
По умолчанию создаются два стейджа: Development и Production.
2. Теперь создайте компонент (Deployment) внутри консоли Choreo
Что происходит в Kubernetes на этом этапе?
Правильно — в кластере пока ничего не происходит. На этом этапе мы просто привязываем компонент к репозиторию GitHub. Для упрощения я использовал пример репозитория, чтобы продемонстрировать процесс.
Однако, что‑то уже начинает происходить за кулисами. Я полагаю, что репозиторий Git инициализируется с помощью Argo Workflows, а реестр контейнеров настраивается в фоновом режиме. Трудно точно сказать, где именно это происходит, но, скорее всего, в плоскости управления под ответственностью Choreo.
Это означает, что устанавливаются различные соединения. Argo Workflows подключается к репозиторию GitHub, и вы можете настроить автоматическую сборку при коммите.
Это соответствует рабочему процессу CI/CD, который мы обсуждали ранее:
Как показано на схеме, Choreo теперь пытается создать наше приложение, используя buildpacks.io. Также происходит сканирование безопасности. Если в процессе обнаруживаются критические проблемы (CVE), сборка завершается с ошибкой. Вот как это выглядит:
Можно заметить, что я использовал более старую версию next. Поэтому я исправил это с помощью npm audit fix и запушил заново. Результат:
Теперь появляется кнопка Deploy, которая запускает процесс развертывания по умолчанию:
Что, вероятно, и происходит на заднем плане
Если вы помните предыдущий рабочий процесс, внутри плоскости управления Choreo, скорее всего, происходит следующее:
-
Создается и помечается образ контейнера.
-
Создаются манифесты Kubernetes.
-
Эти манифесты развертываются в соответствующем пространстве имен с помощью Argo Workflows.
Я предполагаю, что в этой ситуации используются Argo Workflows, а не Argo CD. Мое предположение основано на том, что я не вижу связи между сгенерированными манифестами и Git‑репозиторием в стиле GitOps. Если бы использовался Argo CD, манифесты, вероятно, также хранились бы в репозитории. Однако я могу ошибаться.
Если бы в этом процессе были полностью реализованы автоматическая сборка при коммите и автоматическое развертывание, рабочий процесс выглядел бы следующим образом:
Что происходит на плоскости управления и данных (упрощенный вид):
Choreo создает соту, содержащую компонент (в данном случае это простое веб‑приложение — список дел). В Kubernetes за кулисами используются различные инструменты, такие как:
-
Сетевые политики
-
Интеграция со шлюзом API для обеспечения north‑south трафика
В настоящее время этот компонент является довольно простым и обрабатывает только входящий трафик. Однако ситуация усложняется, когда вы:
-
Добавляете несколько компонентов в одну соту или в разные проекты и разрешаете обмен данными между ними.
Это подводит нас ближе к следующей диаграмме:
Если вы внимательно посмотрите в консоль Choreo в раздел Deployments, вы также увидите, что используется KEDA.
Эта SaaS‑платформа предлагает гораздо больше возможностей. Недавно Choreo добавила функции разработки платформы и интеграции с SRE. Эти функции позволяют определять не только возможности самообслуживания, но и правила комплаенса, политики управления, рабочие процессы и многое другое.
Как я уже говорил в начале, нанимать одних лишь разработчиков недостаточно. Кто‑то должен также нести ответственность за соблюдение стандартов компании, безопасность и передовые методы работы.
Я также считаю, что это лучше (по моему личному мнению), чем Heroku, с точки зрения гибкости, и вот почему:
Таким образом, вы можете сосредоточиться на использовании консоли Choreo и выполнении рабочих нагрузок на вашей приватной плоскости данных, получая следующие преимущества:
-
Более жесткие SLA
-
Больше гибкости и контроля
-
Комплаенс
-
Дополнительные политики и инструменты безопасности
Но самое интересное еще впереди…
OpenChoreo: Лучшая часть? Теперь у него открытый исходный код!
Да, вы правильно прочитали — Choreo откроет свой исходный код в качестве OpenChoreo.
OpenChoreo — это внутренняя платформа разработчика (IDP) с полностью открытым исходным кодом, предназначенная как для инженеров платформ так и для разработчиков.
Также это поможет вам решить «Дилемму IDP »
Большинство организаций сталкиваются с одной и той же проблемой при выборе внутренней платформы разработчика:
Вариант 1:
Создание собственной платформы — вы получаете полный контроль, но это требует времени, усилий и постоянного обслуживания.
Вариант 2:
Покупка SaaS ‑решения — его проще внедрить, но часто требуется ограниченная настройка и потенциальная привязка к поставщику.
OpenChoreo предлагает третий путь: открытую, автономную, готовую к продакшену IDP, которая дает вам лучшее из обоих миров:
-
Контроль, гибкость, функции корпоративного уровня и отсутствие привязки
Вы можете приступить к использованию уже сегодня, но важно помнить, что проект все еще находится в активной разработке. В настоящее время отсутствует единый портал для полной интеграции OpenChoreo.
После KubeCon EU я планирую опубликовать практический блог, в котором поделюсь своим опытом, пошаговыми инструкциями, дорожной картой и всем, что узнаю за кулисами.
Не забывайте подписываться на проект на GitHub, заглядывайте на стенд Choreo (S703) на KubeConи вносить свой вклад, если у вас есть такая возможность — это поможет сделать проект лучше!
Если вам близка философия GitOps и вы хотите разобраться, как именно работает один из ключевых инструментов этой статьи — приглашаем на открытый урок «Введение в ArgoCD». Разберем, как автоматизировать деплойменты, управлять конфигурацией через Git и строить надежные CI/CD-процессы на Kubernetes.
Урок пройдет 15 апреля, записаться можно бесплатно на странице курса «GitOps».
ссылка на оригинал статьи https://habr.com/ru/articles/897574/
Добавить комментарий