Let's get an app deployed with Weave GitOps.
This is Work In Progress
In this short guide, we will see how to get a simple workload running in a cluster using GitOps, and then make a change to that deployment and see it updated automatically via GitOps. Further guides will then show how to move that workload into staging and/or production.
This guide is for Mac and Linux only (so far!). At the moment, Weave GitOps supports Github.
Gitlab and other Git providers are coming soon.
To get this working you need:
- A Github account
- A Github token
- kubectl installed
- A development Kubernetes cluster (this guide uses kind)
- Kind requires Docker
You need a Github Token with
If you don't already have one, please follow the Github guide
Make sure that the token is in your environment as
Please follow the instructions in the CLI installation page to install the command-line tool.
- Create a fresh
You now will have the right
kubeconfig for the kind cluster.
- Install Weave GitOps into the currently active Kubernetes cluster:
You should see:
The install will pause while the containers are loaded into the cluster. (roughly 1 to 2 minutes depending on your system)
Once the system is verified you will see:
- You can see what has been installed:
First we will fork a basic workload repository, then we will add the
wego GitOps automation to deploy into the cluster
We are going to use a deployment of the podinfo sample Kubernetes app as the workload to test.
- Fork the following repository on Github:
- Clone the fork using SSH (replacing
(Note Weave GitOps doesn't support repositories that are cloned via HTTPS)
- Change directory into the path where you cloned your fork of
podinfo-deploy- for example:
This repository only contains Kubernetes YAMLs (and a README):
- Let's enable GitOps for this workload
You should see something like:
(If the final lines are different, then most likely you have a problem with the SSH key used to deploy.)
- Wait for the workload to show up in the cluster:
- You can use the
wego app statuscommand to see the reconciliation.
This shows you when the last deployment was as well as the specific SHA from Git that has been deployed.
You have successfully deployed the app!
wego app addwill have created a
.wegodirectory in your repository (you can configure where this goes - see GitOps Automation configuration)
This directory contains the GitOps Automation configuration.
If you do a tree inside this directory you should see something like:
You can find out more about these YAMLs and the
.wego directory here.
wego has checked in this YAML into your fork (This may change in the future to create a PR instead).
- To access the
podinfoUI you can set up a port forward into the pod.
NB: This command does not return
Now you can browse http://localhost:9898
Use CTRL+C to cancel the
kubectl port-forward command to continue with your command prompt.
- The real aim of GitOps is not just to deploy once, but to reconcile as well. Let's test that out.
PODINFO_UI_COLOR to grey:
- Commit the change to your forked repository.
(If you want an even better experience, create a PR and then merge!)
- Wait for the reconciliation to take place
- You should see the pods recycle
And a little later:
Notice that the backend has not changed and so the backend pod is not affected.
kubectl port-forward and you will see the color has changed.
(If you use a real ingress then you wouldn't need to do this).
You have successfully demonstrated GitOps using Weave GitOps! Well done.