Preparar ativos técnicos de contêiner do Azure para um aplicativo Kubernetes

Este artigo fornece recursos técnicos e recomendações para ajudá-lo a criar uma oferta de contêiner no Azure Marketplace para um aplicativo Kubernetes.

Para obter um exemplo abrangente dos ativos técnicos necessários para uma oferta de contêiner baseada em aplicativo Kubernetes, consulte Exemplos de oferta de contêiner do Azure Marketplace para Kubernetes.

Conhecimento técnico fundamental

Projetar, criar e testar esses ativos leva tempo e requer conhecimento técnico da plataforma Azure e das tecnologias usadas para criar a oferta.

Além do domínio da solução, sua equipe de engenharia deve ter conhecimento sobre as seguintes tecnologias da Microsoft:

• Compreensão básica dos Serviços do Azure
• Como projetar e arquitetar aplicativos do Azure
• Conhecimento prático do Azure Resource Manager
• Conhecimento prático de JSON
• Conhecimento prático do Leme
• Conhecimento prático de createUiDefinition
• Conhecimento prático dos modelos do Azure Resource Manager (ARM)

Pré-requisitos

• Seu aplicativo deve ser baseado em gráfico Helm.

• Se você tiver vários gráficos, poderá incluir outros gráficos de leme como subgráficos, além do gráfico de leme principal.

• Todas as referências de imagem e detalhes do resumo devem ser incluídos no gráfico. Nenhum outro gráfico ou imagem pode ser baixado em tempo de execução.

• Você deve ter um locatário de publicação ativo ou acesso a um locatário de publicação e conta do Partner Center.

• Você deve ter criado um Registro de Contêiner do Azure (ACR) que pertença ao locatário de publicação ativo acima. Você carregará o Cloud Native Application Bundle (CNAB) para isso. Para obter mais informações, consulte Criar um Registro de Contêiner do Azure.

• Instalar a versão mais recente da CLI do Azure.

• O aplicativo deve ser implantável no ambiente Linux.

• As imagens devem estar livres de vulnerabilidades. Para saber mais sobre a verificação de vulnerabilidades, consulte Avaliações de vulnerabilidade do Azure com o Microsoft Defender Vulnerability Management.

• Se estiver executando a ferramenta de empacotamento manualmente, o Docker precisará ser instalado em uma máquina local. Para obter mais informações, consulte a seção de back-end do WSL 2 na documentação do Docker para Windows ou Linux. Isso só é suportado em máquinas Linux/Windows AMD64.

Limitações

• O Container Marketplace suporta apenas imagens AMD64 baseadas em plataforma Linux.
• Apenas AKS gerenciado.
• Não há suporte para contêineres individuais.
• Não há suporte para modelos vinculados do Azure Resource Manager.

Visão geral da publicação

A primeira etapa para publicar sua oferta de contêiner baseado em aplicativo Kubernetes no Azure Marketplace é empacotar seu aplicativo como um pacote de aplicativos nativo da nuvem (CNAB). O CNAB, composto pelos artefatos do seu aplicativo, é publicado primeiro no seu Registro de Contêiner do Azure (ACR) privado e, posteriormente, enviado por push para um ACR público de propriedade da Microsoft, e é usado como o único artefato que você referencia no Partner Center.

A partir daí, a verificação de vulnerabilidades é realizada para garantir que as imagens estejam seguras. Finalmente, o aplicativo Kubernetes é registrado como um tipo de extensão para um cluster do Serviço Kubernetes do Azure (AKS).

Depois que sua oferta é publicada, seu aplicativo aproveita as extensões de cluster para o recurso AKS para gerenciar o ciclo de vida do aplicativo dentro de um cluster AKS.

Conceder acesso ao seu Registro de Contêiner do Azure

Como parte do processo de publicação, a Microsoft copia profundamente o seu CNAB do seu ACR para um ACR específico do Azure Marketplace de propriedade da Microsoft. As imagens são carregadas num registo público acessível a todos. Esta etapa requer que você conceda à Microsoft acesso ao seu registro. O ACR deve estar no mesmo locatário do Microsoft Entra vinculado à sua conta do Partner Center.

A Microsoft tem um aplicativo primário responsável por lidar com esse processo com um id de 32597670-3e15-4def-8851-614ff48c1efa. Para começar, crie uma entidade de serviço com base no aplicativo:

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/ffffffff-ff6d-ff22-77ff-ffffffffffff/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/ffffffff-ff6d-ff22-77ff-ffffffffffff/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

Reúna artefatos para atender aos requisitos de formato de pacote

Cada CNAB é composto pelos seguintes artefactos:

• Gráfico Helm
• CreateUiDefinition
• Modelo do ARM
• Arquivo de manifesto

Atualizar o gráfico de leme

Verifique se o gráfico de leme está de acordo com as seguintes regras:

• Todos os nomes e referências de imagem são parametrizados e representados como values.yaml referências global.azure.images. Atualize seu arquivo de deployment.yaml modelo de gráfico Helm para apontar essas imagens. Isso garante que o bloco de imagens possa ser atualizado para fazer referência às imagens ACR do Azure Marketplace.

• Se você tiver vários gráficos, poderá incluir outros gráficos de leme como subgráficos, além do gráfico de leme principal. Em seguida, atualize cada uma das referências de imagem dependentes para apontar para as imagens incluídas no gráfico principal.values.yaml

• Ao fazer referência a imagens, você pode utilizar tags ou resumos. No entanto, é importante observar que as imagens são marcadas internamente para apontar para o Azure Container Registry (ACR) de propriedade da Microsoft. Quando você atualiza uma tag, uma nova versão do CNAB deve ser enviada ao Azure Marketplace. Isso é para que as alterações possam ser refletidas nas implantações do cliente.

  

Modelos de faturação disponíveis

Para todos os modelos de cobrança disponíveis, consulte as opções de licenciamento para Aplicativos Kubernetes do Azure.

Faça atualizações com base no seu modelo de faturação

Depois de analisar os modelos de faturamento disponíveis, selecione um apropriado para seu caso de uso e conclua as seguintes etapas:

Conclua as seguintes etapas para adicionar identificador nos modelos de faturamento Por núcleo, Por pod e Por nós:

• Adicione um rótulo azure-extensions-usage-release-identifier identificador de faturamento à especificação do Pod em seus arquivos yaml de carga de trabalho .

  • Se a carga de trabalho for especificada como Deployments ou Replicasets ou Statefulsets ou Daemonsets specs, adicione esse rótulo em .spec.template.metadata.labels.

  • Se a carga de trabalho for especificada diretamente como especificações do Pod, adicione esse rótulo em .metadata.labels.

    

    

    

    

• Para o modelo de faturamento por Core, especifique Solicitação de CPU incluindo o resources:requests campo no manifesto do recurso de contêiner. Esta etapa só é necessária para o modelo de faturamento por Core.

  

No momento da implantação, o recurso de extensões de cluster substitui o valor do identificador de cobrança pelo nome da instância de extensão.

Para obter exemplos configurados para implantar o Aplicativo de Votação do Azure, consulte o seguinte:

• Exemplo de arquivo de implantação.
• Exemplo de arquivo de valores.

Para o modelo de faturamento de medidores personalizados, adicione os campos listados abaixo no arquivo values.yaml do seu modelo de leme

• clientId deve ser adicionado em global.azure.identity
• A chave planId deve ser adicionada em global.azure.marketplace. planId
• resourceId deve ser adicionado em global.azure.extension.resrouceId

No momento da implantação, o recurso de extensões de cluster substitui esses campos pelos valores apropriados. Para obter exemplos, consulte o aplicativo baseado em Medidores Personalizados de Votação do Azure.

Criar arquivo de parâmetro de teste

Um arquivo de parâmetro de teste é um JSON usado em conjunto com um modelo ARM para implantar um recurso no Azure. Para aplicativos ou extensões que podem ser implantados em clusters gerenciados (AKS), exigimos que o arquivo de parâmetros seja especificado para validação de implantação. O arquivo de parâmetro de teste deve incluir valores que permitam uma implantação de teste bem-sucedida.

Aqui está um arquivo de parâmetro de teste de exemplo:

Depois que o arquivo de parâmetro de teste for criado, adicione-o ao seu arquivo de manifesto:

Validar o gráfico de leme

Para garantir que o gráfico Helm seja válido, teste se ele pode ser instalado em um cluster local. Você também pode usar helm install --generate-name --dry-run --debug para detetar determinados erros de geração de modelo.

Criar e testar o createUiDefinition

Um createUiDefinition é um arquivo JSON que define os elementos da interface do usuário para o portal do Azure ao implantar o aplicativo. Para obter mais informações, consulte:

• CreateUiDefinition.json para o Azure
• ou veja um exemplo de uma definição de interface do usuário que solicita dados de entrada para uma opção de cluster nova ou existente e passa parâmetros para seu aplicativo.

Depois de criar o arquivo de createUiDefinition.json para seu aplicativo, você precisa testar a experiência do usuário. Para simplificar os testes, copie o conteúdo do arquivo para o ambiente de área restrita. A sandbox apresenta sua interface de usuário na experiência atual do portal em tela cheia. A área restrita é a maneira recomendada de visualizar a interface do usuário.

Criar o modelo do Azure Resource Manager (ARM)

Um modelo ARM define os recursos do Azure a serem implantados. Por padrão, você implantará um recurso de extensão de cluster para o aplicativo Azure Marketplace. Opcionalmente, você pode optar por implantar um cluster AKS.

Atualmente, permitimos apenas os seguintes tipos de recursos:

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

Por exemplo, consulte este modelo ARM de exemplo projetado para obter resultados da definição de interface do usuário de exemplo vinculada anteriormente e passar parâmetros para seu aplicativo.

Fluxo de parâmetros do usuário

É importante entender como os parâmetros do usuário fluem pelos artefatos que você está criando e empacotando. No exemplo do Aplicativo de Votação do Azure, os parâmetros são inicialmente definidos ao criar a interface do usuário por meio de um arquivo createUiDefinition.json:

Os parâmetros são exportados através da outputs seção:

A partir daí, os valores são passados para o modelo do Azure Resource Manager e propagados para o gráfico Helm durante a implantação:

Finalmente, os valores são passados para o gráfico Helm através como values.yaml mostrado.

Criar o arquivo de manifesto

O manifesto do pacote é um arquivo yaml que descreve o pacote e seu conteúdo e informa à ferramenta de empacotamento onde localizar os artefatos dependentes.

Os campos utilizados no manifesto são os seguintes:

Para obter um exemplo configurado para o aplicativo de votação, consulte o exemplo de arquivo de manifesto a seguir.

Estruture a sua aplicação

Coloque o createUiDefinition, o modelo ARM e o arquivo de manifesto ao lado do gráfico Helm do aplicativo.

Para obter um exemplo de um diretório estruturado corretamente, consulte Exemplo de voto do Azure.

Para obter um exemplo do aplicativo de votação que dá suporte a clusters Kubernetes habilitados para Azure Arc, consulte Exemplo somente ConnectedCluster.

Para obter um exemplo do aplicativo de votação que dá suporte a clusters do Serviço Kubernetes do Azure (AKS) e clusters Kubernetes habilitados para Azure Arc, consulte Exemplo de cluster conectado e gerenciado.

Para obter mais informações sobre como configurar um cluster Kubernetes habilitado para Azure Arc para validar o aplicativo, consulte Guia de início rápido: conectar um cluster Kubernetes existente ao Azure Arc.

Use a ferramenta de embalagem de recipiente

Depois de adicionar todos os artefatos necessários, execute a ferramenta container-package-appde empacotamento .

Como os CNABs são um novo formato e têm uma curva de aprendizado, criamos uma imagem do Docker com container-package-app ambiente de inicialização e ferramentas necessárias para executar com sucesso a ferramenta de empacotamento.

Você tem duas opções para usar a ferramenta de empacotamento. Você pode usá-lo manualmente ou integrá-lo a um pipeline de implantação.

Executar manualmente a ferramenta de empacotamento

A imagem mais recente da ferramenta de embalagem pode ser extraída de mcr.microsoft.com/container-package-app:latest.

O comando Docker a seguir extrai a imagem mais recente da ferramenta de empacotamento e também monta um diretório.

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 

Em seguida, execute cpa verify para iterar os artefatos e validá-los um a um. Resolva quaisquer falhas e execute cpa buildbundle quando estiver pronto para empacotar e carregar o CNAB no seu Registro de Contêiner do Azure. O cpa buildbundle comando também executa o processo de verificação antes da criação

cpa verify

cpa buildbundle 

Integrar em um Pipeline do Azure

Para obter um exemplo de como integrar container-package-app em um Pipeline do Azure, consulte o exemplo do Pipeline do Azure

Resolução de Problemas

• Ajuda para solução de problemas de empacotamento
• Publicação da Ajuda de Solução de Problemas

Conteúdos relacionados

• Crie sua oferta Kubernetes