docs(charts_tips_and_tricks): SAP and Deis examples

This adds a couple of examples for building an application chart for
complex multi-part applications.
pull/1481/head
Matt Butcher 8 years ago
parent 846011b02a
commit 91ff73bf53
No known key found for this signature in database
GPG Key ID: DCD5F5E5EF32C345

@ -50,6 +50,35 @@ underscore(`_`) is not expected to output a Kubernetes manifest file. So
by convention, helper templates and partials are placed in a
`_helpers.tpl` file.
## Complex Charts with Many Dependencies
Many of the charts in the [official charts repository](https://github.com/kubernetes/charts)
are "building blocks" for creating more advanced applications. But charts may be
used to create instances of large-scale applications. In such cases, a single
umbrella chart may have multiple subcharts, each of which functions as a piece
of the whole.
The current best practice for composing a complex application from discrete parts
is to create a top-level umbrella chart that
exposes the global configurations, and then use the `charts/` subdirectory to
embed each of the components.
Two strong design patterns are illustrated by these projects:
**SAP's [OpenStack chart](https://github.com/sapcc/openstack-helm):** This chart
installs a full OpenStack IaaS on Kubernetes. All of the charts are collected
together in one GitHub repository.
**Deis's [Workflow](https://github.com/deis/workflow/tree/master/charts/workflow):**
This chart exposes the entire Deis PaaS system with one chart. But it's different
from the SAP chart in that this master chart is built from each component, and
each component is tracked in a different Git repository. Check out the
`requirements.yaml` file to see how this chart is composed by their CI/CD
pipeline.
Both of these charts illustrate proven techniques for standing up complex environments
using Helm.
## YAML is a Superset of JSON
According to the YAML specification, YAML is a superset of JSON. That

Loading…
Cancel
Save