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

15 minutos

O pipeline de liberação 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 Kubernetes, você precisa modificar esse pipeline.

Nesta unidade, irá aprender a:

Atualize o pipeline para acionar uma confirmação na ramificação principal.
Defina variáveis a serem compartilhadas no pipeline.
Crie e publique imagens do Docker.
Publique manifestos do Kubernetes.
Adicione uma tarefa para criar um segredo de pull de imagem para uso entre o Kubernetes e as instâncias do Registro de contêiner.
Implante 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 o azure-pipelines.yml.

Andy: Este foi o estágio de construção que tínhamos em vigor para a solução anterior de contêiner único. Eu sabia que não ia funcionar corretamente, então eu o desativei. Podemos começar reativando gatilhos em confirmações para a main ramificação.
Substitua a linha existente trigger na parte superior do arquivo pelo seguinte trecho. Isso aciona uma execução de pipeline toda vez que uma confirmação é feita na ramificação principal.
```
trigger:
- 'main'
```

Definir variáveis acessíveis através do pipeline

Andy: Vamos precisar adicionar duas variáveis de pipeline. Um para especificar o nome do repositório da tabela de classificação, que é a tabela de classificação. O outro é para o nome do segredo de pull de imagem usado para compartilhamento entre instâncias AKS e ACR durante a implantação.

Adicione o seguinte código realçado à 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 apenas usar uma segunda tarefa para fazer o mesmo para a nossa tabela de classificação.

Adicione uma segunda Docker@2 tarefa para criar e publicar o contêiner da tabela de classificação usando o seguinte trecho realçado. Adicione esta 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)

Gorjeta

Certifique-se de que a tarefa adicionada 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 a próxima fase. Vê falta alguma coisa?

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 terminarmos esta fase.

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

Mara: Eles seriam se estivéssemos adicionando as tarefas de implantação dentro do mesmo estágio da compilação. No entanto, como nossas tarefas de implantação acontecem em seu próprio estágio de implantação , ele é executado em um ambiente novo, provavelmente até mesmo em um agente diferente. Devemos ter a certeza de publicar tudo o que esta fase produz e que a outra fase necessita.

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

Mara: É para isso que serve a PublishBuildArtifacts@1 tarefa. É tão comum que há até uma abreviatura para isso, publish.

Adicione uma publish tarefa que armazene a pasta manifestos para um estágio futuro, conforme mostrado no trecho de código a seguir. Certifique-se de que o recuo desta tarefa corresponde ao 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

Substitua o estágio de implantação

Mara: Vou substituir nosso estágio de implantação existente por um que usa um trabalho de implantação . Um trabalho de implantação é um tipo especial de trabalho que nos permite associar nossa implantação ao ambiente de DevOps do Azure criado anteriormente. Isso facilita o acompanhamento do histórico de implantação, o que será especialmente útil à medida que nossas soluções se tornam mais sofisticadas.

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

Andy: Deixe-me adivinhar, existe uma download abreviatura para essa tarefa?

Mara: Exatamente! Podemos usar o especificador para indicar que queremos o current artefato da execuçã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 de atração de imagem que será compartilhado entre nossas instâncias ACR e AKS. Sabe se há alguma tarefa que possamos usar?

Mara: Eu estava apenas olhando para cima, e estamos com sorte. A KubernetesManifest@0 tarefa suporta 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 principais operações de implantação necessárias para o Kubernetes. Ele suporta várias action opções que vão desde a criação de segredos até a implantação de imagens. Neste caso, a createSecret ação é 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 ARM.
azureResourceGroup Especifica o nome do seu grupo de recursos.
kubernetesCluster especifica o nome do seu cluster AKS.
namespace especifica o namespace Kubernetes ao qual essa ação se aplica.

Adicione o seguinte trecho ao final do pipeline. Certifique-se de que o nome do grupo de recursos e o nome do cluster correspondam aos nomes dos que você criou anteriormente. Certifique-se de que o recuo desta tarefa corresponde ao da tarefa de 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 é acionar 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. Neste caso, deploy para implantar no cluster 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 ARM.
- azureResourceGroup Especifica o nome do seu grupo de recursos.
- kubernetesCluster especifica o nome do seu cluster AKS.
- namespace especifica o namespace Kubernetes ao qual essa ação se aplica.
- imagePullSecrets Especifica a lista de segredos necessários para extrair do registro de contêiner.
- containers Especifica a lista de imagens de contêiner a serem implantadas.

Adicione o seguinte trecho ao final do pipeline. Certifique-se de que o nome do grupo de recursos e o nome do cluster correspondam aos nomes dos que você criou anteriormente. Certifique-se de que o recuo desta tarefa corresponde ao 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)

Execute 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 da ramificação e selecione Executar para acionar uma execução de pipeline.
Selecione Pipelines e, em seguida, selecione seu pipeline para exibir os logs à medida que o pipeline é executado.
Após a conclusão da execução do pipeline, selecione Ambientes no painel esquerdo e, em seguida, selecione o Ambiente de desenvolvimento para exibir seus trabalhos de implantação.
Agora vamos conferir nosso aplicativo Web implantado e nosso endpoint de API. Para fazer isso, precisamos obter os endereços IP externos para os serviços da web e da tabela de classificação.
Navegue até o portal do Azure, selecione seu cluster AKS e selecione Serviços e ingressos.
Selecione o IP externo do seu serviço Web para visualizar o seu site no AKS.
Volte para a janela do portal do Azure de onde parou e, em seguida, copie o IP externo para o serviço da tabela de líderes. Este endereço IP é onde a API da tabela de classificação está hospedada publicamente.
Substitua o espaço reservado no link a seguir pelo IP externo copiado. Você também pode adicionar um pageSize=10 parâmetro de consulta para facilitar a visualização da resposta JSON em seu navegador. Use um URL como o seguinte em uma nova guia do navegador.
```
http://[IP]/api/Leaderboard?pageSize=10
```
Você pode visualizar a resposta JSON bruta da API do placar de líderes hospedada em seu cluster AKS. Agora você tem uma API REST que pode chamar de outros aplicativos.

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