Où dois-je mettre la configuration de mon application?

J'ai lu récemment un débat sur " Où les propriétés qui dépendent de l'environnement doivent-elles être stockées? ".

La méthode classique consiste à avoir plusieurs fichiers de propriétés, un par environnement, et en fonction d'une variable d'environnement (DEV, PROD ...), vous choisissez où les lire au démarrage de l'application (comme avec les profils Spring).

D'un autre côté, si vous utilisez un conteneur pour déployer votre application, il est dit que ce type de configuration doit provenir de l'environnement lui-même (en utilisant des variables d'environnement que l'application lit), afin que l'image ne change pas entre les environnements.

Quels sont les avantages et les inconvénients de chaque approche? Existe-t-il une "meilleure" approche pour le scénario de conteneur?

Qui a dit que les fichiers de propriétés et les variables d'environnement étaient mutuellement exclusifs?

Il y a une distinction à faire entre "où dois-je stocker la configuration de mon application?" Et "d'où vient la source de mon application elle configurée?"

Le résultat le plus probable est que tout le monde devrait probablement continuer à faire ce qu'il fait avec les fichiers de configuration comme mécanisme de stockage (pensez à un état persistant à long terme aussi longtemps que l'environnement existe).

Cependant, plutôt que de déposer ce fichier de configuration dans le contexte de l'application et de le laisser s'exécuter, l'application devrait pouvoir s'attendre à ce que ces variables soient déjà disponibles dans l'environnement au démarrage.

Cela signifie que vous devez disposer de deux flux de travail de déploiement -

1. Je déploie une application dans un environnement en passant par le processus de contrôle des modifications X et en effectuant des révisions Y avec l'outil Z, peu importe.
2. Je déploie ma configuration d'environnement dans un environnement en passant par un processus de contrôle des changements et en effectuant des révisions B avec l'outil C, le même processus, des résultats différents.

Pour utiliser un exemple de gestion des variables d'environnement sous forme de paires de valeurs-clés dans un outil comme consul, si vous stockez des fichiers de configuration dans git, des outils comme git2consul avec handle récupèrent cette configuration dans l'environnement lors de sa mise à jour.

Si vous avez une application qui s'attend à ce que la configuration soit disponible en tant que fichier de configuration, vous pouvez éviter d'envoyer plusieurs copies du fichier de configuration avec l'application en créant un processus de déploiement avec quelque chose comme consul-template qui a la capacité de transformer votre consul retourne les valeurs dans un fichier.

 La façon dont nous le faisons est que nous avons 3 pièces (ou artefacts) pour chaque application en cours d'exécution.

1. L'application que nous développons. C'est la même chose quel que soit l'environnement. Pour correspondre à votre exemple, ce sera l'application Spring sous la forme d'un pot / war.
2. Conteneur qui exécutera l'application. C'est la même chose quel que soit l'environnement. Si vous utilisez Spring Boot, vous n'avez plus besoin de Tomcat et seulement du runtime Java. Utilisez donc le conteneur Docker openjdk.
3. La configuration dont l'application a besoin. C'est la seule chose qui diffère d'un environnement à l'autre. Dans une application Spring, vous utiliserez probablement un fichier de propriétés.

Le fichier de configuration réside dans un contrôle de source distinct. Auparavant, c'était Git, mais nous utilisons maintenant un SaaS que nous avons construit, appelé Config, sur http://www.configapp.com . La fonction principale de Config est la gestion facile de la configuration spécifique à l'environnement. Pour exécuter notre application sur un nouveau serveur, nous extrayons le conteneur Docker, l'artefact d'application et le fichier de configuration de cet environnement. Dans le conteneur, nous montons le répertoire dans lequel l'application et le fichier de configuration sont stockés, dans le cadre de l'exécution du conteneur. Notre application est la même. Notre conteneur / image est le même. Seul le fichier de configuration est différent.

Concernant le fichier de configuration vs les variables d'environnement. Pendant longtemps, nous avons utilisé des fichiers de configuration. Lorsque nous avons utilisé PaaS / cloud, nous avons utilisé des variables d'environnement. C'était un travail supplémentaire si vous avez beaucoup de configuration, nous avons donc fini par utiliser des variables d'environnement pour déterminer le fichier de configuration correct. Nous avons une application qui a transformé les propriétés en variables d'environnement, mais c'est atypique. Si nous avons un serveur de configuration centralisé sanctionné par l'entreprise, nous l'utilisons, sinon nous aimons la simplicité des fichiers de configuration.

Donc, pour résumer, nous tirons app.jar, app.properties, openjdk Docker. Ensuite, nous exécutons openjdk Docker pour monter l'emplacement de app.jar et app.properties. La seule chose spécifique à l'environnement est app.properties. Pour gérer facilement app.properties, quel que soit le nombre de clés de propriété, les environnements, les instances de cluster / région, nous utilisons Config.