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.
This article was written by a guest author. Not long ago, if we wanted to put our code into production, we needed to manually configure a server, our infrastructure, that would host our app or database. This manual process is not only time-consuming, but also prone to errors. That is why at present, developers chose to create “scripts” that are in charge of configuring the infrastructure These “scripts” are known as Infrastructure as Code (IaC).
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.
On August 11th, 2021, we conducted a workshop to discuss implementing a GitOps workflow using ArgoCD, Crossplane, and Shipa. We were overwhelmed by the hundreds of people who registered for the session. We believe it shows a few important challenges have to be solved for GitOps to become mainstream across different enterprises. While GitOps brings many benefits, we often see teams facing challenges.
Is GitOps changing observability as we know it? GitOps has been the buzz word in the DevOps space for several years. GitOps, to those that are not familiar, is an operational methodology for DevOps that leverages a continuous deployment approach with Git as the single source of ‘truth’ for declarative control over both infrastructure and applications.
GitHub Actions are a powerful way to add automation to any source code repository. When you take that power and connect it with InfluxDB, you get an amazing combination that allows you to automate data generation, manage GitOps workflows, and a whole lot more. This post will highlight some of the interesting ways to use InfluxDB and GitHub Actions.
Kubernetes allowed us to manage application deployments and infrastructure components using declarative configuration files (yes, those YAMLs that you may not be a fan of ). While dealing with a myriad of YAML files may be loved by some and hated by others, it enables us to host all these files into a Git repository, hook it up to a pipeline (Jenkins, GitLab, etc.), and have a tool apply those changes to a cluster—and voilà, you have GitOps.
It’s no secret that the software development community is starting to embrace GitOps. With the complexity of engineering modern software today, it is becoming a necessity for many companies to reassess their software development and delivery practices. When Codefresh first released GitOps 2.0 late last year, we had already planned to make it a core pillar of our platform.
