I recently had the pleasure of virtually attending GitOps Days to learn more about GitOps as a principle and gain exposure to some of the major projects within its community. Much of my understanding of GitOps up to now has been self-guided or learned from coworkers, so I was especially seeking more depth as we intentionally incorporate these principles into DDEV as a platform and into how we work internally.
As an SRE at DDEV, I’m currently focused on supporting and building our platform operations and improving our platform’s CI, CD, & CO (continuous integration, continuous deployment, and continuous operations). We are starting to grow our GitOps processes and have already begun adopting GitOps into our workflows. This includes utilizing tools like ArgoCD in conjunction with various other processes and tools to manage declarative environment configurations.
My teammate Shawn, from the DDEV ops/security team, also attended the event. We had the opportunity to discuss some of the tools/apps that were mentioned (ArgoCD, FluxCD, Flagger, GitOps Operator, etc) as well as some conceptual terminology that I had questions about from the sessions. The virtual format was great because I could pause, rewind, and see the chatter from other attendees, and the videos and slides are available in the GitOps conversation kit. With two days of continuous live-stream there was a lot to take in!
Highlights of GitOps Days
Number one highlight was Kelsey Hightower’s keynote, where he demonstrated the power of GitOps. He is an incredible presenter, and understands the value of having a very basic & beginner friendly demo. He started by using `cdk8s` to define the most basic of apps, and from there used it to demonstrate the power and simplicity of GitOps.
My other favorite presentation was “GitOps Today and Tomorrow” by Cornelia Davis (CTO at WeaveWorks, the event organizers). In it, she laid out many nuggets of wisdom that should help guide the future of GitOps. Here are a few notes:
- Decouple “Declarative App Configurations” from “CI created binaries/executables” while still leveraging version control (such as git and container registries) for both.
- Almost everything (if not everything) can be defined declaratively & versioned.
- Continuous Integration (CI) is NOT Continuous Delivery (CD)
- Remember to keep deployment and operations separate from CI!
- GitOps is invaluable when needing to connect CI processes to Continuous Operations (CO) processes.
- “You can GitOps just about anything!” Examples include: Cloud-Native Apps, Infrastructure (in the form of Infrastructure as Code [IAC]), Identity Providers, Kubernetes Clusters, and so much more!
- GitOps = CD + CO + some required CI.
I especially appreciated slide 16 of Cornelia’s presentation as it summarized GitOps Principles so concisely:
GitOps and DDEV
DDEV-Live solves the problem of integrating your project’s GitOps workflow with a hosting provider by making integrations simple via our API token and installable CLI, backed by the knowledge that we use the same GitOps processes internally. DDEV as a dev-to-deploy platform can be used to support the concept of GitOps because DDEV-Local and DDEV-Live themselves can be adopted into a GitOps process because they already align with several of the core GitOps principles.
As Weaveworks CTO Cornelia Davis said during her presentation, the key elements of GitOps are:
- “You can GitOps just about anything.”
- Declarative Declaration. A declared intended state is taken and then interpreted. In our case, when a customer uses the DDEV-Live CLI, their commands are backed by declarative APIs. We’ll talk more about the declarative approach in an upcoming blog.
- Versioned Configs/Resources. The configuration of some or all of the workload is versioned using some form of source control.
- This could mean using Github to version things like Application Configuration, Deployment Configurations, Infrastructure as Code (IaC) etc.
- This could also mean using a container registry like DockerHub or GCR to store versioned container images.
- In our case: DDEV-Live can be utilized as a tool to achieve parts of a GitOps workflow. Utilize Github (or Gitlab in the coming future) to version control your site’s code, then use the CLI to declaratively define how that version controlled code should be configured, and assets added to it. You can even use the CLI to monitor the state of your application, as well as all of your assets.
GitOps, just like Kubernetes, is not the specific answer to any one question or problem. GitOps is a means to an end, just as Kubernetes or anything else in tech is. So before diving headlong into adopting GitOps, I’d advise first to identify what problems/deficiencies could be resolved or mitigated by implementing a GitOps workflow.
I do see this community growing in the future, gaining adoption and traction, as it can be applied to a vast set of situation specific problems.