Automatically apply changes to a Kubernetes cluster.
- All resource files are stored in Git, which means there is a single source of truth for the state of your application.
- When editing resource files, the changes can be documented and merged using your standard Git workflow.
- You can use yaml-crypt or sops to store Kubernetes secrets directly in the repository.
First create an empty, publicly accessible repository. For private repositories, you can use deploy keys. Add the desired Kubernetes resource files to the repository, for example nginx.yaml, and make sure all files have been pushed.
Now download kubernetes-simple.yaml and change
https://github.com/autoapply/hello-world
to the URL of the repository you just created.
Then create the autoapply deployment in your cluster:
$ kubectl apply -f kubernetes-simple.yaml
Now, autoapply will download the resource files from your repository and apply them to the cluster. When you update the repository, autoapply will fetch the new files and update the cluster accordingly.
To automatically setup autoapply in a cluster, see the related autosetup project.
For more detailed instructions, see Hello, World!
A basic configuration file looks like this:
loop:
commands:
- git clone --depth 1 https://github.com/autoapply/hello-world workspace/
- kubectl apply -f workspace/
For more information, see the documentation.
autoapply/autoapply:latest
provides a minimal image with just autoapply installed (Dockerfile)autoapply/autoapply:kubectl
also provides git, kubectl, sops and dockerize (Dockerfile)autoapply/autoapply:helm
also provides git, sops and helm (Dockerfile)autoapply/autoapply:jekyll
also provides ruby, java, git and jekyll (Dockerfile)
- kube-applier is very similar, but less flexible. It doesn't support Helm or custom workflows like using sops.
- Keel provides fully automated updates, but only changes the container image version, nothing else.
- Helm does not provide automated updates, but still offers a consistent way to release new versions. However, you will still need a way to manage the values that will be used to create releases from charts.
- Flux is also very similar, but goes a step further and uses an abstraction on top of the existing Kubernetes model. There is also a blog post by Weaveworks about GitOps and Kubernetes, which gives a good overview of the topic.
- kube-backup is for the opposite way and regularly adds all Kubernetes objects into the configured git repository.
Autoapply is licensed under the MIT License