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.

Esse limite 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 saber mais, confira os 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.

Há dois tipos de preço:

• Camada gratuita
• Camada padrão

Se você criou um repositório antes da introdução da camada Standard, ele foi movido automaticamente para a camada gratuita após a disponibilidade geral. Você pode optar por atualizar para a camada Standard ou permanecer na camada gratuita.

Não é possível fazer downgrade de um repositório da camada Standard para a camada gratuita. Como alternativa, crie um novo repositório na camada gratuita e importe os dados de configuração para ele.

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

Veja as considerações abaixo ao 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 na camada gratuita. Na camada Standard, as assinaturas podem ter um número ilimitado de repositórios de configuração.

• Armazenamento por recurso: na camada gratuita, cada repositório de configuração é limitado a 10 MB de armazenamento regular e 10 MB de armazenamento de instantâneos. Na camada standard, cada repositório de configuração pode usar até 1 GB de armazenamento regular e mais 1 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. Esse histórico é armazenado por sete dias na camada gratuita. Na camada Standard, ele é 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. Quando a cota por hora for atingida, as solicitações poderão retornar o código de status HTTP 429 indicando “muitas solicitações, aguarde uma hora”. À medida que mais solicitações acima da cota são enviadas, um percentual mais alto delas pode retornar o código de status 429.

• Contrato de Nível de Serviço: a camada standard tem um SLA de 99,9% de disponibilidade e 99,95% de disponibilidade com a replicação geográfica habilitada. A camada gratuita não tem um SLA.

• Recursos: ambas 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. A camada Standard oferece 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: os repositórios da camada Standard têm um custo de uso diário. As primeiras 200.000 solicitações no dia são incluídas na cobrança diária. Há também um encargo excedente para solicitações após a alocação diária. Não há nenhum custo ao usar um repositório da camada gratuita.

Você pode atualizar da camada gratuita para a camada Standard a qualquer momento.

Não é possível fazer downgrade de um repositório da camada Standard para a camada gratuita. Como alternativa, crie um novo repositório na camada gratuita e importe os dados de configuração para ele.

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 e Zonas de Disponibilidade no Azure.

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

Os repositórios da Configuração de Aplicativos na camada gratuita são limitados a 1.000 solicitações por dia. Já na camada Standard, pode ocorrer uma limitação temporária quando a taxa de solicitações excede 30.000 solicitações por hora.

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

Se seu aplicativo receber regularmente respostas com o código de status HTTP 429, considere modificá-lo para reduzir o número de solicitações feitas. Para obter mais informações, confira Como reduzir as solicitações feitas à Configuração de Aplicativos.

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

• Ao exceder o limite diário de solicitações em um repositório da camada gratuita.
• Ao exceder o limite de solicitações por hora em um repositório da camada standard.
• Limitação momentânea devido a uma grande intermitência de solicitações†.
• Limitação momentânea devido ao uso excessivo de largura de banda†.
• Ao tentar criar ou modificar uma chave depois que a cota de armazenamento for excedida.

Verifique o corpo da resposta 429 para saber o motivo específico da falha na solicitação.

†Um repositório de configurações pode apresentar limitação momentânea se receber uma grande intermitência de solicitações. Clientes da Configuração de Aplicativos, como o SDK do Azure, as bibliotecas do provedor de configuração e as tarefas do Pipeline do Azure, realizam automaticamente nova tentativa após a ocorrência das solicitações limitadas. Para aplicativos que usam um desses clientes ou um cliente personalizado que fazem nova tentativa após solicitações limitadas, essa limitação momentânea deverá 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 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 do repositório†.

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 valores de chave, portanto, serão necessários 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. 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 limitação por hora. Para obter mais informações, confira Como reduzir as solicitações feitas à Configuração de Aplicativos.

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

Todos os armazenamentos da Configuração de Aplicativos na camada standard habilitaram automaticamente o recurso exclusão reversível. Quando um repositório da Configuração de Aplicativos na camada Standard é excluído, o nome fica reservado por três dias após a exclusã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 armazenamentos da Configuração de Aplicativos na camada standard são suportados pelo recurso de exclusão reversível, 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 valores-chave 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 valores-chave 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 é executado inspecionando o HttpContext por meio do padrão singleton por meio do IHttpContextAccessorpadrão singleton. 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