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.

Esse limite 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 mais informações, consulte Limites de assinatura e serviço do Azure.

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 dois níveis de preços:

• Escalão gratuito
• Escalão standard

Se você criou uma loja antes da introdução da camada Padrão, ela foi automaticamente movida para a camada Gratuita mediante disponibilidade geral. Você pode optar por atualizar para o nível Standard ou permanecer no nível Gratuito.

Não é possível fazer o downgrade de uma loja do nível Standard para o nível Gratuito. Você pode criar um novo repositório na camada Gratuito e, em seguida, importar dados de configuração para esse armazenamento.

Ambas as camadas de Configuração de Aplicativo oferecem funcionalidade principal, 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.

• 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 armazenamentos de configuração na camada padrão.

• 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 padrão, cada armazenamento de configuração pode usar até 1 GB de armazenamento regular e 1 GB adicional 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. Na camada padrão, 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. Quando a cota horária estiver esgotada, as solicitações podem retornar o 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.

• Contrato de nível de serviço: a camada padrão tem um SLA de 99,9% de disponibilidade e 99,95% de disponibilidade com replicação geográfica habilitada. O nível gratuito não tem um SLA.

• Recursos: Ambas 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. A camada Standard oferece 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: As lojas de nível padrão têm uma taxa de uso diária. Os primeiros 200.000 pedidos por dia estão incluídos na taxa diária. Há também uma taxa de excesso de idade para solicitações além da alocação diária. Não há custo para usar uma loja de nível gratuito.

Você pode atualizar do nível Gratuito para o nível Standard a qualquer momento.

Não é possível fazer o downgrade de uma loja do nível Standard para o nível Gratuito. Você pode criar um novo repositório na camada Gratuito 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 serã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 3 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 e zonas de disponibilidade no Azure.

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

Os armazenamentos de configuração no nível Gratuito são limitados a 1.000 solicitações por dia. Os armazenamentos de configuração na camada Standard podem sofrer limitação temporária quando a taxa de solicitação exceder 30.000 solicitações por hora.

Quando uma loja atinge seu limite na camada padrão, ela pode retornar o código de status HTTP 429 para algumas solicitações feitas até o final da hora. O retry-after-ms cabeçalho na resposta fornece um tempo de espera sugerido (em milissegundos) antes de tentar novamente a solicitação.

Se o seu aplicativo tiver respostas regulares com o código de status HTTP 429, considere reprojetá-lo para reduzir o número de solicitações feitas. Para obter mais informações, consulte como reduzir as solicitações feitas à Configuração do aplicativo.

Você receberá uma resposta com o código de status HTTP 429 nestas circunstâncias:

• Exceder o limite de pedidos diários para uma loja no nível Gratuito.
• Exceder o limite de solicitação por hora para uma loja na camada padrão.
• Limitação momentânea devido a uma grande explosão de solicitações†.
• Limitação momentânea devido ao uso excessivo de largura de banda†.
• Tentativa de criar ou modificar uma chave quando a quota de armazenamento é excedida.

Verifique o corpo da resposta 429 para saber o motivo específico pelo qual a solicitação falhou.

†Um repositório de configuração pode sofrer uma limitação momentânea se receber uma grande explosão de solicitações ou transferir um volume excessivo de dados. Os clientes de Configuração de Aplicativo, como o SDK do Azure, as bibliotecas do provedor de configuração e as tarefas do Azure Pipelines, tentam novamente automaticamente em solicitações limitadas. Para qualquer aplicativo que use um desses clientes, ou um cliente personalizado que tente novamente em solicitações limitadas, essa limitação momentânea deve passar despercebida, caso ocorra.

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 enviará uma solicitação para a chave sentinela para a Configuração do aplicativo a cada 30 segundos, portanto, enviará 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, em sua maioria, inalteradas, a maioria delas não contará para os limites de cota horária da loja†.

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, serã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 usarão a cota horária disponível. 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 limitação por hora. Para obter mais informações, consulte como reduzir as solicitações feitas à Configuração do aplicativo.

†As lojas de nível gratuito não têm pedidos frequentes e repetidos excluídos do seu limite diário.

Todas as lojas de configuração de aplicativos na camada padrão ativaram automaticamente o recurso de exclusão suave. Quando uma loja de configuração de aplicativo de camada padrão é 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 Aplicativos na camada padrão suportam o recurso de exclusão suave, que não pode ser desativado. 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 App Configuration Spring carregará 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 carregará 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 singletonIHttpContextAccessor. 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