Atualizar e implantar alterações nos Aplicativos de Contêiner do Azure
O gerenciamento de alterações pode ser um desafio à medida que você desenvolve aplicativos em contêineres na nuvem. Em última análise, você precisa do suporte para acompanhar as alterações, garantir o tempo de atividade e ter mecanismos para lidar com reversões suaves.
O gerenciamento de alterações nos Aplicativos de Contêiner do Azure é alimentado por revisões, que são um instantâneo de cada versão do seu aplicativo de contêiner.
As principais características das revisões incluem:
Imutável: Uma vez estabelecida, uma revisão permanece imutável.
Versioned: As revisões funcionam como um registro das versões do aplicativo contêiner, capturando seu estado em vários estágios.
Provisionado automaticamente: quando você implanta um aplicativo de contêiner pela primeira vez, uma revisão inicial é criada automaticamente.
Alterações de escopo: embora as revisões permaneçam estáticas, as alterações no escopo do aplicativo podem afetar todas as revisões, enquanto as alterações no escopo da revisão criam uma nova revisão.
Registro histórico: por padrão, você tem acesso a 100 revisões inativas, mas pode ajustar esse limite manualmente.
Várias revisões: você pode executar várias revisões simultaneamente. Esse recurso é especialmente benéfico quando você precisa gerenciar diferentes versões do seu aplicativo simultaneamente.
Ciclo de vida
Cada revisão passa por estados específicos, influenciados pelo seu estado e disponibilidade. Durante seu ciclo de vida, um aplicativo de contêiner passa por diferentes provisionamentos, execução e status inativo.
Status de provisionamento
Quando você cria uma nova revisão, o aplicativo de contêiner passa por verificações de inicialização e preparação. Durante essa fase, o status de provisionamento serve como um guia para acompanhar o progresso do aplicativo contêiner.
| Estado | Description |
|---|---|
| Aprovisionamento | A revisão está em processo de verificação. |
| Aprovisionado | A revisão foi aprovada em todas as verificações. |
| Falha no aprovisionamento | A revisão encontrou problemas durante a verificação. |
Estado de execução
Depois que um aplicativo contêiner é provisionado com êxito, uma revisão entra em sua fase operacional. O status de execução ajuda a monitorar a integridade e a funcionalidade de um aplicativo contêiner.
| Estado | Description |
|---|---|
| Aprovisionamento | A revisão está em processo de verificação. |
| Escala até 0 | Zero réplicas em execução e não provisionamento de novas réplicas. O aplicativo de contêiner pode criar novas réplicas se as regras de escala forem acionadas. |
| Ativação | Zero réplicas em execução, uma réplica sendo provisionada. |
| Falha na ativação | A primeira réplica não foi provisionada. |
| Dimensionamento / Processamento | Está a ocorrer uma expansão para dentro ou para fora. Uma ou mais réplicas estão em execução, enquanto outras réplicas estão sendo provisionadas. |
| Em Execução | Uma ou mais réplicas estão em execução. Não há problemas a comunicar. |
| Em execução (no máximo) | O número máximo de réplicas (de acordo com as regras de escala da revisão) está em execução. Não há problemas a comunicar. |
| Desprovisionamento | A revisão está passando de ativa para inativa e está removendo todos os recursos criados. |
| Degradado | Pelo menos uma réplica na revisão está em um estado de falha. Veja os detalhes do estado de execução para problemas específicos. |
| Falhou | Erros críticos causaram falhas nas revisões. O estado de execução fornece detalhes. As causas comuns incluem: • Rescisão • Código de saída 137 |
Estado inativo
As revisões também podem entrar em um estado inativo. Essas revisões não possuem estados de provisionamento ou execução. No entanto, os Aplicativos de Contêiner do Azure mantêm uma lista dessas revisões, acomodando até 100 entradas inativas. Você pode ativar uma revisão a qualquer momento.
Alterar limite de revisão inativo
Você pode usar o parâmetro com os containerapp create comandos ou containerapp update para controlar o --max-inactive-revisions número de revisões inativas controladas por Aplicativos de Contêiner.
Este exemplo demonstra como criar um novo aplicativo de contêiner que rastreia 50 revisões inativas:
az containerapp create --max-inactive-revisions 50
Modos de revisão
Os Aplicativos de Contêiner do Azure dão suporte a dois modos de revisão. Sua escolha de modo determina quantas revisões do seu aplicativo estão ativas simultaneamente.
| Modos de revisão | Description | Predefinido |
|---|---|---|
| Única | Novas revisões são automaticamente provisionadas, ativadas e dimensionadas para o tamanho desejado. Quando todas as réplicas estiverem em execução conforme definido pela regra de escala, o tráfego será desviado da versão antiga para a nova. Se uma atualização falhar, o tráfego permanecerá apontado para a revisão antiga. As revisões antigas são automaticamente desprovisionadas. | Sim |
| Várias | Você pode ter várias revisões ativas, dividir o tráfego entre revisões e escolher quando desprovisionar revisões antigas. Esse nível de controle é útil para testar várias versões de um aplicativo, testar azul-verde ou assumir o controle total das atualizações do aplicativo. Consulte a divisão de tráfego para obter mais detalhes. |
Etiquetas
Para aplicativos de contêiner com tráfego HTTP externo, os rótulos direcionam o tráfego para revisões específicas. Um rótulo fornece uma URL exclusiva que você pode usar para rotear o tráfego para a revisão atribuída ao rótulo.
Para alternar o tráfego entre revisões, você pode mover o rótulo de uma revisão para outra.
- Os rótulos mantêm o mesmo URL quando movidos de uma revisão para outra.
- Um rótulo só pode ser aplicado a uma revisão de cada vez.
- A alocação para divisão de tráfego não é necessária para revisões com rótulos.
- Os rótulos são mais úteis quando o aplicativo está no modo de revisão múltipla.
- Você pode ativar rótulos, divisão de tráfego ou ambos.
Os rótulos são úteis para testar novas revisões. Por exemplo, quando você deseja dar acesso a um conjunto de usuários de teste, você pode dar-lhes o URL do rótulo. Em seguida, quando quiser mover os usuários para uma revisão diferente, você poderá mover o rótulo para essa revisão.
As etiquetas funcionam independentemente da divisão do tráfego. A divisão de tráfego distribui o tráfego que vai para a URL do aplicativo contêiner para revisões com base na porcentagem de tráfego. Quando o tráfego é direcionado para a URL de um rótulo, o tráfego é roteado para uma revisão específica.
O nome do rótulo deve:
- Consistem em caracteres alfanuméricos minúsculos ou traços (
-) - Começar com um caractere alfabético
- Terminar com um caractere alfanumérico
Os rótulos não devem:
- Ter dois traços consecutivos (
--) - Ter mais de 64 caracteres
Você pode gerenciar rótulos na página de gerenciamento de revisão do seu aplicativo de contêiner no portal do Azure.
O URL do rótulo está disponível no painel de detalhes da revisão.
Implementação sem tempo de inatividade
No modo de revisão única, o Container Apps garante que seu aplicativo não tenha tempo de inatividade ao criar uma nova revisão. A revisão ativa existente não é desativada até que a nova revisão esteja pronta.
Se a entrada estiver habilitada, a revisão existente continuará a receber 100% do tráfego até que a nova revisão esteja pronta.
Uma nova revisão é considerada pronta quando:
- A revisão foi provisionada com êxito
- A revisão foi ampliada para corresponder à contagem de réplicas de revisões anteriores (respeitando a contagem mínima e máxima de réplicas da nova revisão)
- Todas as réplicas passaram por suas sondas de inicialização e prontidão
No modo de revisão múltipla, você pode controlar quando as revisões são ativadas ou desativadas e quais revisões recebem tráfego de entrada. Se uma regra de divisão de tráfego estiver configurada com latestRevision definido como true, o tráfego não alternará para a revisão mais recente até que esteja pronto.
Trabalhar com várias revisões
Embora o modo de revisão única seja o padrão, às vezes você pode querer ter controle total sobre como suas revisões são gerenciadas.
O modo de revisão múltipla dá-lhe a flexibilidade de gerir a sua revisão manualmente. Por exemplo, usar o modo de revisão múltipla permite que você decida exatamente quanto tráfego é alocado para cada revisão.
Divisão de tráfego
O diagrama a seguir mostra um aplicativo contêiner com duas revisões.
Esse cenário presume que o aplicativo contêiner esteja no seguinte estado:
- A entrada está habilitada, disponibilizando o aplicativo contêiner via HTTP ou TCP.
- A primeira revisão foi implantada como Revisão 1.
- Depois que o contêiner foi atualizado, uma nova revisão foi ativada como Revisão 2.
- As regras de divisão de tráfego são configuradas para que a Revisão 1 receba 80% das solicitações e a Revisão 2 receba os 20% restantes.
Acesso direto à revisão
Em vez de usar uma regra de roteamento para desviar o tráfego para uma revisão, convém disponibilizar uma revisão para solicitações de uma URL específica. O modo de revisão múltipla pode permitir que você envie todas as solicitações que chegam ao seu domínio para a revisão mais recente, enquanto as solicitações de uma revisão mais antiga estão disponíveis por meio de rótulos para acesso direto.
Estado de ativação
No modo de revisão múltipla, você pode ativar ou desativar revisões conforme necessário. As revisões ativas são operacionais e podem lidar com solicitações, enquanto as revisões inativas permanecem inativas.
O Container Apps não cobra por revisões inativas. No entanto, há um limite para o número total de revisões disponíveis, com as mais antigas sendo eliminadas quando você exceder uma contagem de 100.
Tipos de alterações
As alterações em um aplicativo de contêiner se enquadram em duas categorias: alterações de escopo de revisão ou alterações de escopo de aplicativo. As alterações no escopo de revisão acionam uma nova revisão quando você implanta seu aplicativo, enquanto as alterações no escopo do aplicativo não.
Alterações no âmbito da revisão
Uma nova revisão é criada quando um aplicativo de contêiner é atualizado com alterações no escopo de revisão. As alterações são limitadas à revisão na qual são implantadas e não afetam outras revisões.
Uma alteração de escopo de revisão é qualquer alteração nos parâmetros na properties.template seção do modelo de recurso de aplicativo de contêiner.
Estes parâmetros incluem:
- Sufixo de revisão
- Configuração e imagens de contêiner
- Regras de dimensionamento para o aplicativo de contêiner
Alterações no âmbito da aplicação
Quando você implanta um aplicativo de contêiner com alterações no escopo do aplicativo:
- As alterações são aplicadas globalmente a todas as revisões.
- Uma nova revisão não é criada.
As alterações no escopo do aplicativo são definidas como qualquer alteração nos parâmetros na properties.configuration seção do modelo de recurso do aplicativo contêiner.
Estes parâmetros incluem:
- Valores secretos (as revisões devem ser reiniciadas antes que um contêiner reconheça novos valores secretos)
- Modo de revisão
- Configuração de ingresso, incluindo:
- Ativar ou desativar a entrada
- Regras de divisão de tráfego
- Etiquetas
- Credenciais para registros de contêineres privados
- Configurações do Dapr
Personalizar revisões
Você pode personalizar o nome e os rótulos da revisão para melhor se alinhar com suas convenções de nomenclatura ou estratégia de controle de versão.
Sufixo de nome
A cada revisão em Aplicativos de Contêiner é atribuído um identificador exclusivo. Enquanto os nomes são gerados automaticamente, você pode personalizar o nome da revisão.
O formato típico para um nome de revisão é:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Por exemplo, se você tiver um aplicativo de contêiner chamado album-api e decidir sobre o sufixo de revisão first-revision, o nome completo da revisão se tornará album-api-first-revision.
Um nome de sufixo de revisão deve:
- Consistir apenas em caracteres alfanuméricos minúsculos ou traços (
-) - Começar com um caractere alfabético
- Terminar com um caractere alfanumérico
Os nomes não devem ter:
- Dois traços consecutivos (
--) - Ter mais de 64 caracteres
Você pode definir o sufixo de revisão no modelo ARM, por meio da CLI az containerapp create do Azure e dos comandos, ou ao criar uma revisão por meio do az containerapp update portal do Azure.
Casos de utilização
A seguir estão casos de uso comuns para usar revisões em aplicativos de contêiner. Esta lista não é uma lista exaustiva da finalidade ou dos recursos do uso de revisões de aplicativos de contêiner.
Gestão de versões
As revisões simplificam o processo de introdução de novas versões do seu aplicativo. Quando estiver pronto para lançar uma atualização ou um novo recurso, você poderá criar uma nova revisão sem afetar a versão ativa atual. Essa abordagem garante uma transição suave e minimiza as interrupções para os usuários finais.
Reverter para versões anteriores
Às vezes, você precisa reverter rapidamente para uma versão anterior e estável do seu aplicativo. Você pode reverter para uma revisão anterior do seu aplicativo de contêiner, se necessário.
Testes A/B
Quando você deseja testar versões diferentes do seu aplicativo, as revisões podem oferecer suporte a testes A/B. Você pode encaminhar um subconjunto de seus usuários para uma nova revisão, coletar feedback e tomar decisões informadas com base em dados do mundo real.
Implantações azul-verde
As revisões apoiam a estratégia de implantação azul-verde. Ao ter duas revisões paralelas (azul para a versão ao vivo e verde para a nova), você pode gradualmente fasear uma nova revisão. Quando estiver confiante na estabilidade e no desempenho da nova versão, pode mudar totalmente o tráfego para o ambiente verde.