Flux is a CNCF based open source stack of tools. Flux focuses on making it possible to keep Kubernetes clusters and cloud-native applications in sync with external resources and definitions hosted in environments such as GitHub. Implementing tools like FluxCD should enable you to achieve results such as: The results above can bring obvious benefits, and many teams are adopting FluxCD as their tool of choice for GitOps.
Matt and I are out in Los Angeles this week for KubeCon 2021 this week. At the GitOpsCon event Tuesday we were excited to attend this Kubernetes session: GitOps in the Real World: Opportunities for Developer Experience Improvement
In a previous post, we talked about the increasing adoption of Platform Engineering teams. The post covered topics such as defining Platform Engineering and the roles and responsibilities of the team. When building an internal platform, a clear goal that many teams want to achieve is: Even though this is key to a successful platform team, this responsibility increases complexity, costs, support time, and more. Not to mention that this can be a long, very long journey.
Not to muddy the waters with one more prefix in front of ops, GitOps is a newer DevOps paradigm that slants towards the developer. As the names states, GitOps is focused around Git, the source code management tool. As a developer, leveraging an SCM is one of the quintessential tools of the trade; allowing for collaboration and more importantly saving your hard work off of your machine.
This is the first of many posts highlighting GitOps topics that we’ll be exploring. Within this post, we will explore Helm, a tool used for Kubernetes package management, that also provides templating. Helm provides utilities that assist Kubernetes application deployment. In order to better understand how Helm charts are mapped to Kubernetes manifests, we’ll explain more details below and how to use Helm with and without GitOps.
One of the foundations of GitOps is the usage of Git as the source of truth for the whole system. While most people are familiar with the practice of storing the application source code in version control, GitOps dictates that you should also store all the other parts of your application, such as configuration, kubernetes manifests, db scripts, cluster definitions, etc. But what about secrets? How can you use secrets with GitOps?
GitOps is one method used by teams to deploy microservices, but challenges usually arise when deploying applications across multiple clusters and environments. For your GitOps initiative to be successful, you should consider implementing an application operating model. In this second workshop we covered.
The idea to fully manage applications, in addition to infrastructure, using a Git-based workflow, or GitOps, is gaining a lot of traction recently. We are seeing an increasing number of users connecting their Shipa account with tools such as ArgoCD and FluxCD. Based on that, we conducted multiple user interviews to understand some of the challenges teams face when implementing GitOps, especially those introduced or faced by their developers.