Eventos
Crie aplicativos e agentes de IA
17 de mar., 21 - 21 de mar., 10
Junte-se à série de encontros para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registrar agoraAtualizar e implantar alterações nos Aplicativos de Contêiner do Azure
O gerenciamento de alterações pode ser desafiador à medida que você desenvolve aplicativos conteinerizados na nuvem. Em última análise, você precisa do suporte para controlar 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 aplicativo de contêiner.
As principais características das revisões incluem:
Imutável: uma vez estabelecida, uma revisão permanece imutável.
Controle de versão: as revisões atuam como um registro das versões do aplicativo contêiner, capturando seu estado em vários estágios.
Provisionada automaticamente: quando você implanta um aplicativo de contêiner pela primeira vez, uma revisão inicial é criada automaticamente.
Alterações no escopo: embora as revisões permaneçam estáticas, alterações no escopo do aplicativo podem afetar todas as revisões, enquanto 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 é benéfico principalmente quando você precisa gerenciar diferentes versões do seu aplicativo simultaneamente.
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 um status de provisionamento, execução e inativo diferente.
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á no processo de verificação. |
| Provisionado | A revisão passou com sucesso em todas as verificações. |
| O provisionamento falhou | A revisão encontrou problemas durante a verificação. |
Depois que um aplicativo de contêiner é provisionado com sucesso, 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á no processo de verificação. |
| Dimensionar para 0 | Zero réplicas em execução e não provisionando novas réplicas. O aplicativo de contêiner pode criar novas réplicas se as regras de dimensionamento forem disparadas. |
| Ativando | Zero réplicas em execução, uma réplica sendo provisionada. |
| Falha na ativação | Falha ao provisionar a primeira réplica. |
| Dimensionamento/processamento | A redução ou escala horizontal está ocorrendo. 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 para relatar. |
| Em execução (no máximo) | O número máximo de réplicas (de acordo com as regras de dimensionamento da revisão) está em execução. Não há problemas para relatar. |
| Desprovisionamento | A revisão está fazendo a transição de ativa para inativa e está removendo todos os recursos criados. |
| Degradado | Pelo menos uma réplica na revisão está em um estado com falha. Exibir detalhes de estado de execução para problemas específicos. |
| Com falha | Erros críticos fez com que as revisões falhassem. O estado em execução fornece detalhes. As causas mais comuns incluem: • Encerramento • Código de saída 137 |
As revisões também podem inserir um estado inativo. Essas revisões não têm estados de provisionamento ou de 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.
Você pode usar o parâmetro --max-inactive-revisions com os comandos containerapp create ou containerapp update para controlar o número de revisões inativas controladas pelos Aplicativos de Contêiner.
Primeiro, verifique se você instalou a extensão de Aplicativos de Contêiner, com versão prévia de recursos habilitados, para a CLI do Azure:
az extension add --name containerapp --upgrade --allow-preview true
Este exemplo demonstra como criar um novo aplicativo de contêiner que rastreia 50 revisões inativas:
az containerapp create --max-inactive-revisions 50
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 | Descrição | Padrão |
|---|---|---|
| Single | Novas revisões são provisionadas, ativadas e dimensionadas automaticamente para o tamanho desejado. Depois que todas as réplicas estiverem em execução conforme definido pela regra de dimensionamento, 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 desprovisionadas automaticamente. | 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, teste azul-verde ou assumir controle total das atualizações do aplicativo. Consulte divisão de tráfego para obter mais detalhes. |
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:
- Consistir 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 aplicativo de contêiner no portal do Azure.
A URL do rótulo está disponível no painel de detalhes da revisão.
No modo de revisão única, os Aplicativos de Contêiner garantem que o aplicativo não tenha tempo de inatividade ao criar uma 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 sucesso
- A revisão escalou verticalmente para corresponder à contagem de réplicas de revisões anteriores (respeitando a contagem mínima e máxima da nova revisão)
- Todas as réplicas passaram por suas investigações de inicialização e preparação
No modo de revisão múltipla, você controla 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.
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 para 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.
O diagrama a seguir mostra um aplicativo de contêiner com duas revisões.
O cenário presume que o aplicativo de contêiner está no seguinte estado:
- A opção Entrada está habilitada, o que disponibiliza o aplicativo de 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.
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.
No modo de revisão múltipla, você pode ativar ou desativar revisões conforme necessário. As revisões ativas estão operacionais e podem lidar com solicitações, enquanto as revisões inativas permanecem inativas.
Os Aplicativos de Contêiner não cobram por revisões inativas. No entanto, há um limite no número total de revisões disponíveis, com as mais antigas sendo limpas quando você excede uma contagem de 100.
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.
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
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
Você pode personalizar o nome e os rótulos da revisão para ajustar melhor com suas convenções de nomenclatura ou estratégia de controle de versão.
Cada revisão nos Aplicativos de Contêiner recebe um identificador exclusivo. Embora os nomes sejam 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 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 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.
Veja a seguir casos de uso comuns para usar revisões em Aplicativos de Contêiner. Essa lista não é uma lista completa da finalidade ou dos recursos do uso de revisões de Aplicativos de Contêiner.
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 dinâmica atual. Essa abordagem garante uma transição suave e minimiza as interrupções para os usuários finais.
Às vezes, você precisa reverter rapidamente para uma versão estável anterior do seu aplicativo. Você pode reverter para uma revisão anterior do aplicativo de contêiner, se necessário.
Quando você quiser testar diferentes versões do seu aplicativo, as revisões são compatíveis com teste 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 reais.
As revisões dão suporte para a estratégia de implantação azul-verde. Ao ter duas revisões paralelas (azul para a versão dinâmica e verde para a nova), você pode implementar gradualmente em uma nova revisão. Quando estiver confiante na estabilidade e no desempenho da nova versão, você poderá alternar totalmente o tráfego para o ambiente verde.