adeploy
kapp-controller
Our great sponsors
| adeploy | kapp-controller | |
|---|---|---|
| 2 | 5 | |
| 12 | 254 | |
| - | 3.5% | |
| 7.6 | 8.7 | |
| about 2 months ago | 6 days ago | |
| Python | Go | |
| BSD 3-clause "New" or "Revised" License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
adeploy
-
Helm is both "package manager" and "templating engine" - probably the best package manager but horrible template engine
We created adeploy, which is using Jinja Templating to render Manifests out of a set of template files and variables. We added some functions i.e. to set versions, create labels, include files or to handle secret creation using gopass and support to run in CI/CD without re-creating secrets. Source + (some) docs: https://github.com/awesome-it/adeploy
-
HELM vs KUSTOMIZE
We wrote adeploy which brings Jinja templating for both vanilla manifests and Helm Charts which includes a bench of useful Jinja templating functions i.e. for labeling, secret management etc... The tool supports multiple deployments at different namespaces/releases with different Jinja variables and also includes support to deploy secrets directly from GoPass. It can also be used in CI/CD while secrets are not re-deployed when running via CI/CD. The tool still lacks of some detailed docs and a public pip repo, but this is wip.
kapp-controller
-
Helm is both "package manager" and "templating engine" - probably the best package manager but horrible template engine
We use kapp-controller when applying our charts (it uses helm template instead of helm install) so we can be very rigorous about what fields are changeable (like through pod autoscaling) and what are not (securitycontext, etc.)
-
How to handle the lifecycle of multiple COTS
Even further, you could describe your "fetch", "template", and "deploy" stages in akapp-controller AppCR and then you'd have a controller (like an operator) running the cluster continuously reconciling your private cloud to ensure that it's always reconverging to the desired state. This is basically what's underpinning a number of VMWare's commercial (and OSS) Tanzu offerings, as well as some other organization's internal platforms, or "self hosted private clouds"
-
ArgoCD vs. crossplane-helm provider for managing helm releases?
Full disclosure: I work on https://carvel.dev/kapp-controller/ which can also continuously reconcile helm charts (via our own CRD ).
-
Deployment Packaging Solutions
kapp-controller
-
Deploy Neo4J's APOC plugin with code thanks to CARVEL vendir
kapp-controller - Capture application deployment workflow in App CRD. Reliable GitOps experience powered by kapp.
What are some alternatives?
terraform-provider-docker - Terraform Docker provider
cnab-spec - Cloud Native Application Bundle Specification
devspace-demo - A demo trialing the basic operation of Devspace
kapp - kapp is a simple deployment tool focused on the concept of "Kubernetes application" — a set of resources with the same label
helmfile - Deploy Kubernetes Helm Charts
vendir - Easy way to vendor portions of git repos, github releases, helm charts, docker image contents, etc. declaratively
imgpkg - Store application configuration files in Docker/OCI registries
ytt - YAML templating tool that works on YAML structure instead of text
asdf - k14s asdf plugin
gravity - Kubernetes application deployments for restricted, regulated or remote environments.
terraform-provider-carvel - Carvel Terraform provider with resources for ytt and kapp to template and deploy to Kubernetes
porter - Porter enables you to package your application artifact, client tools, configuration and deployment logic together as an installer that you can distribute, and install with a single command.