Skip to content

deep-dive.md

Latest commit

 

History

History
119 lines (78 loc) · 4.26 KB

deep-dive.md

File metadata and controls

119 lines (78 loc) · 4.26 KB
title GitOps Full Loop: Deep Dive
description GitOps architecture patterns using the two-repo model, Tekton and ArgoCD integration, and production considerations for end-to-end pipelines
sidebar
label order
GitOps Full Loop (Deep Dive)
37
category real-world

GitOps Full Loop - Deep Dive

Overview

GitOps is an operational framework that uses Git as the single source of truth for infrastructure and application configuration. This document covers the architecture patterns, tool integration, and production considerations for a Tekton + ArgoCD pipeline.

The Two-Repo Model

Source Repository

Contains application code: source files, tests, Containerfile. Tekton watches this repo for changes. When a developer pushes, Tekton runs the CI pipeline: lint, test, build image, push image.

Config Repository

Contains Kubernetes manifests: Deployments, Services, ConfigMaps. ArgoCD watches this repo. When the manifests change (typically because Tekton updated an image tag), ArgoCD syncs the cluster to match.

Why Two Repos?

  • Separation of concerns: Application developers own the source repo, platform teams own the config repo
  • Audit trail: Every deployment is a Git commit with author, timestamp, and diff
  • Rollback: Reverting a deployment is just git revert on the config repo
  • Security: CI credentials (for building) stay separate from CD credentials (for deploying)

How Tekton and ArgoCD Connect

The handoff point is simple: Tekton's last pipeline task updates the image tag in the config repo and pushes the commit. ArgoCD detects the new commit and syncs.

Tekton Pipeline
  Task 1: Clone source, run tests
  Task 2: Build image, push to registry
  Task 3: Clone config repo, update image tag, push  <-- handoff
                                                            |
ArgoCD                                                      v
  Detects new commit in config repo
  Compares desired state (Git) vs live state (cluster)
  Applies the diff (kubectl apply)

There is no direct API call between Tekton and ArgoCD. Git is the interface.

ArgoCD Sync Policies

Manual Sync

ArgoCD detects drift but waits for a human to click "Sync". Good for production environments where you want manual approval gates.

Automated Sync

ArgoCD syncs automatically when it detects drift. This demo uses automated sync for simplicity.

Options:

  • prune: Delete resources that exist in the cluster but not in Git
  • selfHeal: Revert manual changes made directly to the cluster

Sync Waves

For ordered deployments (database before app), use sync wave annotations:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"  # lower numbers sync first

Tekton Triggers

In production, you would add Tekton Triggers to automatically start pipelines on Git events:

  1. EventListener: Receives webhooks from GitHub/GitLab
  2. TriggerBinding: Extracts parameters from the webhook payload (repo URL, commit SHA)
  3. TriggerTemplate: Creates a PipelineRun with those parameters

Image Promotion Strategy

A common pattern for multiple environments:

Source Push -> Build -> dev (auto-deploy)
                    -> staging (auto-deploy after dev passes)
                    -> production (manual approval)

Each environment has its own directory in the config repo with its own image tag. Tekton updates dev first, and promotion to staging/production happens through additional pipeline tasks or manual commits.

Production Considerations

Secrets Management

  • Use Sealed Secrets or External Secrets Operator to store secrets in Git safely
  • Never commit plain-text secrets to the config repo

Multi-Cluster

ArgoCD can manage multiple clusters from a single control plane. Define each cluster as a destination in the Application spec.

Notifications

Configure ArgoCD notifications to send Slack/email alerts on sync success, failure, or health degradation.

RBAC

Both Tekton and ArgoCD support fine-grained RBAC. Limit who can create PipelineRuns and who can sync Applications.

Further Resources