Nesta postagem, orientarei você na implantação de configurações do AWS AppConfig usando o AWS Cloud Development Kit (CDK) e as novas construções AppConfig L2 (maior abstração).
Implementaremos uma configuração JSON para uso de sinalizadores de recursos para aplicativos sem servidor e sem servidor com código Python CDK.
Não deixe de verificar a versão mais recente do código no repositório de modelos .
Índice
Introdução rápida ao AppConfig
O AWS AppConfig é um serviço autogerenciado que armazena configurações de TEXTO simples/YAML/JSON para serem consumidas por vários clientes.
Vamos dar uma olhada nas vantagens do AppConfig:
FedRAMP Altamente certificado
Totalmente sem servidor
Suporte pronto para uso para validações de esquema executadas antes de uma atualização de configuração.
A integração pronta para uso com os alarmes do AWS CloudWatch aciona uma reversão automática de configuração se uma atualização de configuração falhar nas suas funções do AWS Lambda. Leia mais sobre isso aqui .
Você pode definir estratégias de implantação de configuração. Estratégias de implantação definem como e quando alterar uma configuração. Leia mais sobre isso aqui .
Ele fornece uma única API que busca a configuração.
Se você leu minhas postagens anteriores do AppConfig, sabe que eu uso o utilitário de sinalizadores de recursos do AWS Lambda Powertools para buscar e avaliar configurações do AppConfig.
Nosso Objetivo
Nosso objetivo é implantar uma configuração JSON de formato livre que possamos usar com o utilitário de sinalizadores de recursos do AWS Lambda Powertools.
A construção que apresento aqui implantará uma configuração JSON no AppConfig como uma configuração de forma livre com uma estratégia de implantação com tempo de espera zero.
Para contas de produção, você deve usar um perfil de implantação canário e configurar validações JSON e um alarme do CloudWatch para acionar uma reversão automática em caso de erros de serviço durante a implantação da configuração.
Se você quiser aprender sobre as melhores práticas para sinalizadores de recursos e como usar, criar e testar sinalizadores de recursos, confira minhas duas postagens sobre eles:
Vamos em frente e escrever algum código.
Dependências do Python
Para consumir a nova construção L2, que contém melhores abstrações, adicione as seguintes instruções ao seu arquivo de poesia:
Esteja ciente de que estamos usando uma construção alfa, que pode quebrar ou conter bugs. Use-a a seu critério. No entanto, depois de testá-la, posso confirmar que ela funciona conforme o esperado no momento da escrita, e já faz parte do projeto AWS Lambda Handler Cookbook.
Construção de configuração
Vamos revisar minha nova construção, que usa construções de abstrações mais altas do L2, reduzindo assim o esforço geral para definir configurações do AppConfig:
Nossa construção requer vários parâmetros de entrada:
id_ (str): O ID do constructo com escopo. Deve ser único.
Ambiente (str): nome do ambiente AppConfig a ser criado.
service_name (str): Nome do aplicativo AppConfig a ser criado.
configuration_name (str): Nome da configuração do AppConfig a ser criada.
configuration_str (str): conteúdo de configuração do AppConfig a ser criado
Nas linhas 33-40, criamos o aplicativo AppConfig; na linha 40, definimos a política de remoção para destroy. Você terá uma abordagem semelhante aplicada a todos os recursos.
Nas linhas 41-48, definimos o ambiente AWS AppConfig.
Nas linhas 51-61, definimos a estratégia de implantação do AppConfig. Escolhi uma implantação imediata (zero minutos para tempos de bake e implantação), mas você deve usar as opções de implantação canary ou definir as suas próprias para cargas de trabalho de produção. Leia a documentação aqui .
Nas linhas 63-75, definimos a configuração para implantar e conectar todos os recursos.
Observe como escolhi a linha 69, o tipo freeform. Você deve usar freeform para uso com o utilitário Powertools feature flags.
Na linha 68, fornecemos a string de configuração que obtivemos como parâmetro de entrada de construção.
A linha 75 é uma solução alternativa até que a política de remoção seja definida e exposta corretamente (veja o link para o problema do CDK).
Conclusão:
As novas construções L2 são uma edição bem-vinda, pois reduzem a quantidade total de código e a complexidade geral, mas sugiro que você crie sua própria construção que englobe essas construções L2 em uma ou use o exemplo que forneci aqui.
Para outras informações e conexão de recursos avançados, como validadores JSON, extensões e alarme CloudWatch, consulte a documentação oficial abaixo: