GitOpsCon North America 2022

The GitOps practice continues evolving and becoming more accepted and integrated into teams daily. Now that we have a more clear path to GitOps, how can we continue to evolve the practice to make it as easy as possible to integrate across the application development life cycle? In this session, we’ll explore possibilities to integrate across the application development lifecycle to further coordinate releases.

GitOps might sound like a self-explanatory term, but it is not as easy as it sounds. Many think this just means to store your Infrastructure-as-Code in Git, then have a pipeline run the code, but it is actually much more complicated than that. True GitOps takes the deployment out of CI/CD, and the most popular solutions are using Kubernetes controllers to do all the heavy lifting. Ensure what you’ve defined in Terraform is what’s always running and available. Flux continuously looks for changes and reconciles with the desired state. Take advantage of all the benefits of GitOps: streamlined and secure deployments, quicker time to market, and more time to concentrate on app development! Pinky will provide an in-depth look at the new Flux Terraform Controller, which enables Terraform deployments to be done the GitOps Way. They’ll end with a demo of a common use case implementation.

What if each developer or team could independently provision and run their own Kubernetes clusters with full api access? Learn how to leverage Argo CD, vcluster and Kubernetes' cluster-api to build dynamic and full-access environments with every pull request. Then see how these independent environments can be stitched together to create a unified view for QE, integration testing or demos. All while managing each environment's costs and compliance from a single view on the host cluster.

Multi-cluster, multi-app edge deployments may involve multiple applications on different cluster types located in different environments. This adds complexity to management, security, and consistency. These complexities can be addressed by using EMCO (Edge Multi-Cluster Orchestrator). With EMCO, GitOps can be leveraged to communicate with Kubernetes clusters over the git protocol, integrating with a variety of public clouds. EMCO acts as the intelligent agent that writes resources to the git location, helping in management, consistency, and security (since no direct communication happens to these clusters). - What goes in the repository: o Kubernetes resources as rendered from Helm Charts. o Cloud-specific configuration and resource files (Kustomization, FluxCD system files, RootSync configurations). - Security considerations: o Token-based authentication for Flux, Azure and Anthos. o Kubernetes Secrets concept for storing and passing sensitive information. o HTTPS APIs ensure data privacy. - The different git libraries in use (and future): o Git2go for interacting with git. o Azure and Anthos APIs o Gitea for local git server

Security is shifting left. What used to be a straightforward task in the past, such as deploying an application, today involves secrets. Secrets are typically stored in a secret management solution framework, yet available to the engineer's disposal. In this lightning talk, I will explain how you could secure your DevOps process today, using an open standard (JTW) to access secrets, without compromising due to security or complaints, or waiting for a DevOps vendor to build a native integration framework for you

Much toil and work is wasted! in the pursuit of glory, the sacrifice of mission, and the hosting... of web applications. In a computable world of information, there are often many valid solutions to the same problem, and naturally, there are a lot of ways to effectively deliver software, but why is GitOps a good way to do that? Is GitOps really just a trendy name for Continuous Delivery, or is there something more here? GitOps has a heart. There is a full-bodied reason for why this community beats to the rhythms and habits begged for by it's tools. This talk will break that down and speak to the question, "Why do we do this?"

Our infrastructure needs are increasingly energy and carbon intensive. CI/CD is one area where we can take steps to measure and reduce our footprint. In this talk, we present our investigation into instrumenting CI/CD systems and GitOps tools to achieve this. We share the outcomes and lessons learned from these experiments so far. Our journey begins with traditional CI/CD where the two are tightly coupled. Transitioning to GitOps often starts with decoupling the two. This is an opportunity to measure the energy consumption of each step and think about environmental impact from the very beginning. Energy use can be measured before and after this decoupling, and we can show you how. On the next stop in our sustainability journey, we evaluate how GitOps tools and patterns can be used to reduce energy consumption and wasted resources. Expressing a system declaratively offers full visibility of the tools running in your clusters. Another promise of GitOps is that it can be used to turn IT off when not needed. GitOps can also support tools and policies to measure and optimize energy and carbon usage. Our journey ends with some reflections on methodology, outcomes, and next steps.

Beyond just "don’t run everything as root" In this talk Chris will trace back the origins of how policies are often incepted, how it can get out of hand, be slow if not impossible to update and measure compliance, and often lead us to question of **is the policy helping or hindering**.

The Devtools platform team at Teachers Pay Teachers were looking to improve their current CICD platform. Having no prior knowledge of Gitops or ArgoCD, the small team decided to give it a go. They’re early on in their migration but the team has learnt a ton. In this talk, team members will share their experience with ArgoCD and some of the decisions and tradeoffs they chose. Some topics they’ll cover are: choosing a gitops implementation, auto vs manual sync, keeping the helm config in the app repo, commit strategies for staging and production, backwards compatibility and more.

Flux is a CNCF tool that enables users to adopt the GitOps methodology for continuous deployment. Flux reconciles your workload from different sources: Git, Helm repository, an S3 bucket, and now Flux maintainers have added support for OCI registries. Not only can Helm charts be stored as OCI artifacts, but also your Kubernetes desired state in plain YAML and other popular formats like Kustomize and Terraform. We will demonstrate how to use OCI registries as a source to deploy workloads using flux: - Deploy charts and Kubernetes manifests from an OCI registry - Sign and verify the workloads - Automatically update configuration repository and observer automatic upgrades We will also present the Flux OCI as source architecture so users can better understand what's going on under the hood when they use OCI registries for their GitOps source.

GitOps is awesome for workflows such as managing sets of applications across fleets of clusters, and the provisioning of multi-tenant infrastructure for teams or end-users. However, there are often gaps in these workflows that require manual configuration or the creation of custom controllers. Additionally, these workflows remain hard to secure, and security best practices like “the least privilege principle” cannot be easily applied. In this session, Avni and Jim will show how Kubernetes-native policies can be used to secure and automate complex GitOps workflows. First, they will showcase use cases for using GitOps such as managing a consistent set of applications across multiple clusters and delivering multi-tenant “Namespaces-as-a-Service” and “Clusters-as-a-Service”, using ArgoCD. Then they will highlight the current gaps in automation and security. Next, they will demonstrate how Kyverno, a Kubernetes native policy engine, can be used with GitOps to address these critical gaps. Attendees will learn how to successfully use policies and GitOps together and also avoid common pitfalls when multiple controllers are in play.

GitOps promises a future where all infrastructure is code, but what about all these legacy applications that have to be kept running while DevOps teams build that future? Enter two CNCF Incubator projects, KubeVirt and ArgoCD! ArgoCD brings tested code control workflows to bear in managing infrastructure, while KubeVirt introduces virtual machines to the Kubernetes ecosystem. This session will demonstrate using ArgoCD to bring up KubeVirt, and bring virtual machines along for the ride while running a version of Bookinfo with mixed VM and containerized microservices. After this session, you’ll be well positioned to bring even your legacy services into a GitOps workflow.

Deploying to static environments(QA/staging/prod) is a familiar process for existing ArgoCD users. However, several teams want to shift left and use preview environments. Preview environments are created dynamically when a pull request is opened and are destroyed when the pull request is merged/approved This talk will focus on implementing preview environments in a GitOps way using ArgoCD.