BROUGHT TO YOU IN PARTNERSHIP WITH

The Essentials
CONTENTS

∙ The Need for a New

Operational Model

∙ Infrastructure Automation

of GitOps
for Modern Applications

∙ GitOps Benefits

∙ GitOps Tooling and Technologies

∙ A Common GitOps Workflow

∙ Conclusion
ISAAC MOSQUERA
CHIEF TECHNOLOGY OFFICER, ARMORY

THE NEED FOR A NEW code (IaC), merge requests (MRs) as the request for change and system

OPERATIONAL MODEL of record, and continuous integration/continuous delivery (CI/CD).

With increasing user demand for always-on applications, available GitOps = IaC + MRs + CI/CD
on any device, the complexity and sophistication of software
development and delivery amplify. Traditional, monolithic apps CORE PRACTICE: INFRASTRUCTURE-AS-CODE
are being decomposed into cloud services that are built and run Infrastructure-as-Code (IaC) is the practice of keeping all infrastructure
by a distributed workforce, collaborating from around the globe. configurations stored as code. GitOps uses a Git repository as the single
Operations teams need a new paradigm to support the upsurge of source of truth for the definition of your infrastructure environments.
deployment frequency across multiplying services and in multiple By shifting your environment definitions from manual configuration
regions, all while reducing risk, increasing uptime, and staying secure. to configuration by code, you gain access to an array of benefits such
as version control, code collaboration, and auditability.
GitOps is an operational framework that takes DevOps best
practices used for application development, such as version You also unlock Git as the user interface for your infrastructure,
control, collaboration, compliance, and CI/CD, and applies them to allowing you to leverage all of the developer tooling, training, and
infrastructure automation. While GitOps practices work well within knowledge associated with Git for your infrastructure operations.
any software environment, Kubernetes is particularly well suited
due to its use of declarative infrastructure definitions kept alongside
application code in a Git repository.

Keeping your system definition in Git means your engineers can use
familiar, Git-based tooling and workflows to manage both application
and infrastructure changes. With the entire state of your cluster kept
under source control, you gain the ability to automate changes for
less risk, recreate historical states, review a robust audit log, manage
compliance, and more.

INFRASTRUCTURE AUTOMATION
FOR MODERN APPLICATIONS
GitOps practices aren’t dependent on any specific technology. While
logically GitOps is simply managing operations by Git, there are three
core practices that make up a mature GitOps practice: Infrastructure-as-

1
 armory.io
Continuous delivery
at enterprise scale

Armory Pipelines as Code

Leverage GitOps principles to simplify managing,
reusing, scaling, and auditing Spinnaker pipelines.

Armory Pipelines as Code enhances Spinnaker's pipeline UI by making

it easy to define pipelines in JSON, HCL or YAML and automatically
sync pipelines between source control and Spinnaker.

With Pipelines as Code, you get

Pipeline version control in Git for collaboration, reviews,

audits, troubleshooting, and change management

Templated and modular pipelines and stages so you can

share best practices, reduce redundancy, and maintain pipeline
consistency across your organization

Repeatable, scalable pipelines for onboarding your

applications and your application developers quickly

Sophisticated features including conditional logic, multiple

repo / multiple branch support, Slack notifications, and more

Dynamically create and store Spinnaker pipelines in a Git repo

Try Armory Pipelines as Code TODAY

 REFCARD | THE ESSENTIALS OF GITOPS

Although IaC is a popular and well-known practice, GitOps isn’t that environment. Changes are proposed on a feature branch, and a
relegated to simply infrastructure. Any operations that can be defined PR is made to merge the changes into the main branch. This PR allows
as code (e.g., network, policy, security) are benefits of GitOps too. In for collaboration between operations engineers for peer review, along
some cases, the term “X-as-Code” (XaC) can be used to encompass with the development teams, security teams, and other stakeholders.
operations beyond infrastructure. This Refcard uses the more This powerful model for collaboration permits anyone to propose a
established term “IaC” with the understanding that we're including the change, while also allowing you to maintain compliance by limiting
entirety of the operational environment, not simply the infrastructure. the number of people who can merge the changes.

DECLARATIVE VS. IMPERATIVE ENVIRONMENTS CORE PRACTICE: CI/CD AUTOMATION

Many modern infrastructure tools such as Kubernetes, Terraform, and The final component of a robust GitOps strategy is automating all
AWS CloudFormation work from a declarative model. An operations changes made to environments via CI/CD. In an ideal scenario, no
engineer declares the desired state as code, and the system changes manual changes are made to a GitOps-managed environment. Instead,
itself to conform to that state via automation. For example, a CI/CD serves as a type of reconciliation loop. Each time a change is
Kubernetes manifest can declare the number of pods desired for a made, the automation tool compares the state of the environment to
particular service. The engineer doesn’t need to write an imperative the source of truth defined in the Git repository. If the Git repository
script to bring these pods up or down until the right number is shows a change, the automation tool reconciles this difference by
achieved because Kubernetes handles this itself. configuring the environment to match the canonical desired state.

It’s the difference between saying, “I have three servers but want six, This type of automation serves as a powerful protection against
so I need to write a script to create three more services,” and simply configuration drift. There are many reasons configurations can fall out
telling the system, “There should be six servers. If there comes a of sync. Whether due to a component failure or inadvertent manual
point when there are too few or too many, change the state of the change, each time the automation runs, it overwrites the existing state
environment until we have the correct number.” Using declarative with Git source of truth.
patterns can be very powerful within a GitOps operational model,
but they aren't a strict requirement. You can still benefit from GitOps AGENT VS. AGENTLESS GITOPS

practices if your environments are imperatively defined. A couple of different models for GitOps automation have emerged,
namely Agent-based and Agentless, each with its own pros and cons.
CORE PRACTICE: USING PULL REQUESTS Agentless GitOps is a traditional model, also known as push-based
FOR CHANGES GitOps, in which your CI/CD tool reads from your Git repository and
It may be surprising to learn that the underlying Git version control pushes changes into your environment.
system used to power tools such as Bitbucket, GitHub, and GitLab • Pro – It’s simpler and more flexible as it can be used with
doesn’t include a way to request your branch be merged back into the any type of infrastructure, from physical servers and VMs to
branch it was created or forked from. This was a later advancement Kubernetes clusters.
introduced by Git management tools. GitHub and Bitbucket use the
• Con – You must give your CI/CD tool access to make writes
term pull request (PR) while GitLab uses the term merge request
to your environment. Requiring your environment to be
(MR), but functionally, they perform as a central point of developer
open to writes from the external internet can cause security
collaboration for code review and change orchestration.
and compliance issues.
Without a proper version control and branching strategy, collaboration
Figure 1: Agentless GitOps model
on new changes is a frustrating endeavor. When anyone can modify a
file without a way to track who made which change, it can be almost
impossible to ensure the correct version is being used. A common
application development workflow uses a main branch as a centralized
collaboration point. Feature branches are created from the main
branch, where new work is developed, and merged back into the main
branch using a pull request. Leveraging this best practice for all of your
infrastructure code nets you the same benefits that developers enjoy.

In an infrastructure model, the main branch represents a particular

environment (e.g., dev or production), as well as the state running in

3 BROUGHT TO YOU IN PARTNERSHIP WITH

 REFCARD | THE ESSENTIALS OF GITOPS

Agent-based GitOps, also known as pull-based GitOps, makes use of an INCREASED DEPLOYMENT FREQUENCY
agent that runs inside of your infrastructure. This agent pulls changes With automated application deployment and environment
in from an external Git repository when it detects that the state of the provisioning, you can do many small, frequent deployments rather
environment is out of sync with the source of truth. than occasional large, risk-prone deployments. Smaller changes are
easier to reason about when troubleshooting and easier to roll back.
• Pro – CD agents can allow you to operate in a more secure
Additionally, deploying features to your users sooner leads to happier
and compliant way without the need to open inbound ports
users, more actionable feedback, and ultimately improved software.
in your firewall.

• Con – Agents must be custom-designed to the type of REDUCED MEAN TIME TO RECOVERY
infrastructure you want to use. A core benefit of keeping environment state in version control is that
rolling back to the last known good configuration when you experience
Figure 2: Agent-based GitOps model
problems is straightforward. This can dramatically reduce your mean
time to recovery (MTTR) because you can fix issues quickly during
an incident by rolling back, and then after your system is operating
normally, you can troubleshoot.

IMPROVED POST-INCIDENT RESPONSE

During a firefight, the goal is simply to get everything operational
and within acceptable limits. There’s not always time to document
enough details about what went wrong so that it can be improved. But
a GitOps system defined as code can be replicated at any version. The
faulty production version can be replicated after an incident in a test
Today, most GitOps agents, such as the GitOps Engine, are designed environment to do forensics and a root cause analysis.
specifically for Kubernetes. For example, these agents won’t run inside
GREATER RELIABILITY AND UPTIME
of a VM-based cluster. A workaround requires setting up a Kubernetes
Manually configured infrastructure can be brittle and unreliable.
cluster dedicated to orchestration. The CD agent runs inside the
With GitOps automation, human error is greatly mitigated, keeping
orchestration cluster and enacts changes to external infrastructure.
your infrastructure uptime stable and allowing your IT Ops team to
Figure 3: GitOps Engine model sleep at night.

SIMPLIFIED COMPLIANCE AND AUDITING

Too often organizations must trade off between moving fast and
staying compliant. With GitOps, compliance and approvals can be
automated, distributed, and conducted asynchronously so the pace
of innovation keeps moving forward.

With manual tools, auditing is highly painful. Pulling data from multiple
places and trying to normalize it is extremely time-consuming. Having
all operations in Git gives you a one-stop shop for audit logs of every

GITOPS BENEFITS change so auditing can be effortless.

GitOps best practices are far-reaching and can provide the following
ENHANCED SECURITY
benefits.
Leveraging Git’s robust permission model makes it simple to grant,
TIGHTER COLLABORATION revoke, and track permissions for each environment. Beyond read/
Using the pull requests as a central point of collaboration enables write access, the Git merge request workflow unlocks an additional
teams across the organization to work together in a fast, automated, ability to grant proposal access. Many users can be granted the ability
and asynchronous way. Best practices from one team can be easily to propose changes, while simultaneously keeping the pool of people
shared and consumed across the organization because they are who can enact those changes small.
documented as code.

4 BROUGHT TO YOU IN PARTNERSHIP WITH

 REFCARD | THE ESSENTIALS OF GITOPS

GITOPS TOOLING AND TECHNOLOGIES 8. The code is iterated on until it meets the standards to be
As a methodology, GitOps doesn’t require any specific technology to merged. This typically means all automated checks have
implement. The following table lists examples of the types of tooling passed, all comments are resolved, and any needed
that you’ll generally want to implement when adopting GitOps, along approvals have been added.
with some examples of each. 9. The Git merge to the main branch triggers the CI/CD
deployment pipeline, where an additional set of
Table 1: Examples of GitOps tooling
automated tests can be run.
TOOLING TYPE EXAMPLE
10. The infrastructure pipeline configures and provisions
Git code repository Git
the environment, while the product pipeline deploys
Git management tool Bitbucket, GitHub, GitLab the application code.

Continuous integration tool CircleCI, Jenkins

Figure 4: GitOps workflow
Continuous delivery tool Spinnaker, Flux

Container registry Docker Hub, GitLab

Configuration manager Ansible, Chef, Puppet

Infrastructure provisioning AWS CloudFormation, Pulumi, Terraform

Container orchestration Kubernetes, Nomad

A COMMON GITOPS WORKFLOW

The power of GitOps is that the same workflows used to add features
to a service or application can be used to configure and provision the
environments where the software runs. This shared understanding
of workflows and tooling across the organization drives many of the
benefits that GitOps brings.

WORKFLOW FOR DEPLOYING A NEW FEATURE

1. A ticket is logged in the product issue tracker for the

new feature.

2. A corresponding ticket is logged in the platform

operations issue tracker to provision the infrastructure
needed to support the new feature.

3. A branch is created in each respective repository to

work on the feature and infrastructure changes.

4. Code is committed to each branch.

5. A pull request is created for each branch to perform

code review and testing.

6. The CI/CD pull request pipeline runs automated tests

and checks against the branch. Sophisticated tooling
will display the results within the PR to aid collaboration
and troubleshooting.

7. The PR serves as the central point of collaboration for

peers and stakeholders. Reviewers comment on the
general approach, as well as on specific lines of code.

5 BROUGHT TO YOU IN PARTNERSHIP WITH

 REFCARD | THE ESSENTIALS OF GITOPS

Workflows can vary depending on the size of the team, the repository
setup, and if you are using Agent or Agentless tooling. The workflow WRITTEN BY ISAAC MOSQUERA,
above can be adapted and extended to meet the specific requirements CHIEF TECHNOLOGY OFFICER & CO-FOUNDER, ARMORY

of your organization. Isaac leads engineering and product teams at

Armory and has been engaged in the Spinnaker
community since it was open sourced in 2015.
CONCLUSION Recently, he was elected to both the Spinnaker Steering
GitOps is an operational model that leverages DevOps best practices Committee and the Continuous Delivery Foundation's Technical
Oversight Committee. He enjoys mountain biking, snowboarding,
used in application development for infrastructure automation. Using and eating copious amounts of gummy bears.
Infrastructure-as-Code, the environment definition is stored in a Git
repository as the single source of truth. The pull request workflow is
used for collaboration and compliance, while CI/CD automation not
only deploys the application code, but also configures and provisions
the underlying environments in which the code runs.
DZone, a Devada Media Property, is the resource software developers,
Adopting GitOps best practices means that developers and operations engineers, and architects turn to time and again to learn new skills, solve
software development problems, and share their expertise. Every day,
engineers can use familiar Git tooling to manage updates to software hundreds of thousands of developers come to DZone to read about the latest
technologies, methodologies, and best practices. That makes DZone the ideal
environments. Automation, along with asynchronous collaboration place for developer marketers to build product and brand awareness and drive
sales. DZone clients include some of the most innovative technology and tech-
at scale, speeds up the pace of innovation to decrease lead times enabled companies in the world including Red Hat, Cloud Elements, Sensu, and
Sauce Labs.
and increase deployment frequency. This increased agility allows
businesses to respond to customer and market demands to build and Devada, Inc.
600 Park Offices Drive
maintain a competitive advantage. Suite 150
Research Triangle Park, NC 27709
Whether teams are working side by side in the same office or 888.678.0399 919.678.0300
Copyright © 2021 Devada, Inc. All rights reserved. No part of this publication
distributed around the world, GitOps increases collaboration between
may be reproduced, stored in a retrieval system, or transmitted, in any form or
development, operations, security, and all business stakeholders. by means of electronic, mechanical, photocopying, or otherwise, without prior
written permission of the publisher.

6 BROUGHT TO YOU IN PARTNERSHIP WITH