<p>I have at least 4 config files for my service.</p>

<p>Like, application.properties, log config file, query file, ...</p>

<p>There are 4 config files which I am storing into kubernetes ConfigMaps and they are for different purposes. Currently, I am creating 4 configMaps for these 4 files and it becomes more work to configure them in deployment file.</p>

<p>We basically keep all these files in GIT and would be driving changes from GIT. So, if we need to modify something in the configMap, we will first update our file in GIT and then recreate a configMap.</p>

<p>Is there any other better way to just update few changes?</p>

<p>Does it make sense to keep all these 4 files in a single configMap.</p>

<p>Any advice please.</p>

<p>This is my personal opinion based on what I have learned so far and there may be different or easier or even better ways out there, so please take this answer with a pinch of salt.</p>

<p>Considering you have multiple services or projects, etc. And each of these projects has its own configuration files or environment variables which is needed by service to function as expected.</p>

<p>What I would do is : </p>

<ol>
<li>Decide which configuration options are secrets and which are normal env variables.</li>
<li>Create two files for these named maybe .. secret-config.yml and env-config.yml</li>
<li><p>Make sure you set the appropriate kind to each of the document. Here is a sample config file and similar secret file can be stored.</p>

<pre><code>apiVersion: v1
data:
  ENV_1: test
  ENV_1: test2
  ENV_1: test3
kind: ConfigMap
metadata:
  annotations:
    field.cattle.io/creatorId: user-8rtg2
  name: my-service-configs
  namespace: my-namespace
</code></pre></li>
<li><p>Now assuming you have a CI-CD environment setup, in your pipeline or deployment-config, add few steps after the service deploys steps to update these secrets/configmaps with the updates values.</p>

<pre><code>sh deploy_to_kubernets
sh update_config_maps
sh update_secrets
</code></pre></li>
</ol>

<p>Now to explain myself :</p>

<ul>
<li><p>Why are we storing config kubernetes YML in repo ?</p>

<p>Because we want to make sure all the related config is accessible and stored in a place where it is relevant. And it makes sense as we are going to use it in CI process.</p></li>
<li><p>What about creating or updating the config &amp; secrets from CI ?</p>

<p>Now for me, since I am using rancher API on top of kubernetes, I can use the API to access my cluster and create or update resources. I am sure you can find something similar to perform this actions on your cluster.</p></li>
</ul>

<p>So concluding, just store your config in your services as it config is part of the service and is necessary for code to work(figure out a way to encode or hide secrets values from being exposed in code). Make sure you create secrets and config maps based on the type of variables you are using. 
 And with this, you will be able to automate the creation of configmaps and each of these configmaps will be in proper context.</p>
