awesome-gitops VS awesome-home-kubernetes

https://github.com/weaveworks/awesome-gitops but also, like, a shell script?

There are books (The Path to GitOps, GitOps and Kubernetes or GitOps Cloud-native Continuous Deployment), whitepapers, and more blog posts than we can manage to count but let us elaborate on the GitOps purpose by taking a quick look on how things evolved in the last few years.

Websites such as awesome-gitops, which was launched by Weaveworks, or gitops.tech, which was put together by INNOQ employees, provide an introductory overview of the available tools. When you take a closer look, you will see that the listed tools can be used to perform a wide variety of tasks related to implementing GitOps, and of course they also differ from one another in terms of their adoption, maturity, and how actively they are maintained. This article identifies three categories from the various use cases: Tools for Kubernetes, supplementary tools, and tools close to infrastructure. In addition, we compiled a table that summarizes the tools and their properties. The tables also contain various Git and GitHub-based metrics (current as of February 2021) that allow you to better assess their adoption, maturity, and how actively they are maintained.

huge fan of k8s. drop what you're doing & use a cross-system object-storage/"apiserver" & control-loops to automate everything; embrace desired state management & thank me latter. but, Heroku &al have a lot of value left.

there's just not that many folk trying to tame deploys on k8s via gitops. flux2 is the rage, it's all over the alpha geek's efforts[1], but it's usually used by someone carefully authoring a fairly complex Helm file, then building out a significant Flux2 HelmRelease object (ex: [2]).

there's a bunch of other tools[3], & i'm frankly not familiar enough. but this idea of having a bunch of source that can deploy itself, simply, is still extremely rare even among the alpha-geek #gitops types. i'm sure some of these tools better match the simplicity of the Heroku model, corresponding branches to environments, which makes so so much sense, but so far i feel like such attempts are still basically unknown.

heroku's really simmered it down to something that made extremely natural sense. huge props to that. too too much of this effort had to go into creating buildpacks & supporting language environments very very carefully very actively, that ability to stealth-containerize an app & not even notice is so much of the special sauce that makes this a hard, hard & eternal problem (because langauges/envs keep changing). there's still a lot of ease of use to Heroku that's potentially will be underrated and/or lost by the oncoming generations. i have high respect for how operateable Heroku is.

[1] https://github.com/k8s-at-home/awesome-home-kubernetes

[2] https://github.com/onedr0p/home-cluster/blob/main/cluster/ap...

[3] https://github.com/weaveworks/awesome-gitops#tools

Also check out the awesome kubernetes@home repo where many homelabbers share their configs.

Sorry I'm not familiar with this. Are you referring to this?

https://github.com/k8s-at-home/awesome-home-kubernetes https://github.com/k8s-at-home/template-cluster-k3s

To see it in action be sure to check out my repository or the many others here.

Make it usable and link to the best place with k3s in action: https://github.com/k8s-at-home/awesome-home-kubernetes

Nice but I suggest going to https://github.com/k8s-at-home/awesome-home-kubernetes and learn from the best at this topic ;)

Check out Flux V2. It syncs a git repo with your cluster, allowing you to define your infrastructure as code. It will keep your cluster synced with your repo and detect changes. A number of example repos are Here and onedr0p did a example repo here There's many options for structuring folder, I'd recommend you have a look at a few repos and pick one you like. The linked template is a good start, as it helps avoid dependency hell with a crd folder that starts before the YAML that needs the crd defined. Many people on the awesome list also run ansible for full infrastructure as code. I spent a lot of time perfecting my setup to go from blank Ubuntu VM to my cluster with a few keystrokes. Running it in git also helps you be able to use things like renovate bot to keep versions up to date. As for namespaces, everyone had their own method, but about using kube-system. Also, keep a eye out for services that refuse to have their name space changed.