Gitops with weaveworks flux

Stephen Moloney

August 29, 2018

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

Weaveworks Flux
Weaveworks Flux
Weaveworks Flux
Weaveworks Flux

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

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

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