Как упростить развертку облачных приложений — представлена новая открытая спецификация

Microsoft и Docker разработали открытую спецификацию Cloud Native Application Bundle (CNAB). Она описывает универсальный способ упаковки контейнерных приложений для работы в гибридных средах. Далее расскажем, зачем понадобилась CNAB и что она собой представляет.


/ фото tsuna72 CC BY

Что такое CNAB

Cloud Native Application Bundle — это спецификация, которая описывает способ упаковки компонентов (API, виртуальные машины, контейнеры), необходимых для запуска облачных приложений в распределенных средах. На первый взгляд, эту задачу должен решать сам Docker. Однако известно, что в случае с масштабными гибридными инфраструктурами, его стандартных функций оказывается недостаточно.

Таким образом, CNAB — это попытка унифицировать процесс упаковки, развертки и управления жизненным циклом распределённых приложений на базе Kubernetes, Helm, Swarm и др., с помощью единого формата пакетов. Эти пакеты базируются на JSON и OpenPGP.

Используя Cloud Native Application Bundle, разработчик получает возможность развернуть свое приложение как на локальной рабочей станции, так и в публичном облаке. Каждый из ИТ-гигантов представил свой инструмент, который демонстрирует возможности спецификации. У Microsoft этим решением стал клиент Duffle, у Docker — Docker app.

Примеры

Как мы говорили выше, спецификация определяет метод упаковки распределенных приложений различных форматов. CNAB включает в себя определение пакета (bundle.json) для описания приложения, а также специальный образ (invocation image) для его установки. Определение пакета выглядит вот так (пример описания есть в официальном репозитории на GitHub):

{
    "schemaVersion": "v1.0.0-WD",
    "name": "helloworld",
    "version": "0.1.2",
    "description": "An example 'thin' helloworld Cloud-Native Application Bundle",
    "maintainers": [
        {
            "name": "Matt Butcher",
            "email": "[e-mail]",
            "url": "https://example.com"
        }
    ],
    "invocationImages": [
        {
            "imageType": "docker",
            "image": "technosophos/helloworld:0.1.0",
            "digest": "sha256:aaaaaaa..."
        }
    ],
    "images": [
        {
            "image": "technosophos/microservice:1.2.3",
            "description": "my microservice",
            "digest": "sha256:aaaaaaaaaaaa...",
            "uri": "urn:image1uri",
            "refs": [
                {
                    "path": "image1path",
                    "field": "image.1.field"
                }
            ]
        }
    ],
    "parameters": {
        "backend_port" : {
            "type" : "int",
            "defaultValue": 80,
            "minValue": 10,
            "maxValue": 10240,
            "metadata": {
               "description": "The port that the back-end will listen on"
            }
        }
    },
    "credentials": {
        "kubeconfig": {
            "path": "/home/.kube/config",
        },
        "image_token": {
            "env": "AZ_IMAGE_TOKEN",
        },
        "hostkey": {
            "path": "/etc/hostkey.txt",
            "env": "HOST_KEY"
        }
    }
}

Этот блок описывает параметры пакета с приложением и предоставляет информацию о том, где «искать» устанавливаемые образы (формат должен быть docker или oci). Дополнительно в определении указываются размеры образа в байтах, платформа, на которой он будет работать, а также архитектура и операционная система.

А вот так описывается непосредственно сам образ:

"invocationImages": [
    {
        "imageType": "docker",
        "image": "technosophos/helloworld:0.1.0",
        "digest": "sha256:aca460afa270d4c527981ef9ca4989346c56cf9b20217dcea37df1ece8120685"
    }
]

Его задача — установить необходимые для работы компоненты. Этими компонентами могут быть контейнеры, функции, виртуальные машины, а также сервисные фреймворки.

Разработчики из Microsoft подготовили отдельное видео, в котором рассказали, как работать со стандартом и привели несколько примеров на реальном коде.

Что думает ИТ-сообщество

CNAB не единственное решение для управления жизненным циклом приложений в облачных средах. Например, для того же Kubernetes есть менеджер Сrossplane и менеджер пакетов Helm. Однако CNAB — это первое решение, которые охватывает сразу несколько популярных инструментов и не зависит от платформы. К слову, CNAB также может работать с Helm: на GitHub даже есть соответствующий пример.

Из-за подобной универсальности ИТ-сообщество встретило появление новой спецификации с энтузиазмом. Один из основателей Kubernetes — Брендан Бернс (Brendan Burns) — отметил, что установка распределённых приложений с помощью CNAB напоминает установку приложения с обыкновенной флешки. По его словам, это так же легко.

Но не все уверены в успехе нового решения. Некоторых пользователей беспокоит, что CNAB ждет судьба других пакетных менеджеров, которые из-за отсутствия операторов (как в Kubernetes) были преданы забвению. Чтобы развеять сомнения и обсудить все возможное функции, к тематическому треду на Hacker News присоединился один из создателей решения. Он отвечал на все вопросы резидентов площадки и выслушивал предложения по разработке.

Пока что CNAB находится в активной стадии девелопмента. И Microsoft, и Docker приглашают всех разработчиков присоединиться к ним, чтобы финализировать спецификацию и выпустить её в продакшн. Пара ИТ-гигантов намерена сделать новый инструмент отраслевым стандартом. При этом представители обеих компаний надеются, что со временем Cloud Native Application Bundle станет развиваться самостоятельно, независимо от её создателей.

---

Посты из нашего корпоративного блога:

• «Как дела у VMware»: обзор новых решений
• Бессерверные вычисления в облаке – тренд современности или необходимость?
• Почему корпоративные заказчики используют виртуальные машины, а не контейнеры

Посты из нашего Telegram-канала:

• ИТ-архитектура будущего — кто и как к ней готовится
• Блокчейн в работе облачного провайдера — 3 сферы применения