Getting Started with Weave GitOps
This hands-on guide will introduce you to the basics of the GitOps Dashboard web UI, to help you understand the state of your system, before deploying a new application to your cluster. It is adapted from this guide - Flux - Getting Started.
If you haven't already, be sure to check out our introduction to Weave GitOps and our installation docs.
Part 1 - Weave GitOps overview
Weave GitOps provides insights into your application deployments, and makes continuous delivery with GitOps easier to adopt and scale across your teams. We will now login to the dashboard web UI and start to explore the state of our GitOps deployments.
Login to the GitOps Dashboard
Expose the service running on the cluster
kubectl port-forward svc/ww-gitops-weave-gitops -n flux-system 9001:9001
Open the dashboard and login using either the cluster user or OIDC based on your configuration. If you followed the example above, the username will be
admin
, and the password is the non-encrypted value you provided as $PASSWORD.
Applications view
When you login to the dashboard you are brought to the Applications view, which allows you to quickly understand the state of your deployments across a cluster at a glance. It shows summary information from kustomization
and helmrelease
objects.
In the above screenshot you can see:
- a
Kustomization
calledflux-system
, which was created when Flux was bootstrapped onto the Cluster, and is deploying the GitOps Toolkit controllers. It is also deploying further Flux objects defined in the same repo, so that Flux will deploy additional workloads which includes our Helm Chart for Weave GitOps. - a
HelmRelease
calledww-gitops
which deploys the aforementioned Helm Chart.
This table view shows the reported status so you can understand whether a reconciliation has been successful, and when they have last been updated. You can also see where the Flux objects are deployed and which Source
object they are reconciling from; clicking the name of the Source it will take you to a detail view for the given source object. The view automatically updates every few seconds so you know the current state of your system.
You can search for and filter objects by Name
by clicking the magnifying glass, or filter by Type
by clicking the strawberry icon to its right.
Clicking the Name of an object will take you to a detailed view for the given Kustomization or HelmRelease. Which we will explore in a moment.
The Sources view
Clicking on Sources in the left hand menu will bring you to the Sources view. This view shows you where flux pulls its application definitions from, for example Git repositories, and the current state of that synchronization. This shows summary information from gitrepository
, helmrepository
, helmchart
and bucket
objects.
In the above screenshot you can see:
- a
GitRepository
calledflux-system
, which was created when Flux was bootstrapped onto the Cluster, and contains the manifests for the GitOps Toolkit and Weave GitOps and various Flux objects. - a
HelmChart
calledflux-system-ww-gitops
, which is automatically created by Flux when you define aHelmRelease
to deploy a Helm Chart from a given source. - a
HelmRepository
calledww-gitops
which pulls from the Helm Repository where the Weave GitOps Helm Chart is published.
The table view again shows summary status information so you can see whether Flux has been able to successfully pull from a given source and which specific commit was last detected. It shows key information like the Interval
, namely how frequently Flux will check for updates in a given source location. You can apply filtering as per the Applications view, can click the URL
to navigate to a given source i.e. a repository in GitHub, or the Name
of a Source
to view more details about it.
The Flux Runtime view
Clicking on Flux Runtime
provides information on the GitOps engine, which is continuously reconciling your desired and live state. It provides two different tabs: controllers and CRDs.
Controllers
The controllers tab shows your installed GitOps Toolkit Controllers and their version.
By default flux bootstrap
will install the following controllers:
- helm-controller
- kustomize-controller
- notification-controller
- source-controller
For a full description of the controllers, see GitOps ToolKit components in the Flux documentation.
From this view you can see whether the controllers are healthy and which version of a given component is currently deployed.
CRDs
The CRD tab lists the custom resources that the GitOps Toolkit Controllers use. This helps you see what resources you will be able to create.
Exploring the flux-system deployment
Let's explore the flux-system
kustomization. Navigate back to the Applications
view and click on the flux-system
object.
After a few moments loading the data, you should see similar to the above screenshot. From here you can see key information about how this resource is defined: which Source
it is reading from, the latest applied commit, the exact path with the Source repository that is being deployed, and the Interval
in which Flux will look to reconcile any difference between the declared and live state - i.e. if a kubectl patch had been applied on the cluster, it would effectively be reverted. If a longer error message was being reported by this object, you would be able to see it in its entirety on this page.
Underneath the summary information are four tabs:
- Details (default) is a table view which shows all the Kubernetes objects (including flux objects, deployments, pods, services, etc) managed and deployed through this
kustomization
. - Events (shown below) shows any related Kubernetes events to help you diagnose issues and understand health over time.
- Reconciliation Graph (shown below) provides a directional graph alternative to the Details view to help you understand how the various objects relate to each other.
- Dependencies provides a directional graph that helps you understand dependencies between objects, if there are any. This helps you make sure that your automations are set up in the correct order.
- Yaml (shown below) provides a raw dump on the current object as it currently exists inside your cluster. Note that this will be different from what's in your gitops repository, since this yaml view will contain the current status of the object.
Events tab
Reconciliation Graph tab
Yaml tab
Source details view
Finally lets look at the Source in more detail - go back to the Details tab, and click GitRepository/flux-system
from the summary at the top of the page.
As with an Application detail view, you can see key information about how the resource is defined. Then beneath alongside the Events tab, is a Related Automations view. This shows all the kustomization
objects which have this object as their Source.
Part 2 - Deploying and viewing podinfo application
Now that you have a feel for how to navigate the dashboard. Let's deploy a new application and explore that as well. In this section we will use the podinfo sample web application.
Deploying podinfo
Clone or navigate back to your git repository where you have bootstrapped Flux, for example:
git clone https://github.com/$GITHUB_USER/fleet-infra
cd fleet-infraCreate a
GitRepository
Source for podinfoflux create source git podinfo \
--url=https://github.com/stefanprodan/podinfo \
--branch=master \
--interval=30s \
--export > ./clusters/my-cluster/podinfo-source.yamlCommit and push the
podinfo-source
to thefleet-infra
repositorygit add -A && git commit -m "Add podinfo source"
git pushCreate a
kustomization
to build and apply the podinfo manifestflux create kustomization podinfo \
--target-namespace=flux-system \
--source=podinfo \
--path="./kustomize" \
--prune=true \
--interval=5m \
--export > ./clusters/my-cluster/podinfo-kustomization.yamlCommit and push the
podinfo-kustomization
to thefleet-infra
repositorygit add -A && git commit -m "Add podinfo kustomization"
git push
View the application in Weave GitOps
Flux will detect the updated fleet-infra
and add podinfo. If we navigate back to the dashboard you should see the podinfo application appear.
Click on podinfo and you will see details about the deployment, including that there is 1 pod available.
Customize podinfo
To customize a deployment from a repository you don’t control, you can use Flux in-line patches. The following example shows how to use in-line patches to change the podinfo deployment.
Add the
patches
section as shown below to the field spec of your podinfo-kustomization.yaml file so it looks like this:./clusters/my-cluster/podinfo-kustomization.yaml---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
name: podinfo
namespace: flux-system
spec:
interval: 60m0s
path: ./kustomize
prune: true
sourceRef:
kind: GitRepository
name: podinfo
targetNamespace: flux-system
patches:
- patch: |-
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: podinfo
spec:
minReplicas: 3
target:
name: podinfo
kind: HorizontalPodAutoscalerCommit and push the podinfo-kustomization.yaml changes:
git add -A && git commit -m "Increase podinfo minimum replicas"
git pushNavigate back to the dashboard and you will now see 2 newly created pods
Suspend updates
Suspending updates to a kustomization allows you to directly edit objects applied from a kustomization, without your changes being reverted by the state in Git.
To suspend updates for a kustomization, from the details page, click on the suspend button at the top, and you should see it be suspended:
This shows in the applications view with a yellow warning status indicating it is now suspended
To resume updates, go back to the details page, click the resume button, and after a few seconds reconsolidation will continue:
Complete!
Congratulations 🎉🎉🎉
You've now completed the getting started guide. We would welcome any and all feedback on your experience.