autoapply

Automatically apply changes to a Kubernetes cluster

Showing:

Popularity

Downloads/wk

36

GitHub Stars

126

Maintenance

Last Commit

4mos ago

Contributors

4

Package

Dependencies

5

Size (min+gzip)

66.7KB

License

MIT

Type Definitions

Tree-Shakeable

No?

Categories

Readme

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

Rate & Review

Great Documentation0
Easy to Use0
Performant0
Highly Customizable0
Bleeding Edge0
Responsive Maintainers0
Poor Documentation0
Hard to Use0
Slow0
Buggy0
Abandoned0
Unwelcoming Community0
100
No reviews found
Be the first to rate

Alternatives

No alternatives found

Tutorials

No tutorials found
Add a tutorial