<p>I'm new to using Helm and I'm not sure which is the best approach when you have two deployments.
I've created a chart for my application. It contains two deployments:</p>

<ol>
<li>app-nginx-phpfpm.yaml</li>
<li>app-mysql.yaml</li>
</ol>

<p>Should I keep them in the same chart or should I create a sub-chart for app-mysql.yaml? </p>

<p>You can have both, depending on how you want to structure your deployments.</p>

<p>You should keep in mind the following</p>

<h1>Considerations</h1>

<h2>Single chart benefits</h2>

<ul>
<li>Easier to deploy: only deploy once, single diffing</li>
<li>Single version, so rollback/upgrades happen on a single element</li>
<li>You can uninstall parts by using feature flags</li>
<li>Installing a new component without touching the rest of the elements may prove tricky</li>
</ul>

<h2>Single chart caveats</h2>

<ul>
<li>Harder to deploy uncoupled services, e.g., a mock service for data access while upgrading the database</li>
<li>Harder to decouple and test each instance</li>
<li>Harder to name and make sense of each component (in different releases your <code>{{.Release.Name}}</code> would already change for each "app").</li>
<li>Harder to provide/keep track of different release cycles for different components</li>
<li>Versions stored in a single ConfigMap, which may lead to size limit problems if you have charts which contain, for example, testing data embedded</li>
</ul>

<h1>Note on version control</h1>

<p>You can have a master chart that you use for testing with all subcharts, and package the subcharts independently but still have everything on the same repo.</p>

<p>For example, I usually keep things like either:</p>

<pre><code>. / helm / charts / whatever / charts / subchart1
. / helm / charts / whatever / charts / subchart2
. / helm / charts / whatever / values.yaml
</code></pre>

<p>or</p>

<pre><code>. / helm / charts / whatever-master / values.yaml
. / helm / charts / whatever-master / requirements.yaml
. / helm / charts / whatever-subchart1 / values.yaml
. / helm / charts / whatever-subchart2 / values.yaml
</code></pre>

<p>And use the requirements.yaml on the master chart to pull from <code>file://../whatever-subchartx</code>.</p>

<p>This way I can have <code>whatever-stress-test</code> and <code>whatever-subcomponent-unit-test</code> while still being flexible to deploy separately components that have different release cycles if so wanted.</p>

<p>This will in the end also depend on your upgrade strategy. Canary upgrades will probably require you to handle stateful microservices in a more specific way than you can have with a single chart, so plan accordingly.</p>
