Gitops with weaveworks flux

Todays lightning talk

Few words on Kubernetes and Helm
Weaveworks Flux and gitops
Demo - Gitops using weaveworks flux

What is gitops?

A way of doing continuous delivery whereby code in git repositories is used to declaratively define the application infrastructure.

Git defines the system at both application and infrastucture level
Git changes means a redefining the system state automatically
Git provides a traceable history of the system
Git provides high visibility of the system for developers and operations teams alike

Why gitops?

Git defines the system at both application and infrastucture level
Git changes means a redefining the system state automatically
Git provides a traceable history of the system
Git provides high visibility of the system for developers and operations teams alike

No manual scripting, save time
Changes in the code defining the application infrastucture automatically trigger changes in the infrastucture
Those changes are version controlled so are highly visible and come with history of changes (git log)
Git becomes the single source of truth for the desired application state

Benefits of gitops

Frees up time for developers to focus on writing features and merge requests and reviewing code
Allow new team members to ship code faster as all that is needed is an approved merge request to get code from development into production
Frees up time for operations to focus on advanced deployment strategies
Reliable deployment relying less or not at all on manual scripts

Philosophy of gitops on a kubernetes cluster

Let git be the single source of truth
Avoid kubectl into your cluster manually, as the entire ci/cd is automated with gitops, this should not be necessary. Let git determine the state and fate of the cluster.
Enhanced security as fewer people within the organisation require access to the cluster. Secrets will not be exposed.
Secrets should also be committed to git in an encrypted format. See the sealed secrets project for an enhanced workflow in this respect. https://github.com/bitnami-labs/sealed-secrets

How is gitops any different from other ways of doing CI/CD ?
Typically, a ci pipeline might handle multiple steps including build, test, and merge to master following by a push of the necessary updates to the kubernetes cluster.
Gitops is a pull based model whereby the CI is used to merge commits in to master but CD is managed internally inside the kubernetes cluster by pulling the modified git repository.
Gitops will ensure convergence

Diagram depicting the separation of concerns

CI - CircleCI, Jenkins, GitlabCi
CD - weaveworks flux operators, runs on the kubernetes cluster

More on gitops later, first a few words on the the technology stack

Today's technology stack

Git
Kubernetes
Helm
Weaveworks Flux

What is Git ?

Distributed Version Control System
Gold standard for code version control
High performance
Security and traceability
Feature rich

Using git, teams can

Declaratively define cloud infrastructure - terraform
Kubernetes manifest written in yaml for defining a k8s cluster
Helm charts for defining entire application stacks in a k8s cluster

What is Kubernetes?

An open-source platform which manages computing, networking and storage resources through a set of standard resource definitions such as a ReplicaSet, Deployment or a Service among others.
Is extensible as developers can define their own custom resources.
Facilitates declarative cluster definition through kubernetes resource definition in yaml files.
Enhances portability of applications on different infrastructure providers

Why Kubernetes?

Simplicity
Portability
Visibility
Microservices
Flexibility

Simplicity

Once the developer learns about kubernetes, it's easier for developers to define their application infrastructure with minimal assistance from operations.

Portability

As kubernetes provides a standard way to define the application, it means your application is more portable and can be shifted more easily from one cloud provider to another or even to bare metal kubernetes clusters.

Visibility

A declarative way to model your infrastructure.

As a collection of yaml files defines the application infrastucture, it is a form of documentation or visibility of the desired state of the applications.

Microservices

Monolithic applications generally run as one highly coupled unit that must be deployed, redeployed and scaled as a whole. Microservices on the other hand are loosely coupled components which can often be deployed, redeployed and scaled independently of one another (as long as the api between components remains backwards compatible). Kubernetes makes it easy to deploy and scale applications as microservices as they can communicate to one another over the cluster network.

Flexibility

Kubernetes is a versatile tool and can handle many types of workloads for varied types of applications

A few words about helm

What is Helm ?

A package manager for apps, utilities and software tools to be deployed onto a kubernetes cluster.
The packages are effectively collections of files
that define some application, tool or utility that will be rendered by a server component called tiller and then in turn sent to the kubernetes control plane for further processing.

What does a helm chart look like ?

helm create frontend

frontend/
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   └── service.yaml
└── values.yaml

frontend/ ├── charts <- where dependency charts for this chart go ├── Chart.yaml <- metadata/information about this chart, eg version, maintainer data ├── templates │ ├── deployment.yaml <- a kubernetes deployment resource │ ├── _helpers.tpl <- helper functions inside templates, repetitive code, etc │ ├── ingress.yaml <- an kubernetes ingress resource (handles incoming connections and internal cluster loadbalancing) │ ├── NOTES.txt <- Information targeting the chart user after chart is successfully released/deployed │ └── service.yaml <- a kubernetes service resource └── values.yaml <- default where values that get assigned in the the templates

Benefits of helm

What are the benefits over plain kubernetes constructs?

Helm charts provide access to the power of a templating system (go templates)
Extract important variable assignments into it's own file - values.yaml
Have control workflows so that conditional yaml files can rendered

Helm Architecture

Composed of two components (Version 2 of helm):

Helm client
Runs on the kubernetes cluster
Runs on the developers desktop (typically - optional)
Tiller
Runs on the kubernetes cluster
Responsible for installing/removing resources by interacting with the kubernetes api server

Helm Architecture - client

Helm client
A cli tool is available for the end user
Sends the commands and chart data to tiller for further handling

Example usage:

helm install --name myblog stable/wordpress

Some examples of helm commands create create a new chart with the given name delete given a release name, delete the release from Kubernetes history fetch release history init initialize Helm on both client and server install install a chart archive lint examines a chart for possible issues list list releases package package a chart directory into a chart archive repo add, list, remove, update, and index chart repositories reset uninstalls Tiller from a cluster rollback roll back a release to a previous revision status displays the status of the named release template locally render templates upgrade upgrade a release

Helm Architecture - Tiller

Tiller
Runs in a pod of its own in the kube-system namespace
Responsible for installing/removing/updating cluster resources by interacting with the kubernetes api server
Based on the chart data and helm command received, tiller sends the appropriate instructions to the kubernetes api server so that the helm release is deployed

Helm - A chart

What is a chart ?

A collection of files for defining resources that are to run on the Kubernetes cluster.

Collectively, the group of resourcess constitute the application, tool or whatever software is being deployed on the server.

Helm - A repository

What is a repository (in helm terms) ?

A place where versions of the chart are stored, archived and made available for retrieval by kubernetes clusters. Essentially, it is a simple HTTP server of yaml and tar files. An index.yaml is an essential file that defines the helm package.

The helm documentation provides guidance for deploying your own repository server.

Helm - A repository

$ helm repo add weaveworks https://weaveworks.github.io/flux
$ helm search weaveworks --versions

  
    NAME            CHART VERSION   APP VERSION     DESCRIPTION                                       
    weaveworks/flux 0.2.2           1.5.0           Flux is a tool that automatically ensures that ...
    weaveworks/flux 0.2.1           1.4.2           Flux is a tool that automatically ensures that ...
    weaveworks/flux 0.2.0           1.3.1           Flux is a tool that automatically ensures that ...
    weaveworks/flux 0.1.1           1.4.1           Flux is a tool that automatically ensures that ...
    weaveworks/flux 0.1.0           1.3.1           Flux is a tool that automatically ensures that ...

Helm - A release

What is a helm release ?

A helm release is an instance of a chart running on a kubernetes cluster. A release is named and more than one release with different names can be run on a kubernetes cluster. The name of a release is unique for a given installation of tiller.

Weaveworks flux

What is it?

A toolkit for deploying your kubernetes cluster using gitops.
It is composed of a flux operator, a flux helm operator and a memcached pod that must first be setup in the kubernetes cluster. I will refer to it as the 'flux system'
The flux system is synced with your kubernetes cluster configuration repository with read and write access.

Based on the policies declared in the config repo, The flux system will watch for new images being pushed to the docker registry. When a new image is detected, the image is pulled and deployed onto the kubernetes cluster and the configuration repository is updated via a git commit with the tag/sha of the latest image. This feature is enabled through annotations in the config repository.
The flux system will also watch for any changes to the configuration repository and any changes to the state of the cluster wil be detected in the yaml files and applied to the cluster

Minimum components required to setup weaveworks flux gitops workflow:

A kubernetes cluster
Create a kubernetes cluster configuration repo.
A docker registry for pushing built images from your ci pipelines.
Helm installed with tiller on the kubernetes cluster

Demo

References

Contact information, useful links

Me stephen@stephenmoloney.com
Useful Links
- https://www.weave.works/blog/category/gitops/
- https://github.com/stefanprodan/gitops-helm
- https://www.weave.works/blog/managing-helm-releases-the-gitops-way
- https://www.weave.works/blog/what-is-gitops-really
- https://github.com/stefanprodan/gitops-helm