cisco-sso / mh Goto Github PK

A templating tool to manage and deploy multiple Helm charts.

License: Apache License 2.0

Makefile 0.72% Go 98.49% Dockerfile 0.79%

helm kubernetes

mh's Introduction

mh

$ mh --help
            __
           /\ \
  ___ ___  \ \ \___
/. __. __.\ \ \  _  \
/\ \/\ \/\ \ \ \ \ \ \
\ \_\ \_\ \_\ \ \_\ \_\
 \/_/\/_/\/_/  \/_/\/_/

mh simplifies multi-chart Helm workflows by rendering ephemeral Helm
chart override files based on templates populated with values from mh
YAML config files.

In other words: We heard you like templates, so we templated your Helm value
overrides.

Usage:
  mh [command]

Available Commands:
  apply       Apply apps
  destroy     Destroy apps
  help        Help about any command
  license     Print license information.
  simulate    Simulate apps
  status      Get status of apps
  version     Print version information.

Flags:
  -c, --config string     config file (you can instead set MH_CONFIG)
  -h, --help              help for mh
  -j, --json              set logging to JSON format

Use "mh [command] --help" for more information about a command.

$ mh license
Copyright © 2018 Cisco Systems, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Getting Started

Install mh.

go get -u github.com/cisco-sso/mh

Select a kubectl context.

(In general, this is when you "choose a Kubernetes cluster" to manage.)

kubectl config get-contexts
kubectl config use-context minikube

Select a mh config.

(There's usally one mh config per kubetl context, but we've left it open ended so that multple teams can more easily work together on one cluster.)

export MH_CONFIG="/path/to/clusters/minikube/mh/main.yaml"

Get status of everything at context "minkube" managed by this mh config.

(This basically runs helm status for each app you target.)

mh status
# ^ get status for all apps in `main.yaml`

mh status wordpress
# ^ get status for just these app(s)

Simulate app upgrades (or simulate install of apps, as needed).

(For each app you target, simulate runs a Helm upgrade/install with debug and dry-run modes enabled.)

mh simulate
# ^ simulate install/upgrade for all apps in `main.yaml`

mh simulate --printRendered
# ^ simulate install/upgrade for all apps in `main.yaml`
#   (verbosely printing app template renderings)

mh simulate wordpress
# ^ simulate install/upgrade just these app(s),
#   even if they are not in `main.yaml`

mh simulate --set "wordpress.image.tag=1.0.0"
# ^ simulate by setting mh values on the command line
#   (can specify multiple or separate values with commas: key1=val1,key2=val2)

Apply app upgrades (or install apps, as needed).

(For each app you target, apply runs a Helm upgrade/install).

mh apply
# ^ apply install/upgrade for all apps in `main.yaml`

mh apply --printRendered
# ^ apply install/upgrade for all apps in `main.yaml`
#   (verbosely printing app template renderings)

mh apply wordpress
# ^ apply install/upgrade just these app(s),
#   even if they are not in `main.yaml`

mh apply --set "wordpress.image.tag=1.0.0"
# ^ apply by setting mh values on the command line
#   (can specify multiple or separate values with commas: key1=val1,key2=val2)

Destroy apps (if they are known to Helm).

(For each app you target, apply runs a Helm delete without purge).

mh destroy
# ^ destroy all apps in `main.yaml`

mh destroy wordpress
# ^ destroy just these app(s),
#   even if they are not in `main.yaml`

Log to JSON!

mh status foo --json 2>&1 | jq --slurp

Docker

docker run --rm \
  -v $(pwd):/platform-deploy \
  -v ~/.kube:/.kube \
  -v ~/.helm:/root/.helm \
  -e KUBECONFIG=/.kube/mycluster.example.org \
  -e MH_CONFIG=/platform-deploy/clusters/mycluster.example.org/mh/main.yaml \
  ciscosso/mh simulate

NOTE: The MH apps and config in this example exist in the platform-deploy tree.

Apps should be stored relative to MH config. (use configPath instead of path).

appSources:
  - name: apps
    kind: configPath
    source: ../../../apps

Contributing

For information on contributing to this repo, please see the accompanying CONTRIBUTING.md file.

mh's People

Contributors

Stargazers

Watchers

Forkers

nvichare rustycl0ck josdotso marsavela simt2 drekle prabdeb gherlein dcwangmit01 wozniakjan vaibhav-kaushal

mh's Issues

Including multi-line files via gomplate breaks the config

I tried to include a multi-line file via gomplate like this:
mh.yaml

targetContext: minikube

gomplate:
  datasources:
  - "cassandra-grafana-dashboard=./cassandra-grafana-dashboard.json"
  datasourceheaders: []

rawCassandraGrafanaDashboard:
  resources:
  - apiVersion: v1
    metadata:
      name: cassandra-grafana-dashboard
    kind: ConfigMap
    spec:
      data:
        cassandra-dashboard.json: |-
[[ include "cassandra-grafana-dashboard" | indent 10 ]]

Running mh simulate fails with:

WARN[0000] Failed to load mh config. Please consider exporting environment variable: MH_CONFIG.  configFile=/Users/sitesar/src/go/src/github.com/cisco-sso/mh/main.yaml configFileEnv=/Users/sitesar/src/go/src/github.com/cisco-sso/mh/main.yaml configFileEnvPresent=true configFileFlag= configFileOrigin=env configFileUsed=/Users/sitesar/src/go/src/github.com/cisco-sso/mh/main.yaml err="While parsing config: yaml: line 18: could not find expected ':'"
FATA[0000] `kubectl config current-context` does not match configured targetContext  command=simulate currentContext=minikube targetContext=localhost

mh parses MH_CONFIG before it runs any command to sanity check the kubectl context, but with this kind of templating, MH_CONFIG isn't valid YAML anymore.

Values of '--set' parameter not honored with 'mh apply'

mh simulate -c mh/main.yaml test-chart --set var1=value1 honors the --set parameter values and overrides the value of var1. It prints the correct/expected output too.

But mh apply -c mh/main.yaml test-chart --set var1=value1 does not honor the values provided by --set parameter and picks up values only from mh/main.yaml.

Sidenote: Not sure (and did not test) if it actually honors the -c mh/main.yaml parameter too. This is set to the same value through environment variable by default.

[Feature] Native support for multiple namespaces.

Per user request.

[Bug] PrintRendered doesn't work on Apply.

mh simulate --printRendered produces a rendering of the Helm override, but mh apply --printRendered does not.

Missing gomplate datasources breaks other apps too

Current Behavior:
After adding a gomplate datasource, if the datasource file is missing, then the apps which even do not make use of that datasource, can not be installed or updated.

Expected Behavior:
Even if the gomplate datasources are missing, mh apply my-gomplate-independent-app should still work.

This issue makes it impossible to use gomplate datasources with CI tools.

[Feature] Allow splitting up of main.yaml into subfiles

As the number of apps grows, the main.yaml mh config file becomes very huge (~2000+ lines in some cases). Thus it would be convenient if the values for some apps can be provided from external files (preferably in the scope of mh config directories). A rough example would be as follows:

Current pattern:

apps:
  - name: my-chart-0.1.0
    key: .myChart
    alias: my-chart

myChart:
  key1: value1
  key2: value2
   .. : ..
  key30: value30

Expected pattern:

apps:
  - name: my-chart-0.1.0
    key: .myChart
    alias: my-chart

myChart:
  file: myChart-values.yaml

This would make it easier to manage the app values separately for each app and will also make the mh config file much cleaner if some app requires a lot of properties to be set.

[Feature] Enable mh templating to pull values from files and generate secrets

There are two things that we need to do in our mh templating system:

Enable the reading of secrets directly from files, in order to set helm chart overrides. Key use case is to read a secret from keybaseFS.
Enable the random generation of secrets, which then may be set as a helm chart override. This helps us auto-generate kube secrets.

[Feature] Allow helm timeout to be configured individually for apps

There should be the option to override/configure the timeout for helm install of the charts. Some actions might take longer, like claiming a PVC in a private cloud, making it necessary to prolong the timeouts to allow a mh app to finish successfully.

No error when invalid appname provided

mh should return non-zero exit code if a non-existent app name is provided while running.
mh apply -p my-non-existant-app exits with return code 0 while it should fail with a non-zero status because the mh-app in consideration (my-non-existant-app) doesn't actually exist.

mh container image doesn't appear to support PriorityClass resources

Error: apiVersion "scheduling.k8s.io/v1beta1" in raw/templates/resources.yaml is not available

My guess is we need to bump the version of helm used in the container image.

[Feature] Support for --set to overwrite mh config values

The support for mh --set similar to helm --set is very much needed to run mh commands through CI/CD systems where it is needed to set the image tag dynamically for each commit.

[Feature] Release Docker build to Docker Hub

selftemplating doesn't work if string contains single quote

Mocked example, similar to one of our auth files where value contains '

cat ./file.yaml

file:
  foo:
    bar:
      value: "abc'def"

gomplate:
  datasources:
  - "file=./file.yaml"
  datasourceheaders: []:
test_val: "[[ (index (ds 'file').foo 'bar').value ]]"

fails with random error converting YAML to JSON: yaml: line 5: did not find expected key" on second iteration of selftemplating, but is broken in first iteration as well because it passes forward

gomplate:
  datasources:
  - "file=./file.yaml"
  datasourceheaders: []:
test_val: 'abc'def'

[Feature] Allow (multiple) regex excludes during apply.

Example: mh apply --exclude foo-* --exclude bar-*

[Feature] Enable mh direct chart overrides via self templating

In helm umbrella charts, the values.yaml subchart definitions in the parent chart are merged directly onto the values.yaml of the subcharts. mh does not work in that same way, and instead requires the app.yaml to interpret the mh config with added customizations in order to produce the overrides for a specific chart.

This creates confusion because the mh yaml file in many cases looks like it would override subcharts directly just like a helm umbrella chart. But it doesn't, because it's up to the app.yaml to interpret it to create the overrides which then maps upon the chart values.yaml

We should enable mh to directly override subcharts similar to umbrella chart behavior. In addition, we should allow the mh config file parameters to self-reference other parts of the mh config file. By doing this, we may be able to reduce or remove the dependencies on our app.yaml files.

There's a PR open in helm right now which does similar things, but it has been open since December 2017. helm/helm#3252 . If that merges first, we will be closer to getting back to native helm.

[Critical] MH compilation is broken

MH compilation is broken since - e600817

Getting the below error -

$ CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o /mh .
# github.com/cisco-sso/mh/vendor/github.com/hairyhenderson/gomplate/funcs
vendor/github.com/hairyhenderson/gomplate/funcs/math.go:235:9: undefined: "math".Round
$

`mh simulate` deployed the chart

Running mh simulate chaoskube has deployed the helm chart.

As a sanity check, I looked at my bash history to make sure it wasn't deployed previously

$ history
 1128  helm list | grep -i chaos
 1129  ls
 1130  vim mh/main.yaml
 1131  mh simulate chaoskube
 1132  kubectl get pods -l app=chaoskube-chaoskube --namespace default --output name
 1133  kubectl pod/chaoskube-chaoskube-7844f5c88d-6wdj9
 1134  kubectl log chaoskube-chaoskube-7844f5c88d-6wdj9
 1135  history

The logs support my observations

$ kubectl logs chaoskube-chaoskube-7844f5c88d-6wdj9
time="2018-08-30T14:52:18Z" level=info msg="Targeting cluster at https://XX.XXX.XXX"
time="2018-08-30T14:52:18Z" level=info msg="Filtering pods by labels: release!=chaoskube"
time="2018-08-30T14:52:18Z" level=info msg="Filtering pods by namespaces: !kube-system"
time="2018-08-30T14:52:25Z" level=info msg="Killing pod default/nginx-ingress-controller-5498d44b97-rs6mm"

$ mh version
INFO[0000] mh                                            command=version version=v0.7.1