Closed chriswolske closed 2 years ago
for what it's worth, this is probably more of a Discussion than an Issue, but I opened an issue because I was told to on https://opengitops.dev/get-involved/ ... :)
In general, I feel GitOps will extend itself beyond cloud native. But, the principles still matter as those are the foundational bits. What did you have in mind @chriswolske?
My world is vmware and baremetal (and other on-prem infrastructure, but it could just as easily be AWS/Azure) and Ansible for most of our automation, instead of Kubernetes and Argo/Flux. (I know these products/technologies are not direct analogies, but bear with me.) I am proposing to my team that we can adopt GitOps principles and have operators that will Pull Automatically and Continuously Reconcile, but its looking like we would need to build out the operators that would do the work.
I get that something declarative like Puppet might cover some or all of this, and trying to do GitOps with Ansible may be a bad idea, but I'm looking for a community where that might be hashed out.
I guess I'm wondering if this is the right place to try to contribute, and maybe if anyone in the leadership of this group has seen or heard of anyone else in a similar situation...
And I am not married to Ansible or anything; I am open to whatever tools make sense and have no interest in making a Gitops-for-Ansible subgroup. Even when I say Ansible above, I really mean Ansible/terraform, at least as a starting point
The principles are written to be agnostic to any tool or infra. The idea being, as long as you meet these criteria, you're doing GitOps.
My opinion is that, immutability it key for GitOps to be successful. While Ansible/Terraform aren't necessarily disqualified, I think running VMs is (unless you emulate what Kubernetes is doing)
Example: You have an Ansible playbook that manages a password for a user. I login to that server, change the password, and do a chattr +i /etc/shadow
. No matter how many times you run that Ansible playbook, it's not switching that back to the desired state. (you need to account for every single scenario, which is hard when things aren't immutable)
In CloudNative/Kubernetes, if something like that happens - Kubrenetes just deletes/recreates that resource. So are you going to delete then recreate the VM everytime that VM fails? But this is more of a "best practices" and/or "patterns" conversation.
Anyway, you're already started a good conversation @chriswolske ! So I think it's 100% worth having a "GitOps with Non-CloudNative Infra" group/discussion/section. A lot of these things can be hashed out there and maybe someone will change my mind 😄 (contrary to most people, I LOVE being wrong)
+1 We are also trying to build GitOps pipeline to manage Terraform like configurations. Look forward to see more discussions about GitOps with Non-CloudNative Infra.
I just stumbled on open-gitops and all of your content over the holiday break. Great stuff. Watched a handful of meeting videos and tried to consume as much content on these repos as possible.
I know this is a CNCF initiative, but is consideration being given to those of us who are not in the cloud-native space? Almost everything I am finding so far is about Kubernetes and argo and flux, and I'm looking at applying GitOps in the context of VMs and different hypervisors and declarative operating system configurations, instead of containers and k8s.
I've run my ideas through the 4 GitOps principles and it all still fits within that framework. I guess I'm just wondering if there is a subgroup of people who are focusing on this context or if non-cloud-native can also have a seat at the big kids table, so to speak.
I'm looking forward to joining (listening in) on the next working group session.