GitOps Principles

What is GitOps?

GitOps is an operational framework that applies DevOps best practices used for application development (version control, collaboration, CI/CD) to infrastructure automation.

Declarative

Infrastructure is described declaratively in Git

Versioned

All changes are tracked with full audit history

Automated

Changes are automatically applied to infrastructure

Auditable

Complete history of who changed what and when

Core Principles

1. Declarative Configuration

Infrastructure is defined in a declarative way, describing the desired state rather than imperative steps.

clusters/production.yaml

apiVersion: v1
kind: Cluster
metadata:
  name: production
  region: PHX1
spec:
  provider: civo
  nodes:
    - g4s.kube.large
    - g4s.kube.large
    - g4s.kube.large

Note

The system reads this desired state and makes it happen, rather than you manually executing commands.

2. Version Controlled

All infrastructure definitions are stored in Git repositories, providing:

Change History

Every change is tracked with commit messages:

git log clusters/production.yaml

See who made changes, when, and why.

Rollback Capability

Easily revert to previous states:

git revert HEAD
hyve reconcile

The infrastructure returns to the previous configuration.

Collaboration

Multiple team members can propose changes:

# Create feature branch
git checkout -b add-monitoring-cluster

# Add cluster definition
hyve cluster add monitoring --provider civo --region NYC1

# Create pull request for review
git push origin add-monitoring-cluster

Audit Trail

Complete history of infrastructure changes:

git log --oneline clusters/
# 387184b Add monitoring cluster
# 40e1298 Scale production to 3 nodes
# 0f395fc Update development region

3. Automated Synchronization

Changes in Git automatically reconcile to the infrastructure:

# Make change in Git
hyve cluster add new-cluster --provider civo --region PHX1

# Commit the change
git add clusters/new-cluster.yaml
git commit -m "Add new cluster"

# Reconcile applies the change
hyve reconcile

4. Single Source of Truth

Git repositories are the single source of truth for infrastructure state:

Define in Git

All cluster definitions exist in Git repositories

~/.hyve/repositories/production/clusters/
├── production.yaml
├── staging.yaml
└── development.yaml

Commit Changes

Changes are committed to version control

git add clusters/production.yaml
git commit -m "Scale production cluster"

Reconcile State

Hyve ensures cloud matches Git

hyve reconcile
# Creates, updates, or deletes resources to match Git

GitOps Workflow with Hyve

Traditional Approach (Imperative)

# Manual commands without version control
civo kubernetes create production --nodes 3 --size g4s.kube.large
civo kubernetes scale production --nodes 5
civo kubernetes delete staging

# No history, no audit trail, no collaboration

Caution

Imperative approaches lack traceability and make it hard to understand the current state.

GitOps Approach (Declarative)

# 1. Define desired state in Git
hyve cluster add production --provider civo --region PHX1 --nodes g4s.kube.large,g4s.kube.large,g4s.kube.large

# 2. Review the generated YAML
cat ~/.hyve/repositories/production/clusters/production.yaml

# 3. Commit to Git
git add clusters/production.yaml
git commit -m "Add production cluster with 3 nodes"

# 4. Reconcile applies changes
hyve reconcile

# 5. Make changes by editing YAML
# Edit clusters/production.yaml to add more nodes

# 6. Commit and reconcile
git commit -am "Scale production to 5 nodes"
hyve reconcile

Note

Every change is tracked, reviewed, and auditable. Infrastructure evolves with clear history.

Benefits of GitOps

Increased Velocity

Faster deployments with automation and standardization

Enhanced Stability

Reduced errors through declarative configurations and automated validation

Better Collaboration

Team members review changes via pull requests before deployment

Improved Security

All changes tracked with audit trails and approval workflows

Easy Rollbacks

Instant rollback to any previous state using Git history

Disaster Recovery

Entire infrastructure can be recreated from Git repository

Hyve’s GitOps Implementation

Multi-Repository Support

Separate repositories for different environments:

# Production repository
hyve git add production --repo-url https://github.com/company/hyve-prod.git

# Staging repository
hyve git add staging --repo-url https://github.com/company/hyve-staging.git

# Development repository
hyve git add development --repo-url https://github.com/company/hyve-dev.git

Each repository maintains:

• Cluster definitions (clusters/)
• Workflow definitions (workflows/)
• Template definitions (templates/)

Reconciliation

Hyve continuously ensures cloud infrastructure matches Git:

# Manual reconciliation
hyve reconcile

# Reconcile specific cluster
hyve reconcile --cluster production

# Dry run (preview changes)
hyve reconcile --dry-run

Workflow Automation

Automated deployment pipelines defined in Git:

workflows/deploy-app.yaml

apiVersion: v1
kind: Workflow
metadata:
  name: deploy-app
spec:
  requirements:
    tools:
      - name: kubectl
        version: "1.28"
  jobs:
    - name: deploy
      steps:
        - name: apply-manifests
          command: kubectl apply -f manifests/

GitOps Best Practices

1. Use Descriptive Commit Messages

Write clear commit messages explaining why changes were made:

# Good
git commit -m "Scale production cluster for increased load during holiday season"

# Bad
git commit -m "Update cluster"

2. Review Changes via Pull Requests

Always use pull requests for production changes:

# Create feature branch
git checkout -b scale-production

# Make changes
hyve cluster add production --provider civo --region NYC1 --nodes g4s.kube.large,g4s.kube.large,g4s.kube.large

# Commit and push
git commit -am "Scale production cluster to 3 nodes"
git push origin scale-production

# Create PR for team review

3. Separate Environments

Use different repositories for different environments:

# Production
hyve git add production --repo-url https://github.com/company/hyve-prod.git

# Staging
hyve git add staging --repo-url https://github.com/company/hyve-staging.git

4. Automate Reconciliation

Set up automated reconciliation in CI/CD:

# In CI/CD pipeline
hyve reconcile --cluster production

5. Test Changes in Development First

Always test changes in development before production:

# Switch to development
hyve git use development

# Test changes
hyve cluster add test-cluster --provider civo --region PHX1
hyve reconcile

# Verify it works, then apply to production
hyve git use production
hyve cluster add production-cluster --provider civo --region NYC1

GitOps vs Traditional

Aspect	Traditional	GitOps
State Storage	Cloud console / CLI	Git repository
Change Method	Manual commands	Git commits
Audit Trail	Limited / None	Complete Git history
Rollback	Manual / Difficult	git revert
Collaboration	Shared credentials	Pull requests
Automation	Custom scripts	Declarative workflows
Security	Risky	Audited & reviewed

Real-World Example

Scenario: Scale Production Cluster

Traditional Approach

# Developer runs command manually
civo kubernetes scale production --nodes 5

# Problems:
# - No record of who made the change
# - No explanation of why
# - No review process
# - Hard to rollback
# - Team members unaware

GitOps Approach

# 1. Developer creates branch
git checkout -b scale-production

# 2. Updates cluster definition
# Edit clusters/production.yaml to add nodes

# 3. Commits with explanation
git commit -am "Scale production to 5 nodes for holiday traffic spike"

# 4. Creates pull request
git push origin scale-production

# 5. Team reviews and approves
# PR shows exact changes, team discusses

# 6. Merge triggers reconciliation
git checkout main
git merge scale-production
hyve reconcile

# Benefits:
# ✅ Full audit trail
# ✅ Team awareness
# ✅ Review process
# ✅ Easy rollback (git revert)
# ✅ Documented reasoning

Disaster Recovery

With GitOps, recovering from disasters is straightforward:

Clone Repository

git clone https://github.com/company/hyve-prod.git
cd hyve-prod

Configure Hyve

hyve git add production --repo-url https://github.com/company/hyve-prod.git
# Authenticate with the Civo CLI (writes ~/.civo.json)
civo apikey save my-token YOUR_CIVO_TOKEN && civo apikey use my-token

Reconcile Infrastructure

hyve reconcile
# Recreates all clusters from Git definitions

Note

Entire infrastructure is recreated exactly as defined in Git, ensuring consistency and reliability.

Related

Repositories

Multi-repository management

Clusters

Cluster definitions and lifecycle

Git Management

Working with Git repositories

Reconciliation

Understanding reconciliation