Подготовка технических ресурсов контейнера Azure для приложения Kubernetes
В этой статье содержатся технические ресурсы и рекомендации, которые помогут вам создать предложение контейнера в Azure Marketplace для приложения Kubernetes.
Полный пример технических ресурсов, необходимых для предложения контейнера на основе приложений Kubernetes, см . в примерах предложений контейнеров Azure Marketplace для Kubernetes.
Основные технические знания
Проектирование, сборка и тестирование используемых ресурсов занимают время и требуют технических знаний не только о платформе Azure, но и о технологиях, используемых для создания предложения.
Ваша команда разработчиков должна не только хорошо разбираться во всем, что касается вашего решения, но и обладать знаниями о технологиях Майкрософт. В частности, вашим специалистам потребуется следующее:
- базовое представление о службах Azure;
- умение разработать приложения Azure;
- опыт работы с Azure Resource Manager;
- с форматом JSON.
- Рабочие знания о Хелме
- Рабочие знания о createUiDefinition
- Рабочие знания шаблонов Azure Resource Manager (ARM)
Необходимые компоненты
Приложение должно быть основано на диаграмме Helm.
Если у вас несколько диаграмм, можно включить другие гистограммы в качестве подзарядок в сторону от основной диаграммы helm.
Все ссылки на изображения и сведения о дайджесте должны быть включены в диаграмму. Никакие другие диаграммы или изображения не могут быть скачаны во время выполнения.
У вас должен быть активный клиент публикации или доступ к клиенту публикации и учетной записи Центра партнеров.
Необходимо создать Реестр контейнеров Azure (ACR), принадлежащую активному клиенту публикации выше. Вы отправите в него пакет облачных собственных приложений (CNAB). Дополнительные сведения см. в статье "Создание Реестр контейнеров Azure".
Установите последнюю версию Azure CLI.
Приложение должно быть развернуто в среде Linux.
Образы должны быть свободными от уязвимостей. Дополнительные сведения о проверке уязвимостей см. в статье об оценках уязвимостей для Azure с помощью Управление уязвимостями Microsoft Defender.
Если средство упаковки запущено вручную, Docker необходимо установить локальный компьютер. Дополнительные сведения см. в разделе серверной части WSL 2 в документации По Docker для Windows или Linux. Это поддерживается только на компьютерах Linux или Windows AMD64.
Ограничения
- Контейнер Marketplace поддерживает только образы AMD64 на платформе Linux.
- Только управляемые AKS.
- Отдельные контейнеры не поддерживаются.
- Связанные шаблоны Azure Resource Manager не поддерживаются.
Обзор процесса публикации
Первым шагом для публикации предложения контейнера на основе приложений Kubernetes в Azure Marketplace является упаковка приложения в виде пакета облачных собственных приложений (CNAB). CNAB, состоящий из артефактов приложения, сначала публикуется в частных Реестр контейнеров Azure (ACR), а затем отправляется в общедоступный ACR корпорации Майкрософт и используется в качестве единственного артефакта, на который вы ссылаетесь в Центре партнеров.
Оттуда выполняется сканирование уязвимостей, чтобы обеспечить безопасность изображений. Наконец, приложение Kubernetes регистрируется в качестве типа расширения для кластера Служба Azure Kubernetes (AKS).
После публикации предложения приложение использует расширения кластера для функции AKS для управления жизненным циклом приложения в кластере AKS .
Предоставление доступа к Реестр контейнеров Azure
В рамках процесса публикации корпорация Майкрософт глубоко копирует CNAB из ACR в ACR, принадлежащей Корпорации Майкрософт, в azure Marketplace, относящейся к ACR. Образы передаются в общедоступный реестр, доступный для всех. На этом шаге требуется предоставить корпорации Майкрософт доступ к реестру. ACR должен находиться в том же клиенте Microsoft Entra, который связан с учетной записью Центра партнеров.
Корпорация Майкрософт имеет первое приложение, ответственное за обработку этого процесса с помощью id 32597670-3e15-4def-8851-614ff48c1efa. Чтобы начать, создайте субъект-службу на основе приложения:
Примечание.
Если у вашей учетной записи нет разрешения на создание субъекта-службы, возвращает сообщение об ошибке, az ad sp create содержащее "Недостаточно привилегий для завершения операции". Чтобы создать субъект-службу, обратитесь к администратору Microsoft Entra.
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",
...
Затем создайте назначение ролей, чтобы предоставить субъекту-службе возможность извлекать из реестра значения, полученные ранее:
Чтобы назначать роли Azure необходимо наличие:
Microsoft.Authorization/roleAssignments/writeтаких привилегий, как Администратор доступа пользователей или Владелец
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
Наконец, зарегистрируйте Microsoft.PartnerCenterIngestion поставщика ресурсов в той же подписке, которая использовалась для создания Реестр контейнеров Azure:
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
Отслеживайте регистрацию и убедитесь, что она завершена, прежде чем продолжить:
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
Сбор артефактов в соответствии с требованиями к формату пакета
Каждый CNAB состоит из следующих артефактов:
- Диаграмма Helm
- CreateUiDefinition
- Шаблон ARM
- Файл манифеста
Обновление диаграммы Helm
Убедитесь, что диаграмма Helm соответствует следующим правилам:
Все имена изображений и ссылки параметризируются и представлены в
values.yamlвиде ссылок global.azure.images. Обновите файлdeployment.yamlшаблона диаграммы Helm, чтобы указать эти изображения. Это гарантирует, что блок изображения можно обновить, чтобы ссылаться на образы ACR в Azure Marketplace.
Если у вас несколько диаграмм, можно включить другие гистограммы в качестве подзарядок в сторону от основной диаграммы helm. Затем обновите все ссылки на зависимые изображения, чтобы указать изображения, включенные в основную диаграмму
values.yaml.При ссылке на изображения можно использовать теги или дайджесты. Однако важно отметить, что образы внутренне переназначаются, чтобы указать на Реестр контейнеров Azure корпорации Майкрософт (ACR). При обновлении тега новая версия CNAB должна быть отправлена в Azure Marketplace. Это позволяет отразить изменения в развертываниях клиентов.
Доступные модели выставления счетов
Для всех доступных моделей выставления счетов см . параметры лицензирования для приложений Azure Kubernetes.
Обновление на основе модели выставления счетов
После просмотра доступных моделей выставления счетов выберите один подходящий для вашего варианта использования и выполните следующие действия.
Выполните следующие действия, чтобы добавить идентификатор в модели выставления счетов для каждого узла для каждого модуля pod.
Добавьте метку
azure-extensions-usage-release-identifierидентификатора выставления счетов в спецификацию Pod в файлах yaml рабочей нагрузки .Если рабочая нагрузка указана в качестве развертываний или реплик или наборов состояний или спецификаций daemonsets, добавьте эту метку в метки .spec.template.metadata.labels.
Если рабочая нагрузка указана непосредственно в качестве спецификаций Pod, добавьте эту метку в метки .metadata.labels.
Для модели выставления счетов perCore укажите запрос ЦП, включив
resources:requestsполе в манифест ресурса контейнера. Этот шаг необходим только для модели выставления счетов perCore.
Во время развертывания функция расширений кластера заменяет значение идентификатора выставления счетов именем экземпляра расширения.
Примеры, настроенные для развертывания приложения для голосования Azure, см. в следующих статьях:
Для модели выставления счетов настраиваемых счетчиков добавьте поля, перечисленные ниже в файле helm template's values.yaml.
- clientId следует добавить в global.azure.identity
- Ключ planId следует добавить в global.azure.marketplace. planId
- resourceId следует добавить в global.azure.extension.resrouceId
Во время развертывания функция расширений кластера заменяет эти поля соответствующими значениями. Примеры см. в приложении на основе пользовательских счетчиков голосов Azure.
Проверка диаграммы Helm
Чтобы убедиться, что диаграмма Helm действительна, проверьте, можно ли установить ее в локальном кластере. Можно также использовать helm install --generate-name --dry-run --debug для обнаружения определенных ошибок создания шаблонов.
Создание и проверка createUiDefinition
CreateUiDefinition — это JSON-файл, определяющий элементы пользовательского интерфейса для портал Azure при развертывании приложения. Дополнительные сведения см. в разделе:
или см. пример определения пользовательского интерфейса, который запрашивает входные данные для нового или существующего выбора кластера и передает параметры в приложение.
После создания файла createUiDefinition.json для приложения необходимо протестировать взаимодействие с пользователем. Чтобы упростить тестирование, скопируйте содержимое файла в среду песочницы. Песочница представляет пользовательский интерфейс в текущем интерфейсе полноэкранного портала. Песочница — это рекомендуемый способ предварительного просмотра пользовательского интерфейса.
Создание шаблона Azure Resource Manager (ARM)
Шаблон ARM определяет ресурсы Azure для развертывания. По умолчанию вы развернете ресурс расширения кластера для приложения Azure Marketplace. При необходимости можно развернуть кластер AKS.
В настоящее время мы разрешаем только следующие типы ресурсов:
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
Например, см. этот пример шаблона ARM, предназначенный для получения результатов из примера определения пользовательского интерфейса, связанного ранее, и передачи параметров в приложение.
Поток параметров пользователя
Важно понять, как поток параметров пользователя выполняется во всех артефактах, которые вы создаете и упаковаете. В примере приложения для голосования Azure параметры изначально определяются при создании пользовательского интерфейса с помощью файла createUiDefinition.json:
Параметры экспортируются с помощью outputs раздела:
Оттуда значения передаются в шаблон Azure Resource Manager и распространяются на диаграмму Helm во время развертывания:
Наконец, значения передаются в диаграмму Helm, values.yaml как показано ниже.
Примечание.
В этом примере extensionResourceName также параметризован и передается ресурсу расширения кластера. Аналогичным образом можно параметризовать другие свойства расширения, например включить автоматическое обновление для дополнительных версий. Дополнительные сведения о свойствах расширения кластера см. в дополнительных параметрах.
Создание файла манифеста
Манифест пакета — это yaml-файл, описывающий пакет и его содержимое, и сообщает средству упаковки, где находить зависимые артефакты.
Поля, используемые в манифесте, приведены следующим образом:
| Имя. | Тип данных | Description |
|---|---|---|
| applicationName | Строка | Имя приложения |
| издатель | Строка | Имя издателя |
| описание | Строка | Краткое описание пакета |
| версия | Строка в #.#.# формате |
Строка версии, описывающая версию пакета приложения, может или не совпадать с версией двоичных файлов внутри. |
| helmChart | Строка | Локальный каталог, в котором можно найти диаграмму Helm относительно этого manifest.yaml |
| clusterARMTemplate | Строка | Локальный путь, в котором можно найти шаблон ARM, описывающий кластер AKS, соответствующий требованиям в поле ограничений. |
| uiDefinition | Строка | Локальный путь, в котором можно найти JSON-файл, описывающий интерфейс создания портал Azure |
| registryServer | Строка | ACR, в котором должен быть отправлен окончательный пакет CNAB |
| extensionRegistrationParameters | Коллекция | Спецификация параметров регистрации расширения. Включите по крайней мере defaultScope и в качестве параметра. |
| defaultScope | Строка | Область по умолчанию для установки расширения. Допустимые значения: cluster или namespace. Если cluster задана область, для каждого кластера разрешено только один экземпляр расширения. Если namespace выбрана область, то для каждого пространства имен разрешено только один экземпляр. Так как кластер Kubernetes может иметь несколько пространств имен, может существовать несколько экземпляров расширения. |
| пространство имен | Строка | (Необязательно) Укажите пространство имен, в который устанавливается расширение. Это свойство является обязательным, если defaultScope задано значение cluster. Ограничения именования пространств имен см. в разделе "Пространства имен" и DNS. |
| supportedClusterTypes | Коллекция | (Необязательно) Укажите типы кластеров, поддерживаемые приложением. Допустимые типы — managedClusters, connectedClusters. ManagedClusters относится к кластерам Служба Azure Kubernetes (AKS). "connectedClusters" относится к кластерам Kubernetes с поддержкой Azure Arc. Если поддерживаетсяClusterTypes, все дистрибутивы managedClusters поддерживаются по умолчанию. Если предоставлена поддержкаClusterTypes, а указанный тип кластера верхнего уровня не указан, все дистрибутивы и версии Kubernetes для этого типа кластера рассматриваются как неподдерживаемые. Для каждого типа кластера укажите список одного или нескольких дистрибутивов со следующими свойствами: -распределение — distributionSupported — неподдерживаемыеVersions |
| distribution | List | Массив дистрибутивов, соответствующих типу кластера. Укажите имя конкретных дистрибутивов. Задайте для значения [All"] значение , чтобы указать, что поддерживаются все дистрибутивы. |
| distributionSupported | Логический | Логическое значение, представляющее, поддерживаются ли указанные дистрибутивы. Если значение false, предоставление неподдерживаемыхversions приводит к ошибке. |
| неподдерживаемыеVersions | List | Список версий для указанных дистрибутивов, неподдерживаемых. Поддерживаемые операторы: — "=" Указанная версия не поддерживается. Например, "=1.2.12" — ">" Все версии, превышающие указанную версию, не поддерживаются. Например, ">1.1.13" — "<" Все версии меньше указанной версии не поддерживаются. Например, "<1.3.14" - "..." Все версии в диапазоне не поддерживаются. Например, "1.1.2...1.1.15" (включает значение справа и исключает левое значение) |
Пример, настроенный для приложения для голосования, см. в следующем примере файла манифеста.
Структура приложения
Поместите файл createUiDefinition, шаблон ARM и файл манифеста рядом с диаграммой Helm приложения.
Пример правильно структурированного каталога см . в примере голосования Azure.
Пример приложения для голосования, поддерживающего кластеры Kubernetes с поддержкой Azure Arc, см . в примере только для ConnectedCluster.
Пример приложения для голосования, поддерживающего кластеры Служба Azure Kubernetes (AKS) и кластеры Kubernetes с поддержкой Azure Arc, см. в примере подключенного и управляемого кластера.
Дополнительные сведения о настройке кластера Kubernetes с поддержкой Azure Arc для проверки приложения см . в кратком руководстве по подключению существующего кластера Kubernetes к Azure Arc.
Использование средства упаковки контейнеров
После добавления всех необходимых артефактов запустите средство container-package-appупаковки.
Так как CNAB — это новый формат и кривая обучения, мы создали образ Docker для работы с начальной средой и инструментами, необходимыми для container-package-app успешного запуска средства упаковки.
У вас есть два варианта использования средства упаковки. Его можно использовать вручную или интегрировать в конвейер развертывания.
Запуск средства упаковки вручную
Последняя версия средства упаковки может быть извлечена.mcr.microsoft.com/container-package-app:latest
Следующая команда Docker извлекает последний образ средства упаковки, а также подключает каталог.
Предположим ~\<path-to-content> , что это каталог, содержащий содержимое для упаковки, следующая команда Docker подключается ~/<path-to-content> к /data контейнеру. Обязательно замените ~/<path-to-content> расположение собственного приложения.
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
Выполните следующие команды в оболочке container-package-app контейнера. Обязательно замените <registry-name> имя ACR:
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
Для проверки подлинности ACR существует два варианта. Один из вариантов используется, az login как показано ранее, а второй — через docker, выполнив команду docker login 'yourACRname'.azurecr.io. Введите имя пользователя и пароль (имя пользователя должно иметь имя ACR, а пароль — созданный ключ, предоставленный в портал Azure) и запустить.
docker login <yourACRname.azurecr.io>
Затем выполните cpa verify итерацию по артефактам и проверьте их по одному. Устраняйте все сбои и запуститеcpa buildbundle, когда вы будете готовы упаковать и отправить CNAB в Реестр контейнеров Azure. Команда cpa buildbundle также запускает процесс проверки перед сборкой
cpa verify
cpa buildbundle
Примечание.
Используйте cpa buildbundle --force только в том случае, если вы хотите перезаписать существующий тег. Если вы уже подключили этот CNAB к предложению Azure Marketplace, вместо этого увеличьте версию в файле манифеста.
Интеграция с Azure Pipeline
Пример интеграции container-package-app с Azure Pipeline см. в примере Azure Pipeline.