DevOps and Docker Updates — GitOps

You might have heard of it, but in 2017 the term GitOps was born, has become a way to describe what a lot of us were already doing: using Git version control systems (GitHub, GitLab, etc.) as a way to manage the dev-to-prod workflow and “infrastructure as code”, and using Git commits as a way to document change, while keeping the history of changes fully documented in repos for the team to see.

Here’s more to get you started on GitOps and Docker!

Getting Started with GitOps

There are a few requirements here. Obviously knowing Git CLI basics and picking a Git server platform (GitHub, Bitbucket, GitLab, and many more) is a first step. Then understand why GitOps is likely better then what you’ve done in the past.

Building infrastructure, deploying code, configuring servers, adding new stuff, changing old stuff…. These are all normal software management tasks, but tracking change is one of the hardest things. Sure we have logs for everything, and change management tools, and ticketing systems, but they all fall short at simple change tracking because they are often complex, don’t track *all changes*, or aren’t available to everyone who needs to see changes. GitOps isn’t Kubernetes specific, but these two overviews will help you understand what we’re talking about:

GitOps what you need to know — www.weave.works
Learn what is GitOps and how you can implement GitOps workflows to reliably run Kubernetes in production and at scale. Also find out why GitOps is the more secure way to deploy apps to Kubernetes.

GitOps: Dev, with a Dash of Ops! | CloudBees — www.cloudbees.com
Why you should care about GitOps GitOps is a set of practices that helps developers perform tasks which typically fall under the operations. It serves as an operating model for developing and delivering Kubernetes-based infrastructure and applications as well as ties in Jenkins X to deliver cloud native applications on Kubernetes.

How Do You Know If You’re Doing GitOps?

Like DevOps, there’s not one single way to “do GitOps” nor a single checkoff list of tasks to implement, but let’s make this simple:

If I can determine the state and configuration of your infrastructure (and app code) by looking at Git commit logs, then you’re doing GitOps.

“Did she change the HTTP proxy to sticky sessions on the web front end yet?” — Look at Git logs

“What tests do we run on the API before the container image is uploaded to our registry” — Look at Git

“Did they upgrade the stagning cluster to Docker 19.03 yet?” — Look at Git logs

Sure, you may not have everything fully automated, even though automation is a big part of DevOps and GitOps. Remember that GitOps is more about having observability of change in a common place all the teams can see, and using those commits to kick off changes once you’ve automated things. Having a central place that all your tools connect to, and using that as the single-source-of-truth, is what will enable you to go faster and automate when you want to.

GitOps: ‘Git Push’ All the Things — The New Stack — thenewstack.io

The idea is to “make git the center of control,” of cloud-native operations, for both the developer and the system administrator

Right Now GitOps is New…

Which means it’s not quite plug-and-play. But, most tools already support Git, webhooks, and some automation that will store its configuration in text so you can use Git to track it. It’s up to you to get all those tools setup the way you want.

The Best CI/CD Tool for Kubernetes Doesn’t Exist — The New Stack — thenewstack.io

A podcast episode talking about what we need in CI/CD for container orchestration

Why we use Terraform and not Chef, Puppet, Ansible, SaltStack, or CloudFormation — blog.gruntwork.io
Update, November 17, 2016: We took this blog post series, expanded it, and turned it into a book called Terraform: Up & Running! Update, July 8, 2019: We’ve updated this blog post series for…

Final Warning: Understand GitOps vs. CIOps

Kubernetes Anti-Patterns: Let’s Do GitOps, Not CIOps! — DZone Cloud — dzone.com
Take a look at what you could be doing wrong with your CIOps infrastructure regarding security and scale, and how you can optimize and scale it with GitOps.

The above is a great blog post on the subtle difference between what I’m talking about in this newsletter and what a lot of us end up doing. Once we have CI/CD, we often want to use it to deploy changes to our servers, and we often let people have access to all the tools like docker, kubectl, and terraform to also change our servers and deploy app updates manually via commands. In order to fully adopt GitOps, all deployments and server updates should be happening through declarative YAML/TOML changes in a git repo. Any commands you’re typing other than “apply this YAML in Git” are lost, and outside the GitOps model, so make it your goal to get everything in declarative files and have the system itself react to Git commits of that infrastructure code.

See ya next week,

Bret