Weave GitOps Automation for Helm and GitHub Actions
The latest release of Weave GitOps enhances automation for Helm and GitHub actions.
Weaveworks donated Flux to the CNCF and still plays a significant role in its continued development and maintenance. Flux and Flagger are core components of the Weave GitOps solution.
Weave GitOps is powered by Flux therefore new Flux features are also available in Weave GitOps. Flux recently released 0.31.0 with some exciting new features, check them out below.
Helm OCI Registries
With the release of Helm 3.8.0, Charts can be stored in OCI registries, just like Docker images. Sharing common storage across technologies results in lower maintenance overhead for your DevOps team. There’s no longer a requirement to host your Helm Charts on a web server, just use your existing container image registry.
Publishing a Helm Chart to a OCI registry is easy, it’s just like a Docker image.
$ helm push == docker push
To install a chart from a registry.
$ helm install myapp oci://registry.acme.com/helm-charts/myapp –version 1.0.0
With the latest release of Flux, OCI registries are supported for the HelmRepository resource.
apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: myrepo namespace: flux-system spec: type: oci interval: 30m url: oci://registry.acme.com/helm-charts
Once the Helm OCI chart registry has been defined, a Helm Chart release is defined using the registry.
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: myapp
namespace: flux-system
spec:
chart:
spec:
sourceRef:
kind: HelmRepository
name: myrepo
chart: myapp
version: ‘1.0.x’
interval: 30m
targetNamespace: mynamespace
Flux supports the use of semver for Helm Chart versions. With the above manifest, Flux will check the registry every 30 minutes and install the latest version matching the semver. For example, if version 1.0.3 is currently installed then version 1.0.6 is pushed to the registry it will be automatically installed. Flux automation means that your CI/CD pipelines are less complex and easier to maintain.
Trigger GitHub Actions
The Flux Notification Controller already has a rich set of integrations such as: Slack, MS Teams, Google Chat, generic webhook, etc. The latest release of Flux adds a new integration to GitHub Actions, which will trigger an action with a repository_dispatch event.
To configure the new Provider, you’ll need a GitHub personal access token stored in a Kubernetes Secret.
$ kubectl create secret generic github-token \
–from-literal=token=$GITHUB_TOKEN
An example Provider manifest:
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
name: github-displatch
namespace: flux-system
spec:
type: githubdispatch
address: https://github.com/steveww/pypodinfo
secretRef:
name: github-token
Configure an Alert to send events to the Provider:
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
name: github-dispatch
namespace: flux-system
spec:
summary: “staging eu-west-2”
providerRef:
name: github-dispatch
eventSeverity: info
eventSources:
kind: Kustomization
name: pypodinfo
Finally you’ll need to define an action in your repository that will be triggered:
name: flux-githubdispatch
on:
repository_dispatch:
types: [Kustomization/pypodinfo.flux-system]
jobs:
run-tests:
if: github.event.client_payload.metadata.summary == ‘staging eu-west-2’
runs-on: ubuntu-latest
steps:
name: Run Tests
run: echo “Starting tests”
With the above example configuration, when a reconciliation happens for the pypodinfo Kustomization, the Alert will send the event to GitHub via the repository_dispatch event type. Notice that the summary field from the Alert is passed in the client metadata and can be referenced in the GitHub Action.
The uses of this new functionality are only limited by your imagination. One example is to prove an automatic rollback of a change if it fails. We can all make a typo that can also be easily missed during review and approval. A typo could cause the deployment of the change to fail. Using the Flux notification to call a GitHub Action, which would then check the status of the application component, detecting the failure and then reverting the commit. The previous good configuration would then be applied to the cluster. Additionally it could go on to create an Issue or Pull Request to notify of the failure. If the change was deployed successfully the action could run a number of tests which, if successful, would create a pull request for promotion to production deployment. The status of all application components is easy to see with Weave GitOps, both the dashboard and the VS Code plugin provide status information for all Flux components.
I’m sure there are many other use cases, why not install Weave GitOps on your cluster and have a play?
Whitepaper: How GitOps Enables A Continuous Application Lifecycle
Discover what you need to start building a GitOps pipeline today.
