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
Services
properly configured with your definedselectors
- Ingress: one or more
Ingress
for each uniquehost
+path
combination defined underconduits
that route to configuresservices
- Helm Hooks: Post install/upgrade (
Jobs
) that alert the deployedconduits
state 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"