Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →
Top 18 Shell Gitops Projects
-
flux2-kustomize-helm-example
A GitOps workflow example for multi-env deployments with Flux, Kustomize and Helm.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
deployKF
deployKF builds machine learning platforms on Kubernetes. We combine the best of Kubeflow, Airflow†, and MLflow† into a complete platform.
-
supergraph-demo
🍿 Compose subgraphs into a Federation v1 supergraph at build-time with static composition to power a federated graph router at runtime.
-
multi-tenancy-gitops
Provides our opinionated point of view on how GitOps can be used to manage the infrastructure, services and application layers of K8s based systems
-
streaming-ops
Simulated production environment running Kubernetes targeting Apache Kafka and Confluent components on Confluent Cloud. Managed by declarative infrastructure and GitOps.
-
podi
a cute gitops utility (~7kb) to turn servers into PaaS platforms using only git+ssh. #hybrid #baremetal #bubblewrap #k8s #podman #docker
-
docker-compose-gitops-action
A GitHub action that makes GitOps with the simplicity of Docker Compose possible.
-
bluesky-flux-sops-azure-template
Boilerplate to set-up Flux and Mozilla SOPs powered by Microsoft Azure
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
This is incredibly popular a take, and this anti-k8s is rapidly upvoted almost every time.
The systemd hate has cooled a bit, but it too functions as a sizable attractor for disdain & accusation hurling. Let's look at one of my favorite excerpts from the article, on systemd:
> Fleet was glorious. It was what made me decide to actually learn how to use systemd in earnest. Before I had just been a "bloat bad so systemd bad" pleb, but once I really dug into the inner workings I ended up really liking it. Everything being composable units that let you build up to what you want instead of having to be an expert in all the ways shell script messes with you is just such a better place to operate from. Not to mention being able to restart multiple units with the same command, define ulimits, and easily create "oneshot" jobs. If you're a "systemd hater", please actually give it a chance before you decry it as "complicated bad lol". Shit's complicated because life is complicated.
Shits complicated because life is complicated. In both cases, having encompassing ways to compose connectivity has created a stable base - starting point to expert/advanced capable - that allowed huge communities to bloom. Rather than every person being out there by ourselves, the same tools work well for all users, the same tools are practiced with the same conventions.
Overarching is key to commanlity being possible. You could walk up to my computer and run 'systemd cat' on any service on it, and quickly see how stuff was setup (especially on my computers which make heavy use of environment variables where possible); before every distro and to a sizable degree every single program was launched & configured differently, requires plucking through init scripts to see how or if the init script was modified. But everything has a well defined shape and form in systemd, a huge variety of capabilities for controlling launch characteristics, process isolation, ulimits, user/group privileges, special tmp directories is all provided out of the box in a way that means there's one man page to go to, and that's instantly visible, so we don't have to go spelunking.
The Cloud Native paradigm that Kubernetes practices is a similar work of revelation, offering similar batteries included capabilities. Is it confusing having pods, replicasets, and services? Yes perhaps at first. But it's unparalleled that one just POSTs resources one wants to an API-server and let's the system start & keep that running; this autonomic behavior is incredibly freeing, leaving control loops doing what humans have had to shepherd & maintain themselves for decades; a paradigm break turning human intent directly into consistent running managed systems.
The many abstractions/resource types are warranted, they are separate composable pieces that allow so much. Need to serve on a second port? Easy. Why are there so many different types? Because computers are complex, because this is a model of what really is. Maybe we can reshuffle to get different views, but most of that complexity will need to stay around, but perhaps in refactores shapes.
And like systemd, Kubernetes with it's Desired State Management and operators, it creates a highly visible highly explorable system; any practitioner can walk up to any cluster and start gleening tons of information from it, can easily see it run.
It's a wrong hearted view to think that simpler is better. We should start with essential complexity & figure out simultaneously a) how to leverage and b) how to cut direct paths through our complex capable systems. We gain more by permitting and enabling than by pruning. We gain my by being capable of working at both big and small scales than we gain by winnowing down/down scoping our use cases. The proof is in the pudding. Today there's hundreds of guides one can go through in an hour to setup & get started running some services on k3s. Today there's a colossal communities of homelab operators sharing helm charts & resources (ex: https://github.com/onedr0p/home-ops), the likes of which has vastly outclassed where we have stood before. Being afraid of & shying away from complexity is a natural response, but i want people to show that they see so many of the underlying simplicities & conceptions that we have gotten from kube that do make things vastly simpler than the wild West untamed world we came from, where there weren't unified patterns of API servers & operators, handling different resources but all alike & consistent. To conquer complexity you must understand it, and I think very few of those with a true view of Kubernetes complexity have the sense that there are massive opportunities for better, for simpler. To me, the mission, the goal, the plan should be to better manage & better package Kubernetes to better onboard & help humans through it, to try to walk people into what these abstractions are for & shine lights on how they all mirror real things computers need to be doing.
(Technical note, Kubernetes typically runs 0 vm's, it runs containers. With notable exceptions being snap-in OCI runtimes like Firecracker and Kata which indeed host pods as vms. Kine relies on containers are far more optimizable; works like Puzzlefs and Composefs CSIs can snap-in to allow vastly more memory-and-storage-efficient filesystems to boot. So many wonderful pluggable/snappable layers; CNI for networking too.)
Project mention: We are excited to announce the release of deployKF! It's an open-source project that makes it actually easy to deploy and maintain Kubeflow (and more) on Kubernetes. | /r/Kubeflow | 2023-08-12
Shell Gitops related posts
-
Rebuilding my homelab: Suffering as a service
-
Ditching PaaS: Why I Went Back to Self-Hosting
-
Homelab setup for Kubernetes training
-
Flux: can I add a monitored path after bootstrap?
-
Is it possible to deploy to KIND cluster via GitHub actions?
-
Highly Available OPNSense
-
MariaDB operator 📦 v0.0.2
-
A note from our sponsor - InfluxDB
www.influxdata.com | 1 Jun 2024
Index
What are some of the best open-source Gitops projects in Shell? This list will help you:
Project | Stars | |
---|---|---|
1 | home-ops | 1,782 |
2 | flux2-kustomize-helm-example | 914 |
3 | k8s-gitops | 615 |
4 | kube-backup | 491 |
5 | flux2-multi-tenancy | 479 |
6 | pi-cluster | 345 |
7 | gitops-catalog | 289 |
8 | deployKF | 278 |
9 | supergraph-demo | 133 |
10 | multi-tenancy-gitops | 109 |
11 | kochhaus-home | 94 |
12 | streaming-ops | 85 |
13 | k8s-gitops | 42 |
14 | actions | 38 |
15 | otp-gitops | 31 |
16 | podi | 12 |
17 | docker-compose-gitops-action | 11 |
18 | bluesky-flux-sops-azure-template | 4 |
Sponsored