Perguntas frequentes sobre a configuração do aplicativo do Azure

A Configuração do Aplicativo ajuda os desenvolvedores a gerenciar as configurações do aplicativo e controlar a disponibilidade dos recursos. Ele visa simplificar muitas das tarefas de trabalhar com dados de configuração complexos.

A Configuração da Aplicação suporta:

• Espaços de nomes hierárquicos
• Etiquetagem
• Consultas extensas
• Recuperação de lotes
• Operações de gestão especializadas
• Uma interface de usuário de gerenciamento de recursos

A Configuração do Aplicativo complementa o Cofre da Chave, e os dois devem ser usados lado a lado na maioria das implantações de aplicativos.

Embora a Configuração do Aplicativo forneça segurança reforçada, o Cofre da Chave ainda é o melhor lugar para armazenar segredos de aplicativos. O Key Vault fornece criptografia no nível de hardware, políticas de acesso granulares e operações de gerenciamento, como rotação de certificados.

Você pode criar valores-chave de Configuração do Aplicativo que fazem referência a segredos armazenados no Cofre de Chaves. Para obter mais informações, consulte Usar referências do Cofre da Chave em um aplicativo ASP.NET Core.

Sim. A Configuração do Aplicativo sempre criptografa todos os dados em trânsito e em repouso. Toda a comunicação de rede é através de TLS 1.2 ou TLS 1.3. A Configuração do Aplicativo oferece suporte à criptografia em repouso com chaves gerenciadas pela Microsoft ou chaves gerenciadas pelo cliente.

O Serviço de Aplicativo do Azure permite que você defina as configurações do aplicativo para cada instância do Serviço de Aplicativo. Essas configurações são passadas como variáveis de ambiente para o código do aplicativo. Você pode associar uma configuração a um slot de implantação específico, se desejar. Para obter mais informações, consulte Definir configurações do aplicativo.

Por outro lado, a Configuração de Aplicativo do Azure permite definir configurações que podem ser compartilhadas entre vários aplicativos. Isso inclui aplicativos executados no Serviço de Aplicativo, bem como outras plataformas. O código do seu aplicativo acessa essas configurações por meio dos provedores de configuração para .NET e Java, por meio do SDK do Azure ou diretamente por meio de APIs REST.

Você pode adicionar referências aos dados de Configuração do Aplicativo nas configurações do Aplicativo do Serviço de Aplicativo. Você também pode importar e exportar configurações entre o Serviço de Aplicativo e a Configuração do Aplicativo. Esse recurso permite que você configure rapidamente uma nova loja de Configuração de Aplicativo com base nas configurações existentes do Serviço de Aplicativo. Você também pode compartilhar a configuração com um aplicativo existente que depende das configurações do Serviço de Aplicativo.

Há um limite de 10 KB para um único valor de chave, incluindo atributos como rótulo, tipo de conteúdo, tags e outros metadados. Não há limite para o número de chaves e etiquetas, desde que seu tamanho total esteja abaixo do limite de armazenamento.

Esse limite de valor-chave deve ser suficiente para uma única configuração na maioria dos aplicativos. Se você achar que sua configuração é maior do que esse limite, considere armazenar seus dados em outro lugar e adicionar uma referência desses dados na Configuração do aplicativo.

Para obter uma lista completa de limites, consulte Assinatura do Azure e limites de serviço.

Você controla quem pode acessar a Configuração do Aplicativo em um nível por loja. Use um repositório separado para cada ambiente que exija permissões diferentes. Essa abordagem fornece o melhor isolamento de segurança.

Se você não precisar de isolamento de segurança entre ambientes, poderá usar rótulos para diferenciar os valores de configuração. Usar rótulos para habilitar configurações diferentes para ambientes diferentes fornece um exemplo completo.

Consulte as melhores práticas.

Existem três níveis de preços: Gratuito, Standard e Premium. Para obter informações detalhadas sobre preços, consulte a página de preços da Configuração do aplicativo.

Todas as camadas de Configuração do Aplicativo oferecem funcionalidades principais, incluindo configurações de configuração, sinalizadores de recursos, referências do Cofre de Chaves, instantâneos de configuração, operações básicas de gerenciamento, métricas e logs.

A seguir estão as considerações para escolher uma camada.

• Objetivo: O nível gratuito é perfeito para avaliar o serviço em ambientes que não são de produção, permitindo que você explore seus recursos sem qualquer custo. A camada Standard é adaptada para casos de uso de produção de volume médio, proporcionando um equilíbrio entre desempenho e eficiência de custos. Para necessidades de produção de alto volume ou de nível empresarial, a camada Premium oferece o mais alto nível de desempenho e escalabilidade, garantindo que seus aplicativos funcionem sem problemas, mesmo sob carga pesada.

• Recursos por assinatura: um recurso consiste em um único repositório de configuração. Cada assinatura é limitada a um repositório de configuração por região no nível Gratuito. As assinaturas podem ter um número ilimitado de lojas de configuração nas camadas Standard e Premium.

• Armazenamento por recurso: no nível Gratuito, cada armazenamento de configuração é limitado a 10 MB de armazenamento regular e 10 MB de armazenamento de snapshot. Na camada Standard, cada armazenamento de configuração pode usar até 1 GB de armazenamento regular e 1 GB adicional de armazenamento de snapshot. No nível Premium, cada armazenamento de configuração pode usar até 4 GB de armazenamento regular e 4 GB adicionais de armazenamento de snapshot.

• Histórico de revisões: a Configuração do aplicativo armazena um histórico de todas as alterações feitas nas chaves. No nível Gratuito, esse histórico é armazenado por sete dias. Nos níveis Standard e Premium, esse histórico é armazenado por 30 dias.

• Cota de solicitações: As lojas de nível gratuito são limitadas a 1.000 solicitações por dia. Quando uma loja atinge 1.000 solicitações, ela retorna o código de status HTTP 429 para todas as solicitações até a meia-noite UTC.

  As lojas de nível padrão são limitadas a 30.000 solicitações por hora. Uma vez esgotada a cota horária, solicitações adicionais podem retornar um código de status HTTP 429, indicando muitas solicitações, até o final da hora. À medida que mais solicitações são enviadas acima da cota, uma porcentagem maior delas pode retornar o código de status 429.

  As lojas de nível Premium não têm limite de cota para solicitações, garantindo que o acesso à loja nunca seja bloqueado.

• Taxa de transferência: as lojas de configuração de aplicativos em todas as camadas têm uma permissão de taxa de transferência. As solicitações que excederem essa permissão receberão uma resposta com o código de status HTTP 429. As lojas no nível Gratuito não têm rendimento garantido.

  Os armazenamentos na camada Standard permitem taxa de execução† até 300 solicitações por segundo (RPS) para solicitações de leitura e até 60 RPS para solicitações de gravação.

  As lojas no nível Premium permitem taxa de execução† até 450 RPS para solicitações de leitura e até 100 RPS para solicitações de gravação.

  †A taxa de execução é normalmente medida como o número médio de solicitações tratadas por uma loja de configuração de aplicativos sem limitação durante um período especificado.

• Contrato de nível de serviço: o nível Gratuito não tem um SLA. A camada Standard tem um SLA de 99,9% de disponibilidade e 99,95% de disponibilidade com replicação geográfica habilitada. A camada Premium tem um SLA de 99,9% de disponibilidade e 99,99% de disponibilidade com replicação geográfica habilitada.

• Recursos: Todas as camadas incluem funcionalidades, incluindo criptografia com chaves gerenciadas pela Microsoft, autenticação via chave de acesso ou ID do Microsoft Entra, RBAC (controle de acesso baseado em função) do Azure, identidade gerenciada, tags de serviço e redundância de zona de disponibilidade. Os níveis Standard e Premium oferecem mais funcionalidades, incluindo suporte a Private Link, criptografia com chaves gerenciadas pelo cliente, proteção contra exclusão suave e capacidade de replicação geográfica.

• Custo: Não há custo para usar uma loja de nível gratuito.

  As lojas de nível padrão têm uma taxa de uso diário, que inclui as primeiras 200.000 solicitações por dia. Os pedidos para além desta atribuição diária incorrem numa taxa de excedente.

  As lojas de nível Premium também têm uma taxa de uso diário e incluem uma réplica. Os primeiros 800.000 pedidos para a origem e os primeiros 800.000 pedidos para a réplica por dia estão incluídos na taxa diária. Os pedidos que excedam esta dotação diária incorrem numa taxa de excedente.

Você pode atualizar uma loja de Configuração de Aplicativo a qualquer momento, por exemplo, do nível Gratuito para o nível Standard ou Premium, ou do nível Standard para o nível Premium.

Não é possível fazer o downgrade de uma loja de Configuração de Aplicativos, por exemplo, da camada Premium para a camada Standard ou da camada Standard para a camada Gratuita. No entanto, você pode criar um novo repositório na camada desejada e, em seguida , importar dados de configuração para esse armazenamento.

Os dados do cliente armazenados na Configuração do Aplicativo residem na região onde a App Configuration Store do cliente foi criada. Os dados do cliente são replicados para outra região somente se o cliente habilitar a replicação geográfica para essa região. Isto aplica-se a todas as regiões disponíveis. Os clientes podem mover, copiar ou acessar seus dados de qualquer local globalmente.

A Configuração de Aplicativo do Azure dá suporte à replicação geográfica para maior resiliência a interrupções regionais.

A Configuração de Aplicativo do Azure dá suporte às zonas de disponibilidade do Azure para proteger seu aplicativo e seus dados contra falhas de um único datacenter. Todas as regiões habilitadas para zona de disponibilidade consistem em um mínimo de três zonas de disponibilidade, onde cada uma é um datacenter fisicamente independente. Para resiliência, esse suporte na Configuração do Aplicativo é habilitado para todos os clientes sem custo extra. A seguir estão as regiões que a Configuração do Aplicativo habilitou o suporte à zona de disponibilidade. Para obter mais informações, consulte Regiões do Azure com suporte à zona de disponibilidade.

A seguir estão as regiões onde a Configuração do Aplicativo habilitou o suporte à zona de disponibilidade.

As lojas de configuração de aplicativos têm diferentes cotas de solicitação com base em sua camada. As lojas de nível gratuito são limitadas a 1.000 solicitações por dia, as lojas de nível Standard a 30.000 solicitações por hora e as lojas de nível Premium não têm limites de solicitação, garantindo acesso ininterrupto.

As lojas de configuração de aplicativos têm permissões de taxa de transferência com base em sua camada. As lojas de nível gratuito não têm rendimento garantido. Os armazenamentos de camada padrão suportam taxa de execução de até 300 solicitações por segundo (RPS) para operações de leitura e até 60 RPS para operações de gravação. As lojas de nível Premium suportam taxa de execução de até 450 RPS para operações de leitura e até 100 RPS para operações de gravação.

Vamos dar um exemplo e supor que você tenha um aplicativo com 1.000 definições de configuração. Seu aplicativo carrega todas essas configurações da Configuração do aplicativo na inicialização. Depois disso, ele verifica se há uma chave sentinela para alterações de configuração a cada 30 segundos. Se você estiver executando em Kubernetes, Serviço de Aplicativo ou VMs, vamos supor que você tenha 50 instâncias do seu aplicativo em execução simultaneamente.

Em primeiro lugar, vamos estimar as solicitações de monitoramento de configuração. Cada instância do seu aplicativo envia uma solicitação para a chave sentinela para a Configuração do Aplicativo a cada 30 segundos, portanto, ele envia 120 (=3600/30) solicitações em uma hora. Como você tem 50 instâncias do seu aplicativo, ele envia 6.000 (=120x50) solicitações totais a cada hora para monitoramento de configuração. Observe que, como as solicitações de chave sentinela são frequentes e praticamente inalteradas, a maioria delas não conta para os limites de cota horária da loja† para um armazenamento de camada Standard.

Em segundo lugar, vamos estimar as solicitações de carregamento/recarregamento de configuração. Seu aplicativo carrega todas as configurações na inicialização ou sempre que uma alteração de chave sentinela é detetada. Cada solicitação para a Configuração do Aplicativo pode recuperar até 100 valores-chave, portanto, são necessárias 10 (=1000/100) solicitações para carregar todas as configurações. Como você tem 50 instâncias de aplicativo, você envia 500 (=10x50) solicitações totais quando seu aplicativo reinicia ou recarrega sua configuração.

Por fim, vamos juntá-lo. Supondo que você atualizou a chave sentinela duas vezes dentro de uma hora, sua loja de configuração de aplicativos receberá, portanto, 7.000 (=6.000+500x2) solicitações totais para essa hora. Observe que, dessas solicitações, apenas cerca de 1.000 (=500x2) solicitações usam a cota horária disponível para um armazenamento de camada Standard. Atualize os números neste exemplo para corresponder à sua configuração e design específicos de acordo para que você tenha um buffer suficiente em relação ao limite de cota horária.

†As lojas de nível gratuito não têm solicitações frequentes e repetidas excluídas de seu limite diário.

Seu aplicativo pode receber uma resposta com o código de status HTTP 429 nas seguintes circunstâncias:

• Exceder a cota de solicitação diária para uma loja no nível Gratuito.
• Exceder a cota de solicitação por hora para uma loja na camada Padrão.
• Exceder a permissão de taxa de transferência para uma loja em qualquer nível.
• Exceder o limite de largura de banda para uma loja em qualquer nível.
• Tentativa de criar ou modificar um valor-chave quando a cota de armazenamento é excedida.

Verifique o corpo da resposta 429 para saber o motivo específico pelo qual a solicitação falhou. Você também pode coletar logs para sua loja de Configuração de Aplicativo no Azure Monitor e configurar alertas para a métrica Uso de Cota de Solicitação .

Receber respostas momentâneas do código de status HTTP 429 geralmente não causa danos, pois os clientes da Configuração do Aplicativo as lidam graciosamente. No entanto, se o seu aplicativo tiver respostas regulares com o código de status HTTP 429, considere as seguintes opções:

• Atualize sua loja para o nível Premium: esse nível não tem limite de cota para solicitações e aumentou a cota de armazenamento e a franquia de taxa de transferência mais alta.
• Usar provedores de configuração de aplicativo: os provedores têm recursos internos de repetição e armazenamento em cache, juntamente com muitos outros recursos de resiliência. Certifique-se de atualizar para a versão mais recente do provedor para todos os aprimoramentos mais recentes.
• Use SDKs de configuração de aplicativo se seu aplicativo precisar enviar solicitações de gravação. Embora os SDKs possam não ser tão ricos em recursos quanto os provedores, eles tentam automaticamente repetir as respostas do código de status HTTP 429 e outros erros transitórios.
• Inclua a lógica de repetição em clientes personalizados se não puder usar Provedores de Configuração de Aplicativo ou SDKs. O retry-after-ms cabeçalho na resposta fornece um tempo de espera sugerido (em milissegundos) antes de tentar novamente a solicitação.
• Distribuir solicitações entre várias instâncias de cliente: isso ajuda a alcançar a taxa de transferência máxima da sua loja de configuração de aplicativos.
• Reduza as solicitações feitas à Configuração do aplicativo: siga as orientações para minimizar o número de solicitações.
• Melhore a resiliência do aplicativo: considere a integração da replicação geográfica para permitir failover e balanceamento de carga. Verifique as práticas recomendadas para criar aplicativos altamente resilientes.

Todas as lojas de Configuração de Aplicações nos níveis Standard e Premium ativaram automaticamente a funcionalidade de eliminação suave. Quando uma loja de configuração de aplicativos de nível Standard ou Premium é excluída, seu nome é reservado para o período de retenção. Para recriar uma loja com o mesmo nome antes que o período de retenção expire, você precisa limpar a loja excluída suavemente primeiro, desde que a loja não tenha a proteção contra limpeza habilitada. Se a proteção contra limpeza estiver ativada, você deverá aguardar o período de retenção expirar. Use a função de limpeza ou defina um período de retenção mais curto se muitas vezes precisar recriar uma loja com o mesmo nome. Os fluxos de trabalho que exigem a recriação de um repositório com o mesmo nome devem permitir uma hora entre a limpeza de um repositório de configuração e a execução da criação subsequente. Essa recomendação está em vigor porque uma vez que uma limpeza é solicitada, a limpeza real dos recursos do repositório de configuração é executada de forma assíncrona, exigindo um pouco de tempo extra para finalizar. Para evitar a necessidade de esperar, recomenda-se que os fluxos de trabalho que criam repositórios de configuração efêmeros usem nomes exclusivos.

Todas as lojas de Configuração de Aplicações nos níveis Standard e Premium suportam a funcionalidade de eliminação suave, que não pode ser desativada. Você pode recuperar um armazenamento excluído dentro de seu período de retenção. Siga estas instruções para recuperar uma loja de configuração de aplicativos excluída por engano.

Sim. Embora você possa gerenciar sinalizadores de recursos e referências do Cofre da Chave na Configuração do Aplicativo por meio do portal do Azure ou da CLI, também pode criá-los e atualizá-los programaticamente usando SDKs de Configuração de Aplicativo. Portanto, você pode escrever seu portal de gerenciamento personalizado ou gerenciá-los em seu CI/CD programaticamente. O sinalizador de recurso e as APIs de referência do Cofre da Chave estão disponíveis em SDKs de todos os idiomas suportados. Confira os links de exemplo para obter exemplos em cada idioma suportado.

Avaliar e consumir sinalizadores de recursos em seu aplicativo requer o provedor de Configuração de Aplicativo e bibliotecas de gerenciamento de recursos, que estão disponíveis em .NET e Java Spring. Consulte a secção Gestão de funcionalidades em Inícios rápidos e tutoriais para obter mais informações.

Os perfis Spring fornecem uma maneira de separar partes do seu aplicativo, incluindo a configuração, e torná-lo disponível apenas em determinados ambientes ou quando bibliotecas específicas são usadas.

Recomenda-se que você defina o rótulo de seus valores-chave para corresponder aos seus perfis do Spring. Por padrão, a biblioteca do provedor do App Configuration Spring carrega os valores-chave com o(s) rótulo(s) correspondente(s) ao(s) perfil(s) ativo(s) atual(is)${spring.profiles.active} do Spring se o filtro de rótulo não estiver definido explicitamente. Se não houver um conjunto de perfis Spring ativo, os valores-chave com "sem rótulo" serão carregados.

Por exemplo, com perfis dev e prod, você cria valores-chave de acordo com os rótulos a seguir.

Quando o perfil Spring é definido como dev, o valor de config.message será Hello from dev. Quando o perfil Spring é definido como prod, o valor de config.message será Hello from prod.

Esse comportamento padrão pode ser substituído definindo o filtro de rótulo no arquivo de bootstrap. A biblioteca do provedor Spring carrega valores-chave com o(s) rótulo(s) especificado(s), independentemente do perfil Spring ativo.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Para selecionar outras etiquetas e o(s) seu(s) perfil(s) Spring, você pode usar um filtro de etiquetas como ',${spring.profiles.active}', que selecionará todas as teclas sem uma etiqueta e as que correspondem aos seus perfis Spring. O(s) rótulo(s) mais à direita têm prioridade quando chaves duplicadas são encontradas.

A partir da versão 3.1.0, a biblioteca permite a Microsoft.FeatureManagement execução de serviços de gerenciamento de recursos, incluindo filtros de recursos, como serviços com escopo em aplicativos .NET baseados em injeção de dependência. Para aproveitar esse recurso, você pode simplesmente substituir a AddFeatureManagement chamada em seu código por AddScopedFeatureManagement, conforme mostrado no seguinte trecho de código:

services.AddScopedFeatureManagement();

Os filtros de recursos podem avaliar um sinalizador de recurso com base nas propriedades de uma solicitação HTTP. Isso geralmente é realizado inspecionando o HttpContext padrão singleton IHttpContextAccessor . No entanto, esse padrão não funciona para aplicativos de servidor Blazor onde os serviços com escopo devem ser usados. Neste caso, AddScopedFeatureManagement o método deve ser usado.

Assine nosso repositório de anúncios do GitHub.

Você pode entrar em contato conosco diretamente no GitHub.

• Sobre a Configuração do Aplicativo do Azure