4 ms·

Correct me if I'm wrong: - GitOps is a fancy word recently created by Gitlab or Github to sound cooler - It means storing your code / services in git a

Correct me if I'm wrong: - GitOps is a fancy word recently created by Gitlab or Github to sound cooler - It means storing your code / services in git and deploying on push It all seems so weird. We had tools like puppet since ice ages which can, after you push to git, reconfigure and deploy whatever you described in your git. Over all your fleet of machines. Am I missing something?

nonameiguess 2y ago
You're half wrong. The term was invented by Weaveworks, a company which no longer exists, but it's main product, FluxCD and the GitOps toolkit it is based on, lives on as a CNCF project. There never was and still is not any requirement that you use Github or Gitlab as your Git server to use this or any other GitOps product I'm aware of. I guess you're more 75% wrong because the second statement is still half wrong. Depending on the product you're using, it can work via webhook if the Git server supports doing that, but predominantly GitOps tooling relies upon polling, so you won't necessarily get a deployment immediately going a git push. You'll get it whenever the next poll happens. Also, FluxCD was created specifically for Kubernetes, which is why a product announcement like this is worded the way it is. It worked by storing Kubernetes custom resource manifests in a Git repo, typically for Helm charts or Kustomize "kustomization" definitions. Roughly the entire point of this was bringing Kubernetes conventions up to par with what was already common for deployment with configuration management tooling that relied upon server-stored configuration as code. I don't think Weaveworks or anyone else involved was under the impression they were the first to ever have this idea. But I also don't believe (but admittedly don't know) that it was particularly easy in 2017 to use Puppet to manage application deployments in Kubernetes. FluxCD also runs in Kubernetes itself, so you don't need any external infrastructure to do this. Maybe this makes it less weird? Multi-container orchestration nearly a decade ago was a fairly immature ecosystem, so they adopted ideas from configuration management of server fleets. Not all change in the world is greenfield innovation that comes absolutely out of nowhere.
- tryauuum 2y ago
  So how did people mange kubernetes before gitops? Automating "kubectl apply" in a different way in each company? Also it's useless to this discussion but polling was also a standard thing in puppet / chef / saltstack. Main motivation was to make deployments more gradual so in case of untested code only stone subset of servers is affected
- tryauuum 2y ago
  I see, I guess I only saw GitOps in gitlab and assumed it's another half-backed feature
r1cka 2y ago
You aren't missing anything. It's just marketing so GitHub/Gitlab stay in the main conversation when DevOps comes up.
Normal_gaussian 2y ago
To be specific GitOps covers the Ops/DevOps around git. So MRs / RBAC for git all the way through CI to CD. I've seen some stretch it to cover VDI equivalents as well. Basically large orgs ditched all their ops people a while ago to focus on integrated teams, and now its marketable to seperate it out again a new set of terms have come round to help orgs pretend they didn't make mistakes. The term DevSecOps really grinds my gears, gitops I'm more ok with, but still...
- fk-corporation 2y ago
  [flagged]
deleted 2y ago
[deleted]

nonameiguess 2y ago

You're half wrong. The term was invented by Weaveworks, a company which no longer exists, but it's main product, FluxCD and the GitOps toolkit it is based on, lives on as a CNCF project. There never was and still is not any requirement that you use Github or Gitlab as your Git server to use this or any other GitOps product I'm aware of. I guess you're more 75% wrong because the second statement is still half wrong. Depending on the product you're using, it can work via webhook if the Git server supports doing that, but predominantly GitOps tooling relies upon polling, so you won't necessarily get a deployment immediately going a git push. You'll get it whenever the next poll happens. Also, FluxCD was created specifically for Kubernetes, which is why a product announcement like this is worded the way it is. It worked by storing Kubernetes custom resource manifests in a Git repo, typically for Helm charts or Kustomize "kustomization" definitions. Roughly the entire point of this was bringing Kubernetes conventions up to par with what was already common for deployment with configuration management tooling that relied upon server-stored configuration as code. I don't think Weaveworks or anyone else involved was under the impression they were the first to ever have this idea. But I also don't believe (but admittedly don't know) that it was particularly easy in 2017 to use Puppet to manage application deployments in Kubernetes. FluxCD also runs in Kubernetes itself, so you don't need any external infrastructure to do this. Maybe this makes it less weird? Multi-container orchestration nearly a decade ago was a fairly immature ecosystem, so they adopted ideas from configuration management of server fleets. Not all change in the world is greenfield innovation that comes absolutely out of nowhere.

tryauuum 2y ago
So how did people mange kubernetes before gitops? Automating "kubectl apply" in a different way in each company? Also it's useless to this discussion but polling was also a standard thing in puppet / chef / saltstack. Main motivation was to make deployments more gradual so in case of untested code only stone subset of servers is affected
tryauuum 2y ago
I see, I guess I only saw GitOps in gitlab and assumed it's another half-backed feature

r1cka 2y ago

You aren't missing anything. It's just marketing so GitHub/Gitlab stay in the main conversation when DevOps comes up.

Normal_gaussian 2y ago

To be specific GitOps covers the Ops/DevOps around git. So MRs / RBAC for git all the way through CI to CD. I've seen some stretch it to cover VDI equivalents as well. Basically large orgs ditched all their ops people a while ago to focus on integrated teams, and now its marketable to seperate it out again a new set of terms have come round to help orgs pretend they didn't make mistakes. The term DevSecOps really grinds my gears, gitops I'm more ok with, but still...

fk-corporation 2y ago
[flagged]

deleted 2y ago

[deleted]