Введение
Я думаю, что многим из нас доводилось слышать аналогии и сравнения между разработкой и производством: «сборочный конвейер», попытки применение паттернов из «Канбан» (системы которая сформировалась в компании Тойота) и даже «Фабрика микросервисов».
При этом, на сегодняшний день, разработка скорее напоминает артели ремесленников из 19 века, чем современный автомобильный завод.
В каждой компании выстроен (иногда выстрадан) свои уникальный процесс производства и инструментарий. В крупных организациях процессы могут отличатся даже между командами в одном отделе или департаменте.
Но если программирование –это творческий процесс, где есть место для индивидуализма и даже гениальных прорывов и изобретений. В котором полная унификация, и стандартизация может стать контр-продуктивным фактором, то в случае с жизненным циклом программного обеспечения, доставкой кода до потребителей и строительством внутренних платформ и инструментов, стандартизация может иметь мультипликативный эффект.
Чем меньше тратится времени на проверку гипотез и прототипирование, на сборку и тестирование проекта – тем больше возможностей для создания и доставки ценности до конечного пользователя.
О стандартах в разработке
Что можно отнести к общепринятым стандартам в веб разработке на сегодняшний день?
Есть набор рекомендаций из хорошо известной статьи «Приложение двенадцати факторов». Многие тезисы из этот статья по прежнему актуальны, не смотря на то, что они были сформулированы выходцем из компании Heroku (возможно первый коммерчески успешный PaaS проект), задолго до того как появился Kubernetes.
Docker и Docker Compose. Компания Docker (Docker inc.) однажды может лишится своей доминирующей позиции в отрасли, но формат Dockerfile давно превратился в стандарт и вряд ли что-то изменится в будущем.
Если говорить о сегодняшнем дне и в перспективе на несколько лет вперед, то в облаке набирают популярность бессерверные технологии. При этом локально (on-premise) в корпоративном секторе, Kubernetes постепенно занимает доминирующую позицию в качестве целевой платформы.
Возникает ситуация когда от разработчиков, требуется понимание целевой инфраструктуры на разных платформах и технологических стеках.
_Возникла необходимость в создании единого стандарта описывающего основные компоненты современного веб приложения.
OAM
В середине октября 2019 года Microsoft и Alibaba Cloud представили новый стандарт для моделирования приложений в сфере облачных и периферийных вычислений - Open Application Model OAM. Цель этого проекта, определить консистентную модель для доставки приложений, которая бы не зависела от платформ и имплементаций. OAM описывает интерфейс для разработчиков, который определяет из чего должно состоять приложение и как оно должно работать.
Микросервисы и OAM
Микросервисный архитектурный паттерн становится все более популярным в разработке; многие разработчики начинаю разбивать монолитные приложения на мелкие части. Каждая из такие частей, согласно определению OAM, может быть смоделирована в Компонент (OAM Component), а вместе несколько компонентов можно соединить в Приложение (OAM Application).
YAML
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: webserver-demo
spec:
components:
- name: hello-world
type: webserver # Запрос на развертывание компонента
properties: # Задаем параметры
image: myimage/hello-world
port: 8000 # Открываем порт
env:
- name: "foo"
value: "bar"
cpu: "100m"
Такие объекты Kubernetes как Service или Ingress необходимы для предоставляения сетевого доступа к приложению. PersistentVolumeClaim нужен для хранения данных. Объекты с которыми работают надстройки над Kubernetes – ServiceMonitor в Prometheus или секреты нужны для обеспечения наблюдаемости и безопасности. Эти ресурсы и модификации нужны для предоставления определенных возможностей, в OAM эти объекты определены как Traits (OAM Traits) или черты.
YAML
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: my-app
spec:
components:
- name: publicweb
type: web-ui
properties:
image: myimage/web-ui:v1.0.1@sha256:hash
param_1: "enabled"
traits:
- type: ingress
properties:
path: /
port: 8080
- name: backend
type: company/test-backend
properties:
debug: "true"
traits:
- type: scaler # Черта «Scaler» указывает количество реплик для компонента backend.
properties: # Здесь может быть «родной» для Kubernetes HPA или например KEDA.
replicas: 4
Черты и компоненты:
Проекты использующие OAM
Нас прежде всего интересует KubeVela, проект вышедший из Alibaba Cloud и Crossplane, который является логическим продолжением идей заложенных в OAM.
PaaS/IDP
Попытки создать новый уровень абстракции поверх YAML API Kubernetes – это обычная практика для крупных организаций.
Kubernetes оперирует инфраструктурными примитивами, а возможности таких инструментов как Helm, kustomize и helmfile достаточно ограничены, поэтому следующий логический шаг, после внедрения Kubernetes, это разработка своего графического конфигуратора для приложений, чтобы упростить работу для разработчиков и платформенной команды.
Вместо графического конфигуратора это может быть манифест TOML или один «убер-YAML» который включает в себя настройки приложения и инфраструктуры.
Разработчики KubeVela пошли другим путем: YAML конфиг (appfile) при каждом запросе на развертывание приложения трансформируется в DAG написанный на CUE. Любой компонент KubeVela можно кастомизировать с помощью CUE – язык конфигураций, который больше похож на HCL и BCL, чем Kubernetes YAML.
Кроме гибкости, такое решение обеспечивает еще и хорошую масштабируемость. KubeVela может работать под нагрузкой в тысячи приложений, чего нельзя сказать о доморощенных проектах, которые обычно развивает небольшая команда разработчиков.
KubeVela - Платформа для приложений
KubeVela это программируемый движок на основе, которого можно построить свою собственную внутреннею платформу для разработки (IDP) или PaaS. Это детище инженеров из Alibaba Cloud, созданное на принципах и стандартах OAM. В этом проекте они заложили свой операционный опыт и оптимальные подходы к построению платформы на базе Kubernetes. Вполне возможно, что Alibaba Cloud является крупнейшим в мире поставщиком такой услуги, как «Управляемый Kubernetes», поэтому их опыт определенно заслуживает внимания.
Архитектура KubeVela
KubeVela Core Controller
Ключевой компонент который отвечает за логику. Он управляет ресурсами API, оркестрацией и прасингом конфиг файлов.cluster-gateway
Эта штука нужна для того, чтобы предоставлять унифицированный доступ к кластерам Kubernetes.
Дополнения:
VelaUX
Пользовательский интерфейс. Во многом повторяет функционал UI консоли Rancher и Openshift, включая возможность визуализации топологии ресурсов приложения или приложений.Workflow
Движок рабочих процессов который KubeVela использует для сложных сценариев доставки приложений.Vela Prism
Надстройка над Kubernetes API Aggregation Layer. KubeVela использует это дополнение для работы с Grafana.
Vela Prism.png Terraform
Для оркестрации можно использовать контроллер Terraform. Переиспользование существующей инфраструктуры (провайдеров Terraform) это важный фактор, когда речь идет о создании гибридного облака. Связка из KubeVela и Terraform позволяет покрывать автоматизацией инфраструктуру в облаке и локально, в кластере Kubernetes и за его пределами.Для сценариев, когда нет доступных кластеров Kubernetes, есть VelaD. Отдельный демон KubeVela на k3s, к которому подключаются кластера Kubernetes для развертывания приложений.
Каталог с дополнениями для KubeVela, который как и в случае с OpenShift и Rancher можно расширить. За исключением того, что процесс этот по моему субъективному мнению, в KubeVela гораздо проще и логичней.
Можно использовать стандартный для Kubernetes YAML или CUE для создания пользовательских «аддонов». Как это реализованно можно посмотреть на примере аддона для cert-manager.
Сопоставление и синхронизация
Как и Crossplane (еще один проект использующий стандарты OAM), KubeVela умеет отслеживать расхождения между конфигурациями и состоянием инфраструктуры/приложения. Без встроенного механизма drift detection сложно себе представить успешное внедрение GitOps – одного из самых популярных, на данный момент трендов в DevOps. Надо или не надо, любой ценой внедрять GitOps – на эту тему можно было бы написать отдельную статью.
CI/CD
KubeVela это еще и полнофункциональная платформа для доставки кода. Под "капотом" такие возможности как: развертывание приложений на несколько кластеров, GitOps и мульти-кластерный конвейер доставки кода, реализованы с помощью интеграции с FluxCD.
Развертывание Helm чартов реализованна с FluxCD, а конвейеры развертывания одного или стека из приложений, с помощью встроенного, легковесного движка рабочих процессов. У такого подхода есть весомые преимущества по сравнению с написанием доморощенных конвейеров непрерывной развертывания, в случае если необходимо реализовать канареечные релизы. Писать конвейер самим или внедрять специализированную систему для непрерывной доставки зависит от требований в организации. KubeVela позволяет обойтись лишь встроенными в платформу инструментами и «родным» для Kubernetes API.
---
Могу лишь предположить, что когда в Alibaba принимали решение о публикации исходного кода KubeVela, то продиктовано это было не только альтруистическими соображениями. Благодаря первоклассной поддержке и интеграции с облачными сервисами Alibaba, такой проект может принести не только очки к репутации, но еще и новых клиентов.
---
Разработчики должны думать об архитектуре приложения, а не инфраструктуре, концепции Kubernetes являются слишком "низкоуровневыми" для разработки.
Чтобы успевать за высокими темпами изменений и сменой трендов в современной разработке, любой сервис или внутренняя платформа для разработчиков, должны быть таки ми же гибкими и расширяемыми как Kubernetes.
Если мы не можем разработать свои стандарты, то нужно принять те стандарты принятые во всем мире, или по крайней мере значительной его частью. Принципы заложенные Apache Foundation – это отличный вариант. Как показывает пример компаний из Китая, открытость не только не мешает, но и помогает курсу на суверенизацию и импортозамещение.
