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

Подсказка

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

Скачать в формате PDF

Миниатюра обложки электронной книги Azure с Cloud Native .NET приложениями.

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

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

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

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

CNABs могут содержать различные виды технологий установки. Этот аспект позволяет использовать такие элементы, как 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 — это Проект «Феникс», который описывает преобразование вымышленной компании из NoOps в DevOps. Одно можно сказать наверняка: DevOps больше не является просто «приятным дополнением» при развертывании сложных облачных нативных приложений. Это требование, и его следует запланировать и обеспечить ресурсами в начале любого проекта.

Ссылки

НазадДалее

  • Last updated on