autoapply / autoapply

Automatically apply changes to a Kubernetes cluster

autoapply

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.

---

1. Usage
2. Configuration
3. Docker tags
4. Related projects
5. License

Usage

To quickly setup autoapply in a Kubernetes cluster, see the autosetup project.

Configuration

A basic configuration file looks like this:

loop:
  commands:
    - git clone --depth 1 https://github.com/autoapply/template-kubectl .
    - kubectl apply -f common/
    - kubectl apply -f dev/

For example repositories, see template-kubectl and template-kustomize. For more configuration files, see examples.

For a full description of the configuration format, see the documentation.

Docker tags

• 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:root provides a minimal image with just autoapply installed, but running as root. This can be useful as a base for custom builds (Dockerfile)

Related projects

• Argo CD is very similar, but has a more complex architecture. It doesn't support yaml-crypt or sops out of the box, but it also supports custom workflows.
• kube-applier is also 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.

License

MIT