Insomnia Technologies Edu

What is GitOps?

GitOps is an operational framework that takes DevOps best practices used for application development, such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation, basically. At its core, GitOps uses Git as the single source of truth for declarative infrastructure and applications, you know?

●
Declarative: The desired state of the system is described declaratively, honestly.
●
Versioned and Immutable: Desired state is stored in Git, providing a complete audit trail, basically.
●
Automated: Software agents automatically reconcile the desired state with the actual state, which is super handy.
●
Continuously Reconciled: The system constantly monitors for drift and corrects it automatically, trust me.

In a GitOps model, you never run kubectl apply manually in production, seriously. Every change is a Git commit, and the cluster autonomously pulls the changes, basically.

Push vs. Pull: Why ArgoCD?

Traditional CI/CD pipelines use a "push" model, where the CI server authenticates with the Kubernetes cluster and pushes changes, honestly. ArgoCD uses a "pull" model, which is fundamentally more secure and reliable for Kubernetes, you know?

Feature	Traditional Push CI/CD	GitOps Pull (ArgoCD)
Cluster Access	CI server needs cluster credentials	Cluster pulls from Git (no inbound access needed)
State Drift	Undetected until next deployment	Continuously monitored and auto-corrected, basically
Audit Trail	Relies on CI/CD logs	Native Git commit history
Rollbacks	Requires complex pipeline re-runs	Simple `git revert` and auto-sync, which is huge
Security Posture	High risk (broad CI credentials)	Low risk (cluster initiates outbound connections)

Installing ArgoCD

Getting started with ArgoCD is straightforward, honestly. The recommended approach is to install it into a dedicated namespace using the official manifests, basically.

install-argocd.sh

bash

              # Create a dedicated namespace
kubectl create namespace argocd

# Install ArgoCD using official manifests
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Verify the installation
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server

# Expose the ArgoCD server (for local testing)
kubectl port-forward svc/argocd-server -n argocd 8080:443

💡 Initial Password Retrieval

The initial password for the admin account is auto-generated and stored in a secret, seriously. Retrieve it using: kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d, basically.

Deploying Your First Application

In ArgoCD, an "Application" is a custom resource that defines the connection between a Git repository and a target Kubernetes cluster/namespace, you know?

argocd-application.yaml

yaml

              apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Notice the syncPolicy block, honestly. By enabling automated, prune, and selfHeal, ArgoCD will automatically apply changes from Git, remove resources deleted from Git, and revert any manual changes made directly to the cluster, which is a huge win, basically.

Production Best Practices

Running ArgoCD in production requires careful planning around security, scalability, and operational hygiene, seriously.

●
Use App of Apps Pattern: Manage multiple applications by having a root application that deploys other applications, you know?
●
Enforce RBAC: Integrate with OIDC/SAML (e.g., GitHub, Okta) and define strict role-based access controls, basically.
●
Separate Clusters: Use different ArgoCD instances or projects for dev, staging, and production environments, honestly.
●
Disable Auto-Sync for Prod: Consider requiring manual approval for production syncs, even if staging is fully automated, trust me.
●
Monitor ArgoCD: Scrape ArgoCD metrics with Prometheus and set up alerts for sync failures, which is super important.

"The goal of GitOps is not just automation, but observability and reliability, honestly. If you can't trace a cluster state back to a specific Git commit, you aren't doing GitOps, basically."
— Weaveworks GitOps Principles

Handling Secrets in a GitOps Workflow

Storing plaintext secrets in Git violates basic security principles, seriously. To maintain the GitOps model while keeping credentials safe, you must encrypt secrets before they reach the repository, you know?

sealed-secrets-example.sh

bash

              # 1. Install kubeseal CLI
brew install kubeseal

# 2. Encrypt a standard Kubernetes secret
kubectl create secret generic db-password \
  --from-literal=password='SuperSecret123' \
  --dry-run=client -o yaml | kubeseal \
  --controller-name=sealed-secrets \
  --controller-namespace=kube-system \
  -o yaml > sealed-secret.yaml

# 3. Commit 'sealed-secret.yaml' to Git safely

💡 Alternative: External Secrets Operator

Instead of encrypting secrets in Git, you can store them in AWS Secrets Manager or HashiCorp Vault, and use the External Secrets Operator to fetch and inject them into the cluster dynamically, basically.

Frequently Asked Questions

Can ArgoCD deploy Helm charts?

Yes, honestly. ArgoCD has native support for Helm. You can point the `source.path` to a Helm chart directory or use a Helm repository URL directly in the `source.repoURL`, basically.

What happens if the Git repository goes down?

ArgoCD caches the last known state, you know? It will continue to function and can still perform self-healing based on the cached state, though new deployments will be blocked until the repository is restored, which makes sense.

How do I handle database migrations in GitOps?

Database migrations should be handled by CI/CD pipelines (push model) or specialized operators (like ArgoCD Resource Hooks with pre-sync jobs), not by the standard GitOps sync process, seriously. This ensures precise execution order, basically.

Does ArgoCD replace Jenkins or GitHub Actions?

No, honestly. CI tools (Jenkins, GitHub Actions) are still needed to build artifacts, run tests, and push images to a registry. ArgoCD handles the CD (Continuous Deployment) portion by pulling those validated artifacts into the cluster, you know?

Conclusion

Adopting GitOps with ArgoCD transforms how you manage Kubernetes infrastructure, basically. By shifting from imperative, manual interventions to a declarative, automated, and auditable workflow, you significantly reduce the risk of human error and configuration drift, which is a mess to deal with otherwise.

Start small: implement ArgoCD for a non-critical staging environment, establish your Git repository structure, and gradually enforce stricter sync policies as your team becomes comfortable with the paradigm, honestly. The investment in learning GitOps pays exponential dividends in cluster stability and developer velocity, trust me.

Next Step: Explore the "App of Apps" pattern to scale your ArgoCD deployment across multiple microservices and environments, basically.