DEV Community: Ayush Sharma

Getting started with ArgoCD

Ayush Sharma — Mon, 16 Aug 2021 14:40:06 +0000

In a typical push-based deployment, tools like Ansible, Jenkins, etc., connect directly to the server or cluster and execute the provisioning commands. This approach works well when the cluster is accessible on the network, and there is direct connectivity between our deployment server and the destination server. For compliance or security reasons, connectivity between the deployment tool and the cluster may not be possible.

ArgoCD is a pull-based deployment tool. It watches a remote Git repository for new or updated Manifest files and synchronises those changes with the cluster. By managing Manifests in Git and syncing them with the cluster, we get all of the advantages of a Git-based workflow (version control, pull-request reviews, transparency in collaboration, etc.) and a one-to-one mapping between what is in the Git repo and what is deployed in the cluster. This method is called GitOps.

In this tutorial, I'm going to do the following:

Install ArgoCD on a Minikube installation.
Create a sample ArgoCD application called ayush-test-application and link it with my repo ayush-sharma/example-assets.
Create and Nginx deployment with 3 replicas.
Ensure the new application shows up on the ArgoCD dashboard and verify it using kubectl.

Installing ArgoCD

For this tutorial, I'm using Minikube version: v1.21.0. You can download and install Minikube from here.

With Minikube up and running, we're going to install ArgoCD. The ArgoCD documentation contains detailed steps on how to install and configure it for any cluster. Once you've executed those steps, make sure to run minikube tunnel in a separate terminal window to ensure Minikube exposes the ArgoCD Server's load balancer endpoint on your local system. To verify this, run kubectl get po -n argocd and check if the argo-server service has an EXTERNAL-IP:

user@system ~ kubectl get svc -n argocd
NAME                    TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
argocd-dex-server       ClusterIP      10.110.2.52     <none>          5556/TCP,5557/TCP,5558/TCP   3h32m
argocd-metrics          ClusterIP      10.100.73.57    <none>          8082/TCP                     3h32m
argocd-redis            ClusterIP      10.104.11.24    <none>          6379/TCP                     3h32m
argocd-repo-server      ClusterIP      10.100.132.53   <none>          8081/TCP,8084/TCP            3h32m
argocd-server           LoadBalancer   10.98.182.198   10.98.182.198   80:32746/TCP,443:31353/TCP   3h32m
argocd-server-metrics   ClusterIP      10.105.182.52   <none>          8083/TCP                     3h32m

Once the installation is complete and the load balanacer is working, the ArgoCD UI will be accessible at the EXTERNAL IP.

Creating the first application

Before we can talk about ArgoCD deployments we need to ensure that a Git repo with a K8s manifest file ready to deploy. I'm using my public repo example-assets with an Nginx deployment manifest file in /argocd/getting-started.

Our goal is to get ArgoCD to listen to the K8s manifest file above for changes and then sync them with the cluster it is deployed in, in this case, Minikube. We do this by creating an Application containing information about the Manifest files' source repo, destination cluster details, and synchronisation policies.

Click New App on the top left to configure a new Application. Since my destination Kubernetes server is the one ArgoCD is installed on (Minikube), I will leave the server defaults as-is. These are the values I configured:

Application Name: ayush-test-application
Project: default
Sync Policy: automated
Sync Options: prune: true; selfHeal: true
Source Repository URL: https://gitlab.com/ayush-sharma/example-assets.git
Source Revision: HEAD
Source Path: argocd/getting-started
Destination Cluster URL: https://kubernetes.default.svc
Destination Namespace: default

To make things easier, you can click EDIT AS YAML on the top-right and paste the following:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ayush-test-application
spec:
  destination:
    name: 'default'
    namespace: default
    server: 'https://kubernetes.default.svc'
  source:
    path: argocd/getting-started
    repoURL: 'https://gitlab.com/ayush-sharma/example-assets.git'
    targetRevision: HEAD
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Your configuration should look like this:

After saving the configuration, your Application should show up as a card on the home page. Since we specified the sync policy as Automated our new Application will begin syncing with the repo immediately.

Creating the Nginx deployment

In this tutorial, my manifest file is a standard Nginx deployment with 3 replicas. Once ayush-test-application completes syncing, ArgoCD will display a nice graphical view of the deployment.

Now let me verify the deployment using kubectl get po:

NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-585449566-584cj   1/1     Running   0          5m
nginx-deployment-585449566-6qn2z   1/1     Running   0          5m
nginx-deployment-585449566-d9fm2   1/1     Running   0          5m

Conclusion

ArgoCD is a relatively light-weight and more secure approach to K8s deployments. I'm especially fond of the one-to-one relationship between what's in the repo and what's in the cluster making incident management a lot simpler.

Another big advantage is that since our Git repo contains everything ArgoCD requires, we could delete the entire ArgoCD installation and set things up from scratch. Meaning that bringing up a second identical cluster with all our workload deployed is now more feasible and practical in the event of a catastrophic outage.

A third big advantage is security: since ArgoCD pulls changes from a remote Git repo, there is no need to define firewall rules and VPC peering connections to get our deployment servers to connect with our cluster, which is one less point of entry. This reduces the attack surface area for our dev/QA/prod servers significantly.

Since the Git repo and branch name is configurable, you can get creative with deployment models. For example, you could have 2 different ArgoCDs running on 2 different QA and prod clusters listening to the same repo's branch. This guarantees that the same Manifest file is deployed on both clusters, ensuring QA and prod environments contain the same codebase. Also, a single ArgoCD is capable of targeting multiple servers, meaning a hub-and-spoke deployment model is possible, where one Master ArgoCD orchestrates deployments across multiple dev, QA, and prod clusters in different regions/environments.

I hope this tutorial was informative. Get creative with ArgoCD, and don't forget to share your experiments with others.

Happy coding :)

5 key best practices for sane and usable Terraform setups

Ayush Sharma — Wed, 14 Jul 2021 00:00:00 +0000

Working with Terraform for over five years has taught me some key lessons. 5 practices have been critical to having a sane and usable Terraform setup regardless of the size of the team or the nature of the project.

1. Know your target audience.

This one might seem obvious, but I’ve seen it go wrong several times. When organising Terraform code, either standardising the directory structure or defining naming conventions, it’s vital to consider the intended audience. Will your team be using these Terraform scripts and modules? Are you handing the work over to another team? Will new people be joining your team sooner or later? Are you working on this project solo? Will you be using this setup in 6 months or a year, or will it be assigned to someone else?

Questions like these will affect several decisions. Ideally, you should have Remote State and State Locking in place regardless of the team size now or in the future. Remote State will ensure your laptop is not the only place your Terraform works and State Locking will ensure that only one person at a time is changing the infrastructure.

The naming convention should make sense to the eventual owners of the project, not just the team that is writing the code. If the project is for another team, make sure they have a say in the naming convention. If non-technical stakeholders or internal security/GCR teams review the code, make sure they check the naming convention. In addition to resource names, you should leverage resource tags to highlight any data classification/privacy requirements (high, medium, low) for more careful examination by reviewers.

2. Reuse. Reuse. Reuse.

The Terraform Registry provides a library of ready-to-use modules for the most common use-cases. I’ve written about the extensive parameterisation available in the VPC module and security groups. Simply calling modules with different parameters will be enough to handle most, if not all, potential use-cases. Reuse these shared modules as much as possible to avoid useless typing/testing/checking/fixing/refactoring.

I’ve also found that separating modules and resources based on the frequency of use or change is beneficial. For example, infrastructure scaffolding used only once belongs together, such as setting up the VPC, security groups, routing tables, VPC endpoints, etc. But things like private hosted zone entries, autoscaling groups, target groups, load balancers, etc., might change with every deployment, so separating these from the one-time scaffolding will make code reviews easier and debugging faster.

3. Explicit rather than implicit.

Terraform code often contains incorrect assumptions baked into it. Teams assume that the Terraform version used to write the code today will never change, or the external modules won’t change, or the providers they are using won’t change. These lead to invisible issues a few weeks down the road when these external dependencies inevitably get updated.

Ensure you are explicitly defining versions everywhere possible: in the main Terraform block, in the provider block, in the module block, etc. Defining versions will ensure that your dependent libraries stay frozen so that you can explicitly update dependencies when required after thorough discussions, reviews, and testing.

4. Automate everywhere. Your laptop. Your shared VM. Your CI/CD.

Leveraging automation at every stage of the deployment process can avoid future problems before they even arise.

Use Git pre-commit hooks to run terraform fmt and terraform validate before you commit your code. Pre-commit hooks ensure that code is, at a bare minimum, adequately formatted and syntactically correct. Check-in this pre-commit file to the repo, and everyone on your team can benefit from the same automation. This small but vital quality control at the first step of the process can achieve substantial time savings as your project progresses.

All modern deployment tools have CI processes. You can use these to run SAST and unit testing tools when pushing your code to origin. I’ve written about how Checkov can test Terraform code for security and compliance and create custom checks for organisation-specific conventions. Add these unit testing tools to your CI pipeline to improve code quality and robustness.

5. Have an awesome README.md!

We all like to think that Terraform code is self-documenting. Sure it is, but only if your future team already knows your company’s naming conventions and guidelines and secret handshakes and inside jokes and whatever else your repo contains besides valid Terraform code. Getting into the habit of having a good README.md can be a huge time saver, and it will keep your team honest by holding them accountable for everything explicitly committed to in the README.

At a minimum, your README should contain the steps to initialise the right Terraform environment on your workstations (Mac, Windows, Linux, etc.), including the Terraform version to install. It should specify the required dependencies (Checkov, TerraGrunt, etc.) with versions and any handy Linux aliases your team uses (some people like to define tff as a short-hand for terraform fmt). Most importantly, the branching and PR review strategy/process, the naming conventions, and the resource tagging standards should be specified.

The README should pass a simple test: if a new member joins your team tomorrow, is the README enough to teach them what to do and how to do it correctly? If not, you may find youself hosting never-ending standards and process meetings repeatedly for the next few months.

Automating ArgoCD using ArgoCD!

Ayush Sharma — Wed, 07 Jul 2021 00:00:00 +0000

We have already seen how ArgoCD makes pull-based GitOps deployments simple. In this tutorial, I’ll show you how to automatically create multiple Applications in ArgoCD using ArgoCD!

Since ArgoCD’s job is to listen to a repo and apply the Manifest files it finds to the cluster, we can use this approach to configure ArgoCD internals as well. In our last example, we used the GUI to create a sample Nginx application with three replicas. We will use the same approach as before. But this time, we will create an Application from the GUI, which will deploy three separate applications - app-1, app-2, and app-3.

Configuring our child applications

Let’s start by creating the Manifest files for our three applications. In my example-assets repository, I have created three applications under argocd/my-apps. All three applications are Nginx with three replicas. Remember to create each application in its own folder.

This is my-apps/app-1/app.yml:

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

This is my-apps/app-2/app.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app-2
  labels:
    app: nginx-app-2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-app-2
  template:
    metadata:
      labels:
        app: nginx-app-2
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

And this is my-apps/app-3/app.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app-3
  labels:
    app: nginx-app-3
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-app-3
  template:
    metadata:
      labels:
        app: nginx-app-3
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Now that our Manifest files are ready, we need to create ArgoCD Applications to point to those Manifests.

ArgoCD can be configured in three different ways: using the GUI, using the CLI, or using Kubernetes Manifest files. We will use the third method.

Create the following Manifest files in a new folder argocd/argo-apps.

This is argocd-apps/app-1.yml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-1
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: argocd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: argocd/my-apps/app-1
    repoURL: https://gitlab.com/ayush-sharma/example-assets.git
    targetRevision: HEAD

This is argocd-apps/app-2.yml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-2
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: argocd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: argocd/my-apps/app-2
    repoURL: https://gitlab.com/ayush-sharma/example-assets.git
    targetRevision: HEAD

And this is argocd-apps/app-3.yml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-3
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: argocd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: argocd/my-apps/app-3
    repoURL: https://gitlab.com/ayush-sharma/example-assets.git
    targetRevision: HEAD

As you can see, we are creating a Kubernetes object called Application in the argocd namespace. This object contains the source Git repository and destination server details. Our Applications are pointing to the Nginx manifest files we created earlier.

Configuring our main application

Now we need some way to tell ArgoCD how to find our three Nginx applications. We do this by creating yet another Application! This pattern is called the App of Apps pattern, where one Application contains the instructions to deploy multiple child Applications.

Create a new Application from the GUI called my-apps with the following configuration:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-apps
spec:
  destination:
    namespace: default
    server: 'https://kubernetes.default.svc'
  source:
    path: argocd/argocd-apps
    repoURL: 'https://gitlab.com/ayush-sharma/example-assets.git'
    targetRevision: HEAD
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

After creation, my-apps will begin syncing on the GUI:

After the sync is complete, our three Nginx applications will appear on the GUI as well:

Since we did not enable AutoSync, manually sync app-1, app-2, and app-3. Once synced, our Nginx replicas will be deployed for all three apps.

Conclusion

Mastering the App of Apps pattern is critical to leveraging the full power of ArgoCD. This method allows us to manage groups of applications cleanly. For example, deploying Prometheus, Grafana, Loki, etc., could be managed by a DevOps Application, whereas deploying frontend code could be managed by a Frontend Application. Configuring different sync options and repo locations for each allows more granular control over different application groups.

Happy coding :)