Exercício – Implantar uma solução de vários contêineres em um cluster do Kubernetes

15 minutos

O pipeline de lançamento fornecido com seu projeto foi concebido para criar a solução como um contêiner do Docker e implantá-la em Serviço de Aplicativo do Azure. Para dar suporte à implantação de vários contêineres em um cluster do Kubernetes, você vai precisar modificar esse pipeline.

Nesta unidade, você aprenderá a:

Atualizar o pipeline para disparar em um commit na ramificação principal.
Definir variáveis a serem compartilhadas no pipeline.
Compilar e publicar imagens do Docker.
Publicar manifestos do Kubernetes.
Adicione uma tarefa para criar um segredo para efetuar pull de imagem para uso entre suas instâncias do Kubernetes e do registro de contêiner.
Implantar imagens atualizadas em um cluster do Kubernetes.

Atualizar o pipeline para dar suporte à gatilhos

Entre na sua organização do Azure DevOps e navegue até seu projeto.
Selecione Pipelines e escolha o seu pipeline.
Selecione Editar para editar o azure-pipelines.yml.

Andy: Esse era o estágio de compilação que tínhamos em uso para a solução anterior de contêiner único. Eu sabia que ele não ia ser executado corretamente, então desabilitei-o. Podemos começar habilitando novamente os gatilhos para commits no branch main.
Substitua a linha trigger existente na parte superior do arquivo pelo snippet de código a seguir. Isso irá disparar uma execução de pipeline sempre que um commit for feito no branch principal.
```
trigger:
- 'main'
```

Definir variáveis acessíveis no pipeline

Andy: Vamos precisar adicionar duas variáveis de pipeline. Um para especificar o nome do repositório do placar de líderes, que é placar de líderes. A outra é para o nome do segredo do pull de imagem usado para compartilhar entre instâncias do AKS e do ACR durante a implantação.

Adicione o código realçado a seguir à seção variables.

variables:
  buildConfiguration: 'Release'
  leaderboardRepository: 'leaderboard'
  webRepository: 'web'
  tag: '$(Build.BuildId)'
  imagePullSecret: 'secret'

Criar e publicar a imagem do Docker no Registro de Contêiner do Azure

Andy: Já temos uma tarefa para criar o aplicativo Web como um contêiner do Docker, que publicamos em nosso registro de contêiner. Podemos usar apenas uma segunda tarefa para fazer o mesmo para o placar de líderes.

Adicione uma segunda tarefa do Docker@2 para criar e publicar o contêiner do placar de líderes usando o snippet de código realçado abaixo. Adicione essa tarefa logo após a tarefa de contêiner da Web.

- task: Docker@2
  displayName: 'Build and push the web image to container registry'
  inputs:
    command: buildAndPush
    buildContext: $(Build.Repository.LocalPath)
    repository: $(webRepository)
    dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.Web/Dockerfile'
    containerRegistry: 'Container Registry Connection'
    tags: |
      $(tag)

- task: Docker@2
  displayName: 'Build and push the leaderboard image to container registry'
  inputs:
    command: buildAndPush
    buildContext: $(Build.Repository.LocalPath)
    repository: $(leaderboardRepository)
    dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.LeaderboardContainer/Dockerfile'
    containerRegistry: 'Container Registry Connection'
    tags: |
      $(tag)

Dica

A tarefa que você adiciona aqui deve usar um recuo consistente com a tarefa anterior, pois o espaço em branco é importante em um arquivo YAML.

Publicar os manifestos do Kubernetes

Andy: Acho que podemos passar para o próximo estágio. Você viu algo faltando?

Clara: Você disse que havia alguns arquivos de manifesto no projeto original que definem a implantação, dos quais os serviços do Kubernetes vão precisar quando implantarmos. Devemos publicá-los antes de concluirmos este estágio.

Andy: Precisamos fazer isso? Eles ainda não estarão no disco local?

Mara: Estariam se estivéssemos adicionando as tarefas de implantação no mesmo estágio que a compilação. No entanto, como nossas tarefas de implantação ocorrem em seu próprio estágio de Implantação, a implantação será executada em um ambiente completamente novo, provavelmente até mesmo em um agente diferente. Devemos nos certificar de publicar tudo que esse estágio produz e que será necessário no outro estágio.

Andy: Esse é um ótimo ponto. É fácil fazer isso? Precisamos apenas garantir que a pasta de manifestos seja copiada para o novo agente.

Mara: É para isso que serve a tarefa PublishBuildArtifacts@1. É tão comum que existe até mesmo uma abreviação para ela, publish.

Adicione uma tarefa publish que armazena a pasta de manifestos para uma fase futura, como no snippet de código a seguir. Os recuos nessa tarefa devem corresponder aos da tarefa anterior.

- task: Docker@2
  displayName: 'Build and push the leaderboard image to container registry'
  inputs:
    command: buildAndPush
    buildContext: $(Build.Repository.LocalPath)
    repository: $(leaderboardRepository)
    dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.LeaderboardContainer/Dockerfile'
    containerRegistry: 'Container Registry Connection'
    tags: |
      $(tag)

- publish: '$(Build.SourcesDirectory)/manifests'
  artifact: manifests

Substituir a fase de implantação

Mara: vou substituir a fase de Implantação existente por um que use um trabalho de implantação. Um trabalho de implantação é um tipo especial de trabalho que nos permite associar nossa implantação ao ambiente Azure DevOps criado anteriormente. Isso facilita o controle do histórico de implantação, o que será especialmente útil à medida que nossas soluções se tornarem mais sofisticadas.

Remova o estágio de Implantação existente (tudo após o estágio de compilação) e o substitua pelo snippet de código abaixo. Anote a linha realçada que indica o ambiente de implantação a ser utilizado.
```
- stage: 'Deploy'
  displayName: 'Deploy the containers'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    displayName: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: 'Dev'
    variables:
    - group: Release
    strategy:
      runOnce:
        deploy:
          steps:
```
Mara: A primeira etapa que adicionaremos ao estágio de implantação é para baixar os artefatos de manifesto publicados anteriormente usando a tarefa DownloadBuildArtifacts@0.

Andy: Deixe-me adivinhar, há uma forma resumida de download para essa tarefa?

Mara: Exatamente! Podemos usar o especificador current para indicar que desejamos o artefato da versão atual do pipeline.
Adicione as linhas realçadas como a primeira etapa do estágio Implantar.
```
- stage: 'Deploy'
  displayName: 'Deploy the containers'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    displayName: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: 'spike.default'
    variables:
    - group: Release
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: manifests
```
Andy: Agora, precisamos criar um segredo para efetuar pull de imagem que será compartilhado entre nossas instâncias do ACR e do AKS. Você sabe se há uma tarefa que podemos usar?

Mara: era exatamente isso que eu procurava, estamos com sorte. A tarefa KubernetesManifest@0 dá suporte a uma ação para criar o segredo necessário.

Tarefa de manifesto do Kubernetes

A tarefa de manifesto do Kubernetes foi projetada para gerenciar todas as operações de implantação principais necessárias para o Kubernetes. Ela dá suporte a várias opções action que vão desde a criação de segredos até a implantação de imagens. Nesse caso, a ação createSecret será usada, juntamente com os seguintes parâmetros:

action indica o recurso a ser executado. Nesse caso, createSecret cria o segredo compartilhado.
connectionType especifica o tipo de conexão de serviço a ser usado. Opções: azureResourceManager ou kubernetesServiceConnection.
secretName especifica o nome do segredo a ser criado.
dockerRegistryEndpoint especifica o nome da conexão dos Serviços de Registro de Contêiner do Azure.
azureSubscriptionConnection especifica o nome da conexão dos Serviços do ARM.
azureResourceGroup especifica o nome do seu grupo de recursos.
kubernetesCluster especifica o nome do seu cluster do AKS.
namespace especifica o namespace do Kubernetes ao qual essa ação se aplica.

Adicione o snippet a seguir ao final do pipeline. O nome do grupo de recursos e o nome do cluster devem corresponder aos nomes dos que você criou anteriormente. Confirme se recuos nessa tarefa correspondem aos da tarefa download.
```
- task: KubernetesManifest@1
  displayName: Create imagePullSecret
  inputs:
    action: createSecret
    connectionType: azureResourceManager
    secretName: $(imagePullSecret)
    dockerRegistryEndpoint: 'Container Registry Connection'
    azureSubscriptionConnection: 'Kubernetes Cluster Connection'
    azureResourceGroup: 'tailspin-space-game-rg'
    kubernetesCluster: 'tailspinspacegame-24591'
    namespace: 'default'
```
Andy: A etapa final é disparar a implantação de nossas imagens para o cluster do Kubernetes. Com base na documentação, parece que podemos usar a mesma tarefa, mas com ação e parâmetros diferentes.
- action indica o recurso a ser executado. Nesse caso, deploy para implantar no cluster do AKS.
- connectionType especifica o tipo de conexão de serviço a ser usado. Opções: azureResourceManager ou kubernetesServiceConnection.
- azureSubscriptionConnection especifica o nome da conexão dos Serviços do ARM.
- azureResourceGroup especifica o nome do seu grupo de recursos.
- kubernetesCluster especifica o nome do seu cluster do AKS.
- namespace especifica o namespace do Kubernetes ao qual essa ação se aplica.
- imagePullSecrets especifica a lista de segredos necessários para efetuar pull do registro de contêiner.
- containers especifica a lista de imagens de contêiner a implantar.

Adicione o snippet a seguir ao final do pipeline. O nome do grupo de recursos e o nome do cluster devem corresponder aos nomes dos que você criou anteriormente. Os recuos nessa tarefa devem corresponder aos da tarefa anterior.

- task: KubernetesManifest@1
  displayName: Deploy to Kubernetes cluster
  inputs:
    action: deploy
    connectionType: azureResourceManager
    azureSubscriptionConnection: 'Kubernetes Cluster Connection'
    azureResourceGroup: 'tailspin-space-game-rg'
    kubernetesCluster: 'tailspinspacegame-24591'
    namespace: 'default'
    manifests: |
      $(Pipeline.Workspace)/manifests/deployment.yml
      $(Pipeline.Workspace)/manifests/service.yml
    imagePullSecrets: |
      $(imagePullSecret)
    containers: |
      $(RegistryName)/$(webRepository):$(tag)
      $(RegistryName)/$(leaderboardRepository):$(tag)

Executar seu pipeline

Selecione Salvar no canto superior direito da página. Selecione Salvar para confirmar sua mensagem de commit.
Selecione Executar, confirme o nome do branch e, em seguida, escolha Executar para disparar uma execução de pipeline.
Selecione Pipelines e, em seguida, selecione o pipeline para exibir os logs enquanto o pipeline é executado.
Após a execução do pipeline ter sido concluída, selecione Ambientes no painel à esquerda e, em seguida, selecione o ambiente de Desenvolvimento para ver seus trabalhos de implantação.
Agora vamos conferir o aplicativo Web implantado e o ponto de extremidade da API. Para fazê-lo, precisaremos obter os endereços IP externos tanto dos serviços de web quanto do placar de líderes.
Navegue até portal do Azure, selecione o cluster do AKS e escolha Serviços e entradas.
Selecione o IP externo do serviço Web para exibir seu site no AKS.
Volte para a janela do portal do Azure em que você parou e copie o IP Externo para o serviço de placar de líderes. Esse endereço IP é onde a API do placar de líderes é hospedada publicamente.
Substitua o espaço reservado no link a seguir pelo IP externo que você copiou. Você também pode adicionar um parâmetro de consulta pageSize=10 para facilitar a exibição da resposta JSON em seu navegador. Use uma URL como a seguinte em uma nova guia do navegador.
```
http://[IP]/api/Leaderboard?pageSize=10
```
Veja a resposta JSON bruto da API do placar de líderes hospedada no seu cluster do AKS. Agora você tem uma API REST que pode ser chamada por outros aplicativos.

Paulo: Isso ficou ótimo! Acho que usar Kubernetes seria uma ótima maneira de adotarmos uma estratégia mais ampla de microsserviços.