This is WIP, freshly pushed. Needs some clarifications, updates on documentation, etc..
mygitops
is tool to help you implement a gitops based
continuous delivery flow in a kubernetes environment.
gitops: git-oriented operations. the state of your system is recorded in a git repository.
updates to your cluster are reflected in this repo.
gitops repository: the repository containing the full state of your kubernetes cluster/services
It's using helm as the underlaying management tool for the services in the cluster.
To integrate it in your CI/CD pipeline, it's recommended you run it as a service listening for incoming new deployment requests.
- All deployment requests are commited and pushed to your gitops repository
- Synchronizes cluster with gitops repo state
- Http api for easy CI/CD pipeline integration
The full cluster state is held in your gitops repo structured as below
When releasing a new version, there are 2 proceses going on under the hood:
- a commit is created in the repo reflecting the pod image repo & tag updates
- the cluster is synced to the new state
Here are some details on how to structure your repo.
mgo
is meant to be ran as a service. It can handle requests to deploy updates
to your cluster via it's HTTP API.
Here's an example integration with gitlab, a full .gitlab-ci.yml
file.
-
statefulset upgrades: currently fails when STS are updated. the crude way is
k delete sts --cascade=false xxxx
. maybe something else works better? -
performance: too many helm upgrades/diffs can end up choking the master node/apiserver. need to limit. maybe rudder is lighter?
-
handle those non-helm manifests (those
*-raw.yaml
files that are raw kubernetes manifests, prob viakubectl apply -f xxxxx
) -
Define/Design authentication of clients
-
gopkg.in vanity package urls
-
handle empty commits in kube, mainly when running just re-deploy
-
Check out Rudder. Might be better than running
exec(helm)
-
Documentation
- update readme, explain updated yaml structure
- how to setup local development env
- how to import a cluster into a mygitops-style repo
- maybe do a demo of an end-to-end integration (CI pipeline -> deployment to cluster)
-
maybe switch to
helm template
&kubectl apply
instead ofhelm upgrade
- also check out
helm template
andkubediff
instead ofhelm diff
that only diffs against helm’s configmaps rather than the cluster state itself
- also check out
-
rename mygitops -> mgo -> (maybe smth better?)
The work on mgo is being supported by Aleth.io.