CI/CD para arquiteturas de microsserviçosCI/CD for microservices architectures

Ciclos de lançamento mais rápidos são uma das principais vantagens de arquiteturas de microsserviços.Faster release cycles are one of the major advantages of microservices architectures. Mas sem um bom processo de CI/CD, não conseguirá chegar a agilidade que prometem de microsserviços.But without a good CI/CD process, you won't achieve the agility that microservices promise. Este artigo descreve os desafios e recomenda algumas abordagens para o problema.This article describes the challenges and recommends some approaches to the problem.

O que é o CI/CD?What is CI/CD?

Quando falamos sobre CI/CD, estamos realmente falando sobre os vários processos relacionados: Integração contínua, entrega contínua e implementação contínua.When we talk about CI/CD, we're really talking about several related processes: Continuous integration, continuous delivery, and continuous deployment.

  • Integração contínua.Continuous integration. Alterações de código com freqüência são intercaladas no ramo principal.Code changes are frequently merged into the main branch. Automatizado de compilação e processos de teste Certifique-se de que o código da ramificação principal é sempre qualidade de produção.Automated build and test processes ensure that code in the main branch is always production-quality.

  • Entrega contínua.Continuous delivery. Quaisquer alterações de código que passam o processo de CI são automaticamente publicadas para um ambiente de produção simulado.Any code changes that pass the CI process are automatically published to a production-like environment. Implantação no ambiente de produção em direto pode exigir a aprovação manual, mas caso contrário, é automatizada.Deployment into the live production environment may require manual approval, but is otherwise automated. O objetivo é que seu código deve ser sempre pronto para implementar para produção.The goal is that your code should always be ready to deploy into production.

  • Implementação contínua.Continuous deployment. Código altera os dois passos anteriores são implementados automaticamente aprovados em produção.Code changes that pass the previous two steps are automatically deployed into production.

Aqui estão alguns objetivos de um processo de CI/CD robusto para uma arquitetura de microsserviços:Here are some goals of a robust CI/CD process for a microservices architecture:

  • Cada equipe pode criar e implementar os serviços que ele é proprietário de forma independente, sem afetar ou interromper outras equipes.Each team can build and deploy the services that it owns independently, without affecting or disrupting other teams.

  • Antes de uma nova versão de um serviço for implementada para produção, é implementada para ambientes de dev/teste/controle de qualidade para a validação.Before a new version of a service is deployed to production, it gets deployed to dev/test/QA environments for validation. Limites de qualidade são impostas em cada estágio.Quality gates are enforced at each stage.

  • Uma nova versão de um serviço pode ser implantada lado a lado com a versão anterior.A new version of a service can be deployed side by side with the previous version.

  • Políticas de controlo de acesso suficientes estão em vigor.Sufficient access control policies are in place.

  • Para cargas de trabalho em contentores, que pode confiar as imagens de contentor que são implementadas em produção.For containerized workloads, you can trust the container images that are deployed to production.

Por que um pipeline de CI/CD robusto é importanteWhy a robust CI/CD pipeline matters

Numa aplicação monolítica tradicional, há um pipeline de compilação único cuja saída é o executável do aplicativo.In a traditional monolithic application, there is a single build pipeline whose output is the application executable. Todos os feeds de trabalho de desenvolvimento para este pipeline.All development work feeds into this pipeline. Se não for encontrado um bug de alta prioridade, uma correção deve ser integrada, testada e publicada, que pode atrasar o lançamento de novas funcionalidades.If a high-priority bug is found, a fix must be integrated, tested, and published, which can delay the release of new features. Pode reduzir esses problemas com módulos bem fatorados e ao utilizar ramos de funcionalidade para minimizar o impacto de alterações de código.You can mitigate these problems by having well-factored modules and using feature branches to minimize the impact of code changes. Mas, à medida que o aplicativo cresce mais complexo e, mais funcionalidades são adicionadas, o processo de lançamento para um monólito tende a se tornarem mais frágil e corrompido.But as the application grows more complex, and more features are added, the release process for a monolith tends to become more brittle and likely to break.

Seguindo a filosofia de microsserviços, nunca deve haver um comboio de versão longo em que cada equipe tem obter na linha.Following the microservices philosophy, there should never be a long release train where every team has to get in line. A equipe que cria o serviço "A" pode libertar uma atualização em qualquer altura, sem aguardar que as alterações no serviço "B" a serem intercalados, testado e implementado.The team that builds service "A" can release an update at any time, without waiting for changes in service "B" to be merged, tested, and deployed.

Diagrama de uma solução de CI/CD

Para obter uma maior velocidade de lançamento, seu pipeline de lançamento deve ser automatizada e altamente confiável para minimizar o risco.To achieve a high release velocity, your release pipeline must be automated and highly reliable to minimize risk. Se de versão para produção de um ou mais vezes diariamente, regressões ou interrupções de serviço tem de ser raras.If you release to production one or more times daily , regressions or service disruptions must be rare. Ao mesmo tempo, se implementada uma atualização incorreta, tem de ter uma forma fiável para rapidamente reverter ou efetuar para uma versão anterior de um serviço.At the same time, if a bad update does get deployed, you must have a reliable way to quickly roll back or roll forward to a previous version of a service.

DesafiosChallenges

  • Muitas bases de código independente pequenas.Many small independent code bases. Cada equipe é responsável por construir seu próprio serviço, com seu próprio pipeline de compilação.Each team is responsible for building its own service, with its own build pipeline. Em algumas organizações, equipes podem usar os repositórios de código separado.In some organizations, teams may use separate code repositories. Repositórios separados podem levar a uma situação em que o conhecimento de como criar o sistema é distribuído por entre as equipes e ninguém na organização sabe como implementar o aplicativo inteiro.Separate repositories can lead to a situation where the knowledge of how to build the system is spread across teams, and nobody in the organization knows how to deploy the entire application. Por exemplo, o que acontece num cenário de recuperação após desastre, se precisar de implementar rapidamente para um novo cluster?For example, what happens in a disaster recovery scenario, if you need to quickly deploy to a new cluster?

    Atenuação: Ter uma pipeline automatizada e unificada para criar e implementar serviços, para que esse conhecimento não é "oculto" dentro de cada equipe.Mitigation: Have a unified and automated pipeline to build and deploy services, so that this knowledge is not "hidden" within each team.

  • Várias linguagens e arquiteturas.Multiple languages and frameworks. Com cada equipe que usa sua própria combinação de tecnologias, ele pode ser difícil de criar um processo de compilação única que funciona em toda a organização.With each team using its own mix of technologies, it can be difficult to create a single build process that works across the organization. O processo de compilação tem de ser suficientemente flexível para que todas as equipes podem adaptá-lo para a sua escolha de linguagem ou arquitetura.The build process must be flexible enough that every team can adapt it for their choice of language or framework.

    Atenuação: Crie contentores o processo de compilação para cada serviço.Mitigation: Containerize the build process for each service. Dessa forma, o sistema de compilação apenas tem de ser capaz de executar os contentores.That way, the build system just needs to be able to run the containers.

  • Integração e o teste de carga.Integration and load testing. Com as equipes de lançar atualizações em seu próprio ritmo, pode ser um desafio para estruturar robusta-a-ponto de teste, especialmente quando os serviços têm dependências noutros serviços.With teams releasing updates at their own pace, it can be challenging to design robust end-to-end testing, especially when services have dependencies on other services. Além disso, a executar um cluster de produção completo pode ser Caro, portanto, é improvável que todas as equipes executará seu próprio cluster completo em escalas de produção, apenas para teste.Moreover, running a full production cluster can be expensive, so it's unlikely that every team will run its own full cluster at production scales, just for testing.

  • Gestão de versões.Release management. Cada equipe deve ser capaz de implantar uma atualização para a produção.Every team should be able to deploy an update to production. Isso não significa que todos os membros da Equipe tem permissões para fazer isso.That doesn't mean that every team member has permissions to do so. Mas ter uma função de gerente de versão centralizado pode reduzir a velocidade das implementações.But having a centralized Release Manager role can reduce the velocity of deployments.

    Atenuação: Mais que o seu processo de CI/CD é automatizado e fiável, deve ser a menos daí a necessidade de uma autoridade central.Mitigation: The more that your CI/CD process is automated and reliable, the less there should be a need for a central authority. Dito isso, poderá ter diferentes políticas para lançar atualizações de funcionalidades principais versus pequenas correções de erros.That said, you might have different policies for releasing major feature updates versus minor bug fixes. A ser descentralizado não significa que a governação de zero.Being decentralized doesn't mean zero governance.

  • As atualizações de serviço.Service updates. Quando atualizar um serviço para uma nova versão, não deve interromper a outros serviços que dependem dele.When you update a service to a new version, it shouldn't break other services that depend on it.

    Atenuação: Utilize técnicas de implantação, como a versão de "blue-Green" ou canary para alterações sem interrupções.Mitigation: Use deployment techniques such as blue-green or canary release for non-breaking changes. De quebras de API, implemente a nova versão lado a lado com a versão anterior.For breaking API changes, deploy the new version side by side with the previous version. Dessa forma, os serviços que consomem a API anterior podem ser atualizados e testados para a nova API.That way, services that consume the previous API can be updated and tested for the new API. Ver serviços de atualização, abaixo.See Updating services, below.

Monorepo versus multi repositórioMonorepo vs. multi-repo

Antes de criar um fluxo de trabalho de CI/CD, deve saber como a base de código será estruturada e gerenciada.Before creating a CI/CD workflow, you must know how the code base will be structured and managed.

  • As equipas funcionam nos repositórios separados ou num monorepo (único repositório)?Do teams work in separate repositories or in a monorepo (single repository)?
  • O que é a sua estratégia de ramificação?What is your branching strategy?
  • Quem pode emitir o código de produção?Who can push code to production? Existe uma função de Gestor de versão?Is there a release manager role?

A abordagem de monorepo tem vindo a ganhar favor, mas há vantagens e desvantagens para ambos.The monorepo approach has been gaining favor but there are advantages and disadvantages to both.

  MonorepoMonorepo Vários repositóriosMultiple repos
VantagensAdvantages Compartilhamento de códigoCode sharing
Mais fácil padronizar o código e as ferramentasEasier to standardize code and tooling
Mais fácil para refatorar o códigoEasier to refactor code
Capacidade de deteção - única vista do códigoDiscoverability - single view of the code
Propriedade clara por equipeClear ownership per team
Potencialmente menos conflitos de intercalaçãoPotentially fewer merge conflicts
Ajuda a impor a separação dos microsserviçosHelps to enforce decoupling of microservices
DesafiosChallenges Alterações ao código compartilhado podem afetar múltiplos microsserviçosChanges to shared code can affect multiple microservices
Maior possibilidade de conflitos de intercalaçãoGreater potential for merge conflicts
As ferramentas tem de dimensionar para uma base de códigos grandesTooling must scale to a large code base
Controlo de acessoAccess control
Processo de implantação mais complexoMore complex deployment process
Mais difícil de compartilhar códigoHarder to share code
Mais difícil de impor padrões de codificaçãoHarder to enforce coding standards
Gestão de dependênciasDependency management
Diffuse detectabilidade de base, fraco de códigoDiffuse code base, poor discoverability
Falta de infraestrutura partilhadaLack of shared infrastructure

Serviços de atualizaçãoUpdating services

Existem várias estratégias para atualizar um serviço que já esteja em produção.There are various strategies for updating a service that's already in production. Aqui, abordamos três opções comuns: Implementar a atualização, a implementação de "blue-Green" e versão canary.Here we discuss three common options: Rolling update, blue-green deployment, and canary release.

Implementar atualizaçõesRolling updates

Uma atualização sem interrupção, implementa novas instâncias de um serviço e as novas instâncias começar a receber pedidos de imediato.In a rolling update, you deploy new instances of a service, and the new instances start receiving requests right away. Como as novas instâncias surgem o tempo limite, as instâncias anteriores são removidas.As the new instances come up, the previous instances are removed.

Exemplo.Example. No Kubernetes, atualizações sem interrupção são o comportamento predefinido quando atualizar a especificação de pod para uma implementação.In Kubernetes, rolling updates are the default behavior when you update the pod spec for a Deployment. O controlador de implementação cria uma nova ReplicaSet para os pods atualizados.The Deployment controller creates a new ReplicaSet for the updated pods. Em seguida, o dimensionamento a ReplicaSet novo ao reduzir verticalmente o um antigo, para manter a contagem de réplica pretendido.Then it scales up the new ReplicaSet while scaling down the old one, to maintain the desired replica count. Não elimina os pods antigos até que as novas esteja prontas.It doesn't delete old pods until the new ones are ready. Kubernetes mantém um histórico da atualização, portanto, pode reverter uma atualização se for necessário.Kubernetes keeps a history of the update, so you can roll back an update if needed.

Exemplo.Example. O Azure Service Fabric utiliza a estratégia de atualização sem interrupção por predefinição.Azure Service Fabric uses the rolling update strategy by default. Esta estratégia é mais adequada para a implementação de uma versão de um serviço com as novas funcionalidades sem alterar as APIs existentes.This strategy is best suited for deploying a version of a service with new features without changing existing APIs. Service Fabric inicia uma implantação de atualização ao atualizar o tipo de aplicação a um subconjunto de nós ou um domínio de atualização.Service Fabric starts an upgrade deployment by updating the application type to a subset of the nodes or an update domain. Ele, em seguida, avança para o domínio de atualização seguinte até que todos os domínios são atualizados.It then rolls forward to the next update domain until all domains are upgraded. Se um domínio de atualização não consegue atualizar, o tipo de aplicação reverte para a versão anterior em todos os domínios.If an upgrade domain fails to update, the application type rolls back to the previous version across all domains. Lembre-se de que tipo de uma aplicação com vários serviços (e se todos os serviços são atualizados como parte de uma implementação de atualização) é propensa a falhas.Be aware that an application type with multiple services (and if all services are updated as part of one upgrade deployment) is prone to failure. Se um serviço não consegue atualizar, todo o aplicativo é revertido para a versão anterior e os outros serviços não são atualizados.If one service fails to update, the entire application is rolled back to the previous version and the other services are not updated.

Um desafio de implementar atualizações é que durante o processo de atualização, uma mistura antigos e novas versões estão em execução e receber tráfego.One challenge of rolling updates is that during the update process, a mix of old and new versions are running and receiving traffic. Durante este período, qualquer solicitação poderia é roteada para qualquer uma das duas versões.During this period, any request could get routed to either of the two versions.

De quebras de API, uma boa prática é suportar as duas versões lado a lado, até que todos os clientes da versão anterior estão atualizados.For breaking API changes, a good practice is to support both versions side by side, until all clients of the previous version are updated. Ver controlo de versões de API.See API versioning.

Implementação de "blue-Green"Blue-green deployment

Uma implementação de "blue-Green", é possível implementar a nova versão juntamente com a versão anterior.In a blue-green deployment, you deploy the new version alongside the previous version. Depois de validar a nova versão, optar por todo o tráfego de uma só vez da versão anterior para a nova versão.After you validate the new version, you switch all traffic at once from the previous version to the new version. Após a mudança do utilizador, monitorizar a aplicação para quaisquer problemas.After the switch, you monitor the application for any problems. Se algo der errado, pode alternar para a versão antiga.If something goes wrong, you can swap back to the old version. Partindo do princípio de que não existem problemas, pode eliminar a versão antiga.Assuming there are no problems, you can delete the old version.

Com um aplicativo mais tradicional monolítico ou de N camadas, implementação de "blue-Green" significava geralmente aprovisionamento dois ambientes idênticos.With a more traditional monolithic or N-tier application, blue-green deployment generally meant provisioning two identical environments. Poderia implementar a nova versão num ambiente de teste, em seguida, redirecionar o tráfego de cliente para o ambiente de teste — por exemplo, trocando VIP endereços.You would deploy the new version to a staging environment, then redirect client traffic to the staging environment — for example, by swapping VIP addresses. Numa arquitetura de microsserviços, as atualizações ocorrem ao nível da microsserviços, para que normalmente seria implementar a atualização para o mesmo ambiente e utilize um mecanismo de deteção de serviço para mudar.In a microservices architecture, updates happen at the microservice level, so you would typically deploy the update into the same environment and use a service discovery mechanism to swap.

Exemplo.Example. No Kubernetes, não precisa de aprovisionar um cluster separado para fazer Implantações de "blue-Green".In Kubernetes, you don't need to provision a separate cluster to do blue-green deployments. Em vez disso, pode tirar partido de seletores.Instead, you can take advantage of selectors. Crie um novo recurso de implementação com uma nova especificação de pod e um conjunto diferente de etiquetas.Create a new Deployment resource with a new pod spec and a different set of labels. Crie esta implementação, sem a eliminar a implementação anterior ou modificando o serviço que aponta para ela.Create this deployment, without deleting the previous deployment or modifying the service that points to it. Assim que estiver a executar os pods de novo, pode atualizar o seletor do serviço de acordo com a nova implementação.Once the new pods are running, you can update the service's selector to match the new deployment.

Uma desvantagem da implementação "blue-Green" é que durante a atualização, está a executar duas vezes mais pods para o serviço (atual e seguinte).One drawback of blue-green deployment is that during the update, you are running twice as many pods for the service (current and next). Se os pods exigem muitos recursos de CPU ou memória, poderá ter de aumentar horizontalmente o cluster temporariamente para lidar com o consumo de recursos.If the pods require a lot of CPU or memory resources, you may need to scale out the cluster temporarily to handle the resource consumption.

Versão canaryCanary release

Numa versão canary, implementar uma versão atualizada para um pequeno número de clientes.In a canary release, you roll out an updated version to a small number of clients. Em seguida, monitorar o comportamento do novo serviço antes de implantá-la em todos os clientes.Then you monitor the behavior of the new service before rolling it out to all clients. Isto permite-lhe fazer uma implementação lenta de maneira controlada, verifique os dados reais e detete os problemas antes de todos os clientes serem afetados.This lets you do a slow rollout in a controlled fashion, observe real data, and spot problems before all customers are affected.

Uma versão canary é mais complexa de gerenciar do que a atualização de "blue-Green" ou sem interrupção, porque tem dinamicamente encaminhar os pedidos para versões diferentes do serviço.A canary release is more complex to manage than either blue-green or rolling update, because you must dynamically route requests to different versions of the service.

Exemplo.Example. No Kubernetes, pode configurar um serviço para abranger dois conjuntos de réplica (uma para cada versão) e ajustar as contagens de réplica manualmente.In Kubernetes, you can configure a Service to span two replica sets (one for each version) and adjust the replica counts manually. No entanto, essa abordagem é refinada em vez disso, devido a forma como o Kubernetes carregar equilibra nas pods.However, this approach is rather coarse-grained, because of the way Kubernetes load balances across pods. Por exemplo, se tiver um total de 10 réplicas, apenas pode mudar o tráfego em incrementos de 10%.For example, if you have a total of 10 replicas, you can only shift traffic in 10% increments. Se estiver a utilizar uma malha de serviço, pode utilizar as regras de roteamento de malha de serviço para implementar uma estratégia de versão canary mais sofisticada.If you are using a service mesh, you can use the service mesh routing rules to implement a more sophisticated canary release strategy.

Passos SeguintesNext steps

Conheça práticas específicas de CI/CD para microsserviços em execução no Kubernetes.Learn specific CI/CD practices for microservices running on Kubernetes.