Práticas recomendadas de Configuração de Aplicativo do Azure

Este artigo discute padrões comuns e práticas recomendadas quando você estiver usando a Configuração de Aplicativo do Azure.

Agrupamentos-chave

A Configuração do Aplicativo fornece duas opções para organizar chaves:

• Prefixos de chave
• Etiquetas

Você pode usar uma ou ambas as opções para agrupar suas chaves.

Os prefixos de chave são as partes iniciais das chaves. Você pode agrupar logicamente um conjunto de chaves usando o mesmo prefixo em seus nomes. Os prefixos podem conter vários componentes conectados por um delimitador, como /, semelhante a um caminho de URL, para formar um namespace. Essas hierarquias são úteis quando você armazena chaves para muitos aplicativos e microsserviços em uma loja de configuração de aplicativos.

Uma coisa importante a ter em mente é que as chaves são o que o código do seu aplicativo faz referência para recuperar os valores das configurações correspondentes. As chaves não devem mudar, ou então você terá que modificar seu código cada vez que isso acontecer.

As etiquetas são um atributo nas chaves. Eles são usados para criar variantes de uma chave. Por exemplo, você pode atribuir rótulos a várias versões de uma chave. Uma versão pode ser uma iteração, um ambiente ou alguma outra informação contextual. Seu aplicativo pode solicitar um conjunto totalmente diferente de valores-chave especificando outro rótulo. Como resultado, todas as referências principais permanecem inalteradas no seu código.

Composições de valor-chave

A Configuração do Aplicativo trata todas as chaves armazenadas com ele como entidades independentes. A Configuração do Aplicativo não tenta inferir qualquer relação entre chaves ou herdar valores-chave com base em sua hierarquia. No entanto, você pode agregar vários conjuntos de chaves usando rótulos acoplados ao empilhamento de configuração adequado no código do aplicativo.

Vamos ver um exemplo. Suponha que você tenha uma configuração chamada Asset1, cujo valor pode variar com base no ambiente de desenvolvimento. Você cria uma chave chamada "Asset1" com um rótulo vazio e um rótulo chamado "Desenvolvimento". No primeiro rótulo, você coloca o valor padrão para Asset1 e coloca um valor específico para "Development" no segundo.

Em seu código, você primeiro recupera os valores-chave sem rótulos e, em seguida, recupera o mesmo conjunto de valores-chave uma segunda vez com o rótulo "Desenvolvimento". Quando você recupera os valores pela segunda vez, os valores anteriores das chaves são substituídos. O sistema de configuração .NET permite que você "empilhar" vários conjuntos de dados de configuração uns sobre os outros. Se uma chave existir em mais de um conjunto, o último conjunto que a contém será usado. Com uma estrutura de programação moderna, como o .NET, você obtém esse recurso de empilhamento gratuitamente se usar um provedor de configuração nativo para acessar a Configuração do Aplicativo. O trecho de código a seguir mostra como você pode implementar o empilhamento em um aplicativo .NET:

// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(configuration["connection_string"])
           .Select(KeyFilter.Any, LabelFilter.Null)
           .Select(KeyFilter.Any, "Development");
});

Usar rótulos para habilitar configurações diferentes para ambientes diferentes fornece um exemplo completo.

Referências a dados externos

A Configuração do Aplicativo foi projetada para armazenar quaisquer dados de configuração que você normalmente salvaria em arquivos de configuração ou variáveis de ambiente. No entanto, alguns tipos de dados podem ser mais adequados para residir noutras fontes. Por exemplo, armazene segredos no Cofre da Chave, arquivos no Armazenamento do Azure, informações de associação em grupos do Microsoft Entra ou listas de clientes em um banco de dados.

Você ainda pode aproveitar a Configuração do Aplicativo salvando uma referência a dados externos em um valor-chave. Você pode usar o tipo de conteúdo para diferenciar cada fonte de dados. Quando seu aplicativo lê uma referência, ele carrega os dados reais da fonte referenciada, supondo que tenha a permissão necessária para a fonte. Se você alterar o local dos dados externos, só precisará atualizar a referência na Configuração do aplicativo em vez de atualizar e reimplantar todo o aplicativo.

O recurso de referência do Cofre da Chave de Configuração do Aplicativo é um exemplo nesse caso. Ele permite que os segredos necessários para um aplicativo sejam atualizados conforme necessário, enquanto os próprios segredos subjacentes permanecem no Cofre da Chave.

Bootstrap de Configuração do Aplicativo

Para acessar uma loja de Configuração de Aplicativos, você pode usar sua cadeia de conexão, que está disponível no portal do Azure. Como as cadeias de conexão contêm informações de credenciais, elas são consideradas segredos. Esses segredos precisam ser armazenados no Cofre da Chave do Azure e seu código deve ser autenticado no Cofre da Chave para recuperá-los.

Uma opção melhor é usar o recurso de identidades gerenciadas no Microsoft Entra ID. Com identidades gerenciadas, você precisa apenas da URL do ponto de extremidade de Configuração do Aplicativo para inicializar o acesso à sua loja de Configuração de Aplicativos. Você pode incorporar a URL no código do aplicativo (por exemplo, no arquivo appsettings.json ). Consulte Usar identidades gerenciadas para acessar a Configuração do Aplicativo para obter detalhes.

Acesso do Serviço Kubernetes do Azure à Configuração do Aplicativo

As opções a seguir estão disponíveis para cargas de trabalho hospedadas no Serviço Kubernetes do Azure (AKS) para acessar a Configuração do Aplicativo do Azure. Essas opções também se aplicam ao Kubernetes em geral.

• Adicione o Provedor Kubernetes de Configuração do Aplicativo do Azure ao seu cluster AKS. O provedor Kubernetes é executado como um pod no cluster. Ele pode construir ConfigMaps e Secrets a partir de valores-chave e referências do Cofre de Chaves em sua loja de Configuração de Aplicativos. O ConfigMap e o Secret são consumíveis como variáveis de ambiente ou arquivos montados sem exigir modificações no código do aplicativo. Se você tiver vários aplicativos em execução no mesmo cluster AKS, todos eles poderão acessar os ConfigMaps e Segredos gerados, eliminando a necessidade de solicitações individuais para a Configuração do Aplicativo. O provedor Kubernetes também suporta atualizações de configuração dinâmica. Esta é a opção recomendada, se viável para si.

• Atualize seu aplicativo para usar as bibliotecas do provedor de Configuração de Aplicativo do Azure. As bibliotecas do provedor estão disponíveis em muitos frameworks e linguagens, como ASP.NET, .NET, Java Spring, JavaScript/Node.js e Python. Essa abordagem oferece acesso total às funcionalidades da Configuração do aplicativo, incluindo configuração dinâmica e gerenciamento de recursos. Você tem controle granular de quais dados carregar e de qual App Configuration Store para cada aplicativo.

• Integre com a implantação do Kubernetes usando o Helm. Se você não deseja atualizar seu aplicativo ou adicionar um novo pod ao seu cluster AKS, você tem a opção de trazer dados da Configuração do Aplicativo para o cluster do Kubernetes usando o Helm via implantação. Essa abordagem permite que seu aplicativo continue acessando a configuração a partir de variáveis e segredos do Kubernetes. Você pode executar a atualização do Helm sempre que quiser que seu aplicativo incorpore novas alterações de configuração.

Acesso do Serviço de Aplicativo ou do Azure Functions à Configuração do Aplicativo

Use o provedor de Configuração de Aplicativo ou bibliotecas SDK para acessar a Configuração de Aplicativo diretamente em seu aplicativo. Essa abordagem oferece acesso total às funcionalidades da Configuração do aplicativo, incluindo configuração dinâmica e gerenciamento de recursos. Seu aplicativo em execução no Serviço de Aplicativo ou no Azure Functions pode obter acesso à sua loja de Configuração de Aplicativo por meio de qualquer um dos seguintes métodos:

• Habilite a identidade gerenciada em seu Serviço de Aplicativo ou Azure Functions e conceda a ela acesso à sua loja de Configuração de Aplicativos. Para obter mais informações, consulte Usar identidades gerenciadas para acessar a Configuração do Aplicativo.
• Armazene a cadeia de conexão em seu repositório de Configuração de Aplicativo nas Configurações de Aplicativo do Serviço de Aplicativo ou do Azure Functions. Para maior segurança, armazene a cadeia de conexão no Cofre da Chave e faça referência a ela no Serviço de Aplicativo ou no Azure Functions.

Você também pode tornar seus dados de Configuração do Aplicativo acessíveis ao seu aplicativo como Configurações do aplicativo ou variáveis de ambiente. Com essa abordagem, você pode evitar alterar o código do aplicativo.

• Adicione referências aos dados de Configuração do Aplicativo nas configurações do Aplicativo do Serviço de Aplicativo ou do Azure Functions. A Configuração do Aplicativo oferece ferramentas para exportar uma coleção de valores-chave como referências de uma só vez. Para obter mais informações, consulte Usar referências de configuração de aplicativo para o Serviço de Aplicativo e o Azure Functions.
• Exporte seus dados de Configuração do Aplicativo para as configurações do Aplicativo do seu Serviço de Aplicativo ou do Azure Functions sem selecionar a opção de exportar como referência. Exporte seus dados novamente sempre que fizer novas alterações na Configuração do aplicativo, se quiser que seu aplicativo pegue a alteração.

Reduzir solicitações feitas à Configuração do Aplicativo

Solicitações excessivas à Configuração do Aplicativo podem resultar em cobranças de limitação ou sobrecarga. Para reduzir o número de pedidos efetuados:

• Aumente o intervalo de atualização, especialmente se os valores de configuração não forem alterados com frequência. Especifique um novo intervalo de atualização usando o SetCacheExpiration método.

• Assista a uma única chave sentinela, em vez de observar chaves individuais. Atualize todas as configurações somente se a chave sentinela mudar. Consulte Usar configuração dinâmica em um aplicativo ASP.NET Core para obter um exemplo.

• Use o Provedor Kubernetes de Configuração de Aplicativo se você executar várias cargas de trabalho em um cluster Kubernetes, cada uma extraindo dados da Configuração de Aplicativo individualmente. O provedor do Kubernetes recupera dados da Configuração do Aplicativo e os disponibiliza como ConfigMaps e Segredos do Kubernetes. Dessa forma, suas cargas de trabalho podem acessar os dados via ConfigMaps e Secrets sem precisar extrair dados da Configuração do Aplicativo separadamente.

• Habilite a replicação geográfica de sua loja de configuração de aplicativos e espalhe suas solicitações por várias réplicas. Por exemplo, use uma réplica diferente de cada região geográfica para um aplicativo implantado globalmente. Cada réplica de Configuração de Aplicativo tem sua cota de solicitação separada. Essa configuração oferece um modelo de escalabilidade e resiliência aprimorada contra interrupções transitórias e regionais.

Importando dados de configuração para a Configuração do Aplicativo

A Configuração do Aplicativo oferece a opção de importar em massa suas definições de configuração de seus arquivos de configuração atuais usando o portal do Azure ou a CLI. Você também pode usar as mesmas opções para exportar valores-chave da Configuração do aplicativo, por exemplo, entre lojas relacionadas. Se você adotou Configuração como Código e gerencia suas configurações no GitHub ou no Azure DevOps, pode configurar a importação de arquivos de configuração contínua usando as Ações do GitHub ou a Tarefa de Push do Pipeline do Azure.

Implantação em várias regiões na Configuração do Aplicativo

Se o seu aplicativo for implantado em várias regiões, recomendamos que você habilite a replicação geográfica da sua loja de Configuração de Aplicativos. Você pode permitir que seu aplicativo se conecte principalmente à réplica correspondente à região onde as instâncias do seu aplicativo são implantadas e permitir que elas façam failover para réplicas em outras regiões. Essa configuração minimiza a latência entre seu aplicativo e a Configuração do Aplicativo, distribui a carga à medida que cada réplica tem cotas de limitação separadas e aprimora a resiliência do aplicativo contra interrupções transitórias e regionais. Consulte Resiliência e recuperação de desastres para obter mais informações.

Construindo aplicações com alta resiliência

Os aplicativos geralmente dependem da configuração para iniciar, tornando a alta disponibilidade da Configuração de Aplicativo do Azure crítica. Para melhorar a resiliência, os aplicativos devem aproveitar os recursos de confiabilidade da Configuração do Aplicativo e considerar tomar as seguintes medidas com base em seus requisitos específicos.

• Provisionamento em regiões com suporte à zona de disponibilidade do Azure. As zonas de disponibilidade permitem que os aplicativos sejam resilientes a interrupções do data center. A Configuração de Aplicações oferece redundância de zona para todos os clientes sem quaisquer encargos adicionais. É recomendável criar sua loja de configuração de aplicativos em regiões com suporte para zonas de disponibilidade. Você pode encontrar uma lista de regiões onde a Configuração do Aplicativo habilitou o suporte à zona de disponibilidade.
• Habilite a replicação geográfica e permita que seu aplicativo faça failover ou distribua carga entre réplicas. Essa configuração oferece um modelo de escalabilidade e resiliência aprimorada contra falhas transitórias e interrupções regionais. Consulte Resiliência e recuperação de desastres para obter mais informações.
• Implante a configuração com práticas de implantação seguras. Alterações de configuração incorretas ou acidentais podem frequentemente causar tempo de inatividade do aplicativo. Você deve evitar fazer alterações de configuração que afetem a produção diretamente, por exemplo, do portal do Azure sempre que possível. Nas práticas de implantação segura (SDP), você usa um modelo de implantação de exposição progressiva para minimizar o raio de explosão potencial de problemas causados pela implantação. Se você adotar o SDP, poderá criar e testar um instantâneo de configuração antes de implantá-lo na produção. Durante a implantação, você pode atualizar instâncias do seu aplicativo para pegar progressivamente o novo instantâneo. Se forem detetados problemas, você poderá reverter a alteração reimplantando o instantâneo LKG (Last Known-Good). O snapshot é imutável, garantindo consistência em todas as implantações. Você pode utilizar instantâneos juntamente com a configuração dinâmica. Use um instantâneo para sua configuração básica e configuração dinâmica para substituições de configuração de emergência e sinalizadores de recursos.
• Inclua a configuração com seu aplicativo. Se você quiser garantir que seu aplicativo sempre tenha acesso a uma cópia da configuração, ou se preferir evitar completamente uma dependência de tempo de execução na Configuração do Aplicativo, você pode extrair a configuração da Configuração do Aplicativo durante o tempo de compilação ou lançamento e incluí-la em seu aplicativo. Para saber mais, confira exemplos de integração da Configuração de Aplicativo com seu pipeline de CI/CD ou implantação do Kubernetes.
• Use provedores de configuração de aplicativo. Os aplicativos desempenham um papel crítico na obtenção de alta resiliência porque podem levar em conta problemas que surgem durante seu tempo de execução, como problemas de rede, e responder a falhas mais rapidamente. Os provedores de Configuração de Aplicativo oferecem uma variedade de recursos internos de resiliência, incluindo descoberta automática de réplicas, failover de réplica, novas tentativas de inicialização com tempos limite personalizáveis, cache de configuração e estratégias adaptáveis para atualização de configuração confiável. É altamente recomendável que você use provedores de Configuração de Aplicativo para se beneficiar desses recursos. Se essa não for uma opção, você deve considerar a implementação de recursos semelhantes em sua solução personalizada para alcançar o mais alto nível de resiliência.

Aplicativos cliente na Configuração do Aplicativo

Ao usar a Configuração do Aplicativo em aplicativos cliente, certifique-se de considerar dois fatores principais. Primeiro, se você estiver usando a cadeia de conexão em um aplicativo cliente, corre o risco de expor a chave de acesso da sua loja de configuração de aplicativos ao público. Em segundo lugar, a escala típica de um aplicativo cliente pode causar solicitações excessivas à sua loja de configuração de aplicativos, o que pode resultar em cobranças excessivas ou limitação. Para obter mais informações sobre limitação, consulte as Perguntas frequentes.

Para resolver essas preocupações, recomendamos que você use um serviço de proxy entre seus aplicativos cliente e sua loja de configuração de aplicativos. O serviço de proxy pode autenticar-se com segurança na sua loja de Configuração de Aplicações sem um problema de segurança de fuga de informações de autenticação. Você pode criar um serviço de proxy usando uma das bibliotecas do provedor de Configuração de Aplicativo, para que possa aproveitar os recursos internos de cache e atualização para otimizar o volume de solicitações enviadas à Configuração do Aplicativo. Para obter mais informações sobre como usar provedores de Configuração de Aplicativo, consulte os artigos em Inícios rápidos e Tutoriais. O serviço de proxy serve a configuração de seu cache para seus aplicativos cliente e você evita os dois possíveis problemas discutidos nesta seção.

Aplicativos multilocatários na Configuração do Aplicativo

Um aplicativo multilocatário é criado em uma arquitetura em que uma instância compartilhada do seu aplicativo atende a vários clientes ou locatários. Por exemplo, você pode ter um serviço de e-mail que ofereça aos usuários contas separadas e experiências personalizadas. Seu aplicativo geralmente gerencia configurações diferentes para cada locatário. Aqui estão algumas considerações de arquitetura para usar a Configuração do Aplicativo em um aplicativo multilocatário.

Configuração como código

A configuração como código é uma prática de gerenciamento de arquivos de configuração sob seu sistema de controle de origem, por exemplo, um repositório git. Ele oferece benefícios como rastreabilidade e processo de aprovação para quaisquer alterações de configuração. Se você adotar a configuração como código, a Configuração do Aplicativo terá ferramentas para ajudá-lo a gerenciar seus dados de configuração em arquivos e implantá-los como parte de seu processo de compilação, lançamento ou CI/CD. Desta forma, as suas aplicações podem aceder aos dados mais recentes a partir da(s) sua(s) loja(s) de Configuração de Aplicações.

• Para o GitHub, você pode importar arquivos de configuração do repositório do GitHub para a loja de configuração de aplicativos usando as Ações do GitHub
• Para o Azure DevOps, você pode incluir o Push de Configuração do Aplicativo do Azure, uma tarefa de pipeline do Azure, em seus pipelines de compilação ou liberação para sincronização de dados.
• Você também pode importar arquivos de configuração para a Configuração do Aplicativo usando a CLI do Azure como parte do seu sistema de CI/CD. Para obter mais informações, consulte az appconfig kv import.

Esse modelo permite que você inclua etapas de validação e teste antes de confirmar dados na Configuração do aplicativo. Se você usar várias lojas de Configuração de Aplicativos, também poderá enviar os dados de configuração para elas de forma incremental ou de uma só vez.

Próximos passos

• Chaves e valores