This is a generic Helm chart that can define and manage arbitrary Kubernetes Service and Ingress objects in an opinionated fashion.
The chart lets the operator define custom "conduits" using a simplified YAML syntax. Whereby a "conduit" can be defined as a set of uniquely named Ingress definition (i.e.hosts+paths), that when deployed, serve as a single well established application traffic "pipeline" that services HTTP(s) for one or more long-lived FQDNs into an ever evolving set of backend target Services.
Although this chart can be used on its own and send traffic to any deployed application on Kubernetes, it was designed to play nicely with applications deployed by appdeploy which you can find at: https://github.com/bitsofinfo/appdeploy
- Conventions
- What it does
- What its not intended for
- Alerts
- Options
- Meta-variables
- Diagram
- Examples
- Using as a dependency
- Packaging/Using
- Related projects
The appconduits chart uses some of the same conventions and terminology as described by its sibling chart appdeploy
Specifically the following definitions:
As one would expect, an environment is something like dev, qa, prod or stage.
Within an environment, one or more contexts can exist as a way to logically sub-divide applications within an environment. The loose rule is that all applications sharing the same context talk to one another or similar configuration sources/databases etc. Contexts permit a level of classification that applications can use to alter how they bootup, configs they load etc. within an environment. The name of a context generally includes the environment implicit in its name (i.e. qa-silo1)
Sometimes an application artifact may operate in different modes, these different modes may enable or disable certain aspects of standard functionality provided by the artifact; such as the availability or lack thereof certain exposed APIs or ports. In these cases the classifier can simply act as a naming decoration to help identify this.
The above is simple set of terminologies found in this chart's configuration, but does not physically impose anything (functionality wise) on the artifacts (Ingress,Service) that are generated by this chart.
In short, the above terminology may or may not work for you, but have proved to be a useful set of conventions used in the real world and has worked pretty well.
In an of itself, this chart provisions nothing as its default values.yaml is empty on the key element of configuration
under the section conduits whereby you define actual contexts with services and ingress who's combination thereof constitute a "conduit". See the examples as the best way to get a feel for things.
This chart produces the following Kubernetes YAML objects that adhere to a general convention described above.
Depending on your values.yaml customizations, specifically the configuration of the conduits section, this Chart will produce the following kinds of artifacts:
- Services: one or more
Servicesproperly configured with your definedselectors - Ingress: one or more
Ingressfor each uniquehost+pathcombination defined underconduitsthat route to configuresservices - Helm Hooks: Post install/upgrade (
Jobs) that alert the deployedconduitsstate to Slack
This chart does not deploy application image artifacts. It simply provides a simplified way to express custom Services and Ingress that point to already deployed apps. If you need a chart to just deploy apps check out: appdeploy.
The whole point of appconduits is to enable teams to establish well defined and well recognized traffic routes to logical applications which may actually be composed of many different deployed image artifacts with ever changing versions. By expressing Service and Ingress relationships and organizing them under the guise of a single conduit, it decouples the management of how traffic routes to logical applications from the deployment of those application artifacts. Overall this can greatly simplify management of the numerous Service/Ingress objects required to realize these flows by expressing them as a single conduit managed as a Helm release along with all the benefits it provides.
All configurable options are documented in values.yaml
See the helm docs for setting values
on how to customize/change these values when doing a helm ... invocation.
The best way to get a feel for things is to try the example
For examples see the examples/ folder
Build it: helm package appconduits
Then copy the resulting tgz into your dependant chart's charts/ folder
From there you can customize your chart's values.yaml to further refine the
defaults provided by appconduits/values.yaml
For example, lets say you create a deriviative chart based on appconduits.
Your derivative chart's values.yaml could further provide defaults on top
of appconduits as follows:
my-custom-chart/values.yaml
my-own-chart-property1: "some value"
# Specify value customizations for the 'appconduits' dependency
# To override the values of "sub-charts" you have to scope them
# as follows:
# https://github.com/helm/helm/blob/master/docs/chart_template_guide/subcharts_and_globals.md
appconduits:
conduitname: "whatever"
....
helm package . -d repo/charts/
helm repo index repo/
helm repo add bitsofinfo-appconduits https://raw.githubusercontent.com/bitsofinfo/appconduits/master/repo
helm repo update
# requirements.yaml
dependencies:
- name: appconduits
version: "1.1.0"
repository: "https://raw.githubusercontent.com/bitsofinfo/appconduits/master/repo"