GitOps, Argo, and Azure Kubernetes Service - Part 1

First, what is GitOps? Is it the same as DevOps?
DevOps is the union of people, process, and products to enable the continuous delivery of value to our end users.
GitOps is different than DevOps because it focuses specifically on practices designed to improve infrastructure and application configuration management using Git.

GitOps builds on DevOps with Git as a single source of truth for the
desired state of the system

• The entire system state is under version control and described in Git (trunk best)
• Operational changes on production clusters are made by pull request
• Rollback and audit logs are provided via Git
• When disaster strikes, the whole infrastructure can be quickly restored from Git

Why Gitops?

• Audit trail of deployments
• Limit access to clusters
• Make Disaster Recovery an unpainful event
  

Second, what is Argo?
Argo is a declarative GitOps continuous delivery tool specifically designed for Kubernetes. Argo relies on Git to be the "source of truth" for defining everything you want for your application state; essentially, you are declaring the state of the world you want for your application, and Argo will either ensure it is that way, or alert you if it is not that way (I.E. out of sync).

Features:

• Automated deployment of applications to specified target environments
• Support for multiple config management/templating tools (Kustomize, Helm, Ksonnet, Jsonnot, plain- YAML)
• Ability to manage and deploy to multiple clusters
• SSO Integration (OIDC, OAuth2, LDAP, SAML 2.0, GitHub, Gitlab, Microsoft)
• Multi-tenancy and RBAC policies for authorization
• Rollback/Roll-anywhere to any application configuration committed in Git repository
• Health status analysis of application resources
• Automated configuration drift detection and visualization
• Automated or manual syncing of applications to its desired state
• WebUl which provides real-time view of application activity
• CLI for automation and Cl integration
• Wobhook integration (GitHub, BitBucket, Gitlab)
• Access tokens for automation
• PreSync, Sync, PostSync hooks to support complex application rollouts
  (e.g.blue/green & canary upgrades)
• Audit trails for application events and APl calls
• Prometheus metrics

Why you should not use kubectl to manage Kubernetes cluster?!

• Ci/CD needs write access to your clusters
• How to track rollout failures?
• No audit trail of the Kubernetes resources
• No single source of truth of the state in the cluster
• It's imperative. It should be declarative.

I will explain take you now though a simple demo on how to setup ArgoCD with Azure Devops and AKS

Note: I already have ASK cluster setup on my azure subscription

Demo Steps:
1- Create manifest/yaml deployment file and store them in Azure Devops repos

deployment.yaml
----------------------
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azureheroes
spec:
  selector:
    matchLabels:
      app: azureheroes
  replicas: 4
  template:
    metadata:
      labels:
        app: azureheroes
    spec:
      containers:
      - name: azureheroes
        image: hello-world
        ports:
        - containerPort: 8090

service.yaml
----------------------
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: mazureheroesyapp
  ports:
  - port: 8090
    protocol: TCP
    targetPort: 8090

2-Install ArgoCD with Application "CRD"
2.1-let’s create a namespace for Argo CD to deploy all of its components in. To do this run:

• kubectl create namespace argocd
  

2.2- Next we can install Argo CD into the new namespace we created. We will reference Argo CD’s repository for the latest Argo CD operator

• kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yamlYou should see the following:
  

You should end up with many objects in the Argo CD namespace.

2.2 - now, in order to access ArgoCD CP from the UI, you have to expose/publish the servcie, hence I will change the ArgoCD-Server from ClusterIP to LoadBalancer

by running the following command:

• kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
  
• kubectl get services --namespace argocd argocd-server --output jsonpath='{.status.loadBalancer.ingress[0].ip}'
  

NOTE: This is not recommended in production environments. Only use in a dev/test environments. In production environments, it is recommended to use an ingress for the Argo CD API server that is secured.

2.3- now, let's open the UI
username: admin
password: run this command since Argo CD auto generated a password during the deployment

• kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo
  

That’s it! You have Argo CD deployed on your AKS cluster. In the next post, I will walk through deploying a simple app to your Kubernetes cluster via Argo CD.