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 controlar 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.
Versionado: as revisões atuam como um registro das versões do aplicativo de 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 de 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 por seu status e disponibilidade. Durante seu ciclo de vida, um aplicativo de contêiner passa por diferentes provisionamentos, execução e um status inativo.
Status do 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 de contêiner.
| Status | Descrição |
|---|---|
| Provisionamento | A revisão está em processo de verificação. |
| Provisionado | A revisão passou com êxito em todas as verificações. |
| O provisionamento falhou | A revisão encontrou problemas durante a verificação. |
Status de execução
Depois que um aplicativo de contêiner é provisionado com êxito, uma revisão entra em sua fase operacional. O status em execução ajuda a monitorar a integridade e a funcionalidade de um aplicativo de contêiner.
| Status | Descrição |
|---|---|
| Provisionamento | A revisão está em processo de verificação. |
| Dimensionar para 0 | Zero réplicas em execução e não provisionar novas réplicas. O aplicativo de contêiner pode criar novas réplicas se as regras de escala forem acionadas. |
| Ativando | Zero réplicas em execução, uma réplica sendo provisionada. |
| Falha na ativação | A primeira réplica falhou ao provisionar. |
| Dimensionamento / Processamento | Está ocorrendo escalonamento para dentro ou para fora. Uma ou mais réplicas estão em execução, enquanto outras réplicas estão sendo provisionadas. |
| Executando | Uma ou mais réplicas estão em execução. Não há problemas a relatar. |
| Corrida (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 relatar. |
| Desprovisionamento | A revisão está fazendo a transição de ativo para inativo e está removendo todos os recursos criados. |
| Degradado | Pelo menos uma réplica na revisão está em um estado de falha. Exibir detalhes do estado de execução para problemas específicos. |
| Com falha | Erros críticos causaram falha nas revisões. O estado de execução fornece detalhes. As causas mais comuns incluem: •Rescisão • Código de saída 137 |
Status 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 inativa
Você pode usar o parâmetro com os containerapp create comandos or containerapp update para controlar o --max-inactive-revisions número de revisões inativas controladas pelos Aplicativos de Contêiner.
Este exemplo demonstra como criar um novo aplicativo de contêiner que controla 50 revisões inativas:
az containerapp create --max-inactive-revisions 50
Modos de revisão
Os Aplicativos de Contêiner do Azure oferecem 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 | Descrição | Padrão |
|---|---|---|
| Único | Novas revisões são automaticamente provisionadas, ativadas e dimensionadas para o tamanho desejado. Depois que todas as réplicas estiverem sendo executadas 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 |
| Múltiplas | 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-esverdeado ou assumir o controle total das atualizações do aplicativo. Consulte Divisão de tráfego para obter mais detalhes. |
Rótulos
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 à qual o rótulo foi atribuído.
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 a mesma URL quando movidos de uma revisão para outra.
- Um rótulo pode ser aplicado a apenas uma revisão por 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 várias revisões.
- Você pode habilitar rótulos, divisão de tráfego ou ambos.
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 fornecer a eles a URL do rótulo. Em seguida, quando você deseja mover seus usuários para uma revisão diferente, você pode mover o rótulo para essa revisão.
Os rótulos funcionam independentemente da divisão de tráfego. A divisão de tráfego distribui o tráfego destinado à URL do aplicativo do contêiner para revisões com base no percentual 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.
Um nome de rótulo precisa:
- Consistem em caracteres alfanuméricos minúsculos ou traços (
-) - Comece 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 aplicativo de contêiner no portal do Azure.
A URL do rótulo está disponível no painel de detalhes da revisão.
Implantação sem tempo de inatividade
No modo de revisão única, os Aplicativos de Contêiner garantem que seu aplicativo não tenha tempo de inatividade ao criar uma nova revisão. A revisão ativa existente não será desativada até que a nova revisão esteja pronta.
Se a entrada estiver habilitada, a revisão existente continuará recebendo 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 seus testes 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 mudará para a revisão mais recente até que ela esteja pronta.
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 oferece a flexibilidade de gerenciar sua revisão manualmente. Por exemplo, o uso de vários modos de revisão permite que você decida exatamente quanto tráfego é alocado para cada revisão.
Separação de tráfego
O diagrama a seguir mostra um aplicativo de contêiner com duas revisões.
Esse cenário presume que o aplicativo de contêiner está no seguinte estado:
- A entrada está habilitada, disponibilizando o aplicativo contêiner via HTTP ou TCP.
- A primeira revisão é 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, enquanto a Revisão 2 recebe 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 para 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 no número total de revisões disponíveis, com as mais antigas sendo eliminadas quando você excede uma contagem de 100.
Alterar tipos
As alterações feitas em um aplicativo de contêiner se enquadram em uma das duas categorias: alterações no escopo da revisão e no escopo do aplicativo. As alterações no escopo da revisão disparam uma nova revisão quando você implanta o aplicativo, enquanto as alterações no escopo do aplicativo não.
Alterações de escopo de revisão
Quando um aplicativo de contêiner é atualizado com uma alteração no escopo da revisão, uma nova revisão é criada. As alterações são limitadas à revisão na qual são implantadas e não afetam outras revisões.
Uma alteração no escopo da revisão é qualquer alteração nos parâmetros na seção properties.template do modelo de recurso do aplicativo de contêiner.
Os parâmetros incluem:
- Sufixo de revisão
- Configuração e imagens de contêiner
- Regras de escala para o aplicativo de contêiner
Alterações no escopo do aplicativo
Ao implantar 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.
Alterações no escopo do aplicativo são definidas como qualquer alteração nos parâmetros na seção properties.configuration do modelo de recurso do aplicativo de contêiner.
Os parâmetros incluem:
- Valores secretos (as revisões precisam ser reiniciadas antes que um contêiner reconheça novos valores secretos)
- Modo de revisão
- Configuração de entrada, incluindo:
- Ligar ou desligar a entrada
- Regras de divisão de tráfego
- Rótulos
- Credenciais para registros de contêiner privado
- Configurações do Dapr
Personalizar revisões
Você pode personalizar o nome e os rótulos de revisão para se alinhar melhor às suas convenções de nomenclatura ou estratégia de controle de versão.
Sufixo do 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 de 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 primeiro-revisão, o nome completo da revisão se tornará album-api-first-revision.
Um nome de sufixo de revisão deve:
- Consistem apenas em caracteres alfanuméricos minúsculos ou traços (
-) - Comece 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 do ARM por meio da CLI do Azure az containerapp create e comandos az containerapp update ou criando uma revisão por meio do portal do Azure.
Casos de uso
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.
Gerenciamento 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.
Revertendo 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 de A/B
Quando você deseja testar versões diferentes do seu aplicativo, as revisões podem oferecer suporte a testes A/B. Você pode rotear um subconjunto de seus usuários para uma nova revisão, coletar comentários e tomar decisões informadas com base em dados do mundo real.
Implantações azul-verde
As revisões dão suporte à 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 fazer uma nova revisão. Quando estiver confiante na estabilidade e no desempenho da nova versão, você poderá alternar o tráfego totalmente para o ambiente verde.