Perguntas frequentes sobre a Configuração de Aplicativos do Azure

A Configuração de Aplicativos ajuda os desenvolvedores a gerenciar configurações de aplicativos e controlar a disponibilidade de recursos. Ela visa simplificar muitas das tarefas envolvidas no trabalho com dados de configuração complexos.

A Configuração de Aplicativos dá suporte a:

• Namespaces hierárquicos
• Rotulagem
• Consultas extensivas
• Recuperação em lote
• Operações especializadas de gerenciamento
• Uma interface de usuário para o gerenciamento de recursos

A Configuração de Aplicativos complementa o Key Vault e eles devem ser usados em conjunto na maioria das implantações de aplicativo.

Embora a Configuração de Aplicativos forneça uma segurança reforçada, o Key Vault ainda é a melhor opção para armazenar os segredos dos aplicativos. O Key Vault fornece criptografia no nível de hardware, além de políticas de acesso granulares e operações de gerenciamento, como a rotação de certificado.

Você pode criar chave-valores da Configuração de Aplicativos que fazem referência a segredos armazenados no Key Vault. Para saber mais, confira Usar referências do Key Vault em um aplicativo ASP.NET Core.

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

É possível definir as configurações do aplicativo para cada instância do Serviço de Aplicativo do Azure. Essas configurações são transmitidas como variáveis de ambiente ao código do aplicativo. Você pode associar uma configuração a um slot de implantação específico, caso desejado. Para saber mais, confira Definir configurações de aplicativo.

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

Você pode adicionar referências aos dados da Configuração de Aplicativos 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 de Aplicativos. Esse recurso permite configurar rapidamente um novo repositório da Configuração de Aplicativos com base nas configurações existentes do Serviço de Aplicativo. Você também pode compartilhar a configuração com um aplicativo existente que seja baseado nas configurações do Serviço de Aplicativo.

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

Esse limite de chave/valor deve ser suficiente para uma configuração na maioria dos aplicativos. Se você achar que sua configuração é maior que esse limite, poderá considerar armazenar seus dados em outro lugar e adicionar uma referência desses dados na Configuração de Aplicativos.

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

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

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.

Confira as práticas recomendadas.

Existem três camadas de preços: Gratuita, Standard e Premium. Para obter informações detalhadas sobre preços, consulte a página de preços da Configuração de Aplicativos.

Todas as camadas da Configuração de Aplicativos oferecem funcionalidades principais, incluindo definições de configuração, sinalizadores de recursos, referências ao Key Vault, instantâneos de configuração, operações básicas de gerenciamento, métricas e logs.

Veja as considerações abaixo ao escolher uma camada.

• Finalidade: A camada Gratuita é ideal para avaliar o serviço em ambientes de não produção, permitindo explorar seus recursos sem nenhum custo. A camada Standard é adaptada para casos de uso de produção de médio volume, oferecendo um equilíbrio entre desempenho e eficiência de custos. Para necessidades de produção de alto volume ou 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 alta demanda.

• Recursos por assinatura: um recurso consiste em um único repositório de configuração. Cada assinatura é limitada a um repositório de configurações por região na camada Gratuita. As assinaturas podem ter um número ilimitado de repositórios de configurações nas camadas Standard e Premium.

• Armazenamento por recurso: Na camada Gratuita, cada repositório de configurações é limitado a 10 MB de armazenamento regular e 10 MB de armazenamento de instantâneos. Na camada Standard, cada repositório de configurações pode usar até 1 GB de armazenamento regular e um adicional de 1 GB de armazenamento de instantâneos. Na camada Premium, cada repositório de configurações pode usar até 4 GB de armazenamento regular e um adicional de 4 GB de armazenamento de instantâneos.

• Histórico de revisão: a Configuração de Aplicativos armazena um histórico de todas as alterações feitas nas chaves. Na camada Gratuita, esse histórico é armazenado por sete dias. Nas camadas Standard e Premium, esse histórico é armazenado por 30 dias.

• Cota de solicitações: os repositórios da camada gratuita são limitados a 1.000 solicitações por dia. Quando um repositório atinge 1.000 solicitações, ele retorna o código de status HTTP 429 para todas as solicitações até a meia noite (UTC).

  Os repositórios da camada Standard são limitados a 30.000 solicitações por hora. Uma vez que a cota horária é esgotada, solicitações adicionais podem retornar um código de status HTTP 429, indicando muitas solicitações, até o final do horário. À medida que mais solicitações acima da cota são enviadas, um percentual mais alto delas pode retornar o código de status 429.

  Os repositórios de camada Premium não têm limite de cota nas solicitações, garantindo que o acesso ao repositório nunca seja bloqueado.

• Taxa de transferência: os repositórios de Configuração de Aplicativos em todas as camadas têm uma permissão de taxa de transferência. As solicitações que excederem esse subsídio receberão uma resposta de código de status HTTP 429. Os repositórios na camada Gratuita não têm taxa de transferência garantida.

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

  As lojas na camada Premium permitem uma taxa de execução† de 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 manipuladas por um repositório de Configuração de Aplicativos sem limitação durante um período especificado.

• Contrato de Nível de Serviço (SLA): A camada Gratuita não possui SLA. A camada Standard tem um SLA de 99,9% de disponibilidade e 99,95% com replicação geográfica habilitada. A camada Premium tem um SLA de 99,9% de disponibilidade e 99,99% com replicação geográfica habilitada.

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

• Custo: Não há custo para usar um repositório da camada Gratuita.

  Os repositórios da camada Standard têm uma cobrança de uso diário, que inclui as primeiras 200.000 solicitações diárias. Solicitações além dessa alocação diária geram uma cobrança excedente.

  Os repositórios da camada Premium também têm uma cobrança de uso diário e incluem um réplica. As primeiras 800.000 solicitações para a origem e as primeiras 800.000 solicitações para a réplica a cada dia estão incluídas na cobrança diária. As solicitações que excederem essa alocação diária incorrerão em uma cobrança por excesso.

Você pode atualizar um repositório da Configuração de Aplicativos a qualquer momento, por exemplo, da camada Gratuita para a Standard ou Premium, ou da Standard para a Premium.

Você não pode fazer downgrade de um repositório da Configuração de Aplicativos, por exemplo, da camada Premium para a Standard ou da Standard para a Gratuita. No entanto, você pode criar um repositório na camada desejada e importar os dados de configuração para essa repositório.

Os dados do cliente armazenados na Configuração de Aplicativos ficam na região em que foi criado o repositório da Configuração de Aplicativos do cliente. 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. Isso se aplica a todas as regiões disponíveis. Os clientes podem mover, copiar ou acessar os respectivos dados de qualquer local do mundo.

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

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

A seguir estão as regiões nas quais a Configuração de Aplicativos habilitou o suporte à Zona de Disponibilidade.

Os repositórios de Configuração de Aplicativos têm cotas de solicitação diferentes com base na camada deles. Os repositórios de camadas gratuitas são limitados a 1.000 solicitações por dia, repositórios de camadas Standard a 30.000 solicitações por hora e repositórios de camada Premium não têm limites de solicitação, garantindo acesso ininterrupto.

Os repositórios de Configuração de Aplicativos têm subsídios de taxa de transferência com base na camada deles. Os repositórios de camada Gratuita não têm taxa de transferência garantida. Os repositórios de camada Standard dão suporte a uma taxa de execução de até 300 RPS (solicitações por segundo) para operações de leitura e até 60 RPS para operações de gravação. Os repositórios de camada Premium dão suporte a uma 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 de Configuração de Aplicativos após a 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 no Kubernetes, Serviço de Aplicativo ou VMs, vamos supor que você tenha 50 instâncias de seu aplicativo em execução simultaneamente.

Em primeiro lugar, vamos estimar as solicitações de monitoramento de configuração. Cada instância do aplicativo enviará uma solicitação para que a chave sentinela Configuração de Aplicativos a cada 30 segundos, portanto, enviará 120 solicitações (=3600/30) em uma hora. Considerando que você tem 50 instâncias do seu aplicativo, seu aplicativo envia 6.000 (=120x50) total de solicitações a cada hora para monitoramento de configuração. Observe que, como solicitações de chave sentinela são frequentes e praticamente inalteradas, a maioria delas não é contabilizada com relação aos limites de cota† por hora para um repositório da 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 é detectada. Cada solicitação para Configuração de Aplicativos pode recuperar até 100 pares de chave/valor, portanto, serão necessárias 10 solicitações (=1000/100) para carregar todas as configurações. Considerando que você tem 50 instâncias de aplicativo, você envia 500 (=10x50) total de solicitações quando seu aplicativo reinicia ou recarrega sua configuração.

Finalmente, vamos juntar tudo. Supondo que você tenha atualizado a chave sentinela duas vezes em uma hora, seu repositório de Configuração de Aplicativos receberá 7.000 solicitações totais (=6.000+500x2) para essa hora. Observe que, dessas solicitações, apenas cerca de 1.000 (=500x2) usarão a cota disponível por hora para um repositório de camada Standard. Atualize os números neste exemplo para corresponder à configuração e ao design específicos de acordo, para que você tenha um buffer suficiente em relação ao limite de cota por hora.

†Repositórios de camada Gratuita não têm solicitações repetidas e frequentes excluídas do limite diário.

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

• Ao exceder a cota diária de solicitações em um repositório da camada Gratuita.
• Ao exceder a cota de solicitações por hora em um repositório da camada Standard.
• Ao exceder a permissão de taxa de transferência para um repositório em qualquer camada.
• Ao exceder o subsídio de largura de banda para um repositório em qualquer camada.
• Ao tentar criar ou modificar uma chave depois que a cota de armazenamento é excedida.

Verifique o corpo da resposta 429 para saber o motivo específico da falha na solicitação. Você também pode coletar logs para seu repositório de Configuração de Aplicativos no Azure Monitor e configurar alertas para a métrica de Uso da Cota de Solicitações.

O recebimento de respostas momentâneas do código de status HTTP 429 geralmente não causa nenhum dano, pois os clientes da Configuração de Aplicativos lidam com eles normalmente. No entanto, se o aplicativo tiver regularmente respostas com código de status HTTP 429, considere as seguintes opções:

• Atualizar seu repositório para a camada Premium: essa camada não tem limite de cota em solicitações, tem uma maior cota de armazenamento e permissão de taxa de transferência mais alta.
• Usar provedores de Configuração de Aplicativos: os provedores têm recursos internos de repetição e cache, juntamente com muitos outros recursos de resiliência. Certifique-se de atualizar para a versão mais recente do provedor para usufruir de todos os aprimoramentos mais recentes.
• Usar os SDKs de Configuração de Aplicativos se o aplicativo precisar enviar solicitações de gravação. Embora os SDKs possam não ser tão avançados em recursos quanto provedores, eles fazem novas tentativas automaticamente ao receberem respostas do código de status HTTP 429 e outros erros transitórios.
• Inclua lógica de repetição em clientes personalizados se você não puder usar Provedores de Configuração de Aplicativos ou SDKs. O cabeçalho retry-after-ms na resposta fornece um tempo de espera sugerido (em milissegundos) antes de repetir a solicitação.
• Distribuir solicitações em várias instâncias de cliente: isso ajuda a atingir a taxa de transferência máxima do repositório de Configuração de Aplicativos.
• Reduzir as solicitações feitas à Configuração de Aplicativos: siga as diretrizes para minimizar o número de solicitações.
• Aprimorar 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.

Todos os repositórios de configurações da Configuração de Aplicativos nas camadas Standard e Premium têm o recurso de exclusão temporária habilitado automaticamente. Quando um repositório da Configuração de Aplicativos das camadas Standard ou Premium é excluído, seu nome é reservado durante o período de retenção. Para recriar um armazenamento com o mesmo nome antes que o período de retenção expire, você precisa limpar o armazenamento com exclusão reversível primeiro, desde que o armazenamento não tenha a proteção contra limpeza habilitada. Se a proteção contra limpeza estiver habilitada, você deverá aguardar o período de retenção acabar. Use a função de limpeza ou defina um período de retenção mais curto se você geralmente precisa recriar um armazenamento com o mesmo nome. Os fluxos de trabalho que exigem a recriação de um repositório com o mesmo nome devem permitir um intervalo de uma hora entre a limpeza de um repositório de configurações e a criação subsequente. Essa recomendação está em vigor porque, quando uma limpeza é solicitada, a limpeza real dos recursos do repositório de configurações é realizada de forma assíncrona, exigindo um pouco mais de tempo para ser finalizada. Para evitar qualquer necessidade de espera, recomenda-se que os fluxos de trabalho que criam repositórios de configurações efêmeros usem nomes exclusivos.

Todos os repositórios da Configuração de Aplicativos nas camadas Standard e Premium dão suporte ao recurso de exclusão temporária, que não pode ser desabilitado. Você pode recuperar um armazenamento excluído dentro de seu período de retenção. Siga estas instruções para recuperar um armazenamento de Configuração de Aplicativos excluído por engano.

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

Avaliar e consumir sinalizadores de recursos em seu aplicativo requer as bibliotecas de gerenciamento de recursos e de provedores da Configuração de Aplicativos, que estão disponíveis no .NET e no Java Spring. Confira a seção Gerenciamento de recursos em Guias de Início Rápido e Tutoriais para obter mais informações.

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

É recomendável definir o rótulo de seus valores-chave para corresponder aos seus perfis do Spring. Por padrão, a biblioteca do provedor de Spring de Configuração de Aplicativos do Azure carregará os pares chave-valor com os rótulos correspondentes aos perfis ativos atuais do Spring (${spring.profiles.active}) se o filtro de rótulo não estiver definido explicitamente. Se não houver nenhum perfil Spring ativo definido, os valores-chave com "sem rótulo" serão carregados.

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

Quando o perfil do Spring for definido como dev, o valor de config.message será Hello from dev. Quando o perfil do Spring for 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 inicialização. A biblioteca do provedor de Spring carregará os pares chave-valor com os rótulos especificados, independentemente do perfil ativo do Spring.

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

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

A partir da versão 3.1.0, a biblioteca Microsoft.FeatureManagement permite executar 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 chamada AddFeatureManagement em seu código AddScopedFeatureManagement, conforme mostrado no seguinte snippet 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 por meio do singleton IHttpContextAccessor padrão. No entanto, esse padrão não funciona para aplicativos de servidor Blazor em que os serviços com escopo devem ser usados. Nesse caso, o método AddScopedFeatureManagement deve ser usado.

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

Entre em contato conosco diretamente no GitHub.

• Sobre a Configuração de Aplicativos do Azure