Подготовка технических ресурсов контейнера Azure для приложения Kubernetes

В этой статье содержатся технические ресурсы и рекомендации, которые помогут вам создать предложение контейнера в Azure Marketplace для приложения Kubernetes.

Для полного примера технических ресурсов, необходимых для предложения контейнера на основе приложений Kubernetes, см. образцы предложений контейнеров для Kubernetes в Azure Marketplace.

Основные технические знания

Проектирование, сборка и тестирование используемых ресурсов занимают время и требуют технических знаний не только о платформе Azure, но и о технологиях, используемых для создания предложения.

Ваша команда разработчиков должна не только хорошо разбираться во всем, что касается вашего решения, но и обладать знаниями о технологиях Майкрософт. В частности, вашим специалистам потребуется следующее:

• базовое представление о службах Azure;
• умение разработать приложения Azure;
• опыт работы с Azure Resource Manager;
• Базовые знания о работе с форматом JSON.
• Рабочие знания о Хелме
• Практическое знание в области createUiDefinition
• Рабочие знания шаблонов Azure Resource Manager (ARM)

Предварительные требования

• Ваше приложение должно быть основано на Helm chart.

• Диаграмма Helm не должна содержать .tgz архивные файлы; все файлы должны быть распакованы.

• Если у вас несколько чартов, можно включать другие чарты Helm как субчарты, помимо основного чарта.

• Все ссылки на изображения и сведения о дайджесте должны быть включены в диаграмму. Никакие другие диаграммы или изображения не могут быть скачаны во время выполнения.

• У вас должен быть активный клиент публикации или доступ к клиенту публикации и учетной записи Центра партнеров.

• Вы должны были создать реестр контейнеров Azure (ACR), который принадлежит активному арендатору публикации, указанному выше. Вы загрузите туда пакет облачных нативных приложений (CNAB). Дополнительные сведения см. в статье "Создание Реестр контейнеров Azure".

• Установите последнюю версию Azure CLI.

• Приложение должно быть развернуто в среде Linux.

• Образы должны быть свободными от уязвимостей. Инструкции по указанию требований к сканированию уязвимостей см. в разделе "Устранение неполадок с сертификацией контейнеров". Дополнительные сведения о проверке уязвимостей см. в статье об оценках уязвимостей для Azure с помощью Управление уязвимостями Microsoft Defender.

• Если средство упаковки запущено вручную, Docker необходимо установить на локальном компьютере. Дополнительные сведения см. в разделе, посвященном серверной части WSL 2, в документации Docker для Windows или Linux. Это поддерживается только на компьютерах Linux или Windows AMD64.

Ограничения

• Платформа Container Marketplace поддерживает только образы AMD64 для систем на базе Linux.
• Предложение Container Marketplace поддерживает развертывание на управляемом AKS и Kubernetes с поддержкой Arc. Одно предложение может быть направлено только на один тип кластера: либо управляемый AKS, либо Kubernetes с поддержкой Arc.
• Предложения для кластеров Kubernetes с поддержкой Arc поддерживают только предварительно определенные модели выставления счетов. Дополнительные сведения о моделях выставления счетов см. в разделе "Планирование предложения контейнеров в Azure".
• Отдельные контейнеры не поддерживаются.
• Связанные шаблоны Azure Resource Manager не поддерживаются.

Обзор процесса публикации

Первым шагом для публикации предложения контейнера на основе приложений Kubernetes в Azure Marketplace является упаковка приложения в виде пакета облачных собственных приложений (CNAB). CNAB, состоящий из артефактов вашего приложения, сначала публикуется в частный Реестр контейнеров Azure (ACR), а затем отправляется в публичный ACR Microsoft и используется в качестве единственного артефакта, на который вы ссылаетесь в Центре партнеров.

Оттуда выполняется сканирование уязвимостей, чтобы обеспечить безопасность изображений. Наконец, приложение Kubernetes регистрируется в качестве типа расширения для кластера Служба Azure Kubernetes (AKS).

После публикации предложения ваше приложение использует функцию расширения кластеров AKS для управления жизненным циклом приложения в кластере AKS.

Предоставьте доступ к вашему реестру контейнеров Azure

В процессе публикации корпорация Майкрософт полностью копирует ваш CNAB из вашего ACR в специальный ACR от Azure Marketplace, принадлежащий корпорации Майкрософт. Образы передаются в общедоступный реестр, доступный для всех. На этом шаге требуется предоставить корпорации Майкрософт доступ к реестру. ACR должен находиться в том же клиенте Microsoft Entra, который связан с учетной записью Центра партнеров.

Майкрософт имеет приложение собственной разработки, ответственное за обработку этого процесса с помощью id32597670-3e15-4def-8851-614ff48c1efa. Чтобы начать, создайте учетную запись службы, основанную на приложении.

az login

az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa 

az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa

az acr show --name <registry-name> --query "id" --output tsv

...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...

az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull

az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait

az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>

Connect-AzAccount

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App" 

New-AzADServicePrincipal -ApplicationId 32597670-3e15-4def-8851-614ff48c1efa

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App"

Select-AzSubscription -SubscriptionId <subscriptionId>
Get-AzContainerRegistry -ResourceGroupName <resource-group> -Name <registry-name>

...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...

New-AzRoleAssignment -ObjectId <sp-id> -Role acrpull -Scope <registry-id>

Connect-AzAccount
Select-AzSubscription -SubscriptionId <subscription-id>
Register-AzResourceProvider -ProviderNamespace Microsoft.PartnerCenterIngestion

Get-AzResourceProvider -ProviderNamespace Microsoft.PartnerCenterIngestion

Соберите артефакты, чтобы соответствовать требованиям к формату пакета

Каждый CNAB состоит из следующих артефактов:

• Диаграмма Helm
• CreateUiDefinition
• Шаблон ARM
• Файл манифеста

Обновление диаграммы Helm

Убедитесь, что диаграмма Helm соответствует следующим правилам:

• Все имена изображений и ссылки параметризируются и представлены в values.yaml виде ссылок global.azure.images. Обновите файл шаблона диаграммы Helm deployment.yaml, чтобы указать на эти изображения. Это гарантирует, что блок изображения можно обновить, чтобы ссылаться на образы ACR в Azure Marketplace.

• Если у вас несколько чартов, можно включать другие чарты Helm как субчарты, помимо основного чарта. Все зависимые ссылки на изображения helm-чартов потребуют обновления и должны указывать на изображения, включенные в основной чарт values.yaml.

• При ссылке на изображения можно использовать теги или дайджесты. Однако важно отметить, что образы заново перенаправляются внутри системы, чтобы указывать на принадлежащий Microsoft Реестр контейнеров Azure (ACR). При обновлении тега новая версия CNAB должна быть отправлена в Azure Marketplace. Это нужно для того, чтобы изменения были отражены в рабочих процессах клиентов.

  

Доступные модели выставления счетов

Для всех доступных моделей выставления счетов смотрите параметры лицензирования для приложений Azure Kubernetes.

Внесите изменения на основе вашей модели выставления счетов.

После просмотра доступных моделей выставления счетов выберите один подходящий для вашего варианта использования и выполните следующие действия.

Выполните следующие действия, чтобы добавить идентификатор в модели выставления счетов: Для каждого ядра, Для каждого модуля, Для каждого узла.

• Добавьте метку идентификатора выставления счетов azure-extensions-usage-release-identifier в спецификацию Pod в ваших yaml-файлах нагрузки.

  • Если рабочая нагрузка указана как спецификации Deployments, ReplicaSets, StatefulSets или DaemonSets, добавьте эту метку в .spec.template.metadata.labels.

  • Если рабочая нагрузка указана в спецификациях Pod, добавьте эту метку под .metadata.labels.

    

    

    

    

• Для модели выставления счетов perCore укажите CPU Request, включив поле resources:requests в манифест ресурса контейнера. Этот шаг необходим только для модели выставления счетов perCore.

  Снимок экрана запросов на ресурсы процессора в файле pods.yaml. Содержимое похоже на образец файла модели выставления счета за ядро, который приведен в этой статье.

Во время развертывания функция расширений кластера заменяет значение идентификатора выставления счетов именем экземпляра расширения.

Примеры, настроенные для развертывания приложения для голосования Azure, см. в следующих статьях:

• Пример файла развертывания.
• Пример файла значений.

Для модели выставления счетов настраиваемых счетчиков добавьте поля, перечисленные ниже в файле helm template's values.yaml.

• clientId необходимо добавить в global.azure.identity
• Ключ planId следует добавить в global.azure.marketplace. идентификатор плана
• resourceId следует добавить в раздел global.azure.extension.resrouceId

Во время развертывания функция расширений кластера заменяет эти поля соответствующими значениями. Примеры см. в приложении Azure Vote, созданном на основе пользовательских счетчиков.

Проверка диаграммы Helm

Чтобы убедиться, что диаграмма Helm действительна, проверьте, можно ли установить ее в локальном кластере. Можно также использовать helm install --generate-name --dry-run --debug для обнаружения определенных ошибок создания шаблонов.

Создать и протестировать createUiDefinition

CreateUiDefinition — это JSON-файл, определяющий элементы пользовательского интерфейса для портал Azure при развертывании приложения. Дополнительные сведения см. в разделе:

• CreateUiDefinition.json для Azure

• или см. пример определения пользовательского интерфейса, который запрашивает входные данные для нового или существующего выбора кластера и передает параметры в приложение.

После создания файла createUiDefinition.json для приложения необходимо протестировать взаимодействие с пользователем. Чтобы упростить тестирование, скопируйте содержимое файла в среду песочницы. Песочница отображает ваш пользовательский интерфейс в текущем полноэкранном режиме портала. Песочница — это рекомендуемый способ предварительного просмотра пользовательского интерфейса.

Создание шаблона Azure Resource Manager (ARM)

Шаблон ARM определяет ресурсы Azure для развертывания. По умолчанию вы развернете ресурс расширения кластера для приложения Azure Marketplace. При необходимости можно развернуть кластер AKS.

В настоящее время мы разрешаем только следующие типы ресурсов:

• Microsoft.ContainerService/managedClusters
• Microsoft.KubernetesConfiguration/extensions

Например, см. этот пример шаблона ARM, предназначенный для получения результатов из примера определения пользовательского интерфейса, связанного ранее, и передачи параметров в приложение.

Поток параметров пользователя

Важно понять, как параметры пользователя проходят через объекты, которые вы создаете и упаковываете. В примере приложения для голосования Azure параметры изначально определяются при создании пользовательского интерфейса с помощью файла createUiDefinition.json:

Параметры экспортируются с помощью outputs раздела:

Снимок экрана примера createUiDefinition, упомянутого в этой статье. Отображаются выходные строки для заголовка приложения, 'value1' и 'value2'.

Оттуда значения передаются в шаблон Azure Resource Manager и распространяются на диаграмму Helm во время развертывания:

Наконец, значения передаются в диаграмму Helm через values.yaml, как показано.

Создание файла манифеста

Манифест пакета — это yaml-файл, описывающий пакет и его содержимое, и сообщает средству упаковки, где находить зависимые артефакты.

Поля, используемые в манифесте, приведены следующим образом:

Для примера, сконфигурированного для приложения для голосования, см. следующий пример файла манифеста.

Структура приложения

Поместите файл createUiDefinition, шаблон ARM и файл манифеста рядом с диаграммой Helm приложения.

Для примера правильно структурированного каталога см. пример Azure Vote.

Для примера приложения для голосования, поддерживающего кластеры Kubernetes с поддержкой Azure Arc, см. пример только для ConnectedCluster .

Дополнительные сведения о том, как настроить кластер Kubernetes с поддержкой Azure Arc для проверки приложения, см. в разделе Краткое руководство: Подключение существующего кластера Kubernetes к Azure Arc.

Используйте средство упаковки контейнеров

После добавления всех необходимых артефактов запустите средство container-package-app упаковки для проверки артефактов, сборки пакета и отправки пакета в Реестр контейнеров Azure.

Так как CNAB — это новый формат, и к нему нужно привыкнуть, мы создали образ Docker для container-package-app со стартовой средой и инструментами, необходимыми для успешного запуска средства упаковки.

У вас есть два варианта использования средства упаковки. Его можно использовать вручную или интегрировать в конвейер развертывания.

Запуск средства упаковки вручную

Последнюю версию средства упаковки можно извлечь из mcr.microsoft.com/container-package-app:latest.

Следующая команда Docker извлекает новейший образ инструмента для упаковки, а также подключает каталог.

docker pull mcr.microsoft.com/container-package-app:latest

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest 

export REGISTRY_NAME=<registry-name>

az login 

az acr login -n $REGISTRY_NAME 

cd /data/<path-to-content>

docker login <yourACRname.azurecr.io>

docker pull mcr.microsoft.com/container-package-app:latest

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v d:/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest 

Затем выполните cpa verify, чтобы просмотреть артефакты и проверить их поочередно, устраняя любые сбои. Запуститеcpa buildbundle, когда вы будете готовы упаковать и отправить CNAB в Реестр контейнеров Azure. Команда cpa buildbundle запускает процесс проверки, создает пакет и отправляет пакет в Реестр контейнеров Azure.

cpa verify

cpa buildbundle 

Интеграция с Azure Pipeline

Пример интеграции container-package-app с Azure Pipeline см. в примере Azure Pipeline.

Пример интеграции CNAB в Github Actions см. в примере действия Github

Устранение неполадок

• Справка по устранению неполадок упаковки
• Устранение неполадок с публикацией

Связанный контент

• Создайте предложение Kubernetes