Closed o6uoq closed 2 years ago
@o6uoq we'll be having our first community call on December 10 at 5pm GMT. Definitely join!
@dj1k thanks for letting me know. How can I be made aware of the details e.g. link/calendar invite/etc?
Yes, please!
I agree with this issue but would go beyond just Hashi technologies... The idea that you could use GitOps principles to manage "out of cluster" resources just like you do cluster resources would be highly beneficial. Infa-as-code tools are just one possible implementation, Microsoft recently proposed managing "edge" devices from within k8s clusters by creating specific controllers that could communicate directly with the edge devices but could be managed with resource representations in k8s, which would be a perfect fit for GitOps, in my opinion.
Yes - the various cloud providers are also providing CRDs to drive external services.
Speaking of Hashicorp, Nomad should be considered as an alternative to K8S as well. I would like to get involved an join the comminuty call, too.
@tpouyer agreed. However, the HashiCorp Stack aka HashiStack (namely Consul, Terraform, Vault and Nomad) are all declarative and can driven by Git.
What interests me is this from Guide To GiOps:
A path towards a developer experience for managing applications; where end-to-end CICD pipelines and Git workflows are applied to both operations, and development.
This extends (as a venn and not outlying) the declarative nature of HashiCorp tooling, and the great features of Terraform Cloud (or manually done in CI/CD) provide a rich GitOps experience.
I agree with @o6uoq, and I don't think GitOps should not be specific for k8s. However, there is a difference between IaC tools and GitOps: GitOps state the Git is the single source of truth, IaC doesn't mention where the truth should be saved. Terraform for example uses a state that is generated, and can be saved outside of Git.
@OmerKahani agreed however the differences are venn vs outlying. The declarative of nature of HashiStack has the caveat of state, depending on which tool you're using (Consul vs Terraform). I hope to have a demo of this workflow by end of year.
GitOps Principles state:
The Five GitOps Principles are as follows:
1. Declarative Configuration: All resources managed through a GitOps process must be completely expressed declaratively.
2. Version controlled, immutable storage: Declarative descriptions are stored in a repository that supports immutability, versioning and version history. For example, git.
3. Automated delivery: Delivery of the declarative descriptions, from the repository to runtime environment, is fully automated.
4. Software Agents: Reconcilers maintain system state and apply the resources described in the declarative configuration.
5. Closed loop: Actions are performed on divergence between the version controlled declarative configuration and the actual state of the target system.
HashiStack is declarative and driven by VCS (version controlled + immutable storage), automated delivery either through DIY CI/CD or Terraform Cloud, leaving the only unfulfilled requirements to be within the venn of GitOps is both [4]
and [5]
.
@o6uoq đ
@o6uoq it's been great having you in the GitOps WG meetings so far. I'm looking forward to your continued participation in the WG and OpenGitOps project in 2022! ⨠Also this topic is still relevant!
Hi @o6uoq , is there anyway we can work together on this ?
@nishadmehendale please join weave-community.slack.com and feel free to message me :)
@o6uoq, I would suggest sticking to the CNCF slack, as that is the official communication channel for the OpenGitOps project.
When it comes to utilizing HashiCorp tools for GitOps, let me know if you folks want more people involved. đ
đđŧ I would like to be involved in the GitOps Working Group and also discuss formalising better patterns of integrating GitOps into Infrastructure-as-Code, combining patterns and how that can apply to the HashiStack (Terraform, Consul, Vault, Terraform Cloud).
Terraform Cloud has an incredible range of git integration and I think there's an opportunity to extend GitOps beyond just Kubernetes into other patterns (albeit as a venn vs outlying).