Skip to content

Automatically apply changes to a Kubernetes cluster

License

Notifications You must be signed in to change notification settings

terowz/autoapply

 
 

Repository files navigation

autoapply

Build Status Coverage status Docker build status License

Automatically apply changes to a Kubernetes cluster.

Technical overview

  • 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:helm also provides git, sops and helm (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

About

Automatically apply changes to a Kubernetes cluster

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • JavaScript 95.1%
  • Dockerfile 4.5%
  • Makefile 0.4%