GitOps with ArgoCD-sneakPeak

Gitops: A way of implementing Continuous Deployment for cloud native applications

Photo by Yancy Min on Unsplash

At the very core sits the git repository that contains declarative descriptions of the infra we desire and an automated process to make the environment match the described / desired state in the repository

There are two ways to implement the deployment strategy for GitOps: Push-based and Pull-based deployments, When possible, the Pull-based approach should be preferred as it is considered the more secure {the creds are not passed outside of the system} and thus better practice to implement GitOps.

Photo by Hunters Race on Unsplash

This is where ArgoCD comes in play which extends kubernetes using CRD’s, It ensures that the repository and the environment are always in sync, It also can make use of Kustomize and Helm for application templating.

SetUp

Lets get started and have a go at setting it up in our K8s Cluster

Assumption: To simplify the understanding process lets take the bare minimum resource to setup, i.e an application Pod {using a deployment } in each environment which to make it easy are separate namespaces in the same cluster { this is definitely not something we shall do with real environments } so in the same repository we have 3 folders representing 3 env’s and each has a deployment yaml which publishes an nginx container. A bare minimum nginx deployment given below for dev env, lets look at dev.. similar would be for other env’s respectively. I am also assuming you have minikube or something similar to set this up on and that you are using a mac

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-app-1-deployment
  labels:
    app: dev-app-1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dev-app-1
  template:
    metadata:
      labels:
        app: dev-app-1
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80

once we have this in place, follow through the next steps to get ArgoCD in place and login to the cli and the UI respectively

— 1: install argocd cli
— brew tap argoproj/tap
— brew install argoproj/tap/argocd

- 2: install argocd CRD within your cluster
— 2a: create Namespace for ArgoCD: kubectl create namespace argocd
— 2b: kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

— 2c: get the password from the secret: kubectl get secret argocd-initial-admin-secret -o yaml and base64 — decode it
— 2d: port forward the svc: kubectl port-forward svc/argocd-server -n argocd 8080:443
— 2d: login into argocd: argocd login — insecure — username admin — password $PASS {the password fetched in step 2c}— grpc-web localhost:8080
— 2e: Change password: argocd account update-password
— 2f: you can login via ui using your new password

at this point you would have logged into the UI and would see a page similar to below

Next would be to set up the project and the application, the project helps define the link between the source being the repositories and destination being specific namespaces and the resources which can be created using this project, below we are giving access to all repositories by setting it to “*”, since the application will sit in the same cluster where the project is we set the server value to “https://kubernetes.default.svc”

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: development
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: development project
  sourceRepos:
    - "*"
  destinations:
    - namespace: development
      server: https://kubernetes.default.svc
    - namespace: argocd
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: ""
      kind: Namespace
  namespaceResourceBlacklist:
    - group: ""
      kind: ResourceQuota
    - group: ""
      kind: LimitRange
    - group: ""
      kind: NetworkPolicy
  namespaceResourceWhitelist:
    - group: "apps"
      kind: Deployment
    - group: "apps"
      kind: StatefulSet
    - group: "extensions/v1beta1"
      kind: Ingress
    - group: "v1"
      kind: Service
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: development
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: development
  source:
    repoURL: https://github.com/{{orgName}}/argo.git
    targetRevision: HEAD
    path: argocd/theApps/dev/
  destination:
    server: https://kubernetes.default.svc
    namespace: development
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

you also get to see the full repo name which i have removed

we can also dig deeper into each application or project

Configuration drift is quite a problem, as the longer it persists, the more critical it becomes. Teams that don’t know what exactly is deployed on a cluster, or multiple clusters, can have many issues with failed deployments

Argo CD has a very smart way to solve the configuration drift problem. After the initial deployment takes place, Argo CD continuously monitors the cluster and compares it to git.

so now on every time we make a change to the repository it will get synced with the cluster and vice versa, if we manually make any changes to the cluster resources which are part of the repository ArgoCD will sync the changes to back to what they are in the repo.

While the UI and the feature list is quite extensive, as the name suggest this was just a sneak peak into doing GitOps with ArgoCD