Estratégias de implantação azul-verde no Azure Spring Apps
Observação
Azure Spring Apps é o novo nome do serviço Azure Spring Cloud. Embora o serviço tenha um novo nome, você verá o nome antigo em alguns locais por um tempo enquanto trabalhamos para atualizar ativos como capturas de tela, vídeos e diagramas.
Este artigo se aplica ao: ✔️ nível Básico/Standard ✔️ nível Enterprise
Este artigo descreve o suporte à implantação azul-verde no Azure Spring Apps.
Os Aplicativos Spring do Azure (plano Standard e superior) permite duas implantações para cada aplicativo, sendo que apenas uma delas recebe o tráfego de produção. Esse padrão é normalmente conhecido como implantação azul-verde. O suporte do Azure Spring Apps para implantação azul-verde, junto com um pipeline de CD (entrega contínua) e testes automatizados rigorosos, permite implantações de aplicativos ágeis com alta confiança.
Implantações alternadas
A maneira mais simples de fazer a implantação azul-verde com o Azure Spring Apps é criar duas implantações fixas e sempre implantar na implantação que não esteja recebendo o tráfego de produção. Com a tarefa do Azure Spring Apps para o Azure Pipelines, você pode implantar dessa maneira apenas definindo o sinalizador UseStagingDeployment 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 de preparo deployment2.
Depois da v4 ter iniciado na deployment2, você pode executar testes automatizados e manuais nela por meio de um ponto de extremidade de teste privado para garantir que a v4 atenda a todas as expectativas.
Quando você tiver confiança na v4, poderá definir deployment2 como a implantação de produção para que ela receba todo o tráfego de produção. A v3 permanecerá em execução na deployment1 caso você descubra um problema crítico que exija a reversão.
Agora, deployment1 é a implantação de preparo. Portanto, a próxima sequência do pipeline de implantação é implantada na deployment1.
Agora você pode testar V5 no ponto de extremidade de teste privado da deployment1.
Por fim, depois que a v5 atender a todas as suas expectativas, você definirá deployment1 como a implantação de produção mais uma vez, para que a v5 receba todo o tráfego de produção.
Questões possíveis na 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, ela apresenta várias desvantagens, conforme descrito nas seções a seguir.
Implantação de preparação persistente
A implantação de preparação 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 de corrida de aprovação
Suponha que, no aplicativo acima, o pipeline de lançamento exija aprovação manual antes que cada nova versão do aplicativo possa receber o tráfego de produção. Isso cria o risco de que enquanto uma versão (v6) aguarda aprovação manual na implantação de preparação, o pipeline de implantação será executado novamente e a substituirá por uma versão mais recente (v7). Em seguida, quando a aprovação para v6 for concedida, o pipeline que implantou a v6 definirá a implantação de preparação como produção. Mas agora ele será a v7 não aprovada, e não a v6 aprovada, que é implantada nessa implantação e recebe tráfego.
Você pode impedir a condição de corrida garantindo que o fluxo de implantação de uma versão não comece até que o fluxo de implantação de todas as versões anteriores seja concluído ou anulado. 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 ter permissão para persistir por tempo suficiente para se ter certeza de que uma reversão não será necessária.
Na ilustração a seguir, a versão v5 está em execução na implantação deployment-v5. O nome da implantação agora contém a versão porque a implantação foi criada especificamente para esta versão. Não há nenhuma 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 do aplicativo v6 lá.
Não há nenhum risco de que outra versão seja implantada em paralelo. Primeiro, o Azure Spring Apps não permite a criação de uma terceira implantação enquanto duas implantações já existem. Em segundo lugar, mesmo que fosse possível ter mais de duas implantações, cada implantação é identificada pela versão do aplicativo que ela contém. Assim, o pipeline que orquestra a implantação da v6 tentaria apenas definir deployment-v6 como a implantação de produção.
Depois que a implantação criada para a nova versão receber o tráfego de produção, você precisará remover a implantação que contém a versão anterior para liberar espaço para futuras implantações. Talvez você queira adiar por alguns minutos ou horas para poder reverter para a versão anterior se descobrir um problema crítico na nova versão.
Questões da abordagem de implantações nomeadas
A abordagem de implantações nomeadas tem os seguintes benefícios:
- Ela impede a condição de corrida de aprovação.
- Ele reduz o consumo de recursos excluindo a implantação de preparação quando esta não está em uso.
No entanto, também há desvantagens, conforme descrito na seção a seguir.
Falhas de pipeline de implantação
Entre o momento em que uma implantação é iniciada e a hora em que a implantação de preparação é excluída, qualquer tentativa adicional de executar o pipeline de implantação falhará. O pipeline tentará criar uma 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 posteriormente 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.