Skip to content

otkd/CGOA-Study-Guide

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

15 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Certified GitOps Associate (CGOA) Study Guide

GitHub License

CGOA Banner

Disclaimer

This study guide is an unofficial resource created to assist candidates preparing for the Certified GitOps Associate (CGOA) exam. Originally compiled during the beta due to the limited availability of dedicated materials for the CGOA, as such it has not been endorsed by the Linux Foundation or any other official body associated with the CGOA certification.

Introduction

The Certified GitOps Associate (CGOA) is a certification offered by the Linux Foundation:

The purpose of the Certified GitOps Associate (CGOA) certification is to provide assurance that CGOAs can effectively demonstrate their understanding of GitOps principles, terminology, and best practices in setting up a GitOps managed software system in addition to related practices such as Configuration of Code, Infrastructure as Code, DevOps & DevSecOps, and CI & CD and how to map them to GitOps.

More information about the certification can be found on the official exam page.

Table of Contents

Background

Resources:

Domains & Competencies

GitOps Terminology - 20%

Continuous

Continuous is intended to match the industry standard term: reconciliation continues to happen, not that it must be instantaneous.

Declarative Description

A configuration that describes the desired operating state of a system without specifying procedures for how that state will be achieved. This separates configuration (the desired state) from the implementation (commands, API calls, scripts etc.) used to achieve that state.

Desired State

The aggregate of all configuration data that is sufficient to recreate the system so that instances of the system are behaviourally indistinguishable. This configuration data generally does not include persistent application data, e.g., database contents, though often does include credentials for accessing that data, or configuration for data recovery tools running on that system.

State Drift

When a system's actual state has moved or is in the process of moving away from the desired state, this is often referred to as drift.

Resources:

State Reconciliation

The process of ensuring the actual state of a system matches its desired state. Contrary to traditional CI/CD where automation is generally driven by pre-set triggers, in GitOps reconciliation is triggered whenever there is a divergence. Divergence could be due to the actual state unintentionally drifting from the desired state declarations, or a new desired state declaration version having been changed intentionally. Actions are taken based on policies around feedback from the system and previous reconciliation attempts, in order to reduce deviation over time.

GitOps Managed Software System

A software system managed by GitOps includes:

  1. One or more runtime environments consisting of resources under management.
  2. The management agents within each runtime.
  3. Policies for controlling access and management of repositories, deployments, runtimes.

State Store

A system for storing immutable versions of desired state declarations. This state store should provide access control and auditing on the changes to the Desired State. Git, from which GitOps derives its name, is the canonical example used as this state store but any other system that meets these criteria may be used. In all cases, these state stores must be properly configured and precautions must be taken to comply with requirements set out in the GitOps Principles.

  • State Store = Single Source of Truth

Feedback Loop

Open GitOps follows control-theory and operates in a closed-loop. In control theory, feedback represents how previous attempts to apply a desired state have affected the actual state. For example, if the desired state requires more resources than exist in a system, the software agent may make attempts to add resources, to automatically rollback to a previous version, or to send alerts to human operators.

Rollback

Rollback is the process of reverting a system to a previous state. In GitOps, the rollback process is often automated by changing the desired state to a previous version and allowing the reconciliation process to apply that state.

git revert is an example of a rollback operation in Git.

Resources:

GitOps Principles - 30%

Resources:

GitOps is a set of principles for operating and managing software systems. These principles are derived from modern software operations but are also rooted in pre-existing and widely adopted best practices.

The desired state of a GitOps managed system must be:

Declarative

A system managed by GitOps must have its desired state expressed declaratively.

Versioned and Immutable

Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.

Pulled Automatically

Software agents automatically pull the desired state declarations from the source.

Continuously Reconciled

Software agents continuously observe actual system state and attempt to apply the desired state.

Related Practices - 16%

Configuration as Code (CaC)

Configuration as Code (CaC) involves managing and provisioning infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. This practice enables developers and IT operations teams to automatically manage and provision their infrastructure using code. CaC is a key component of GitOps, as it allows for the desired state of infrastructure to be described declaratively and managed alongside application code.

Resources:

Infrastructure as Code (IaC)

Infrastructure as Code (IaC) is a key practice within DevOps that involves managing and provisioning computing infrastructure through code instead of through manual processes. With IaC, infrastructure is provisioned and managed using code and software development techniques, such as version control and continuous integration. IaC is foundational to GitOps, enabling the automatic, consistent deployment of infrastructure alongside applications.

Resources:

DevOps and DevSecOps

  • DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and provide continuous delivery with high software quality. GitOps can be seen as an evolution of DevOps principles, focused on using Git as a single source of truth for declarative infrastructure and applications.
  • DevSecOps extends DevOps by integrating security practices into the DevOps process, ensuring that security is built into the software development lifecycle. GitOps can be used to enforce security policies and best practices across the software development lifecycle.

Resources:

CI and CD

  • Continuous Integration (CI): The automated process of integrating code changes from multiple contributors into a shared repository. This process includes automated testing to validate code changes before they are merged, ensuring that the codebase remains stable and functional.
  • Continuous Delivery (CD): The practice of automating the software delivery process to ensure that code changes can be deployed to production at any time. GitOps can be used to automate the continuous delivery process, ensuring that the desired state of the system is always reflected in the production environment.

Resources:

GitOps Patterns - 20%

Deployment and Release Patterns

  • Recreate: This pattern involves tearing down the existing instances of an application before deploying the new version. While straightforward, the main drawback is the downtime between stopping the old version and starting the new version, making it less desirable for production environments that require high availability.
  • Rolling Updates: Kubernetes supports rolling updates natively, allowing updates to be applied incrementally without taking the service down. This strategy updates pods one by one, ensuring that a certain number of old and new pods are running simultaneously, which minimizes downtime and ensures that at least part of the application remains available during the update.
  • Blue-Green: Involves running two identical environments ("blue" for the current version and "green" for the new version) and switching traffic from blue to green once the new version is verified to be stable. This pattern is useful for minimizing downtime and risk during deployments.

Resources:

Progressive Delivery Patterns

  • Canary: This involves rolling out the change to a small subset of users or servers first, monitoring the performance and stability, and then gradually increasing the rollout to more users.
  • Shadow/Blue-Green Mirroring: This pattern involves deploying the new version alongside the old version in such a way that the new version processes real-world traffic in parallel without affecting the end-user experience, primarily for testing purposes.
  • A/B Testing/Traffic Splitting: Similar to canary releases but focuses more on comparing user behavior between the old and new versions to make data-driven decisions on feature adoption.

Resources:

Pull vs. Event-driven

Principle 3 specifies the desired state must be "pulled" rather than "pushed", primarily because the software agents must be able to access the desired state from the state store at any time, not only when there is an intentional change in the state store triggering a push event. This is a prerequisite for reconciliation to happen continuously, as specified in principle 4.

Note that – in contrast to traditional CI/CD, where automation is generally driven by pre-set triggers – in GitOps, reconciliation is triggered whenever there is a divergence. Divergence could be due to the actual state unintentionally drifting from the desired state declarations – not only due to a new desired state declaration version having been changed intentionally.

  • Pull-Based: Required for GitOps, agents within the cluster continuously monitor the Git repository for changes and apply updates automatically.

  • Event-Driven: While not the primary model in GitOps, event-driven mechanisms can complement GitOps by triggering actions based on specific events.

Resources:

Architecture Patterns (in-cluster and external reconciler, state store management, etc.)

  • In-Cluster Reconciler: A software agent that runs within the cluster and is responsible for monitoring the state of the cluster and applying the desired state.
  • External Reconciler: Similar to in-cluster reconcilers, but run outside the cluster, often used for multi-cluster management or for managing resources that are not directly accessible from within the cluster.
  • State Store Management: Structuring and managing the state store to ensure immutability, versioning, and complete version history.
  • Secrets Management: Managing secrets in a secure and compliant manner, often using tools like Vault, Sealed Secrets, or GitOps-specific solutions like KubeSecrets.

Resources:

Tooling - 14%

Manifest Format and Packaging

  • Kustomize: Offers a template-free way to customize application configuration that simplifies the declaration of application manifests for Kubernetes.
  • Helm: Provides packaging of Kubernetes applications into charts, making it easy to share and distribute a wide range of applications.
  • Declaritive YAML/JSON: A format for expressing the desired state of a system in a way that is both human-readable and machine-readable.

Resources:

State Store Systems (Git and alternatives)

  • Git: A distributed version control system that is widely used for source code management and is the canonical example of a state store used in GitOps.
  • OCI Registry: A container registry that is used to store and distribute container images.
  • S3: A scalable object storage service that is used to store and retrieve data.

Resources:

Reconciliation Engines (ArgoCD, Flux, and alternatives)

  • ArgoCD: A declarative, GitOps continuous delivery tool for Kubernetes.
  • Flux: A tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.
  • Jenkins X: An open-source system that provides pipeline automation, GitOps, and continuous delivery for cloud-native applications on Kubernetes.

Resources:

Interoperability with Notifications, Observability, and Continuous Integration Tools

  • DORA Metrics: Metrics that are used to measure the performance of software delivery and operational processes including:
    • Deployment Frequency: The frequency of deployments to production
    • Lead Time for Changes: The time it takes to go from code committed to code successfully running in production
    • Change Failure Rate: The percentage of changes that result in a failure in production
    • Time to Restore Service: The time it takes to restore service after a failure
  • Keptn: Integrates with Flux and ArgoCD to provide automated continuous delivery and operations for cloud-native applications.
  • Prometheus & Alertmanager: Used for monitoring and alerting, providing a rich set of metrics and alerting capabilities.
  • Jenkins: A popular open-source automation server used to automate the building, testing, and deployment of software.
  • Slack & Microsoft Teams: Popular messaging platforms used for notifications and collaboration.

Resources:

Additional Resources