https://github.com/bitsofinfo/appconduits
Helm Chart for managing custom Kubernetes Service and Ingress traffic flows
https://github.com/bitsofinfo/appconduits
deployment helm helm-charts ingress kubernetes service-mesh
Last synced: 10 months ago
JSON representation
Helm Chart for managing custom Kubernetes Service and Ingress traffic flows
- Host: GitHub
- URL: https://github.com/bitsofinfo/appconduits
- Owner: bitsofinfo
- Created: 2019-06-10T16:48:13.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2023-02-23T16:38:23.000Z (almost 3 years ago)
- Last Synced: 2025-01-29T11:12:59.131Z (12 months ago)
- Topics: deployment, helm, helm-charts, ingress, kubernetes, service-mesh
- Homepage: https://bitsofinfo.wordpress.com/2019/07/12/manage-custom-ingress-via-helm/
- Size: 1.67 MB
- Stars: 0
- Watchers: 3
- Forks: 1
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
Awesome Lists containing this project
README
# appconduits
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](https://github.com/bitsofinfo/appdeploy) which you can find at: https://github.com/bitsofinfo/appdeploy
* [Conventions](#convention)
* [What it does](#does)
* [What its not intended for](#doesnot)
* [Alerts](#alerts)
* [Options](#options)
* [Meta-variables](#metavar)
* [Diagram](#diag)
* [Examples](examples/)
* [Using as a dependency](#dependency)
* [Packaging/Using](#pack)
* [Related projects](#related)
The `appconduits` chart uses some of the [same conventions and terminology](https://github.com/bitsofinfo/appdeploy#convention) as described by its sibling chart [appdeploy](https://github.com/bitsofinfo/appdeploy)
Specifically the following definitions:
### environment
As one would expect, an *environment* is something like `dev`, `qa`, `prod` or `stage`.
### context
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`)
### classifier
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.
## Important!
In an of itself, this chart provisions nothing as its default [values.yaml](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](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](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 defined `selectors`
* **Ingress**: one or more `Ingress` for each unique `host`+`path` combination defined under `conduits` that route to configures `services`
* **Helm Hooks**: Post install/upgrade (`Jobs`) that alert the deployed `conduits` 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](https://github.com/bitsofinfo/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](values.yaml)
See the [helm docs for setting values](https://github.com/helm/helm/blob/master/docs/chart_best_practices/values.md)
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](examples/)
## Examples
For examples see the [examples/ folder](examples/)
## As a dependency in another chart
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/
```
## Using
```
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"
```
* [appdeploy](https://github.com/bitsofinfo/appdeploy)
* [helmfile-deploy](https://github.com/bitsofinfo/helmfile-deploy)