Implantação contínua com recipientes personalizados em Serviço de Aplicações do Azure

Neste tutorial, configura a implementação contínua para uma imagem personalizada de um recipiente de repositórios Azure Container Registry geridos ou Docker Hub.

1. Ir para o Centro de Implantação

Na portal do Azure, navegue na página de gestão para a sua aplicação Serviço de Aplicações.

A partir do menu esquerdo, clique no Centro >de Implementação Definições.

2. Escolha a fonte de implantação

Escolha a fonte de implantação depende do seu cenário:

  • O registo do contentor configura o CI/CD entre o registo do contentor e Serviço de Aplicações.
  • A GitHub Actions opção é para si se mantiver o código fonte para a sua imagem de recipiente em GitHub. Desencadeado por novos compromissos com o seu repositório GitHub, a ação de implementação pode ser executada docker build e docker push diretamente para o registo do seu contentor, atualizando depois a sua aplicação de Serviço de Aplicações para executar a nova imagem. Para mais informações, consulte como o CI/CD funciona com GitHub Actions.
  • Para configurar o CI/CD com os Pipelines Azure, consulte implementar um recipiente de aplicações web Azure a partir de Pipelines Azure.

Nota

Para uma aplicação Docker Compose, selecione Registo de Contentores.

Se escolher GitHub Actions, cliqueemAutorize e siga as indicações de autorização. Se já tiver autorizado com GitHub antes, pode implementar a partir do repositório de um utilizador diferente clicando na Conta Change.

Assim que autorizar a sua conta Azure com GitHub, selecione a Organização, Repositório e Ramo para implementar.

2. Configurar as definições de registo

3. Configurar as definições de registo

Para implementar uma aplicação multi-contentores (Docker Compose), selecioneDoCkerCompose no Tipo de Recipiente.

Se não vir o dropdown do tipo de recipiente, volte para a Fonte e selecioneRegisto do Sistema.

Na fonte de registo, selecione onde está o seu registo de contentores. Se não for Azure Container Registry nem Docker Hub, selecioneRegisto dePrivate.

Nota

Se a sua aplicação multi-contentor (Docker Compose) utilizar mais do que uma imagem privada, certifique-se de que as imagens privadas estão no mesmo registo privado e acessíveis com as mesmas credenciais de utilizador. Se a sua aplicação multi-contentores utilizar apenas imagens públicas, selecioneDocker Hub, mesmo que algumas imagens não estejam em Docker Hub.

Siga os próximos passos selecionando o separador que corresponde à sua escolha.

O dropdown do Registo exibe os registos na mesma subscrição que a sua aplicação. Selecione o registo que deseja.

Nota

Selecione a Imagem e a Etiqueta para implementar. Se quiser, digite o comando de arranque no Ficheiro De Arranque.

Siga o passo seguinte dependendo do Tipo de Recipiente:

  • Para Docker Compose, selecione o registo para as suas imagens privadas. Cliqueno ficheiro ClickChoose para fazer o upload do seu ficheiro Docker Compose ou apenascolar o conteúdo do seu ficheiro Docker Compose para a Config.
  • Para um único recipiente, selecione a imagem e a etiqueta para implementar. Se quiser, digite o comando de arranque no Ficheiro De Arranque.

Serviço de Aplicações anexa a cadeia no Ficheiro de Arranqueaté ao fim do docker run comando (como o segmento) ao iniciar o [COMMAND] [ARG...] seu contentor.

3. Ativar o CI/CD

4. Ativar o CI/CD

Serviço de Aplicações apoia a integração ci/CD com Azure Container Registry e Docker Hub. Para o ativar, selecioneOn em implementação contínua.

Nota

Se selecionar GitHub Actions na Fonte, não obtém esta opção porque o CI/CD é manuseado por GitHub Actions diretamente. Em vez disso, vê uma secção de Configuração do Fluxo de Trabalho, onde pode clicar emficheiroPreview para inspecionar o ficheiro de fluxo de trabalho. O Azure compromete este ficheiro no repositório de origem GitHub selecionado para lidar com tarefas de construção e implementação. Para mais informações, consulte como o CI/CD funciona com GitHub Actions.

Ao ativar esta opção, Serviço de Aplicações adiciona um webhook ao seu repositório em Azure Container Registry ou Docker Hub. As suas publicações de repositório para este webhook sempre que a sua imagem selecionada for atualizada com docker push. O webhook faz com que a sua aplicação Serviço de Aplicações reinicie e corra docker pull para obter a imagem atualizada.

Para outros registos privados, pode publicar no webhook manualmente ou como um passo num pipeline CI/CD. No URL Webhook, clique no botão Copiar para obter o URL webhook.

Nota

O suporte para aplicações multi-contentores (Docker Compose) é limitado:

  • Para Azure Container Registry, Serviço de Aplicações cria um webhook no registo selecionado com o registo como âmbito. A docker push a qualquer repositório no registo (incluindo os não referenciados pelo seu ficheiro Docker Compose) desencadeia um reinício da aplicação. É melhor modificar o webhook para um âmbito mais restrito.
  • Docker Hub não suporta webhooks ao nível do registo. Tem de adicionar os webhooks manualmente às imagens especificadas no seu ficheiro Docker Compose.

4. Guarde as suas definições

5. Guarde as suas definições

ClickSave.

Como o CI/CD funciona com GitHub Actions

Se escolher GitHub Actions na Fonte (ver Escolha fonte de implantação), Serviço de Aplicações configura o CI/CD das seguintes formas:

  • Deposita um ficheiro de fluxo de trabalho GitHub Actions no seu repositório de GitHub para lidar com a construção e implementação de tarefas para Serviço de Aplicações.
  • Adiciona as credenciais para o seu registo privado como GitHub segredos. O ficheiro de fluxo de trabalho gerado executa a ação Azure/docker-login para iniciar sessão com o seu registo privado e, em seguida, corre docker push para ser implantado nele.
  • Adiciona o perfil de publicação da sua aplicação como um segredo GitHub. O ficheiro de fluxo de trabalho gerado utiliza este segredo para autenticar com Serviço de Aplicações, executando a ação de implementação do Azure/webapps para configurar a imagem atualizada, que desencadeia um reinício de aplicação para puxar a imagem atualizada.
  • Captura informações a partir dos registos de fluxo de trabalho e exibe-as no separador Registos no Centro de Implementação da sua aplicação.

Pode personalizar o fornecedor de GitHub Actions construir de acordo com as seguintes formas:

  • Personalize o ficheiro de fluxo de trabalho depois de gerado no seu repositório GitHub. Para obter mais informações, consulte a sintaxe do fluxo de trabalho para GitHub Actions. Apenas certifique-se de que o fluxo de trabalho termina com a ação de implementação do Azure/webapps para desencadear um reinício da aplicação.
  • Se o ramo selecionado estiver protegido, ainda pode pré-visualizar o ficheiro de fluxo de trabalho sem guardar a configuração, em seguida, adicioná-lo e os segredos GitHub necessários no seu repositório manualmente. Este método não lhe dá a integração de registo com o portal do Azure.
  • Em vez de um perfil de publicação, desloque-se usando um diretor de serviço em Azure Ative Directory.

Autenticar com um diretor de serviço

Esta configuração opcional substitui a autenticação predefinida por perfis de publicação no ficheiro de fluxo de trabalho gerado.

Gerencie um diretor de serviço com o comando ad sp create-for-rbac no Azure CLI. No exemplo seguinte, substitua <o id> de subscrição, <nome> de grupo e <nome> de aplicações pelos seus próprios valores. Guarde toda a saída JSON para o próximo passo, incluindo o nível {}superior.

az ad sp create-for-rbac --name "myAppDeployAuth" --role contributor \
                            --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name> \
                            --sdk-auth

Importante

Para a segurança, conceder o mínimo de acesso necessário ao diretor de serviço. O âmbito do exemplo anterior está limitado à aplicação Serviço de Aplicações específica e não a todo o grupo de recursos.

Em GitHub, navegue no seu repositório e, em seguida, selecioneDefinições > Segredos > Adicione um novo segredo. Cole toda a saída JSON do comando Azure CLI para o campo de valor do segredo. ao segredo um nome como AZURE_CREDENTIALS.

No ficheiro de fluxo de trabalho gerado pelo Centro de Implantação, reveja o azure/webapps-deploy passo com código como o seguinte exemplo:

- name: Sign in to Azure 
# Use the GitHub secret you added
- uses: azure/login@v1
    with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Deploy to Azure Web App
# Remove publish-profile
- uses: azure/webapps-deploy@v2
    with:
    app-name: '<app-name>'
    slot-name: 'production'
    images: '<registry-server>/${{ secrets.AzureAppService_ContainerUsername_... }}/<image>:${{ github.sha }}'
    - name: Sign out of Azure
    run: |
    az logout

Automatizar com CLI

Para configurar o registo do contentor e a imagem do Docker, oconjunto de recipientes de configuração runaz webapp.

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name '<image>:<tag>' --docker-registry-server-url 'https://<registry-name>.azurecr.io' --docker-registry-server-user '<username>' --docker-registry-server-password '<password>'

Para configurar uma aplicação multi-contentores (Docker Compose), prepare um ficheiro Docker Compose localmente e, em seguida, runazwebapp config conjunto com o --multicontainer-config-file parâmetro. Se o seu ficheiro Docker Compose contiver imagens privadas, adicione--docker-registry-server-* parâmetros como mostrado no exemplo anterior.

az webapp config container set --resource-group <group-name> --name <app-name> --multicontainer-config-file <docker-compose-file>

Para configurar o CI/CD do registo do contentor para a sua aplicação, o recipiente deimplantação runaz webapp configur com o --enable-cd parâmetro. O comando sai do URL webhook, mas tem de criar o webhook no seu registo manualmente num passo separado. O exemplo a seguir permite o CI/CD na sua aplicação e, em seguida, utiliza o URL webhook na saída para criar o webhook em Azure Container Registry.

ci_cd_url=$(az webapp deployment container config --name <app-name> --resource-group <group-name> --enable-cd true --query CI_CD_URL --output tsv)

az acr webhook create --name <webhook-name> --registry <registry-name> --resource-group <group-name> --actions push --uri $ci_cd_url --scope '<image>:<tag>'

Mais recursos