Поделиться через


Пакеты приложений, ориентированных на облако

Совет

Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Cloud Native .NET apps for Azure eBook cover thumbnail.

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

Контейнеры Docker могут работать в Kubernetes с помощью диаграммы Helm для развертывания. Функции Azure можно выделить с помощью шаблонов Terraform. Наконец, виртуальные машины могут быть выделены с помощью Terraform, но созданы с помощью Ansible. Это большой спектр технологий, и не было способа упаковать их все вместе в разумный пакет. До настоящего момента.

Пакеты облачных собственных приложений (CNABs) являются совместными усилиями многих общинных компаний, таких как Microsoft, Docker и HashiCorp для разработки спецификации для упаковки распределенных приложений.

Усилия были объявлены в декабре 2018 года, поэтому есть еще справедливый бит работы, чтобы сделать, чтобы разоблачить усилия для большей общины. Однако существует уже открытая спецификация и эталонная реализация, известная как Даффл. Это средство, написанное в Go, — это совместная работа между Docker и Корпорацией Майкрософт.

CNAB может содержать различные виды технологий установки. Этот аспект позволяет использовать такие элементы, как Helm Chart, шаблоны Terraform и сборники схем Ansible в одном пакете. После создания пакеты являются автономными и переносимыми; их можно установить с USB-накопителя. Пакеты криптографически подписаны, чтобы убедиться, что они исходят из стороны, которой они утверждают.

Ядро CNAB называется файлом bundle.json. Этот файл определяет содержимое пакета, будь то Terraform или изображения или что-либо другое. Рис. 11-9 определяет CNAB, который вызывает некоторые Terraform. Обратите внимание, что на самом деле он определяет образ вызова, используемый для вызова Terraform. После упаковки файл Docker, расположенный в каталоге cnab , встроен в образ Docker, который будет включен в пакет. Установка Terraform в контейнере Docker в пакете означает, что пользователям не нужно устанавливать Terraform на компьютере, чтобы запустить объединение.

{
    "name": "terraform",
    "version": "0.1.0",
    "schemaVersion": "v1.0.0-WD",
    "parameters": {
        "backend": {
            "type": "boolean",
            "defaultValue": false,
            "destination": {
                "env": "TF_VAR_backend"
            }
        }
    },
    "invocationImages": [
        {
        "imageType": "docker",
        "image": "cnab/terraform:latest"
        }
    ],
    "credentials": {
        "tenant_id": {
            "env": "TF_VAR_tenant_id"
        },
        "client_id": {
            "env": "TF_VAR_client_id"
        },
        "client_secret": {
            "env": "TF_VAR_client_secret"
        },
        "subscription_id": {
            "env": "TF_VAR_subscription_id"
        },
        "ssh_authorized_key": {
            "env": "TF_VAR_ssh_authorized_key"
        }
    },
    "actions": {
        "status": {
            "modifies": true
        }
    }
}

Рис. 10-18 . Пример файла Terraform

Также bundle.json определяется набор параметров, передаваемых в Terraform. Параметризация пакета позволяет устанавливать в различных средах.

Формат CNAB также гибкий, что позволяет использовать его для любого облака. Его можно использовать даже для локальных решений, таких как OpenStack.

Решения DevOps

Есть так много великих инструментов в пространстве DevOps в эти дни, и еще более фантастические книги и документы о том, как добиться успеха. Любимая книга, чтобы приступить к путешествию DevOps является Phoenix Project, который следует за преобразованием вымышленной компании из NoOps в DevOps. Одна вещь заключается в том, что DevOps больше не является "хорошим" при развертывании сложных облачных собственных приложений. Это требование и должно быть запланировано и ресурсоемким в начале любого проекта.

Ссылки