Getting Started with Deploying Applications to Argocd: A Beginner’s Guide (Part 2)

Let’s talk about using the Application resource in Kubernetes. It’s a powerful way to manage applications and deployment to ArgoCD.

Remember that post we talked about earlier at:

Getting Started with Deploying Applications to Kubernetes: A Beginner’s Guide for Local…

Well, now we’re going to create some apps using Application in ArgoCD.

But before we get into that, we need to set up our kind cluster. Don't sweat it though, it's easy, just check out this post at:

Configuring Local Ingress Domains for your Kind Cluster with MetalLB, Dnsmasq and Ingress-Nginx

Now, to install ArgoCD from the Helm chart, we need to make some changes. By default, ArgoCD has SSL autoredirection enabled, but we gotta disable that. Just keep in mind that I haven’t set up an ingress with SSL in this tutorial, so if you’re looking for a solution with SSL, you’re in the wrong place. We’re just in a local test environment without certificates.

Here are the steps you need to follow to configure it:

First, we’ll edit the deployment of argocd-server and add --insecure:

And when we install the Ingress Controller, we need to edit this part of the YAML file:

Going back to the argocd installation, we will use helm to perform the installation:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Next, create the ingress with the following DNS:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  rules:
  - host: argo.kind.cluster
    http:
      paths:
      - backend:
          serviceName: argocd-server
          servicePort: http

To get the initial password from ArgoCD, run this command:

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

Then, access the ArgoCD dashboard and update the password:

We can now deploy our applications in argocd !

Visualizing the Relationships Between Argo CD, ChartMuseum, and DNSMasq Services.

In this brief explanation, we will outline our plan for implementing the services Argo CD, ChartMuseum, and Dnsmasq. For more detailed information, please refer to the second post that we have provided for your convenience.

As we can observe, we have deployed our ChartMuseum in the same cluster and in order to access the charts saved in it, we will need to specify the DNS entry of the service that points to the ChartMuseum pod. (chartmuseum.chartmuseum.svc.cluster.local)

We need to select an HTTPS method and connect:

Uploading our chart

To get started, we’ve set up an Ingress that points to our ChartMuseum service. Here’s the configuration for ChartMuseum.

To upload a Helm package to ChartMuseum, you’ll need to configure your local Helm client to point to the ChartMuseum repository. This can be done by adding the repository URL as a Helm repository using the helm repo add command. For example:

helm repo add chartmusem chartmuseum.kind.cluster

Next, build the Helm package by running the helm package command on the root directory of your chart. This will create a .tgz file that contains the chart.

Finally, upload the Helm package to ChartMuseum by running the curl command with the — data-binary flag to send the .tgz file to the ChartMuseum API endpoint. For example:

curl --data-binary "@mychart-1.0.0.tgz" http://chartmuseum.kind.cluster/api/charts

To verify that your chart has been uploaded successfully, you can either use the ChartMuseum UI or API, or you can run the helm search command to search for the chart in the repository. Additionally, you can access ChartMuseum from your browser by navigating to the repository URL.

Preparing a Application(CRD) to use it in ArgoCD.

To deploy an application using ArgoCD, you’ll need to prepare a configuration file that tells ArgoCD how to deploy the app. In this example, we’re deploying an app called devops-app, and we're using a chart from ChartMuseum to define its configuration.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: devops-app
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source:
    repoURL: http://chartmuseum.chartmuseum.svc.cluster.local
    chart: devops-app-chart
    targetRevision: 0.4.0
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

It’s important to note that before deploying the application, you need to switch your namespace to the one where ArgoCD is installed. This is because ArgoCD manages applications within its own namespace, and it needs access to Kubernetes resources to deploy and manage the application.

Once you’ve switched to the ArgoCD namespace, you can apply the configuration file using the kubectl apply command. This will create an ArgoCD Application resource and trigger the deployment of the application.

Here’s an example command to apply the configuration file:

kubectl apply -n argocd -f application.yaml

After applying the ArgoCD Application resource for devops-app, ArgoCD will begin deploying the application according to the configuration specified in the manifest.

You can monitor the deployment progress using the ArgoCD web UI, which will show you the status of the application and any errors that may occur during deployment. Here’s an example screenshot of the UI:

Once the deployment is complete, you can access your application and verify that it’s running correctly. You can do this by accessing the URL or IP address specified in your Ingress resource, which will route traffic to the application.

Here’s an example screenshot of accessing the deployed application:

If everything is working correctly, you should be able to see your application’s UI and interact with it as expected.

In the next post, we will dive into the advanced features of ArgoCD and explore how to use ApplicationSet to manage multiple applications at scale. Stay tuned for more!