Onde devo colocar a configuração do meu aplicativo?

Ultimamente, tenho lido um debate sobre " Onde as propriedades que dependem do ambiente devem ser armazenadas? ".

A maneira clássica é ter vários arquivos de propriedades, um por ambiente, e com base em uma variável de ambiente (DEV, PROD ...), você escolhe onde lê-los ao iniciar o aplicativo (como nos perfis do Spring).

Por outro lado, se você estiver usando um contêiner para implantar seu aplicativo, é dito que esse tipo de configuração deve vir do próprio ambiente (usando variáveis ​​de ambiente que o aplicativo lê), para que a imagem não mude entre os ambientes.

Quais são os prós e os contras de cada abordagem? Existe uma abordagem "melhor" para o cenário de contêiner?

Quem disse que os arquivos de propriedades e as variáveis ​​de ambiente são mutuamente exclusivas?

Há uma distinção a ser feita entre "onde posso armazenar a configuração do meu aplicativo?" E "onde minha fonte de aplicativos é sua configuração?"

O resultado mais provável é que todo mundo provavelmente deve apenas continuar fazendo o que estão fazendo com arquivos de configuração como um armazenamento mecanismo (pensar a longo prazo, estado persistente durante o tempo que existe o meio ambiente).

No entanto, em vez de soltar esse arquivo de configuração no contexto do aplicativo e deixá-lo executar, o aplicativo deve esperar que essas variáveis ​​já estejam disponíveis no ambiente quando for inicializado.

Isso significa que você precisa ter dois fluxos de trabalho de implantação -

1. Implantei um aplicativo para um ambiente, passando pelo processo de controle de alterações X e revisando Y com a ferramenta Z, qualquer que seja.
2. Implantei a configuração do meu ambiente em um ambiente, passando por Um processo de controle de alterações e fazendo revisões B com a ferramenta C, mesmo processo, resultado diferente.

Para usar um exemplo de gerenciamento de variáveis ​​de ambiente como pares de Valor-chave em uma ferramenta como consul, se você estiver armazenando arquivos de configuração no git, ferramentas como git2consul podem gerenciar essa configuração no ambiente quando ela é atualizada.

Se você tem um aplicativo que espera que a configuração esteja disponível como um arquivo de configuração, é possível evitar o envio de várias cópias do arquivo de configuração com o aplicativo, criando um processo de implantação com algo como consul-template, que pode ativar seu valores consul novamente em um arquivo.

 A maneira como fazemos isso é que temos 3 peças (ou artefatos) para cada aplicativo em execução.

1. A aplicação que estamos desenvolvendo. É o mesmo, independentemente do ambiente. Para corresponder ao seu exemplo, esse será o aplicativo Spring como um jar / war.
2. O contêiner que executará o aplicativo. É o mesmo, independentemente do ambiente. Se você estiver usando o Spring Boot, não precisará mais do Tomcat e apenas do Java Runtime. Portanto, use o contêiner openjdk Docker.
3. A configuração que o aplicativo precisa. Essa é a única coisa diferente entre os ambientes. Em um aplicativo Spring, você provavelmente estará usando um arquivo de propriedades.

O arquivo de configuração vive em um controle de origem separado. Isso costumava ser o Git, mas agora estamos usando um SaaS que construímos chamado Config, em http://www.configapp.com . O principal recurso do Config é o fácil manuseio de configurações específicas do ambiente. Para executar nosso aplicativo em um novo servidor, puxamos o contêiner do Docker, o artefato do aplicativo e o arquivo de configuração para esse ambiente. No contêiner, montamos o diretório em que o aplicativo e o arquivo de configuração estão armazenados, como parte da execução do contêiner. Nossa aplicação é a mesma. Nosso contêiner / imagem é o mesmo. Somente o arquivo de configuração é diferente.

Em relação ao arquivo de configuração versus variáveis ​​de ambiente. Durante muito tempo, estávamos usando arquivos de configuração. Quando usamos PaaS / cloud, usamos variáveis ​​de ambiente. Foi um trabalho extra se você tiver muita configuração, por isso acabamos usando variáveis ​​de ambiente para determinar o arquivo de configuração correto. Temos um aplicativo que transformou propriedades em variáveis ​​de ambiente, mas isso é atípico. Se tivermos um servidor de configuração centralizado sancionado pela empresa, usaremos isso, caso contrário gostaremos da simplicidade dos arquivos de configuração.

Então, para resumir, puxamos app.jar, app.properties, openjdk Docker. Em seguida, rodamos o openjdk Docker montando o local de app.jar e app.properties. A única coisa específica do ambiente é app.properties. Para gerenciar facilmente app.properties, independentemente de quantas chaves de propriedade, ambientes, instâncias de cluster / região, usamos o Config.