Skip to content
This repository has been archived by the owner on Nov 6, 2019. It is now read-only.
/ heighliner Public archive

Continuous Delivery from GitHub to your Kubernetes cluster

License

Notifications You must be signed in to change notification settings

manifoldco/heighliner

Heighliner

Build Status codecov Go Report Card GoDoc

A Heighliner is truly big. Its hold will tuck all of our frigates and transports into a little corner-we'll be just one small part of the ship's manifest.

Heighliner aims to make your workflow with GitHub and Kubernetes easy. Automatically deploy previews of GitHub pull requests to your cluster and use GitHub Releases to deploy to staging and production.

Warning: this project is still under heavy development and is not recommended for production usage yet. Breaking changes might occur until v1.0.0.

Goals

Cloud Native. Instead of templating, Heighliner runs your infrastructure as software, keeping the state of your deployments always as they should be.

Connected. The cluster is aware of container registry and source code repository state. It reacts to them (creating new deploys), and reflects into them (updating GitHub PR deployment status). Preview deploys are automatically created and destroyed. Deploys can auto-update based on Semantic Versioning policies, or be manually controlled.

Complete. A Heighliner Microservice comes with DNS and TLS out of the box.

Convention and Configuration. Reasonable defaults allow you to get up and running without much effort, but can be overridded for customization.

Installation

Heighliner consists out of multiple components, we've explained these in detail in the design docs and in an introductory blog post

For a full installation process, have a look at the installation docs or our getting started guide

Usage

Configure a GitHub Repository

Ensure that you have an API token installed in your cluster. Follow our how to for further instructions.

The GitHub repository resource is used to synchronize releases and pull requests with cluster state, and update pull requests with deployment status.

apiVersion: hlnr.io/v1alpha1
kind: GitHubRepository
metadata:
  name: cool-repository
spec:
  repo: my-repository
  owner: my-account
  configSecret:
    name: my-github-secret

Configure a Versioning Policy

The versioning policy resource defines how microservices are updated based on available releases.

apiVersion: hlnr.io/v1alpha1
kind: VersioningPolicy
metadata:
  name: release-patch
spec:
  semVer:
    version: release
    level: patch

Configure an Image Policy

The image policy resource synchronizes Docker container images with cluster state. It cross references with GitHub releases, filtering out images that do not match the versioning policy.

apiVersion: hlnr.io/v1alpha1
kind: ImagePolicy
metadata:
  name: my-image-policy
spec:
  image: my-docker/my-image
  imagePullSecrets:
  - name: my-docker-secrets
  versioningPolicy:
    name: release-patch
  filter:
    github:
      name: cool-repository

Configure a Network Policy

The network policy resource handles exposing instances of versioned microservices within the cluster, or to the outside world. domain can be templated for use with preview releases (pull requests).

apiVersion: hlnr.io/v1alpha1
kind: NetworkPolicy
metadata:
  name: hlnr-www
spec:
  microservice:
    name: my-microservice
  ports:
  - name: headless
    port: 80
    targetPort: 80
  externalDNS:
  - domain: my-domain.com
    port: headless
    tlsGroup: my-cert-manager-tls-group
  updateStrategy:
    latest: {}

Configure a Microservice

The microservice resource is a template for deployments of images that match the image policy.

apiVersion: hlnr.io/v1alpha1
kind: Microservice
metadata:
  name: my-microservice
spec:
  imagePolicy:
    name: my-image-policy

Contributing

Thanks for taking the time to join the community and helping out!