Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O Azure Container Registry é um serviço gerido de registo de contentores utilizado para armazenar e gerir as imagens privadas dos seus contentores Docker e artefactos relacionados para as suas implementações de containers.
Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.
Este artigo descreve como tornar o Registo de Contentores resiliente a uma variedade de potenciais interrupções e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Descreve também como pode usar backups para recuperar de outros tipos de problemas e destaca algumas informações-chave sobre o acordo de nível de serviço (SLA) do Container Register.
Recomendações de implantação de produção para confiabilidade
Para cargas de trabalho de produção, recomendamos que você execute as seguintes ações:
Use a camada Premium do Registro de Contêiner, que fornece os recursos de confiabilidade mais abrangentes. A camada Premium também oferece limites de desempenho mais altos, recursos de segurança aprimorados e recursos avançados que são essenciais para cargas de trabalho de contêineres de produção. Para obter mais informações sobre camadas de serviço e recursos, consulte Camadas de serviço do Registro de Contêiner.
Provisione seu Registro de Contêiner em uma região que ofereça suporte a zonas de disponibilidade.
Para cenários de várias regiões, configure a replicação geográfica para distribuir seu registro em várias regiões com base em seus requisitos geográficos e de conformidade específicos.
Visão geral da arquitetura de confiabilidade
O Registro de Contêiner é criado na infraestrutura distribuída do Azure para fornecer alta disponibilidade e durabilidade de dados. O serviço consiste em vários componentes-chave que trabalham juntos para garantir a confiabilidade. O diagrama a seguir ilustra a arquitetura de serviço principal.
O plano de controle é um componente de gerenciamento centralizado na região inicial para configuração do Registro, configuração de autenticação e políticas de replicação.
O plano de dados é um serviço distribuído que lida com operações de push e pull de imagem de contêiner entre regiões e zonas de disponibilidade.
A camada de armazenamento é uma solução de Armazenamento do Azure endereçável ao conteúdo que persiste imagens de contêiner e artefatos. Ele inclui desduplicação automática, criptografia em repouso e replicação integrada.
A Microsoft é responsável por gerenciar a infraestrutura subjacente do Registro de Contêiner, que inclui os seguintes tipos de manutenção:
Manutenção do plano de controle para gerenciamento de registro
Manutenção do plano de dados para operações de imagem de contêiner entre regiões e zonas de disponibilidade
Como cliente, você é responsável pelas seguintes ações:
Resiliência no nível do aplicativo: Implemente a lógica de repetição apropriada e a manipulação de failover em seus aplicativos de contêiner e plataformas de orquestração.
Configuração de resiliência de zona: Verifique se o registro de contêiner está implantado em uma região que ofereça suporte a zonas de disponibilidade.
Configuração de replicação geográfica: Escolha as regiões apropriadas para replicação geográfica com base em sua distribuição geográfica, conformidade e requisitos de desempenho.
O Registro de contêiner também suporta tarefas, o que pode ajudá-lo a automatizar suas compilações de contêiner e operações de manutenção. As tarefas são executadas na infraestrutura de computação gerenciada pela Microsoft e em gatilhos manuais de suporte, baseados em eventos ou agendados. Para obter mais informações, consulte Automatizar compilações e manutenção de imagens de contêiner usando tarefas do Registro de contêiner.
Note
O Registro de Contêiner oferece suporte a registros conectados, que são réplicas locais ou remotas que são sincronizadas com seu Registro de Contêiner baseado em nuvem. Ao usar registros conectados, você é responsável por configurá-los para atender aos seus requisitos de confiabilidade. Os registos ligados estão fora do âmbito deste artigo.
Resiliência a falhas transitórias
Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
O Container Registry lida com falhas transitórias internamente através de vários mecanismos. O serviço implementa a lógica de repetição automática para operações de registro e mantém o pool de conexões para uso eficiente de recursos. As operações do Registro de contêiner são projetadas para serem idempotentes, o que permite novas tentativas seguras de operações push e pull. As tarefas lidam automaticamente com falhas transitórias quando executam muitos tipos de operações.
Para aplicativos cliente que usam o Registro de Contêiner, implemente políticas de repetição apropriadas com backoff exponencial ao executar operações do Registro. Use o cliente Docker oficial ou SDKs de Registro de Contêiner, que incluem mecanismos de repetição internos para falhas transitórias comuns.
Resiliência a falhas na zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
A redundância de zona protege seu registro de contêiner contra falhas de zona única, distribuindo dados e operações do registro em várias zonas de disponibilidade dentro da região. As operações de pull e push de imagem de contêiner continuam a funcionar durante interrupções de zona, com failover automático para zonas íntegras.
A redundância de zona é habilitada por padrão para todos os registros em regiões que oferecem suporte a zonas de disponibilidade, tornando seus recursos mais resilientes automaticamente e sem custo adicional. Esse aprimoramento se aplica a todas as camadas de serviço, incluindo Basic e Standard, e foi aplicado a registros novos e existentes.
Importante
O portal do Azure e outras ferramentas podem ainda não refletir a atualização de redundância de zona com precisão.
A zoneRedundancy propriedade na configuração do seu registro ainda pode aparecer como false, mas a redundância de zona está ativa para todos os registros em regiões suportadas.
Estamos atualizando ativamente as superfícies do portal e da API para refletir esse comportamento padrão de forma mais transparente. Todos os recursos habilitados anteriormente continuam a funcionar conforme o esperado.
Considerations
- Apoio regional: Registos redundantes de zona podem ser implementados em qualquer região que suporte zonas de disponibilidade. Se o seu registo estiver numa região que não suporta zonas de disponibilidade, então para torná-lo redundante de zona tem de criar um novo registo numa região que suporte zonas de disponibilidade. Em seguida, você precisa migrar suas imagens de contêiner criando um pipeline de transferência ou importando imagens de contêiner.
Considerations
Tarefas: Atualmente, as tarefas do Registro de contêiner não oferecem suporte a zonas de disponibilidade. A redundância de zona aplica-se ao próprio serviço de registo, mas não às tarefas ou às suas operações.
Geo-replicação: Se o seu registro usa replicação geográfica, todas as réplicas criadas em regiões com zonas de disponibilidade são tornadas redundantes de zona automaticamente.
Cost
A redundância de zona está incluída nos registos de contentores sem custos adicionais.
Configurar o suporte à zona de disponibilidade
Crie um registro com redundância de zona. Quando você cria um registro em uma região suportada, ele é automaticamente redundante de zona. Para obter mais informações sobre como criar um novo registro, consulte Criar um registro com redundância de zona no Registro de contêiner.
Habilite a redundância de zona em um registro existente. Os registros que estão em regiões com zonas de disponibilidade são automaticamente redundantes de zona. Não é necessário ativar a redundância de zona.
Desative a redundância de zona. A redundância de zona não pode ser desativada.
Comportamento quando todas as zonas estão íntegras
Esta seção descreve o que esperar quando os recursos do Registro de Contêiner são configurados para redundância de zona e todas as zonas de disponibilidade estão operacionais.
Roteamento de tráfego entre zonas: O Registro de Contêiner usa a funcionalidade de roteamento interno para distribuir automaticamente as operações do plano de dados em todas as zonas de disponibilidade dentro de uma região. O serviço de registro roteia automaticamente as solicitações para zonas íntegras sem a necessidade de balanceadores de carga externos.
Replicação de dados entre zonas: Os dados do Registro, incluindo imagens de contêiner, manifestos e metadados, são replicados de forma assíncrona em várias zonas de disponibilidade. As alterações são replicadas rapidamente entre zonas para manter a alta disponibilidade e a durabilidade dos dados. A replicação é assíncrona, mas normalmente é concluída em poucos minutos e todas as zonas permanecem disponíveis para operações de leitura e gravação durante a replicação.
Comportamento durante uma falha de zona
Esta seção descreve o que esperar quando os recursos do Registro de Contêiner são configurados para redundância de zona e há uma interrupção da zona de disponibilidade.
Quando uma zona fica indisponível, o Registro de Contêiner lida automaticamente com o processo de failover com impacto mínimo nas operações do Registro.
Deteção e resposta: A plataforma Container Registry deteta automaticamente falhas em uma zona de disponibilidade e inicia uma resposta. O serviço encaminha automaticamente o tráfego para as restantes zonas íntegras. Nenhuma intervenção manual é necessária para iniciar um failover de zona.
Notificações: A Microsoft não o(a) notifica automaticamente quando uma zona está indisponível. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo sobre problemas.
Você também pode monitorar as métricas de disponibilidade do Registro no Azure Monitor.
Solicitações ativas: Quando uma zona de disponibilidade não está disponível, todas as solicitações em andamento conectadas a recursos na zona de disponibilidade defeituosa são encerradas. Eles precisam ser tentados novamente.
Perda de dados esperada: Quaisquer gravações recentes feitas na zona defeituosa podem não ser replicadas para outras regiões, o que significa que elas podem ser perdidas até que a zona se recupere. Normalmente, espera-se que a perda de dados seja inferior a 15 minutos, mas isso não é garantido.
Tempo de inatividade esperado: Uma pequena quantidade de tempo de inatividade pode ocorrer durante o failover automático à medida que o tráfego é redirecionado para zonas íntegras. Esse tempo de inatividade normalmente é de alguns segundos para a maioria das operações do Registro. Recomendamos que você siga as práticas recomendadas de tratamento de falhas transitórias para minimizar o efeito do failover de zona em seus aplicativos.
Reencaminhamento do tráfego: A plataforma redireciona automaticamente o tráfego para zonas íntegras sem exigir que você faça alterações na configuração.
Recuperação de zona
Quando a zona de disponibilidade afetada se recupera, o Registro de Contêiner distribui automaticamente as operações por todas as zonas disponíveis, incluindo a zona recuperada. O serviço reequilibra o tráfego e a distribuição de dados sem exigir intervenção manual ou causar interrupção do serviço.
Teste de falhas de zona
A plataforma Container Registry gerencia o roteamento de tráfego, failover e failback para registros com redundância de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar ou validar processos de falha da zona de disponibilidade.
Resiliência a falhas em toda a região
O Registro de Contêiner fornece suporte nativo a várias regiões por meio da replicação geográfica quando o Registro usa a camada Premium. A replicação geográfica cria réplicas de registro em várias regiões de sua escolha. A região que você implanta o recurso do Registro é conhecida como a região inicial.
A replicação geográfica permite resiliência a interrupções regionais. Se o seu registo for replicado geograficamente e ocorrer uma interrupção regional, os dados do registo continuarão disponíveis a partir das outras regiões que selecionou. Se você não habilitar a replicação geográfica, seus dados poderão ficar indisponíveis durante uma interrupção de região.
Você também pode usar a replicação geográfica para obter acesso local a imagens de contêiner nessas regiões e reduzir a latência para aplicativos distribuídos globalmente.
Quando você implanta o Registro de Contêiner e habilita a replicação geográfica, a Microsoft usa o Gerenciador de Tráfego do Azure para distribuir solicitações de plano de dados entre suas réplicas e para fazer failover automaticamente entre réplicas se uma réplica regional não estiver disponível.
A replicação geográfica do Registro de Contêiner não depende de regiões emparelhadas do Azure. Você pode selecionar qualquer combinação de regiões do Azure para replicação com base em seus requisitos geográficos, de desempenho e de conformidade específicos. Cada registro replicado geograficamente funciona como um ponto de extremidade do registro. Ele suporta a maioria das operações de registro, incluindo pushes, pulls e tarefas de gerenciamento de imagem.
Esta seção resume as informações sobre a replicação geográfica no que diz respeito à confiabilidade. Para obter mais informações, consulte Replicação geográfica no Registro de contêiner.
Suporte de região
A replicação geográfica está disponível em todas as regiões do Azure onde a camada Premium é suportada. Você pode replicar para qualquer combinação de regiões, independentemente de o Azure emparelhar essas regiões.
Requirements
Você deve usar a camada Premium para habilitar a replicação geográfica.
Considerations
Réplicas com redundância de zona: Qualquer réplica criada numa região com zonas de disponibilidade é automaticamente com redundância de zona.
Plano de controlo: O plano de controlo funciona na região de origem. Se a região inicial não estiver disponível, as operações do plano de controle não estarão disponíveis e talvez não seja possível modificar a configuração do Registro.
Tarefas: Atualmente, as tarefas do Registro de contêiner não oferecem suporte a réplicas geográficas. As tarefas são sempre executadas na região de origem. Se a região inicial não estiver disponível, a tarefa não será executada.
Cost
Cada região replicada geograficamente é cobrada separadamente de acordo com o preço do nível Premium para a respetiva região. As taxas de saída também se aplicam à transferência de dados entre regiões durante a replicação inicial e a sincronização contínua.
Configurar suporte a várias regiões
A replicação geográfica pode ser configurada durante a criação do Registro ou adicionada aos registros Premium existentes. A replicação geográfica pode ser configurada por meio do portal do Azure, da CLI do Azure, do Azure PowerShell ou dos modelos do Azure Resource Manager.
Crie um registro replicado geograficamente. Configure a replicação geográfica após a criação do Registro especificando regiões extras.
Habilite a replicação geográfica em um registro existente. Para habilitar os recursos de replicação geográfica, atualize os registros de camada Basic ou Standard existentes para a camada Premium. Você pode alterar as regiões de replicação a qualquer momento. Para obter mais informações, consulte Configurar a replicação geográfica.
Desative a replicação geográfica. Remova réplicas regionais individuais por meio do portal do Azure ou das ferramentas de linha de comando. O registro da região de origem não pode ser removido.
Comportamento quando todas as regiões estão saudáveis
Esta seção descreve o que esperar quando um registro é configurado para replicação geográfica e todas as regiões estão operacionais.
Roteamento de tráfego entre regiões: O Registro de Contêiner opera em uma configuração ativa-ativa onde cada ponto de extremidade regional pode servir todas as operações do plano de dados de forma independente, incluindo leituras e gravações. As operações de plano de dados, como operações push e pull de contêineres, são roteadas automaticamente usando o Gerenciador de Tráfego com critérios baseados em desempenho para determinar o ponto de extremidade regional ideal para desempenho.
Replicação de dados entre regiões: A replicação geográfica sincroniza automaticamente imagens de contêiner e artefatos em todas as regiões configuradas usando replicação assíncrona com consistência eventual. O serviço usa armazenamento endereçável ao conteúdo para replicar com eficiência apenas as camadas de imagem exclusivas. Essa abordagem minimiza o uso da largura de banda e o tempo de replicação. As operações de leitura e gravação funcionam em todas as regiões replicadas geograficamente. As alterações feitas em qualquer região são replicadas para todas as outras regiões.
A replicação normalmente é concluída em poucos minutos após as alterações. No entanto, não há garantia sobre o tempo de replicação de dados. Imagens de contêiner grandes ou atualizações de alta frequência podem levar mais tempo para serem replicadas em todas as regiões.
Comportamento durante uma interrupção regional
Esta seção descreve o que esperar quando um registro é configurado para replicação geográfica e há uma interrupção na região primária.
Quando uma região fica indisponível, as operações de contêiner podem continuar a usar pontos de extremidade regionais alternativos.
Deteção e resposta: O Registro de Contêiner monitora a integridade de cada réplica regional e é responsável por redirecionar o tráfego para outra região.
Notificações: A Microsoft não notifica automaticamente quando uma região está fora de serviço. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.
Você também pode monitorar as métricas de disponibilidade do Registro para cada ponto de extremidade regional no Azure Monitor.
Solicitações ativas: Quaisquer solicitações ativas atualmente em voo para uma região indisponível falharão e deverão ser repetidas para que possam ser direcionadas para uma região saudável.
Perda de dados esperada: Quaisquer gravações recentes feitas na região defeituosa podem não ser replicadas para outras regiões. Essa falha significa que eles podem ser perdidos até que a região se recupere. Normalmente, espera-se que a perda de dados seja inferior a 15 minutos, mas isso não é garantido.
Tempo de inatividade esperado: Para operações de plano de dados, uma pequena quantidade de tempo de inatividade é esperada para operações de plano de dados enquanto o failover é concluído, o que normalmente leva de 1 a 2 minutos.
Se a região de origem não estiver disponível, as operações do avião de controle ficarão indisponíveis até que a região se recupere.
Reencaminhamento do tráfego: Quando uma região fica indisponível, as operações de contêiner são automaticamente roteadas para outra réplica em uma região íntegra. Os clientes não precisam alterar o ponto de extremidade no qual interagem com o registro. A Microsoft lida automaticamente com roteamento, failover e failback.
Recuperação da região
Quando uma região se recupera, as operações do plano de dados são retomadas automaticamente para esse ponto de extremidade regional por meio do roteamento do Gerenciador de Tráfego. O serviço sincroniza todas as alterações que ocorrem durante a interrupção usando replicação assíncrona com consistência eventual.
Teste para falhas regionais
Você não pode simular a falha de uma das regiões associadas ao seu registro, mas pode testar a capacidade do aplicativo de fazer failover entre regiões. Você pode simular o failover regional desativando temporariamente as réplicas geográficas, o que as remove do roteamento do Gerenciador de Tráfego. Em seguida, você pode verificar se as operações de contêiner fazem failover com êxito para regiões alternativas sem realmente sofrer uma interrupção regional. Para obter mais informações, consulte Desabilitar temporariamente o roteamento para replicação.
Quando você reativa a réplica, o Gerenciador de Tráfego retoma o roteamento do tráfego para a réplica reativada. Além disso, metadados e imagens são sincronizados com eventual consistência com a réplica reativada para garantir a consistência dos dados em todas as regiões.
Backup e restauração
O Registro de Contêiner oferece suporte à exportação de imagens e artefatos de contêiner do seu Registro para armazenamento externo ou registros alternativos. Use os recursos de importação e exportação do Registro de Contêiner ou comandos padrão do Docker para criar cópias de imagens de contêiner críticas para cenários de recuperação de desastres.
Para a maioria das soluções, você não deve confiar exclusivamente em backups. Em vez disso, use os outros recursos descritos neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não oferecem. Para obter mais informações, consulte O que são redundância, replicação e backup?.
Contrato de nível de serviço
O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.