paint-brush
Getting Started with GitOps 2.0 Using ArgoCD & Codefreshby@Codefresh
521 reads
521 reads

Getting Started with GitOps 2.0 Using ArgoCD & Codefresh

by CodefreshNovember 16th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Codefresh has released a GitOps dashboard for Kubernetes applications. The GitOps tool is a command-line tool and a graphical User Interface. The most popular GitOps tools today are Flux and ArgoCD. The new GitOp dashboard is different than existing GitOps views because it holds deployment information on multiple levels. It includes a handy search field that can search your Git history with business terms (i.e. JIRA issue numbers and commit messages) instead of plain text commit messages.

Company Mentioned

Mention Thumbnail
featured image - Getting Started with GitOps 2.0
Using ArgoCD & Codefresh
Codefresh HackerNoon profile picture

GitOps is the practice of deploying applications by using Git Operations only (and not clicking UI buttons). The paradigm already existed in one form or another but was officially named as “GitOps” in 2017 by Weaveworks and has since become very popular for Kubernetes deployments.

The concepts behind GitOps are very simple:

  • The state of the system/applications is always stored in Git.
  • Git is always the source of truth for what happens in the system.
  • If you want to change the state you need to perform a Git operation such as creating a commit or opening a pull request.
  • Once the Git state is changed, then the cluster (or whatever your deployment target is) state should match what is described in the Git repository.

Specifically for Kubernetes, GitOps says that you must not use `kubectl` to change the cluster state in an ad hoc manner. 

Current GitOps tools

The most popular GitOps tools today are Flux and ArgoCD. Flux is a command-line utility while ArgoCD also includes a graphical User Interface that shows the state of the cluster.

Both tools work in a similar manner:

  1. You install an agent in your Kubernetes cluster.
  2. You link your Git repository that holds your Kubernetes manifests.
  3. You decide if you want “auto-sync” behavior or not.

Performing a deployment means committing to the Git repository. If auto-sync is enabled then both tools will instruct the cluster to change its state in order to match what the Git repository describes.

If auto-sync is not enabled, you can delegate the sync action to another external entity such as a CI platform.

If you want advanced deployments such as blue/green/canaries, you can also look at Flagger and Argo Rollouts respectively.

GitOps and observability

The current GitOps tools work great for developers and operators, but as GitOps is getting more popular, we should include all other project stakeholders in the deployment process.

Project managers and product owners do not really care about Git commits. They care about features. Customers are getting value when features are shipped in production.

Today, most GitOps tools are really low-level and are specifically designed for developers/operators. Knowing that the cluster is in sync with a specific Git hash, is certainly important information, but is it really useful for business stakeholders?

Wouldn’t it be great if GitOps tools could also present business features in their dashboards?

Getting the full view of the software lifecycle

At Codefresh, we believe that GitOps is a very important paradigm and should not be constrained only in low-level tools, but instead be accessible to all project stakeholders.

This is why we have invested considerable effort into our new GitOps dashboard that goes above and beyond by showing plain Git hashes and cluster information.

The new GitOps dashboard is different than existing GitOps views because it holds deployment information on multiple levels:

  • Git commits and committers
  • Pull Request information
  • JIRA issues (i.e. business features)
  • Kubernetes services that were affected by a deployment
  • Container images that had a version change
  • Timeline of deployment status
  • One-click rollbacks

The main point here is that this dashboard can easily answer questions such as:

  • Is the JIRA issue 8323 deployed right now in production?
  • Can we rollback to the next commit after Git hash ec2a32f?
  • Did we deploy JIRA issue 2354 last Thursday?

The dashboard also includes a handy search field that can search your Git history with business terms (i.e. JIRA issue numbers and pull requests) instead of just Git hashes and plain text commit messages.

In additions to the details of a specific application, there is also a global dashboard for all GitOps applications:

The overview dashboard combines technical details for an application (its deployment status) with business information (features implemented).

Powered by the ArgoCD project

The GitOps functionality in Codefresh is actually powered by the ArgoCD project. ArgoCD already has implemented not only the basic GitOps mechanism (polling Git repositories for changes) but also a powerful synchronization operation that includes advanced features such as:

The integration with ArgoCD happens via an in-cluster agent that you can install with the Codefresh CLI.

Once you install the agent, Codefresh will even auto-import all your existing ArgoCD applications in the Codefresh GitOps dashboard.

The road to GitOps 2.0

We believe that GitOps observability should not be constrained just to developers and operators. GitOps should cover the full software lifecycle (and not just deployments), thus providing value to all project stakeholders.

Enriching the basic Git information with business information, thus combining Git hashes and JIRA issues, is just one of the first steps for moving into a better GitOps model that will standardize the features and requirements of a GitOps platform.

We have many more features under construction for the Codefresh GitOps dashboard and we cannot wait for you to discover them!