README.md

kubecrt

Convert Helm charts to Kubernetes resources.

Description

kubecrt allows you to define your application's Kubernetes infrastructure based on a single configuration file.

The configuration file contains your application name, and namespace (both can also be set using CLI arguments), and you provide a list of charts that you want to install, optionally providing override values for those charts.

When running kubecrt, you provide it your project's configuration file, and in turn, it returns you the parsed Kubernetes resource files generated by the charts.

This allows you to use Helm Charts without actually using Helm, and instead using regular kubectl to deploy and manage your resources.

The configuration file you feed into kubecrt will be processed using the epp templating tool, allowing you to inject variables at runtime, based on your own conditional logic (production vs staging, etc...).

Installation

brew tap blendle/blendle
brew install kubecrt

Usage

See kubecrt --help

kubecrt - convert Helm charts to Kubernetes resources

Given a charts.yml file, compile all the charts with
the provided template variables and return the
resulting Kubernetes resource files to STDOUT, or
write them to a provided file.

Doing this, you can use Kubernetes charts, without
having to use Helm locally, or Tiller on the server.

Usage:
  kubecrt [options] CHARTS_CONFIG
  kubecrt -h | --help
  kubecrt --version
  kubecrt --example-config

Where CHARTS_CONFIG is the location of the YAML file
containing the Kubernetes Charts configuration.

Arguments:
  CHARTS_CONFIG                    Charts configuration file

Options:
  -h, --help                       Show this screen
  --version                        Show version
  -n NS, --namespace=NS            Set the .Release.Namespace chart variable,
                                   used by charts during compilation
  -a NAME, --name=NAME             Set the .Release.Name chart variable, used by
                                   charts during compilation
  -o PATH, --output=PATH           Write output to a file, instead of STDOUT
  -r NAME=URL, --repo=NAME=URL,... List of NAME=URL pairs of repositories to add
                                   to the index before compiling charts config
  -p DIR, --partials-dir=DIR       Path from which to load partial templates
                                   [default: config/deploy/partials]
  -j, --json                       Print resources formatted as JSON instead of
                                   YAML. Each resource is printed on a single
                                   line.
  --example-config                 Print an example charts.yaml, including
                                   extended documentation on the tunables

Charts Configuration File

See kubecrt --example-config

# apiVersion defines the version of the charts.yaml structure. Currently,
# only "v1" is supported.
apiVersion: v1

# name is the .Release.Name template value that charts can use in their
# templates, which can be overridden by the "--name" CLI flag. If omitted,
# "--name" is required.
name: my-bundled-apps

# namespace is the .Release.Namespace template value that charts can use in
# their templates. Note that since kubecrt does not communicate with
# Kubernetes in any way, it is up to you to also use this namespace when
# doing kubectl apply [...]. Can be overridden using "--namespace".  If omitted,
# "--namespace" is required.
namespace: apps

# charts is an array of charts you want to compile into Kubernetes resource
# files.
#
# A single chart might be used to deploy something simple, like a memcached pod,
# or something complex, like a full web app stack with HTTP servers, databases,
# caches, and so on.
charts:

# A Chart can either be in the format REPO/NAME, or a PATH to a local chart.
#
# If using REPO/NAME, kubecrt knows by-default where to locate the "stable"
# repository, all other repositories require the "repo" configuration (see
# below).
- stable/factorio:
    # values is a map of key/value pairs used when compiling the chart. This
    # uses the same format as in regular chart "values.yaml" files.
    #
    # see: https://git.io/v9Tyr
    values:
      resources:
        requests:
          memory: 1024Mi
          cpu: 750m
      factorioServer:
        # charts.yaml supports the same templating as chart templates do,
        # using the "sprig" library.
        #
        # see: https://masterminds.github.io/sprig/
        name: >
          {{ env "MY_SERVER_NAME" | default "hello world!" }}

- stable/minecraft:
    # version is a semantic version constraint.
    #
    # see: https://github.com/Masterminds/semver#basic-comparisons
    version: ~> 0.1.0
    values:
      minecraftServer:
        difficulty: hard

- opsgoodness/prometheus-operator:
    # repo is the location of a repositry, if other than "stable". This is
    # the URL you would normally add using "helm repo add NAME URL".
    repo: http://charts.opsgoodness.com
    values:
      sendAnalytics: false

# For the above charts, see here for the default configurations:
#
#   * stable/factorio: https://git.io/v9Tyr
#   * stable/minecraft: https://git.io/v9Tya
#   * opsgoodness/prometheus-operator: https://git.io/v9SAY

Partial Templates

You can optionally split your charts.yml file into multiple chunks, by using partial templates. This works almost the same way as Helm's support for these in charts. See the Helm documentation for more details.

To use these partials, you have to set the --partials-dir flag when calling kubecrt, pass it the path to your partials directory, and then use those partials in your charts.yml.

Example:

charts.yml:

apiVersion: v1
name: my-bundled-apps
namespace: apps
charts:
- stable/factorio:
    values:
      resources:
{{ include "factorio/resources" . | indent 8 }}

partials/factorio/resources.yml

{{- define "factorio/resources" -}}
requests:
  memory: 1024Mi
  cpu: 750m
{{- end -}}

You can then run this as follows:

kubecrt --partials-dir ./partials charts.yml

And the result is a fully-parsed charts printed to stdout.

Some notes:

• you can use subfolders to organise your partials
• each named define has to be uniquely named, or risk being overwritten
• you can define multiple define blocks in a single file
• the files don't need to be yaml files, you can use any content you need

Releasing new version

make (major|minor|patch)
git push --tags
make dist
open _dist/

Next, go to the GitHub releases page, and edit the tag you just push:

• Release title: vx.x.x
• Describe this release: short description of important changes
• Attach binaries: drop the files created in _dist here

Click "Update release".

Don't forget to update the Homebrew formula, located at blendle/homebrew-blendle.