Construa um pipeline CI/CD para microserviços no Kubernetes usando Azure DevOps e Helm

Criar um processo fiável de integração contínua e entrega contínua (CI/CD) para uma arquitetura de microserviços pode ser desafiante. Cada equipa precisa de lançar serviços de forma rápida e fiável, sem perturbar outras equipas ou desestabilizar a aplicação como um todo.

Este artigo descreve um exemplo de pipeline CI/CD para implementar microserviços no Azure Kubernetes Service (AKS). Cada equipa e projeto é diferente, por isso não tome este artigo como um conjunto de regras rígidas e rápidas. Em vez disso, usa-o como ponto de partida para desenhar o teu próprio processo de CI/CD.

A lista seguinte resume os objetivos de um pipeline CI/CD para microserviços alojados no Kubernetes:

• As equipes podem criar e implantar seus serviços de forma independente.
• Alterações de código que passam pelo processo de CI são automaticamente implementadas num ambiente semelhante à produção.
• Cada etapa do gasoduto impõe limites de qualidade.
• Uma nova versão de um serviço pode ser implantada lado a lado com a versão anterior.

Para mais informações, veja CI/CD para arquiteturas de microserviços.

Suposições

Para este exemplo, aqui estão algumas suposições sobre a equipa de desenvolvimento e a base de código:

• O repositório de código é um monorepo, com as pastas organizadas por microserviço.
• A estratégia de ramificação da equipe é baseada no desenvolvimento baseado em troncos.
• A equipe usa ramificações de release para gerenciar lançamentos. Versões separadas são criadas para cada microsserviço.
• O processo CI/CD utiliza Azure Pipelines para construir, testar e implementar os microserviços no AKS.
• As imagens de contentores de todos os microserviços são armazenadas numa única instância partilhada do Azure Container Registry, com um repositório separado para cada microserviço. Use as permissões do repositório ABAC do Container Registry Azure para definir cada identidade de pipeline para o seu próprio repositório, ou use registos separados onde sejam necessários limites de confiança mais fortes.
• A equipe usa gráficos Helm para empacotar cada microsserviço.
• É utilizado um modelo de implementação push, onde o Azure Pipelines e os agentes associados realizam implementações ligando-se diretamente ao cluster AKS.

Essas suposições orientam muitos dos detalhes técnicos do pipeline de CI/CD. No entanto, pode adaptar a abordagem básica aqui descrita para outros processos, ferramentas e serviços, como GitHub Actions, Jenkins ou Docker Hub.

Alternatives

Ao escolher uma estratégia CI/CD com AKS, considere as seguintes alternativas comuns:

• Em vez de usar o Helm como ferramenta de gestão e implementação de pacotes, pode usar o Kustomize, uma ferramenta nativa de Kubernetes que introduz uma forma sem modelos para personalizar e parametrizar a configuração da aplicação.

• Em vez de usar Azure DevOps para repositórios e pipelines Git, pode usar repositórios GitHub para repositórios Git privados e públicos, e GitHub Actions para pipelines CI/CD.

  O GitHub Actions oferece integração com o AKS com fluxos de trabalho iniciais e suporta OpenID Connect (OIDC) para autenticação segura e sem segredo no Azure.

• Em vez de usar um modelo de implementação push, considere gerir a configuração do Kubernetes em grande escala usando um GitOps (modelo pull deployment). Um operador Kubernetes dentro do cluster, como o Flux ou o Argo CD , sincroniza o estado do cluster com base na configuração armazenada num repositório Git. O GitOps elimina a necessidade de os pipelines terem acesso direto a clusters, reduz a superfície de ataque e oferece capacidades de auto-reparação e deteção de deriva.

  Sugestão

  Ao avaliar modelos de implementação baseados em push versus baseados em pull (GitOps), considere os requisitos da sua carga de trabalho. As implementações baseadas em push oferecem atualizações determinísticas e controlo direto do pipeline, o que favorece práticas de implementação segura. As implementações baseadas em pull (GitOps) oferecem consistência, auditabilidade e auto-recuperação, o que as torna ideais para ambientes onde os clusters precisam de se reconciliar com um estado desejado sem acesso direto pipeline-to-cluster.

Compilações de validação

Suponha que um programador está a trabalhar num microserviço chamado Delivery Service. Ao desenvolver uma nova funcionalidade, o programador verifica o código num ramo de funcionalidades. Por convenção, as ramificações de funcionalidades são nomeadas feature/*.

O arquivo de definição de compilação inclui um gatilho que filtra pelo nome da ramificação e pelo caminho de origem:

trigger:
  batch: true
  branches:
    include:
    # for new release to production: release flow strategy
    - release/delivery/v*
    - refs/release/delivery/v*
    - main
    - feature/delivery/*
    - topic/delivery/*
  paths:
    include:
    - /src/shipping/delivery/

Quando se utiliza esta abordagem, cada equipa pode ter o seu próprio pipeline de build. Só o código que está registado na /src/shipping/delivery pasta desencadeia uma compilação do Delivery Service. Enviar commits para uma ramificação que corresponde ao filtro inicia uma construção CI. Neste ponto do fluxo de trabalho, a compilação CI executa algumas verificações mínimas de código:

1. Compile o código.
2. Execute testes de unidade.

O objetivo é manter os tempos de compilação curtos para que o desenvolvedor possa obter feedback rápido. Quando a funcionalidade está pronta para ser integrada na principal, o programador abre uma PR. Esta operação dispara outra compilação de CI que executa algumas verificações adicionais:

1. Compile o código.
2. Execute testes de unidade.
3. Execute testes estáticos de segurança de aplicações (SAST) no código-fonte.
4. Crie a imagem do contentor runtime.
5. Execute verificações de vulnerabilidade na imagem.

Compilação completa de CI/CD

Quando a equipa está pronta para implementar uma nova versão do Serviço de Entrega, o gestor de lançamentos cria um ramo a partir do ramo principal, usando este padrão de nomenclatura: release/<microservice name>/<semver>. Por exemplo, release/delivery/v1.0.2.

Criar este ramo desencadeia uma build completa de CI que executa todos os passos anteriores e estes passos:

1. Empurra a imagem do contentor para o Registo do Contentor. A imagem está marcada com o número de versão no nome da agência.
2. Execute helm package para empacotar o gráfico Helm para o serviço. O gráfico também é marcado com um número de versão.
3. Empurre o pacote Helm para o registo de contêineres.

Se esta compilação for bem-sucedida, ativa um processo de deployment (CD) através de um pipeline de release do Azure Pipelines. Este pipeline contém os seguintes passos:

1. Implante o gráfico Helm em um ambiente de QA.
2. Um aprovador assina antes que o pacote passe para a produção. Consulte Controle de distribuição de versões usando aprovações.
3. Remarque a imagem Docker para o namespace de produção no Registo de Containers. Por exemplo, se a tag atual for myrepo.azurecr.io/delivery:v1.0.2, a tag de produção será myrepo.azurecr.io/prod/delivery:v1.0.2.
4. Implante o gráfico Helm no ambiente de produção.

Mesmo num monorepo, especifique estas tarefas a microserviços individuais para que as equipas possam implementar de forma independente. O processo inclui alguns passos manuais: aprovação de PRs, criação de ramos de lançamento e aprovação de implementações no cluster de produção. As equipas de carga de trabalho podem automatizar estes passos, se assim o desejarem.

Isolamento de ambientes

Implementas serviços em múltiplos ambientes, incluindo ambientes para desenvolvimento, testes de fumo, testes de integração, testes de carga e produção. Esses ambientes precisam de algum nível de isolamento. No Kubernetes, podes escolher entre isolamento físico e isolamento lógico. O isolamento físico é implantado em clusters separados. O isolamento lógico utiliza namespaces e políticas.

A nossa recomendação é criar um cluster de produção dedicado juntamente com um cluster separado para os seus ambientes de desenvolvimento/teste. Use o isolamento lógico para separar ambientes dentro do cluster de desenvolvimento/teste. Os serviços implantados no cluster de desenvolvimento/teste nunca devem ter acesso a armazenamentos de dados que armazenam dados corporativos.

Para impor o isolamento dentro de um cluster, siga os seguintes passos:

• Espaços de nomes: Use espaços de nomes Kubernetes para separar logicamente ambientes (por exemplo, dev, staging, qa).
• Políticas de rede: Aplicar as políticas de rede do Kubernetes para negar a comunicação pod-a-pod entre namespaces.
• Quotas de recursos: Aplicar quotas de recursos por namespace para evitar problemas de vizinhos ruidosos em clusters partilhados.
• Integração com Microsoft Entra ID: Combinar autenticação Microsoft Entra ID com Kubernetes RBAC e Microsoft Entra ID para controlar que utilizadores e grupos da Microsoft Entra podem aceder a cada espaço de nomes.

Autenticação e autorização

Use autenticação secretless sempre que possível, tanto para os pipelines que implementam os seus microserviços como para as cargas de trabalho que esses pipelines implementam:

• Federação de identidade de carga de trabalho para pipelines: Para Azure Pipelines, use uma ligação de serviço de federação de identidade de carga de trabalho para autenticar no Azure sem armazenar segredos de principal de serviço de longa duração. Para GitHub Actions, configure o OIDC para alcançar a mesma autenticação sem segredos.
• ID de carga de trabalho Microsoft Entra para cargas de trabalho implementadas: Configure os microserviços que o seu pipeline implementa para usarem o ID de carga de trabalho Microsoft Entra em vez de injetar credenciais através de manifestos, valores Helm ou segredos Kubernetes. O Workload ID federa contas de serviço Kubernetes com Microsoft Entra ID para que os pods possam autenticar-se aos serviços Azure (como Azure Key Vault, Container Registry ou SQL do Azure) sem que o pipeline gere quaisquer segredos.

Gestão de segredos

Nunca incorpore segredos (strings de ligação, chaves API, palavras-passe de base de dados) diretamente no código-fonte, Dockerfiles, ficheiros de valores de Helm ou definições de pipeline. Em vez disso:

• Guarda segredos no Cofre da Chave.
• Use o Key Vault Provider for Secrets Store CSI Driver para montar segredos diretamente em pods como volumes ou variáveis de ambiente. Esta abordagem mantém segredos fora dos objetos Kubernetes Secret , que são codificados base64, não encriptados por defeito.
• Para segredos de pipeline, use a integração do Key Vault com o Azure Pipelines ou os segredos do GitHub Actions.
• Ativar a proteção contra eliminação e purga suave do Key Vault para proteger contra eliminação de segredos acidentalmente ou maliciosas.

Processo de construção

Quando possível, empacote seu processo de compilação em um contêiner do Docker. Esta configuração permite construir artefactos de código usando o Docker sem ter de configurar um ambiente de compilação em cada máquina de compilação. Um processo de construção containerizado simplifica a expansão do pipeline de CI ao adicionar novos agentes de compilação. Além disso, qualquer programador da equipa pode construir o código correndo o contentor de compilação.

Ao usar builds multiestágio no Docker, pode definir o ambiente de compilação e a imagem de runtime num único Dockerfile. Por exemplo, o seguinte Dockerfile constrói uma aplicação .NET 10:

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
USER app
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src/Fabrikam.Workflow.Service

COPY Fabrikam.Workflow.Service/Fabrikam.Workflow.Service.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.csproj

COPY Fabrikam.Workflow.Service/. .
RUN dotnet build Fabrikam.Workflow.Service.csproj -c Release -o /app/build --no-restore

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

FROM build AS publish
RUN dotnet publish Fabrikam.Workflow.Service.csproj -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Fabrikam.Workflow.Service.dll"]

Este Dockerfile define vários estágios de compilação. Note que o estágio nomeado base usa a imagem de runtime .NET 10 ASP.NET, enquanto o estágio nomeado build usa o SDK completo .NET 10. O build palco constrói o projeto .NET. Mas o contêiner de runtime final é construído a partir de base, que contém apenas o runtime e é significativamente menor do que a imagem completa do SDK.

Construindo um executor de teste

Outra boa prática é executar testes de unidade no contêiner. Por exemplo, o código seguinte mostra parte de um Dockerfile que constrói um executor de testes:

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

Um programador pode usar este Dockerfile para executar os testes localmente:

docker build . -t delivery-test:1 --target=testrunner
docker run delivery-test:1

O pipeline de CI também deve executar os testes como parte da etapa de verificação de compilação.

Este ficheiro usa o comando Docker ENTRYPOINT , não o comando Docker RUN , para executar os testes.

• Se você usar o RUN comando, os testes serão executados toda vez que você criar a imagem. Se usares ENTRYPOINT, os testes são com opção de participação. Eles são executados somente quando você direciona explicitamente a testrunner etapa.
• Um teste com falha não faz com que o comando Docker build falhe. Este comportamento permite-lhe distinguir falhas de construção de contentores de falhas de teste.
• Os resultados do teste podem ser guardados num volume montado.

Práticas recomendadas de contêiner

Aqui estão algumas outras práticas recomendadas a serem consideradas para contêineres:

• Defina convenções organizacionais para etiquetas de contentores, versionamento e convenções de nomenclatura para recursos implementados no cluster (por exemplo, pods e serviços). A utilização destas convenções pode facilitar o diagnóstico de problemas de implementação.
• Durante o ciclo de desenvolvimento e testes, o processo CI/CD constrói muitas imagens de contentores. Apenas algumas dessas imagens são candidatas a lançamento, e apenas algumas dessas candidatas a lançamento são promovidas para produção. Tenha uma estratégia clara de versão para saber quais as imagens que estão atualmente em produção e possa facilmente reverter para uma versão anterior, se necessário.
• Sempre implante tags de versão de contêiner específicas, não latest.
• Use namespaces no Registo de Contentores para isolar imagens aprovadas para produção a partir de imagens que ainda estão a ser testadas. Não mova uma imagem para o namespace de produção até que esteja pronto para implantá-la na produção. Combinar esta prática com a versionação semântica das imagens de contentores pode reduzir as hipóteses de implantar acidentalmente uma versão que não esteja aprovada para lançamento.
• Siga o princípio do menor privilégio executando contêineres como um usuário sem privilégios. No Kubernetes, utilize os Padrões de Segurança dos Pods com admissão de Segurança dos Pods (que substituíram as Políticas de Segurança dos Pods obsoletas no Kubernetes 1.25) para impor restrições como impedir que os contentores corram como root. Usa o restricted perfil para cargas de trabalho em produção.
• Use imagens base mínimas ou sem distribuição (por exemplo, imagens baseadas em Alpine, imagens base ou sem distribuição no Azure Linux, ou imagens .NET esculpidas) para reduzir a superfície de ataque das suas imagens do contentor.
• Para registos Premium, configure uma política de retenção de Registos de Contentores para eliminar manifestos não identificados. Para eliminar etiquetas por idade ou nome, agende uma tarefa do Registo de Contentores que execute purga acr. Preservar imagens referenciadas por implantações ativas e planos de rollback.

Diagramas Helm

Considere usar o Helm para gerenciar a criação e a implantação de serviços. As seguintes funcionalidades do Helm suportam um pipeline CI/CD:

• Um único microserviço é frequentemente definido por múltiplos objetos Kubernetes. O Helm permite que estes objetos sejam agrupados num único gráfico de Helm.
• Podes implementar um gráfico usando um único comando Helm em vez de uma série de comandos kubectl.
• Gráficos são versionados de forma explícita. Use o Helm para lançar uma versão, exibir versões e reverter para uma versão anterior. O Helm utiliza versionamento semântico para acompanhar atualizações e revisões.
• Os gráficos Helm usam modelos para evitar a duplicação de informações, como rótulos e seletores, em muitos arquivos.
• O Helm pode gerenciar dependências entre gráficos.
• Pode armazenar gráficos num repositório Helm, como o Container Registry, e integrá-los no pipeline de compilação.

Para mais informações, consulte Use Container Registry como repositório Helm para os seus gráficos de aplicação.

Um único microserviço pode exigir múltiplos ficheiros de configuração Kubernetes. Para atualizar um serviço, pode ser necessário editar todos estes ficheiros para atualizar seletores, rótulos e etiquetas de imagem. O Helm trata estes ficheiros como um único pacote chamado gráfico e facilita a atualização dos ficheiros YAML usando variáveis. O Helm utiliza uma linguagem de templates (baseada em templates Go) que permite escrever ficheiros de configuração YAML parametrizados.

Por exemplo, aqui está parte de um arquivo YAML que define uma implantação:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "package.fullname" . | replace "." "" }}
  labels:
    app.kubernetes.io/name: {{ include "package.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

...

spec:
  template:
    spec:
      containers:
      - name: &package-container_name fabrikam-package
        image: {{ .Values.dockerregistry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        env:
        - name: LOG_LEVEL
          value: {{ .Values.log.level }}

Pode ver que o nome de implementação, os rótulos e a especificação do contentor usam todos parâmetros de template, que fornece no momento da implementação. Por exemplo, na linha de comando:

helm install <release-name> oci://<registry>/<repository>/<package-chart-name> --version <desiredVersion> \
     --set image.tag=0.1.0 \
     --set image.repository=package \
     --set dockerregistry=$ACR_SERVER \
     --namespace backend

Embora um pipeline CI/CD possa instalar um gráfico diretamente no Kubernetes, criar um arquivo de gráficos (ficheiro .tgz) e enviar o gráfico para um repositório Helm, como o Container Registry. Para mais informações, consulte Pacotes e implantações de gráficos de Helm (tarefa HelmDeploy).

Revisions

Os gráficos de Helm têm sempre um número de versão que deve usar versionamento semântico. Um gráfico também pode ter um appVersion. Este campo é opcional e não precisa de estar relacionado com a versão do gráfico. Algumas equipas podem querer versionar as aplicações separadamente das atualizações dos gráficos. Uma abordagem mais simples é usar um número de versão, para que haja uma relação 1:1 entre a versão do gráfico e a versão da aplicação. Dessa forma, você pode armazenar um gráfico por versão e implantar facilmente a versão desejada:

helm install <package-chart-name> --version <desiredVersion>

Outra boa prática é fornecer uma anotação de causa de alteração no modelo de implantação:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "delivery.fullname" . | replace "." "" }}
  labels:
     ...
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

Esta anotação permite-lhe visualizar o campo de causa de mudança para cada revisão usando o kubectl rollout history comando. No exemplo anterior, a causa de mudança é fornecida como um parâmetro gráfico de Helm.

kubectl rollout history deployments/delivery-v010 -n backend

deployment.apps/delivery-v010
REVISION  CHANGE-CAUSE
1         Initial deployment

Você também pode usar o helm list comando para exibir o histórico de revisões:

helm list -n backend

NAME              NAMESPACE   REVISION    UPDATED                                 STATUS      CHART               APP VERSION
delivery-v0.1.0   backend     1           2024-04-07 00:25:30.000000 +0000 UTC    deployed    delivery-v0.1.0     v0.1.0

Azure Pipelines

Azure Pipelines, um serviço em Azure DevOps, tem dois tipos de pipelines: pipelines de build e pipelines release. O pipeline de build executa o processo de CI e cria artefactos de build. Para uma arquitetura de microsserviços no Kubernetes, esses artefatos são as imagens de contêiner e os gráficos Helm que definem cada microsserviço. O pipeline de lançamento executa o processo CD que implementa um microserviço num cluster.

Com base no fluxo de CI descrito anteriormente neste artigo, um pipeline de compilação pode consistir nas seguintes tarefas:

1. Constrói o contentor do test runner usando a Docker tarefa.
2. Execute os testes invocando docker run contra o contentor do executor de testes usando a Docker tarefa.
3. Publique os resultados do teste usando a PublishTestResults tarefa. Para mais informações, veja Construir uma imagem.
4. Executa o SAST no código-fonte.
5. Constrói o contentor de execução usando local docker build e a Docker tarefa ou usando builds do Container Registry e a AzureCLI tarefa. Gerar uma lista de materiais de software (SBOM) para a imagem, por exemplo, usando a ferramenta SBOM da Microsoft, e publicá-la como um artefacto de pipeline associado ao digest da imagem ou anexá-la à imagem no Registo de Contentores.
6. Execute uma análise de vulnerabilidades de imagens de contentores (por exemplo, usando o Microsoft Defender for Containers ou uma ferramenta não Microsoft como o Trivy) para detetar vulnerabilidades conhecidas antes da publicação da imagem.
7. Empurra a imagem do contentor para o Registo de Contentores (ou outro registo de contentores) usando a Docker tarefa ou AzureCLI .
8. Assine a imagem empurrada pelo Immutable Digest para garantir a sua integridade e autenticidade. Para Azure Pipelines, siga as orientações de assinatura de notação.
9. Empacota o gráfico de Helm usando a HelmDeploy tarefa.
10. Envie o pacote Helm para o Container Registry (ou outro repositório Helm) usando a HelmDeploy tarefa.

A saída do pipeline de CI é uma imagem de contêiner pronta para produção e um gráfico Helm atualizado para o microsserviço. Neste ponto, o pipeline de lançamento pode assumir o controle. Existe um pipeline de lançamento único para cada microserviço. O pipeline de release está configurado para ter uma fonte de trigger definida para o pipeline CI que publicou o artefacto. Este pipeline permite-lhe implementar cada microserviço de forma independente. O pipeline de liberação executa as seguintes etapas:

1. Implante o gráfico Helm em ambientes de desenvolvimento/QA/preparo. Podes usar o helm upgrade comando com a --install bandeira para suportar a primeira instalação e as atualizações subsequentes.
2. Aguarde até que um aprovador aprove ou rejeite a implantação.
3. Remarque a imagem do contentor para divulgação.
4. Envie a tag de liberação para o registro do contêiner.
5. Implante o gráfico Helm no cluster de produção. Use o Ratify com Azure Policy para validar assinaturas de imagem durante a admissão e, separadamente, configure uma política de imagens permitidas para restringir imagens a registos de confiança.

Para obter mais informações sobre como criar um pipeline de versão, consulte Pipelines de versão, versões de rascunho e opções de versão.

O diagrama a seguir mostra o processo de CI/CD de ponta a ponta descrito neste artigo:

Alternativa ao GitHub Actions

Se a tua equipa usa o GitHub para controlo de versão, o GitHub Actions fornece uma plataforma equivalente de CI/CD. Para além dos fluxos de trabalho iniciais e da autenticação OIDC mencionados anteriormente, considere estas capacidades específicas do GitHub quando direcionar o AKS:

• Ambientes e regras de proteção. Se o seu plano GitHub e a visibilidade do repositório os suportarem, use ambientes GitHub com revisores obrigatórios, temporizadores de espera e ramos de implementação para implementar portas de aprovação.
• Digitalização de contentores. Use as ações do marketplace do GitHub Actions para Trivy, Microsoft Defender para DevOps, ou ferramentas semelhantes para digitalização de imagens de contentores diretamente no seu fluxo de trabalho.

Observabilidade e monitorização

Implementar a observabilidade em todo o pipeline CI/CD e ambiente de execução:

• Monitorização de oleodutos. Acompanhe a duração da construção, taxas de aprovação nos testes, frequência de implementação e taxas de falhas. O Azure DevOps fornece análises integradas. O GitHub Actions pode usar dashboards que não sejam da Microsoft.
• Monitorização em tempo de execução. Use o serviço gerido Azure Monitor para Prometheus e Azure Managed Grafana para monitorizar a saúde e as métricas de carga de trabalho do cluster AKS.
• Telemetria de aplicação. Instrumente os seus microserviços com o Azure Monitor Application Insights para rastreamento distribuído, registo de pedidos e rastreamento de dependências.
• Emitindo Alerta Configure alertas para falhas de implementação, reinício de pods, elevadas taxas de erro e saturação de recursos para permitir uma resposta rápida a incidentes.

Well-Architected Alinhamento do quadro

Ao desenhar o seu pipeline CI/CD para microserviços no Kubernetes, considere os pilares do Azure Well-Architected Framework:

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Ray Kao | Engenheiro Principal de Soluções

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Passos seguintes

• Adopt a Git branching strategy (Adotar uma estratégia de ramificação do Git)
• O que é Azure Pipelines?
• Pipelines de lançamento, versões de rascunho e opções de lançamento
• Controle de implantação usando aprovações
• Introdução ao Registro de Contêiner do Azure
• ID de carga de trabalho Microsoft Entra com AKS
• Fornecedor do Cofre de Chaves do Azure para Secrets Store CSI Driver
• DevSecOps no AKS

Recursos relacionados

• CI/CD para microsserviços
• Arquitetura de microserviços em AKS
• Serviço GitOps para Kubernetes do Azure
• Arquitetura de referência para um cluster AKS
• Arquitetura de linha de base CI/CD com Azure Pipelines