Como devo armazenar minhas variáveis ​​de ambiente?

Essa é uma pergunta muito ampla sobre métodos e conselhos sobre variáveis ​​/ estrutura do ambiente. Mas, em última análise, estou procurando respostas para a pergunta muito específica de 'Como devo armazenar minhas variáveis ​​de ambiente?'

Primeiramente alguns esclarecimentos:

• Um ambiente para mim pode ser de 3 a 10 servidores e é uma maneira de conter a infraestrutura de um cliente específico.
• Dentro de cada ambiente, existem algumas variáveis ​​que são geradas automaticamente a partir de algumas entradas principais (nome, tamanho, etc.).

No momento, estamos armazenando todas as nossas variáveis ​​de ambiente em uma estrutura como esta:

<playbook>.yml                   # Various playbooks for deployment
roles/windows                    # Ansible role for Ubuntu
roles/ubuntu                     # Ansible role for Ubuntu
config/hosts/<name>.yml          # Ansible inventory
config/hosts/vars/<name>.json    # Environment specific variables 

No momento, a configuração é inicializada como um submódulo no repositório git acima. Como o arquivo de variáveis ​​muda com bastante frequência, isso causa problemas na alteração dos dados, uma vez, duas ou até três vezes entre confirmações, tornando as alterações cada vez mais difíceis de rastrear.

Do ponto de vista pessoal daqui para frente, devemos procurar armazenar todas as variáveis ​​de nossos clientes de maneira centralizada / escalável e depois conectá-las a ela com um inventário dinâmico e ansible .

Entendo que existem algumas tecnologias que parecem fazer parte do que poderia ser necessário, como o Consul, mas elas parecem funcionar melhor em um ambiente que atende a um grande aplicativo, em vez de muitas pequenas e ligeiramente diferentes.

Essencialmente, vejo-nos tendo que escrever um script de inventário e, em seguida, apenas empurrar todos os nossos dados para algum banco de dados criado não para fins específicos e continuar como se nada tivesse mudado. Vejo isso concebivelmente como uma maneira de reduzir potencialmente muitos dados que armazenamos atualmente e talvez procurar maneiras diferentes de armazenar os dados, em vez de apenas aumentar o que serve novamente.

Espero que alguém tenha algum tipo de experiência na implementação de infraestrutura como código ao ter que lidar com muitos ambientes menores em oposição a um, dois ou três grandes.

Alguma sugestão?

Eu tive duas execuções fazendo variáveis ​​de ambiente de uma maneira escalável e nenhuma delas acabou perfeita porque, como eu descobri, é uma coisa muito complicada de acertar. Vou dar um resumo das duas experiências abaixo:

Fatores comuns

• As variáveis ​​de ambiente são armazenadas em um repositório separado do código-fonte original (elas são submoduladas juntas, mas ainda são baseadas em repositórios separados)
• Existe um processo de "construção" separado para o artefato e suas variáveis.
• Há não um processo de liberação separado para as variáveis de ambiente. Se você quiser alterar variáveis ​​de ambiente, precisará passar pelos mesmos painéis de revisão de alterações e

Usando pares Consul KV

As variáveis ​​de ambiente são carregadas de um repositório de artefato (nunca o repositório git original) e carregadas em uma árvore de pares KV com espaço para nome, por exemplo

/env/dev1/my/application/v1.1.1

Onde o dev1 anterior é o nome do ambiente, o my / application é o namespace do aplicativo e a v1.1.1 é a versão das variáveis ​​de ambiente a serem usadas.

Para os desenvolvedores, todas essas coisas são invisíveis. No tempo de execução, a plataforma verifica se o ambiente existe no cluster cônsul atual (se não houver um problema e houver erros), em seguida, verificará a subárvore quanto ao espaço de nomes dos aplicativos (dessa forma, não haverá contaminação cruzada em um aplicativo faz referência a outros aplicativos), o número da versão da configuração é obtido do rótulo conectado ao artefato implementável. Atualizar esse rótulo é a principal coisa aqui, porque significa que, se perdermos os dois data centers de produção, poderemos suportar o ambiente novamente lendo simplesmente os metadados de nossos artefatos implementáveis ​​e carregando todas as variáveis ​​de ambiente no armazenamento KV.

Problemas com essa abordagem Os desenvolvedores sempre, e quero dizer sempre, encontravam uma maneira de inserir alterações de configuração no ambiente que tinham impactos significativos na maneira como o aplicativo seria executado. Porque sempre era mais fácil aprovar as alterações de configuração do que as alterações de código.

Armazenando um Artefato de "Implantação" com variáveis ​​incorporadas

Isso une firmemente a versão exata do artefato à versão da configuração. Se você alterou a configuração, teve que reconstruir esse artefato de implantação.

O artefato de implementação em si era essencialmente um arquivo yaml que continha a URL para o binário liberável e toda a configuração anexada a ele.

A plataforma contém componentes para ler variáveis ​​e depois distribuí-las na árvore de processos do aplicativo quando ele é inicializado.

Até agora, isso foi muito mais bem-sucedido, porque existe um artefato com o qual podemos rastrear a história e que podemos manter em qualquer painel de revisão e dizer "este é o único artefato com o qual nos preocupamos, não precisamos olhar para quaisquer outras alterações, apenas alterações nessa coisa "(por exemplo, versão do aplicativo a ser implantada, variáveis ​​de ambiente incluídas etc.)

Isso torna um pouco mais difícil para os desenvolvedores tentarem criar lógica em seus aplicativos, que mudará seu comportamento com base em variáveis, para que possam realizar alterações sem passar por ciclos de teste apropriados.

Pontos bônus

Considere os segredos do aplicativo. Até agora, nossa solução para isso foi fornecer uma chave pública RSA que as equipes de desenvolvimento usam para criptografar um armazenamento de chaves Java estendido (quase todas as linguagens têm uma biblioteca em algum lugar que pode ler armazenamentos de chaves Java); isso é tratado como um terceiro tipo de artefato e é puxado para o servidor, descriptografado com a chave privada da nossa plataforma e fornecido ao aplicativo em tempo de execução.

É certo que o gerenciamento de segredos é sua própria lata de minhocas. Mas provavelmente vale a pena considerar.

Se seus ambientes forem por cliente, sugiro que, no seu caso específico, tenha um repositório por cliente . (Em geral, é repositório por ambiente.) Esse repositório teria uma estrutura de diretórios padrão para variáveis ​​de ambiente, variáveis ​​e inventários ansíveis, segredos fortemente criptografados (tokens de acesso à conta, chaves privadas etc.). Você submodularia o código nesses repositórios. Eu provavelmente faria isso em vários repositórios. Um para funções e módulos ansible, um para scripts de manutenção e implantação, um para cada aplicativo principal em execução nos ambientes.

Agora você pode opcionalmente dividir o código ou fixar o submódulo em uma tag específica para liberação , certificando-se de que o código que gerencia o ambiente do cliente não seja alterado, a menos que testado e liberado.

Se você estiver usando um repositório de artefatos , verifique se os artefatos estão com versão correta e se essas versões estão especificadas nas variáveis ​​de ambiente corretamente.

A automação é importante porque as variáveis ​​de ambiente não devem ser atualizadas por humanos sempre que possível, mas geradas por scripts. Verifique se quase não há atualizações manuais no inventário por cliente e os desenvolvedores atualizam apenas os repositórios de código. Se eles desejam fazer alterações na configuração, isso deve ser feito em um dos scripts de geração, que é executado para gerar as variáveis ​​e o diff é confirmado no repositório do cliente. Vale a pena configurar a integração contínua para esse processo. Sem isso, em algum momento, haverá muitos repositórios para manter .