Melhores práticas da Configuração de Aplicativos do Azure
Este artigo aborda padrões comuns e práticas recomendadas quando você estiver usando Azure App configuração.
Agrupamentos de chaves
A configuração do aplicativo fornece duas opções para organizar as chaves:
- Prefixos de chave
- Rótulos
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ê está armazenando chaves para muitos aplicativos e microsserviços em um repositório de Configurações de Aplicativo.
Uma coisa importante a ter em mente é que as chaves são as referências do código do aplicativo para recuperar os valores das configurações correspondentes. As chaves não devem ser alteradas ou, caso contrário, você precisará modificar seu código sempre que isso acontecer.
Os Rótulos 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 algumas outras informações contextuais. Seu aplicativo pode solicitar um conjunto totalmente diferente de valores de chave especificando outro rótulo. Como resultado, todas as referências de chave permanecem inalteradas no seu código.
Composições chave-valor
A Configuração de Aplicativo trata todas as chaves armazenadas com ela como entidades independentes. A Configuração de Aplicativos não tenta inferir nenhuma relação entre chaves ou herdar valores de chave com base em sua hierarquia. No entanto, você pode agregar vários conjuntos de chaves usando rótulos juntamente com o empilhamento de configuração adequado no código do aplicativo.
Vamos examinar 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 "Desenvolvimento" no último.
Em seu código, você primeiro recupera os valores de chave sem rótulos e, em seguida, recupera o mesmo conjunto de valores de 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 do .NET permite "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 essa funcionalidade de empilhamento gratuitamente se usar um provedor de configuração nativo para acessar a Configuração de Aplicativos. O seguinte snippet de código mostra como você pode implementar essa pilha no 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 de Aplicativos foi projetada para armazenar todos os 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 em outras fontes. Por exemplo, armazene segredos no Key Vault, 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 de Aplicativos 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 o aplicativo lê uma referência, ele carrega os dados reais da fonte referenciada, supondo que ele tenha a permissão necessária para ela. Ao alterar o local dos dados externos, você só precisa atualizar a referência na Configuração de Aplicativos em vez de atualizar e reimplantar todo o aplicativo.
O recurso referência do Key Vault da Configuração de Aplicativos é um exemplo neste caso. Ele permite que os segredos necessários para um aplicativo sejam atualizados conforme necessário, enquanto os próprios segredos subjacentes permanecem no Key Vault.
Inicialização da Configuração de Aplicativos
Para acessar um armazenamento 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 credencial, elas são consideradas segredos. Esses segredos precisam ser armazenados no Azure Key Vault, e seu código deve ser autenticado no Key Vault 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 da Configuração de Aplicativos para inicializar o acesso ao seu armazenamento de Configuração de Aplicativos. Você pode inserir a URL no código do aplicativo (por exemplo, na appsettings.jsno arquivo). Confira Usar identidades gerenciadas para acessar a Configuração de Aplicativos para obter detalhes.
Acesso do Serviço de Kubernetes do Azure à Configuração de Aplicativos
As opções a seguir estão disponíveis para cargas de trabalho hospedadas no AKS (Serviço de Kubernetes do Azure) para acessar a Configuração de Aplicativos do Azure. Essas opções também se aplicam ao Kubernetes em geral.
Adicione o Provedor de Kubernetes de Configuração de Aplicativos do Azure ao cluster do AKS. O provedor do Kubernetes é executado como um pod no cluster. Ele pode construir ConfigMaps e Segredos a partir de chave-valores e referências do Key Vault em seu repositório de Configuração de Aplicativos. O ConfigMap e o Segredo são consumíveis como variáveis de ambiente ou arquivos montados sem a necessidade de modificações no código do aplicativo. Se você tiver vários aplicativos em execução no mesmo cluster do AKS, todos eles poderão acessar o ConfigMaps e os Segredos gerados, eliminando a necessidade de solicitações individuais para a Configuração de Aplicativos. O provedor do Kubernetes também dá suporte a atualizações de configuração dinâmicas. Essa é a opção recomendada, se viável para você.
Atualize seu aplicativo para usar bibliotecas do provedor de Configuração de Aplicativos do Azure. As bibliotecas de provedor estão disponíveis em muitas estruturas e idiomas, como ASP.NET, .NET, Java Spring, JavaScript/Node.js e Python. Essa abordagem permite acesso completo às funcionalidades da Configuração de Aplicativos, incluindo a configuração dinâmica e o gerenciamento de recursos. Você tem controle granular de quais dados carregar e de qual repositório de Configuração de Aplicativos para cada aplicativo.
Integre-se à implantação do Kubernetes usando o Helm. Se você não quiser atualizar seu aplicativo ou adicionar um novo pod ao cluster do AKS, terá a opção de trazer dados da Configuração de Aplicativos para o cluster do Kubernetes usando o Helm por meio da implantação. Essa abordagem permite que seu aplicativo continue acessando a configuração 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 de Aplicativos
Use o provedor de Configuração de Aplicativos ou as bibliotecas do SDK para acessar a Configuração de Aplicativos diretamente no aplicativo. Essa abordagem permite acesso completo às funcionalidades da Configuração de Aplicativos, incluindo a configuração dinâmica e o gerenciamento de recursos. O aplicativo em execução no Serviço de Aplicativo ou no Azure Functions pode obter acesso ao repositório Configuração de Aplicativos com um dos seguintes métodos:
- Habilitar a identidade gerenciada no Serviço de Aplicativo ou no Azure Functions e permitir que ela acesse o repositório da Configuração de Aplicativos. Para obter mais informações, confira Como usar identidades gerenciadas para acessar a Configuração de Aplicativos.
- Armazenar a cadeia de conexão do repositório da Configuração de Aplicativos nas Configurações do aplicativo do Serviço de Aplicativo ou do Azure Functions. Para segurança aprimorada, armazene a cadeia de conexão no Key Vault e faça referência a ela no Serviço de Aplicativo ou no Azure Functions.
Você também pode deixar os dados da Configuração de Aplicativos acessíveis ao aplicativo como Configurações do aplicativo ou variáveis de ambiente. Com essa abordagem, você evita alterar o código do aplicativo.
- Adicionar referências aos dados da Configuração de Aplicativos nas Configurações do aplicativo do Serviço de Aplicativo ou do Azure Functions. A Configuração de Aplicativos oferece ferramentas para exportar uma coleção de chaves-valores como referências de uma só vez. Para obter mais informações, confira Usar as referências da Configuração de Aplicativos para o Serviço de Aplicativo e o Azure Functions.
- Exporte seus dados de Configuração de Aplicativos para as Configurações de aplicativo do seu Serviço de Aplicativo ou Azure Functions sem selecionar a opção de exportar como referência. Exportar os dados novamente sempre que fizer novas alterações na Configuração de Aplicativos se quiser que o aplicativo capture a alteração.
Reduzir solicitações feitas à configuração do aplicativo
Solicitações excessivas para a configuração do aplicativo podem resultar na limitação ou encargos excedentes. Para reduzir o número de solicitações feitas:
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 método
SetCacheExpiration
.Assista a uma única chave do Sentinela, em vez de observar as chaves individuais. Atualize todas as configurações somente se a chave do Sentinela for alterada. Consulte Usar a configuração dinâmica em um aplicativo ASP.NET Core para ver um exemplo.
Use o provedor de Kubernetes de Configuração de Aplicativo se você executar várias cargas de trabalho em um cluster do Kubernetes, cada um extraindo dados da Configuração de Aplicativos individualmente. O provedor do Kubernetes recupera dados da Configuração de Aplicativos e os disponibiliza como Kubernetes ConfigMaps e Segredos. Dessa forma, suas cargas de trabalho podem acessar os dados por meio de ConfigMaps e Segredos sem a necessidade de efetuar pull de dados da Configuração de Aplicativos separadamente.
Habilite a replicação geográfica do seu repositório de Configuração de Aplicativos e espalhe suas solicitações em 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 paralisações transitórias e regionais.
Importando dados de configuração para configuração de aplicativo
A configuração de 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 de Aplicativos, por exemplo, entre lojas relacionadas. Se você adotou a Configuração como Código e gerencia suas configurações no GitHub ou no Azure DevOps, poderá configurar a importação contínua de arquivos de configuração usando o GitHub Actions ou a Tarefa de importação do pipeline do Azure.
Implantação de várias regiões na Configuração de Aplicativos
Se seu aplicativo for implantado em várias regiões, recomendamos que você habilite a replicação geográfica do repositório de Configuração de Aplicativos. Você pode permitir que seu aplicativo se conecte principalmente à réplica correspondente à região onde as instâncias do 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 o aplicativo e a Configuração do Aplicativo, distribui a carga à medida que cada réplica tem cotas de limitação separadas e aumenta a resiliência do aplicativo contra paralisações transitórias e regionais. Consulte Resiliência e recuperação de desastres para obter mais informações.
Criando aplicativos com alta resiliência
Os aplicativos geralmente dependem da configuração para iniciar, tornando a alta disponibilidade da Configuração de Aplicativos do Azure crítica. Para melhorar a resiliência, os aplicativos devem aproveitar os recursos de confiabilidade da Configuração de Aplicativos e considerar tomar as medidas a seguir com base em seus requisitos específicos.
- Provisionar em regiões com suporte à zona de disponibilidade do Azure. As zonas de disponibilidade permitem que os aplicativos sejam resilientes a interrupções de data center. A Configuração de Aplicativos oferece redundância de zona para todos os clientes sem encargos extras. É recomendável criar seu repositório de Configuração de Aplicativos em regiões com suporte para zonas de disponibilidade. Você pode encontrar uma lista de regiões em que a Configuração de Aplicativos habilitou o suporte à zona de disponibilidade.
- Habilite a replicação geográfica e permita que seu aplicativo faça failover ou distribua a 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.
- Implantar 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 afetam a produção diretamente do portal do Azure, por exemplo, sempre que possível. Em SDP (práticas de implantação seguras), 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 as instâncias do aplicativo para selecionar progressivamente o novo instantâneo. Se forem detectados problemas, você poderá reverter a alteração reimplantando o instantâneo LKG (last-known-good). O instantâneo é imutável, garantindo consistência em todas as implantações. Você pode utilizar instantâneos junto 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 uma dependência de runtime na Configuração de Aplicativos completamente, você poderá efetuar pull da configuração da Configuração de Aplicativos durante o tempo de build ou lançamento e incluí-la com seu aplicativo. Para saber mais, confira exemplos de integração da Configuração de Aplicativos ao pipeline de CI/CD ou implantação do Kubernetes.
- Use provedores de Configuração de Aplicativos. Os aplicativos desempenham um papel fundamental na obtenção de alta resiliência porque podem considerar problemas decorrentes durante o runtime, como problemas de rede, e responder a falhas mais rapidamente. Os provedores de Configuração de Aplicativos oferecem uma variedade de recursos internos de resiliência, incluindo descoberta automática de réplica, failover de réplica, 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 Aplicativos para se beneficiar desses recursos. Se essa não for uma opção, considere implementar recursos semelhantes em sua solução personalizada para alcançar o nível mais alto de resiliência.
Aplicativos cliente na Configuração de Aplicativos
Quando usar a Configuração de Aplicativos em aplicativos cliente, não deixe de considerar dois fatores principais. Primeiro, se estiver usando a cadeia de conexão em um aplicativo cliente, você correrá o risco de expor a chave de acesso do seu armazenamento de Configuração de Aplicativos para o público. Segundo, a escala comum de um aplicativo cliente pode causar solicitações excessivas ao armazenamento de Configuração do Aplicativos, o que pode resultar em encargos excedentes ou limitação. Para saber 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 seu armazenamento de Configuração de Aplicativos. O serviço de proxy pode se autenticar com segurança com seu armazenamento de Configuração de Aplicativos sem um problema de segurança ao vazar informações de autenticação. Você pode criar um serviço de proxy usando uma das bibliotecas de provedor da Configuração de Aplicativos, para que você possa aproveitar os recursos internos de cache e atualização para otimizar o volume de solicitações enviadas para a Configuração de Aplicativos. Para obter mais informações sobre como usar provedores de Configuração de Aplicativos, consulte os artigos nas Guias de Início Rápido e Tutoriais. O serviço de proxy serve a configuração de seu cache para seus aplicativos cliente e você evita os dois problemas potenciais que são discutidos nesta seção.
Aplicativos multilocatário na Configuração de Aplicativos
Um aplicativo multilocatário é criado em uma arquitetura em que uma instância compartilhada do aplicativo atende a vários clientes ou locatários. Por exemplo, você pode ter um serviço de email que oferece aos usuários contas separadas e experiências personalizadas. Seu aplicativo normalmente gerencia configurações diferentes para cada locatário. Aqui estão algumas considerações de arquitetura para usar a Configuração de Aplicativos em um aplicativo multilocatário.
Configuração como código
A configuração como código é uma prática de gerenciar arquivos de configuração no sistema de controle do código-fonte, por exemplo, um repositório Git. Ela oferece benefícios como rastreabilidade e processo de aprovação para qualquer alteração de configuração. Se você adotar a configuração como código, a Configuração de Aplicativos terá ferramentas para ajudar você a gerenciar seus dados de configuração em arquivos e implantá-los como parte do processo da CI/CD, de liberação ou de compilação. Dessa forma, seus aplicativos podem acessar os dados mais recentes dos seus repositórios da Configuração de Aplicativos.
- Para o GitHub, você pode importar arquivos de configuração do repositório do GitHub para o repositório de Configuração de Aplicativos usando o GitHub Actions
- Para o Azure DevOps, você pode incluir a Importação da Configuração de Aplicativos do Azure, uma tarefa de pipeline do Azure, nos seus pipelines de build ou de lançamento para a sincronização de dados.
- Você também pode importar arquivos de configuração para a Configuração de Aplicativos usando a CLI do Azure como parte do seu sistema de CI/CD. Para obter mais informações, confira az appconfig kv import.
Esse modelo permite que você inclua etapas de validação e de teste antes de confirmar os dados na Configuração de Aplicativos. Se você usar vários repositórios da Configuração de Aplicativos, também poderá enviar por push os dados de configuração para eles de modo incremental ou todos de uma só vez.