Estratégias de implantação azul-verde no Azure Spring Apps
Nota
Azure Spring Apps é o novo nome para o serviço Azure Spring Cloud. Embora o serviço tenha um novo nome, você verá o nome antigo em alguns lugares por um tempo enquanto trabalhamos para atualizar ativos, como capturas de tela, vídeos e diagramas.
Este artigo aplica-se a: ✔️ Basic/Standard ✔️ Enterprise
Este artigo descreve o suporte de implantação azul-verde no Azure Spring Apps.
Azure Spring Apps (plano Standard e superior) permite duas implantações para cada aplicativo, apenas um dos quais recebe tráfego de produção. Esse padrão é comumente conhecido como implantação azul-verde. O suporte do Azure Spring Apps para implantação azul-verde, juntamente com um pipeline de Entrega Contínua (CD) e testes automatizados rigorosos, permite implantações ágeis de aplicativos com alta confiança.
Implantações alternadas
A maneira mais simples de implementar a implantação azul-verde com o Azure Spring Apps é criar duas implantações fixas e sempre implantar na implantação que não está recebendo tráfego de produção. Com a tarefa Azure Spring Apps para Azure Pipelines, você pode implantar dessa maneira apenas definindo o UseStagingDeployment sinalizador como true.
Veja como a abordagem de implantações alternadas funciona na prática:
Suponha que seu aplicativo tenha duas implantações: deployment1 e deployment2. Atualmente, deployment1 é definido como a implantação de produção e está executando a versão v3 do aplicativo.
Isso torna deployment2 a implantação de preparo. Assim, quando o pipeline de Entrega Contínua (CD) estiver pronto para ser executado, ele implantará a próxima versão do aplicativo, versão v4, na implantação deployment2de preparo.
Depois de v4 iniciado no deployment2, você pode executar testes automatizados e manuais em relação a ele por meio de um ponto de extremidade de teste privado para garantir que v4 atenda a todas as expectativas.
Quando você tiver confiança no v4, poderá definir deployment2 como a implantação de produção para que ele receba todo o tráfego de produção. v3 permanecerá em deployment1 execução caso você descubra um problema crítico que exija reversão.
Agora, deployment1 é a implantação de preparação. Portanto, a próxima execução do pipeline de implantação será implantada no deployment1.
Agora você pode testar V5 no deployment1ponto de extremidade de teste privado do .
Finalmente, depois de v5 atender a todas as suas expectativas, você define deployment1 como a implantação de produção mais uma vez, para que v5 receba todo o tráfego de produção.
Compensações da abordagem de implantações alternadas
A abordagem de implantações alternadas é simples e rápida, pois não requer a criação de novas implantações. No entanto, apresenta várias desvantagens, conforme descrito nas secções seguintes.
Implantação de preparo persistente
A implantação de preparo sempre permanece em execução e, portanto, consumindo recursos da instância do Azure Spring Apps. Isso efetivamente dobra os requisitos de recursos de cada aplicativo no Azure Spring Apps.
A condição da corrida de aprovação
Suponha que, no aplicativo acima, o pipeline de liberação exija aprovação manual antes que cada nova versão do aplicativo possa receber tráfego de produção. Isso cria o risco de que, enquanto uma versão (v6) aguarda aprovação manual na implantação de preparo, o pipeline de implantação será executado novamente e o substituirá por uma versão mais recente (v7). Em seguida, quando a aprovação for v6 concedida, o pipeline implantado v6 definirá a implantação de preparo como produção. Mas agora será o não aprovado v7, não o aprovado v6, que é implantado nessa implantação e recebe tráfego.
Talvez seja possível evitar a condição de corrida garantindo que o fluxo de implantação de uma versão não possa começar até que o fluxo de implantação de todas as versões anteriores seja concluído ou abortado. Outra maneira de evitar a condição de corrida de aprovação é usar a abordagem de implantações nomeadas descrita abaixo.
Implantações nomeadas
Na abordagem de implantações nomeadas, uma nova implantação é criada para cada nova versão do aplicativo que está sendo implantado. Depois que o aplicativo é testado em sua implantação personalizada, essa implantação é definida como a implantação de produção. A implantação que contém a versão anterior pode persistir apenas o tempo suficiente para ter certeza de que uma reversão não será necessária.
Na ilustração abaixo, a versão v5 está sendo executada na implantação deployment-v5. O nome da implantação agora contém a versão porque a implantação foi criada especificamente para essa versão. Não há outra implantação no início. Agora, para implantar a versão v6, o pipeline de implantação cria uma nova implantação deployment-v6 e implanta a versão v6 do aplicativo lá.
Não há risco de outra versão ser implantada em paralelo. Primeiro, o Azure Spring Apps não permite a criação de uma terceira implantação enquanto já existem duas implantações. Em segundo lugar, mesmo que fosse possível ter mais de duas implantações, cada implantação é identificada pela versão do aplicativo que contém. Assim, o pipeline orquestrando a implantação do apenas tentaria definir deployment-v6 como a implantação de v6 produção.
Depois que a implantação criada para a nova versão receber tráfego de produção, você precisará remover a implantação que contém a versão anterior para abrir espaço para implantações futuras. Você pode querer adiar por algum número de minutos ou horas para que possa reverter para a versão anterior se descobrir um problema crítico na nova versão.
Compensações da abordagem de implantações nomeadas
A abordagem de implantações nomeadas tem os seguintes benefícios:
- Impede a condição de corrida de aprovação.
- Ele reduz o consumo de recursos excluindo a implantação de preparo quando ela não está em uso.
No entanto, também há desvantagens, conforme descrito na seção a seguir.
Falhas no pipeline de implantação
Entre o momento em que uma implantação é iniciada e o momento em que a implantação de preparo é excluída, quaisquer tentativas adicionais de executar o pipeline de implantação falharão. O pipeline tentará criar uma nova implantação, o que resultará em um erro porque apenas duas implantações são permitidas por aplicativo no Azure Spring Apps.
Portanto, a orquestração de implantação deve ter os meios para repetir um processo de implantação com falha em um momento posterior ou os meios para garantir que os fluxos de implantação para cada versão permaneçam na fila até que o fluxo seja concluído para todas as versões anteriores.