Answers: <p>If you're just migrating I'd also recommend using <code>helm</code>.</p>
  <p>When using <code>helm</code> create the chart definition within the source code repository of the application, <a href="https://helm.sh/docs/helm/helm_create/" rel="nofollow noreferrer">https://helm.sh/docs/helm/helm_create/</a>.</p>
  <p>With an increasing number of services it can become harder and harder to manage so people have started to embrace a &quot;monorepo&quot; that contains a definition of the all the <code>helm charts</code> they currently have deployed and their respective versions. This way you can easily track when a version of service A was bumped and when a version of service B was bumped. <a href="https://www.infracloud.io/blogs/monorepo-ci-cd-helm-kubernetes/" rel="nofollow noreferrer">https://www.infracloud.io/blogs/monorepo-ci-cd-helm-kubernetes/</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2020-10-30T15:32:27.813Z
Answers: 2020-10-30T15:32:27.813Z
Answers: Derek Pedersen
Answers: <p>I don't think there is a right answer here, because there are pros and cons to both options.</p>
  <p>A centralized approach is potentially DRYer and easier to manage but isn't connected to the apps themselves, so a change in the Kubernetes repository could make an app fail and the developer would be none the wiser.</p>
  <p>A distributed or per repository approach allows you to delegate part of the work responsibility/powers to the developers of that repository but has the fragmentation problem (i.e. if your organization changes the way a commonly used Nginx deployment is done, it has to be updated in all repositories).</p>
  <p>I'm sure there are more reasons and opinions, but in my view, these are the biggest points (besides what you already described). I hope this helps!</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-12-04T16:09:18.600Z
Answers: 2020-12-04T16:09:18.600Z
Answers: migueldavid
Body: <p>We are currently migrating our Services to a Kubernetes environment.</p>
  <p>My question is if the configuration yaml file for each application</p>
  <ul>
  <li>should be in the repository where the application source itself is stored,</li>
  <li>or if there should be a centralized repository just for all the configuration files.</li>
  </ul>
  <p>Currently I'm drifting more towards a centralized repository holding all configs, as dependencies on different versions of applications / services can be managed there. Another thing is that a change in the configuration should not trigger a rebuild of the application itself and this is also easier if the configuration and the application repositories are not the same.</p>
  
Tags: <kubernetes><configuration-management><configuration>
Title: One Repository for Kubernetes configuration or one configuration per application repository
UserDisplayName: wertzui
ThreadText: # One Repository for Kubernetes configuration or one configuration per application repository
  
  (Asked by: username_0 on 2020-10-20)
  
  We are currently migrating our Services to a Kubernetes environment.
  
  My question is if the configuration yaml file for each application
  
  * should be in the repository where the application source itself is stored,
  * or if there should be a centralized repository just for all the configuration files.
  
  Currently I'm drifting more towards a centralized repository holding all configs, as dependencies on different versions of applications / services can be managed there. Another thing is that a change in the configuration should not trigger a rebuild of the application itself and this is also easier if the configuration and the application repositories are not the same.
  
  **Tags:** kubernetes, configuration-management, configuration
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2020-10-30. Score: 1
  
  If you're just migrating I'd also recommend using `helm`.
  
  When using `helm` create the chart definition within the source code repository of the application, <https://helm.sh/docs/helm/helm_create/>.
  
  With an increasing number of services it can become harder and harder to manage so people have started to embrace a "monorepo" that contains a definition of the all the `helm charts` they currently have deployed and their respective versions. This way you can easily track when a version of service A was bumped and when a version of service B was bumped. <https://www.infracloud.io/blogs/monorepo-ci-cd-helm-kubernetes/>
  
  
  ---
  
  ### Answer by username_2 on 2020-12-04. Score: 0
  
  I don't think there is a right answer here, because there are pros and cons to both options.
  
  A centralized approach is potentially DRYer and easier to manage but isn't connected to the apps themselves, so a change in the Kubernetes repository could make an app fail and the developer would be none the wiser.
  
  A distributed or per repository approach allows you to delegate part of the work responsibility/powers to the developers of that repository but has the fragmentation problem (i.e. if your organization changes the way a commonly used Nginx deployment is done, it has to be updated in all repositories).
  
  I'm sure there are more reasons and opinions, but in my view, these are the biggest points (besides what you already described). I hope this helps!
  
  
  ---
  
  