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 projetado para criar a solução como um contêiner do Docker e implantá-la no Serviço de Aplicativo do Azure. Para dar suporte à implantação de vários contêineres em um cluster do Kubernetes, você precisa modificar esse pipeline.

Nesta unidade, você aprenderá a:

Atualizar o pipeline para disparar em um commit na ramificação principal.
Defina variáveis a serem compartilhadas em todo o 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 a gatilhos

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

Andy: Esta era a fase de construção que tínhamos utilizada para a solução de contêiner único anterior. Eu sabia que não ia funcionar corretamente, então eu desabilitei. Podemos começar habilitando novamente os gatilhos para commits na ramificação main.
Substitua a linha existente trigger na parte superior do arquivo pelo snippet a seguir. Isso irá disparar uma execução de pipeline sempre que um commit for feito na ramificação principal.
```
trigger:
- 'main'
```

Definir variáveis acessíveis em todo o pipeline

Andy: Precisaremos adicionar duas variáveis de pipeline. Uma para especificar o nome do repositório do placar, que é leaderboard. 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 à variables seção.

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

Criar e publicar 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 simplesmente usar uma segunda tarefa para fazer o mesmo para o placar de líderes.

Adicione uma segunda Docker@2 tarefa para compilar e publicar o contêiner do placar usando o trecho realçado a seguir. Adicione essa tarefa logo após a tarefa de contêiner 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

Verifique se a tarefa que você adiciona aqui usa 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ê vê algo faltando?

Mara: Você mencionou que havia alguns arquivos de manifesto no projeto de origem que definem a implantação e os serviços que o Kubernetes precisa quando implantamos. Devemos publicá-las antes de concluirmos este estágio.

Andy: Precisamos? Elas não estarão ainda no disco local?

Clara: Elas estariam se estivéssemos adicionando as tarefas de implantação no mesmo estágio que o build. No entanto, como nossas tarefas de implantação ocorrem em seu próprio estágio de implantação , elas são executadas em um ambiente novo, provavelmente até mesmo em um agente diferente. Devemos assegurar a publicação de tudo que este estágio produza que o outro estágio precise.

Andy: Esse é um grande ponto. É fácil de fazer? Só precisamos garantir que a pasta de manifestos seja copiada para o novo agente.

Mara: Esse é o propósito da PublishBuildArtifacts@1 tarefa. É tão comum que há até uma abreviação para ela, publish.

Adicione uma publish tarefa que armazena a pasta de manifestos para um estágio futuro, conforme mostrado no snippet de código a seguir. Certifique-se de que os recuos desta tarefa correspondam 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 o estágio de implantação

Clara: Substituirei o estágio 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 do Azure DevOps criado anteriormente. Isso facilita o acompanhamento do histórico de implantações, que será especialmente útil à medida que nossas soluções ficarem mais sofisticadas.

Remova o estágio de implantação existente (tudo após o estágio de build) e substitua-o pelo snippet a seguir. 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:
```
Clara: A primeira etapa que adicionaremos no estágio de implantação é baixar os artefatos de manifesto publicados anteriormente usando a tarefa DownloadBuildArtifacts@0.

Andy: Deixe-me adivinhar, há uma download abreviação para essa tarefa?

Mara: Exatamente correto! 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
```
Paulo: Agora, precisamos criar um segredo de pull de imagem que será compartilhado entre nossas instâncias do ACR e do AKS. Você sabe se há uma tarefa que podemos usar?

Clara: Eu recém estava conferindo isso, e estamos com sorte. A tarefa KubernetesManifest@0 oferece suporte à ação necessária para criar o segredo.

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. Ele dá suporte a várias action opções que vão desde a criação de segredos até a implantação de imagens. Nesse caso, a ação createSecret é 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 usada. 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 grupo de recursos.
kubernetesCluster especifica o nome do cluster do AKS.
namespace especifica o namespace do Kubernetes ao qual essa ação se aplica.

Adicione o trecho de código a seguir ao final do seu pipeline. Verifique se o nome do grupo de recursos e o nome do cluster correspondem 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 no cluster do Kubernetes. Com base na documentação, parece que podemos usar a mesma tarefa, mas com uma 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 usada. Opções: azureResourceManager ou kubernetesServiceConnection.
- azureSubscriptionConnection especifica o nome da conexão dos Serviços do ARM.
- azureResourceGroup especifica o nome do grupo de recursos.
- kubernetesCluster especifica o nome do 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 serem implantadas.

Adicione o snippet a seguir ao final do pipeline. Verifique se o nome do grupo de recursos e o nome do cluster correspondem aos nomes dos que você criou anteriormente. Certifique-se de que a indentação dessa tarefa corresponda à 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 confirmação.
Selecione Executar, confirme o nome do branch e selecione Executar para desencadear uma execução de pipeline.
Selecione Pipelines e, em seguida, selecione o pipeline para exibir os logs enquanto o pipeline é executado.
Depois que a execução do pipeline for concluída, selecione Ambientes no painel esquerdo e selecione o ambiente de desenvolvimento para exibir seus trabalhos de implantação.
Agora vamos conferir nosso aplicativo web implantado e o endpoint 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é o portal do Azure, selecione o cluster do AKS e selecione Serviços e entradas.
Selecione o IP externo do seu 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 marcador de posição no link a seguir pelo IP externo copiado. Você também pode adicionar um pageSize=10 parâmetro de consulta para facilitar a exibição da resposta JSON no navegador. Use uma URL como a seguinte em uma nova aba do navegador.
```
http://[IP]/api/Leaderboard?pageSize=10
```
Você pode exibir a resposta JSON bruta da API do placar de líderes hospedada no cluster do AKS. Agora você tem uma API REST que pode ser chamada por outros aplicativos.

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

Comentários

Esta página foi útil?