In a series of previous articles, I covered a lot about the “Quarkus – Kubernetes extension” and also the “Helm Extension for Quarkus”.
In my previous article, you could read more about the “Argo CD Extension for Quarkus” I tried out. As a base for this, I used my already existing Linux demo environment, including Quarkus and K3s (a lightweight certified Kubernetes distribution) and setup via Vagrant. The focus of that part 1 article, was setting up the ArgoCD environment. You could read for example about how I met a requirement for using the “Argo CD Extension for Quarkus”, by adding a project under version control system Git and pushing it on a GitHub Private repository.
In this part 2 article, I will continue following some of the next steps as described in the “Getting Started” part of the Argo CD documentation:
- Login Using The CLI
- Register A Cluster To Deploy Apps To (Optional)
- Create An Application From A Git Repository, Creating Apps Via CLI
- Create An Application From A Git Repository, Creating Apps Via UI
- Sync (Deploy) The Application, Syncing via CLI
- Sync (Deploy) The Application, Syncing via UI
[https://argo-cd.readthedocs.io/en/stable/getting_started/#getting-started]
I will be using the Argo CD CLI and UI in combination with an example GitHub repository containing a guestbook application.
Overview of my Linux demo environment, including Argo CD
Below, you can see an overview of my Linux demo environment, as described in my previous article:
[Quarkus – trying out the “Argo CD Extension for Quarkus” (part 1)]
This includes the Argo CD API Server and Argo CD CLI.
For the Linux demo environment to start, from the Oracle VM VirtualBox Manager on my Windows laptop, I started the appliance (in “Headless Start” mode).
Once the VM was running, for executing later manual steps, I used vagrant ssh to connect into the running VM.
In my previous article, I already described how I installed Argo CD via kubectl.
[Quarkus – trying out the “Argo CD Extension for Quarkus” (part 1)]
This time however, I wanted Argo CD to be installed by using Helm.
But first, I had to remove the Argo CD Kubernetes objects that were created the previous time, when I installed Argo CD via kubectl, in order to be able to install Argo CD by using Helm.
Removing the created Kubernetes objects
As you may remember from my previous article, all the Argo CD Kubernetes objects were created in 1 namespace, named argocd.
In order to delete all the resources in the argocd namespace, I used the following command on the Linux Command Prompt:
kubectl delete -n argocd all --all
Remark about option –all:
[https://kubernetes.io/docs/reference/kubectl/generated/kubectl_delete/]
With the following output:
pod “argocd-application-controller-0” deleted
pod “argocd-applicationset-controller-694458f998-cp4lk” deleted
pod “argocd-dex-server-746dd6b4b9-g9cgf” deleted
pod “argocd-notifications-controller-746cd74b97-28tgf” deleted
pod “argocd-redis-db5bc49bf-bdd9t” deleted
pod “argocd-repo-server-775b449c46-f54lw” deleted
pod “argocd-server-7d4d46b98-bpxrh” deleted
service “argocd-applicationset-controller” deleted
service “argocd-dex-server” deleted
service “argocd-metrics” deleted
service “argocd-notifications-controller-metrics” deleted
service “argocd-redis” deleted
service “argocd-repo-server” deleted
service “argocd-server” deleted
service “argocd-server-metrics” deleted
deployment.apps “argocd-applicationset-controller” deleted
deployment.apps “argocd-dex-server” deleted
deployment.apps “argocd-notifications-controller” deleted
deployment.apps “argocd-redis” deleted
deployment.apps “argocd-repo-server” deleted
deployment.apps “argocd-server” deleted
replicaset.apps “argocd-server-7d4d46b98” deleted
statefulset.apps “argocd-application-controller” deleted
Install Argo CD by using Helm
I navigated to the “Operator Manual, Installation” part of the Argo CD documentation. From there, I navigated to the “Helm” part.
The Argo CD can be installed using Helm. The Helm chart is currently community maintained and available at argo-helm/charts/argo-cd.
[https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/#helm]
Then, I clicked on the “argo-helm/charts/argo-cd” link.
I logged in into github.com with my own GitHub account.
[https://github.com/argoproj/argo-helm/tree/main/charts/argo-cd]
In order to be able to clone this project onto my local computer, above the list of files, I clicked on “<> Code”.
Then, I clicked on “Code”.
In order to be able to clone this project onto my local computer, I clicked on “Copy URL to clipboard”.
https://github.com/argoproj/argo-helm.git
I will be using this remote repository URL later on.
The https:// clone URLs are available on all repositories, regardless of visibility. https:// clone URLs work even if you are behind a firewall or proxy.
When you git clone, git fetch, git pull, or git push to a private remote repository using HTTPS URLs on the command line, Git will ask for your GitHub username and password. When Git prompts you for your password, enter your personal access token.
[https://docs.github.com/en/get-started/git-basics/about-remote-repositories#cloning-with-https-urls]
On my Windows laptop, as you may remember from a previous article, I had a shared folder available.
[Quarkus – Supersonic Subatomic Java – Get Started (reinvestigated)]
So, in this shared folder, I navigated to helmcharts.
Next, in order to Clone a repository into a new directory, I used the following command:
[https://git-scm.com/docs/git-clone]
git.exe clone --progress --verbose https://marclameriks@github.com/argoproj/argo-helm.git
Remark about option –progress:
Progress status is reported on the standard error stream by default when it is attached to a terminal, unless –quiet is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.
[https://git-scm.com/docs/git-clone#Documentation/git-clone.txt—progress]
Remark about option –verbose:
Run verbosely. Does not affect the reporting of progress status to the standard error stream.
[https://git-scm.com/docs/git-clone#Documentation/git-clone.txt–v]
Remark about authenticating with GitHub from Git:
In order to authenticate with GitHub from Git, I used the following format (after some research):
[https://stackoverflow.com/questions/10054318/how-do-i-provide-a-username-and-password-when-running-git-clone-gitremote-git]
https://<username>@<repository>
With the following output:
Cloning into 'argo-helm'... POST git-upload-pack (193 bytes) POST git-upload-pack (gzip 61370 to 30395 bytes) remote: Enumerating objects: 23815, done. remote: Counting objects: 100% (339/339), done. remote: Compressing objects: 100% (163/163), done. remote: Total 23815 (delta 291), reused 176 (delta 176), pack-reused 23476 (from 4) Receiving objects: 100% (23815/23815), 47.12 MiB | 1.26 MiB/s, done. Resolving deltas: 100% (16821/16821), done.
Next, I checked my shared folder, directory helmcharts\argo-helm.
From there I navigated to helmcharts\argo-helm\charts\argo-cd.
As you can see in the directory above, there is a file Chart.yaml and a file values.yaml.
Below, you can see the content of file Chart.yaml:
apiVersion: v2 appVersion: v3.2.3 kubeVersion: ">=1.25.0-0" description: A Helm chart for Argo CD, a declarative, GitOps continuous delivery tool for Kubernetes. name: argo-cd version: 9.3.0 home: https://github.com/argoproj/argo-helm icon: https://argo-cd.readthedocs.io/en/stable/assets/logo.png sources: - https://github.com/argoproj/argo-helm/tree/main/charts/argo-cd - https://github.com/argoproj/argo-cd keywords: - argoproj - argocd - gitops maintainers: - name: argoproj url: https://argoproj.github.io/ dependencies: - name: redis-ha version: 4.34.11 repository: https://dandydeveloper.github.io/charts/ condition: redis-ha.enabled annotations: artifacthub.io/signKey: | fingerprint: 2B8F22F57260EFA67BE1C5824B11F800CD9D2252 url: https://argoproj.github.io/argo-helm/pgp_keys.asc artifacthub.io/changes: | - kind: added description: Ability to define global volumes and volume mounts
Below, you can see the content of file values.yaml (only showing the begin part):
## Argo CD configuration
## Ref: https://github.com/argoproj/argo-cd
##
# -- Provide a name in place of `argocd`
nameOverride: argocd
# -- String to fully override `"argo-cd.fullname"`
fullnameOverride: ""
# -- Override the namespace
# @default -- `.Release.Namespace`
namespaceOverride: ""
# -- Override the Kubernetes version, which is used to evaluate certain manifests
kubeVersionOverride: ""
# Override APIVersions
# If you want to template helm charts but cannot access k8s API server
# you can set api versions here
apiVersionOverrides: {}
…
Before I am going to use the Argo CD Helm chart, I wanted to make a change.
As you may remember from my previous article, the argocd-server service is of service type ClusterIP.
Remark about service type ClusterIP:
Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default that is used if you don’t explicitly specify a type for a Service.
[https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types]
This time however, I wanted to use another service type.
Because I wanted to expose a Service onto an external IP address, one that’s accessible from outside of my cluster, I opted for using service type NodePort (including using my own port number), as I already did before and described in one of my articles some time ago.
[Quarkus – Kubernetes extension (reinvestigated, part 4), implementing a Service of service type NodePort]
Service with service type: NodePort
If you set the type field to NodePort, the Kubernetes control plane allocates a port from a range specified by –service-node-port-range flag (default: 30000-32767). Each node proxies that port (the same port number on every Node) into your Service. Your Service reports the allocated port in its .spec.ports[*].nodePort field.
Using a NodePort gives you the freedom to set up your own load balancing solution, to configure environments that are not fully supported by Kubernetes, or even to expose one or more nodes’ IP addresses directly.
For a node port Service, Kubernetes additionally allocates a port (TCP, UDP or SCTP to match the protocol of the Service). Every node in the cluster configures itself to listen on that assigned port and to forward traffic to one of the ready endpoints associated with that Service. You’ll be able to contact the type: NodePort Service, from outside the cluster, by connecting to any node using the appropriate protocol (for example: TCP), and the appropriate port (as assigned to that Service).
[https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport]
Be aware that when using a service type NodePort you expose one or more nodes’ IP addresses directly. So, this type of service exposure is not very secure, because external clients basically have access to worker nodes directly. NodePort is mainly recommended for demos and test environments. Do not use this service type in production.
[Quarkus – Kubernetes extension (reinvestigated, part 5), implementing a Service of service type LoadBalancer with K3s]
I changed the content of file values.yaml to (only showing the “Server service configuration” part):
[in bold, I highlighted the changes]
## Server service configuration
service:
# -- Server service annotations
annotations: {}
# -- Server service labels
labels: {}
# -- Server service type
type: NodePort
# -- Server service http port for NodePort service type (only if `server.service.type` is set to "NodePort")
nodePortHttp: 30080
# -- Server service https port for NodePort service type (only if `server.service.type` is set to "NodePort")
nodePortHttps: 30443
# -- Server service http port
servicePortHttp: 80
# -- Server service https port
servicePortHttps: 443
# -- Server service http port name, can be used to route traffic via istio
servicePortHttpName: http
# -- Server service https port name, can be used to route traffic via istio
servicePortHttpsName: https
# -- Server service https port appProtocol
## Ref: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol
servicePortHttpsAppProtocol: ""
# -- The class of the load balancer implementation
loadBalancerClass: ""
# -- LoadBalancer will get created with the IP specified in this field
loadBalancerIP: ""
# -- Source IP ranges to allow access to service from
## EKS Ref: https://repost.aws/knowledge-center/eks-cidr-ip-address-loadbalancer
## GKE Ref: https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview#limit-connectivity-ext-lb
loadBalancerSourceRanges: []
# -- Server service external IPs
externalIPs: []
# -- Denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints
## Ref: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip
externalTrafficPolicy: Cluster
# -- Used to maintain session affinity. Supports `ClientIP` and `None`
## Ref: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
sessionAffinity: None
As you can see above, I navigated to “Server service configuration” and changed the Argo CD Server service type, to: NodePort.
Install the Argo CD Helm chart
Now, in order to install the Argo CD Helm chart (in the argocd namespace), I used the following commands on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_install]
cd /mnt/mysharedfolder/helmcharts/argo-helm/charts helm install argo-cd ./argo-cd --namespace argocd
With the following output:
Error: INSTALLATION FAILED: unable to continue with install: ServiceAccount “argocd-application-controller” in namespace “argocd” exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key “app.kubernetes.io/managed-by”: must be set to “Helm”; annotation validation error: missing key “meta.helm.sh/release-name”: must be set to “argo-cd”; annotation validation error: missing key “meta.helm.sh/release-namespace”: must be set to “argocd”
See https://stackoverflow.com/questions/62964532/helm-not-creating-the-resources
Apparently, the resource ServiceAccount “argocd-application-controller” in namespace “argocd” already exists. So first, I had to delete it.
In order to list all serviceaccounts in the argocd namespace, I used the following command on the Linux Command Prompt:
kubectl get serviceaccounts -n argocd
With the following output:
NAME SECRETS AGE argo-cd-argocd-redis-secret-init 0 11m argocd-application-controller 0 5m46s argocd-applicationset-controller 0 5m46s argocd-dex-server 0 5m46s argocd-notifications-controller 0 5m46s argocd-redis 0 5m46s argocd-repo-server 0 5m46s argocd-server 0 5m46s default 0 14m
In order to delete all serviceaccounts in the argocd namespace, I used the following command on the Linux Command Prompt:
kubectl delete -n argocd serviceaccounts --all
With the following output:
serviceaccount "argo-cd-argocd-redis-secret-init" deleted serviceaccount "argocd-application-controller" deleted serviceaccount "argocd-applicationset-controller" deleted serviceaccount "argocd-dex-server" deleted serviceaccount "argocd-notifications-controller" deleted serviceaccount "argocd-redis" deleted serviceaccount "argocd-repo-server" deleted serviceaccount "argocd-server" deleted serviceaccount "default" deleted
Again, in order to install the Argo CD Helm chart (in the argocd namespace), I used the following command on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_install]
helm install argo-cd ./argo-cd --namespace argocd
With the following output:
Error: INSTALLATION FAILED: unable to continue with install: Secret "argocd-notifications-secret" in namespace "argocd" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "argo-cd"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "argocd"
Apparently, the resource Secret “argocd-notifications-secret” in namespace “argocd” already exists. So first, I had to delete it.
In order to list all secrets in the argocd namespace, I used the following command on the Linux Command Prompt:
kubectl get secrets -n argocd
With the following output:
NAME TYPE DATA AGE
argocd-initial-admin-secret Opaque 1 16m
argocd-notifications-secret Opaque 0 10m
argocd-redis Opaque 1 16m
argocd-secret Opaque 5 10m
In order to delete all secrets in the argocd namespace, I used the following commands on the Linux Command Prompt:
kubectl delete -n argocd secrets --all
With the following output:
secret "argocd-initial-admin-secret" deleted secret "argocd-notifications-secret" deleted secret "argocd-redis" deleted secret "argocd-secret" deleted
Again, in order to install the Argo CD Helm chart (in the argocd namespace), I used the following command on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_install]
helm install argo-cd ./argo-cd --namespace argocd
With the following output:
Error: INSTALLATION FAILED: unable to continue with install: ConfigMap "argocd-cm" in namespace "argocd" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "argo-cd"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "argocd"
Apparently, the resource ConfigMap “argocd-cm” in namespace “argocd” already exists. So first, I had to delete it.
In order to list all configmaps in the argocd namespace, I used the following command on the Linux Command Prompt:
kubectl get configmaps -n argocd
With the following output:
NAME DATA AGE argocd-cm 9 14m argocd-cmd-params-cm 0 14m argocd-gpg-keys-cm 0 14m argocd-notifications-cm 0 14m argocd-rbac-cm 0 14m argocd-ssh-known-hosts-cm 1 14m argocd-tls-certs-cm 0 14m kube-root-ca.crt 1 20m
In order to delete all configmaps in the argocd namespace, I used the following command on the Linux Command Prompt:
kubectl delete -n argocd configmaps --all
With the following output:
configmap "argocd-cm" deleted configmap "argocd-cmd-params-cm" deleted configmap "argocd-gpg-keys-cm" deleted configmap "argocd-notifications-cm" deleted configmap "argocd-rbac-cm" deleted configmap "argocd-ssh-known-hosts-cm" deleted configmap "argocd-tls-certs-cm" deleted configmap "kube-root-ca.crt" deleted
Again, in order to install the Argo CD Helm chart (in the argocd namespace), I used the following commands on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_install]
helm install argo-cd ./argo-cd --namespace argocd
With the following output:
Error: INSTALLATION FAILED: unable to continue with install: CustomResourceDefinition "applications.argoproj.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "argo-cd"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "argocd"
After some research on the Internet, I changed the content of file values.yaml to (only showing the “Custom resource configuration” part):
[in bold, I highlighted the changes]
## Custom resource configuration
crds:
# -- Install and upgrade CRDs
install: false
# -- Keep CRDs on chart uninstall
keep: true
# -- Annotations to be added to all CRDs
annotations: {}
# -- Additional labels to be added to all CRDs
additionalLabels: {}
Again, in order to install the Argo CD Helm chart (in the argocd namespace), I used the following command on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_install]
helm install argo-cd ./argo-cd --namespace argocd
With the following output:
NAME: argo-cd
LAST DEPLOYED: Tue Jan 13 09:20:17 2026
NAMESPACE: argocd
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
NOTES:
In order to access the server UI you have the following options:
1. kubectl port-forward service/argo-cd-argocd-server -n argocd 8080:443
and then open the browser on http://localhost:8080 and accept the certificate
2. enable ingress in the values file `server.ingress.enabled` and either
- Add the annotation for ssl passthrough: https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#option-1-ssl-passthrough
- Set the `configs.params."server.insecure"` in the values file and terminate SSL at your ingress: https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#option-2-multiple-ingress-objects-and-hosts
After reaching the UI the first time you can login with username: admin and the random password generated during the installation. You can find the password by running:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
(You should delete the initial secret afterwards as suggested by the Getting Started Guide: https://argo-cd.readthedocs.io/en/stable/getting_started/#4-login-using-the-cli)
In order to list helm releases (for the current namespace context), I used the following command on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_list]
helm list
With the following output:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
k3s-release default 1 2025-08-13 08:54:45.276772079 +0000 UTC deployed k3s-chart-0.1.0 1.16.0
In order to list all releases across all namespaces, I used the following command on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_list]
helm list --all-namespaces
With the following output:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
argo-cd argocd 1 2026-01-13 09:33:02.169702739 +0000 UTC deployed argo-cd-9.3.0 v3.2.3
helm-kubernetes-quickstart nl-amis-development 2 2025-11-19 15:21:02.359823405 +0000 UTC deployed kubernetes-quickstart-1.0.0-SNAPSHOT
k3s-release default 1 2025-08-13 08:54:45.276772079 +0000 UTC deployed k3s-chart-0.1.0 1.16.0
traefik kube-system 1 2025-08-13 08:51:34.633744141 +0000 UTC deployed traefik-34.2.1+up34.2.0 v3.3.2
traefik-crd kube-system 1 2025-08-13 08:51:09.549088333 +0000 UTC deployed traefik-crd-34.2.1+up34.2.0 v3.3.2
In order to list all releases for a specific namespace, I used the following command on the Linux Command Prompt:
[https://helm.sh/docs/helm/helm_list]
helm list --namespace argocd
With the following output:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
argo-cd argocd 1 2026-01-13 09:33:02.169702739 +0000 UTC deployed argo-cd-9.3.0 v3.2.3
So now, let’s check the Kubernetes objects that were created.
I checked whether the Pods were running successfully, via a series of commands on the Linux Command Prompt.
kubectl get namespaces
With the following output:
NAME STATUS AGE argocd Active 24d default Active 153d kube-node-lease Active 153d kube-public Active 153d kube-system Active 153d kubernetes-dashboard Active 153d nl-amis-development Active 153d
kubectl get services -n argocd
With the following output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE argo-cd-argocd-applicationset-controller ClusterIP 10.43.135.23 <none> 7000/TCP 4m27s argo-cd-argocd-dex-server ClusterIP 10.43.6.39 <none> 5556/TCP,5557/TCP 4m27s argo-cd-argocd-redis ClusterIP 10.43.90.59 <none> 6379/TCP 4m27s argo-cd-argocd-repo-server ClusterIP 10.43.98.107 <none> 8081/TCP 4m27s argo-cd-argocd-server NodePort 10.43.189.214 <none> 80:30080/TCP,443:30443/TCP 4m27s
kubectl get replicasets -n argocd
With the following output:
NAME DESIRED CURRENT READY AGE argo-cd-argocd-applicationset-controller-d95667bb6 1 1 1 4m39s argo-cd-argocd-dex-server-5db69dd4c5 1 1 1 4m39s argo-cd-argocd-notifications-controller-b7fb4658b 1 1 1 4m39s argo-cd-argocd-redis-64744bd689 1 1 1 4m39s argo-cd-argocd-repo-server-6989765765 1 1 1 4m39s argo-cd-argocd-server-75d7874dcb 1 1 1 4m39s
kubectl get pods -n argocd
With the following output:
NAME READY STATUS RESTARTS AGE argo-cd-argocd-application-controller-0 1/1 Running 0 4m50s argo-cd-argocd-applicationset-controller-d95667bb6-2sd4l 1/1 Running 0 4m51s argo-cd-argocd-dex-server-5db69dd4c5-5h27c 1/1 Running 0 4m51s argo-cd-argocd-notifications-controller-b7fb4658b-fcth9 1/1 Running 0 4m51s argo-cd-argocd-redis-64744bd689-bdqk4 1/1 Running 0 4m50s argo-cd-argocd-repo-server-6989765765-k47fw 1/1 Running 0 4m51s argo-cd-argocd-server-75d7874dcb-qq5jp 1/1 Running 0 4m51s
kubectl get endpointslice -n argocd
With the following output:
NAME ADDRESSTYPE PORTS ENDPOINTS AGE argo-cd-argocd-applicationset-controller-9h9vz IPv4 7000 10.42.0.131 5m16s argo-cd-argocd-dex-server-pdjzz IPv4 5556,5557 10.42.0.132 5m16s argo-cd-argocd-redis-mzlc7 IPv4 6379 10.42.0.135 5m16s argo-cd-argocd-repo-server-4797m IPv4 8081 10.42.0.129 5m16s argo-cd-argocd-server-xstlh IPv4 8080,8080 10.42.0.133 5m16s
kubectl get nodes
With the following output:
NAME STATUS ROLES AGE VERSION ubuntu2204.localdomain Ready control-plane,master 153d v1.33.3+k3s1
kubectl get serviceaccounts -n argocd
With the following output:
NAME SECRETS AGE argo-cd-argocd-redis-secret-init 0 5m36s argo-cd-argocd-repo-server 0 5m31s argocd-application-controller 0 5m31s argocd-applicationset-controller 0 5m31s argocd-dex-server 0 5m31s argocd-notifications-controller 0 5m31s argocd-server 0 5m31s default 0 9m37s
kubectl get secrets -n argocd
With the following output:
NAME TYPE DATA AGE argocd-initial-admin-secret Opaque 1 5m35s argocd-notifications-secret Opaque 0 5m40s argocd-redis Opaque 1 5m43s argocd-secret Opaque 5 5m40s sh.helm.release.v1.argo-cd.v1 helm.sh/release.v1 1 5m45s
kubectl get configmaps -n argocd
With the following output:
NAME DATA AGE argo-cd-argocd-redis-health-configmap 2 5m47s argocd-cm 17 5m47s argocd-cmd-params-cm 20 5m47s argocd-gpg-keys-cm 0 5m47s argocd-notifications-cm 1 5m47s argocd-rbac-cm 4 5m47s argocd-ssh-known-hosts-cm 1 5m47s argocd-tls-certs-cm 0 5m47s kube-root-ca.crt 1 8m29s
Below, you see an overview of my Kubernetes cluster at this moment, with regard to the Argo CD API Server (argocd-server):
The argocd-server service is of service type NodePort.
Download Argo CD CLI
In my previous article, I described how I downloaded and installed the Argo CD CLI. Now I wanted to check if it is still working.
I should be able to run argocd commands.
So, let’s try it.
In order to print version information, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_version/]
argocd version
With the following output:
argocd: v3.2.2+8d0dde1
BuildDate: 2025-12-18T10:17:02Z
GitCommit: 8d0dde1388a92ca4dc0daacec5707f4378b9d06a
GitTreeState: clean
GoVersion: go1.25.0
Compiler: gc
Platform: linux/amd64
{"level":"fatal","msg":"Argo CD server address unspecified","time":"2025-12-19T14:12:55Z"}
This looked familiar. There is some work to be done.
Access the Argo CD API Server
In my previous article, I described how by default, the Argo CD API server is not exposed with an external IP. To access the API server, again I opted for using port forwarding.
I wanted to be able to use a Web Browser on my Windows laptop, to connect to the
Argo CD API server.
In my previous article, I also described how in the Oracle VM VirtualBox Manager on my Windows laptop, I navigated to the appliance | Details | Network | Advanced | Port Forwarding. And that I added two extra port forwarding rules (for ports 8085 en 8086).
In order to determine the IP of the K3s node, I used the following commands on the Linux Command Prompt, as I described in a previous article:
[Creating a re-usable Vagrant Box from an existing VM with Ubuntu and k3s (with the Kubernetes Dashboard) and adding mysql, using Vagrant and Oracle VirtualBox]
nodeIP=$(kubectl get node ubuntu2204.localdomain -o yaml | grep address: | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}") echo "---$nodeIP---"
With the following output:
---10.0.2.15---
Next, for port forwarding port 8085 on my Linux demo environment, I used the following command on the Linux Command Prompt:
socat tcp-listen:8085,fork tcp:$nodeIP:30080 &
With the following output:
[1] 60902
vagrant@ubuntu2204:/mnt/mysharedfolder/helmcharts/argo-helm/charts$ 2026/01/13 10:41:42 socat[60902] E bind(5, {AF=2 0.0.0.0:8085}, 16): Address already in use
^C
[1]+ Exit 1 socat tcp-listen:8085,fork tcp:$nodeIP:30080
Because of the port forwarding steps described in my previous article, port 8085 was already in use.
In order to find the process/service listening on port 8085, I used the following command on the Linux Command Prompt:
[https://man7.org/linux/man-pages/man8/lsof.8.html]
sudo lsof -i :8085
With the following output:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME kubectl 10355 vagrant 8u IPv4 111056 0t0 TCP *:8085 (LISTEN)
Remark about the -i option:
-i [i]
Selects the listing of files any of whose Internet address matches the address specified in i. If no address is specified, this option selects the listing of all Internet and x.25 (HP-UX) network files
Next, I killed that process:
sudo kill 10355
I repeated the steps above for port 8086.
Again, for port forwarding port 8085 on my Linux demo environment, I used the following command on the Linux Command Prompt:
socat tcp-listen:8085,fork tcp:$nodeIP:30080 &
With the following output:
[1] 60998
Again, for port forwarding port 8085 on my Linux demo environment, I used the following command on the Linux Command Prompt:
socat tcp-listen:8086,fork tcp:$nodeIP:30443 &
With the following output:
[2] 61015
With the port forwarding in place, I repeated the previous argocd command.
argocd version
With the following output:
argocd: v3.2.2+8d0dde1 BuildDate: 2025-12-18T10:17:02Z GitCommit: 8d0dde1388a92ca4dc0daacec5707f4378b9d06a GitTreeState: clean GoVersion: go1.25.0 Compiler: gc Platform: linux/amd64 argocd-server: v3.2.3+2b6251d
Below, you see an overview of my Kubernetes cluster at this moment:
In order to check access to the Argo CD API Server via port 8085, I used the following command on the Linux Command Prompt:
curl http://localhost:8085
With the following output:
<a href="https://localhost:8085/">Temporary Redirect</a>.
Remark about redirect:
Argo CD API server runs both a gRPC server (used by the CLI), as well as a HTTP/HTTPS server (used by the UI). Both protocols are exposed by the argocd-server service object on the following ports:
- 443 – gRPC/HTTPS
- 80 – HTTP (redirects to HTTPS)
[https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#ingress-configuration]
In order to check access to the Argo CD API Server via port 8086, I used the following command on the Linux Command Prompt:
curl https://localhost:8086
With the following output:
2026/01/13 10:51:15 socat[61123] E write(6, 0x55d3711aa000, 24): Broken pipe
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Remark about self-signed certificate:
This default installation will have a self-signed certificate and cannot be accessed without a bit of extra work. Do one of:
- Follow the instructions to configure a certificate (and ensure that the client OS trusts it).
- Configure the client OS to trust the self-signed certificate.
- Use the –insecure flag on all Argo CD CLI operations in this guide.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#1-install-argo-cd]
Before looking further into this, first I continued following the steps as described in the “Getting Started” part of the Argo CD documentation.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#getting-started]
Login Using The CLI
I continued with reading the documentation.
The initial password for the admin account is auto-generated and stored as clear text in the field password in a secret named argocd-initial-admin-secret in your Argo CD installation namespace. You can simply retrieve this password using the argocd CLI:
argocd admin initial-password -n argocd
[https://argo-cd.readthedocs.io/en/stable/getting_started/#4-login-using-the-cli]
In order to retrieve the password for the admin account, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_admin/]
argocd admin initial-password -n argocd
With the following output:
I continued with reading the documentation.
Using the username admin and the password from above, login to Argo CD’s IP or hostname:
argocd login <ARGOCD_SERVER>
[https://argo-cd.readthedocs.io/en/stable/getting_started/#4-login-using-the-cli]
Remark:
Step 3 refers to: “Access The Argo CD API Server”.
In order to login to Argo CD’s IP or hostname, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_login/]
argocd login https://localhost:8086
With the following output:
Then, I had a look at: https://github.com/argoproj/argo-cd/issues/10884
Next, I used the following command on the Linux Command Prompt:
argocd login localhost:8086
With the following output:
WARNING: server certificate had error: error creating connection: tls: failed to verify certificate: x509: certificate signed by unknown authority. Proceed insecurely (y/n)? y
Username: admin
Password:
‘admin:login’ logged in successfully
Context ‘localhost:8086’ updated
In order to avoid the warning, I used the following command on the Linux Command Prompt:
argocd login --insecure localhost:8086
With the following output:
Username: Username: admin
Password:
‘admin:login’ logged in successfully
Context ‘localhost:8086’ updated
Remark about option –insecure:
Skip server certificate and domain verification
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_login/#argocd-login-command-reference]
I continued with reading the documentation.
Change the password using the command:
argocd account update-password
[https://argo-cd.readthedocs.io/en/stable/getting_started/#4-login-using-the-cli]
In order to change the password for the admin account, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_account/]
argocd account update-password
With the following output:
*** Enter password of currently logged in user (admin):
*** Enter new password for user admin:
*** Confirm new password for user admin:
Password updated
Context ‘localhost:8086’ updated
Now, I wanted to try out some argocd commands.
In order to list Argo CD Contexts, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/latest/user-guide/commands/argocd_context/]
argocd context
With the following output:
CURRENT NAME SERVER
* localhost:8086 localhost:8086
In order to list Argo CD applications, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_list/]
argocd app list
With the following output:
NAME CLUSTER NAMESPACE PROJECT STATUS HEALTH SYNCPOLICY CONDITIONS REPO PATH TARGET
In order to list all known certificates, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_cert_list/]
argocd cert list
With the following output:
HOSTNAME TYPE SUBTYPE INFO
[ssh.github.com]:443 ssh ecdsa-sha2-nistp256 SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
[ssh.github.com]:443 ssh ssh-ed25519 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
[ssh.github.com]:443 ssh ssh-rsa SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s
bitbucket.org ssh ecdsa-sha2-nistp256 SHA256:FC73VB6C4OQLSCrjEayhMp9UMxS97caD/Yyi2bhW/J0
bitbucket.org ssh ssh-ed25519 SHA256:ybgmFkzwOSotHTHLJgHO0QN8L0xErw6vd0VhFA9m3SM
bitbucket.org ssh ssh-rsa SHA256:46OSHA1Rmj8E8ERTC6xkNcmGOw9oFxYr0WF6zWW8l1E
github.com ssh ecdsa-sha2-nistp256 SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
github.com ssh ssh-ed25519 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
github.com ssh ssh-rsa SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s
gitlab.com ssh ecdsa-sha2-nistp256 SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw
gitlab.com ssh ssh-ed25519 SHA256:eUXGGm1YGsMAS7vkcx6JOJdOGHPem5gQp4taiCfCLB8
gitlab.com ssh ssh-rsa SHA256:ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ
ssh.dev.azure.com ssh ssh-rsa SHA256:ohD8VZEXGWo6Ez8GSEJQ9WpafgLFsOfLOtGGQCQo6Og
vs-ssh.visualstudio.com ssh ssh-rsa SHA256:ohD8VZEXGWo6Ez8GSEJQ9WpafgLFsOfLOtGGQCQo6Og
In order to list all known TLS certificates, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_cert_list/]
argocd cert list --cert-type https
With the following output:
HOSTNAME TYPE SUBTYPE INFO
In order to log out from Argo CD, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/latest/user-guide/commands/argocd_logout/]
argocd logout localhost:8086
With the following output:
Logged out from 'localhost:8086'
Remember, the warning mentioned above:
You should delete the argocd-initial-admin-secret from the Argo CD namespace once you changed the password. The secret serves no other purpose than to store the initially generated password in clear and can safely be deleted at any time. It will be re-created on demand by Argo CD if a new admin password must be re-generated.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#4-login-using-the-cli]
So, in order to list all secrets in the argocd namespace, I used the following command on the Linux Command Prompt:
kubectl get secrets -n argocd
With the following output:
NAME TYPE DATA AGE
argocd-initial-admin-secret Opaque 1 148m
argocd-notifications-secret Opaque 0 148m
argocd-redis Opaque 1 148m
argocd-secret Opaque 5 148m
sh.helm.release.v1.argo-cd.v1 helm.sh/release.v1 1 148m
Next, in order to get the secret argocd-initial-admin-secret‘s YAML, I used the following command on the Linux Command Prompt:
kubectl get secret argocd-initial-admin-secret -n argocd -o yaml
With the following output:
apiVersion: v1
data:
password: Ulh1UGhvbW8wa0Y4cy1zcg==
kind: Secret
metadata:
creationTimestamp: “2026-01-13T09:33:12Z”
name: argocd-initial-admin-secret
namespace: argocd
resourceVersion: “74739”
uid: 57c3958f-4ce3-4d77-b3b6-015b6f67f619
type: Opaque
Then, in order to get the password (base64 decoded) of the secret argocd-initial-admin-secret, I used the following command on the Linux Command Prompt:
kubectl get secret argocd-initial-admin-secret -n argocd --template={{.data.password}} | base64 -d
With the following output:
RXuPhomo0kF8s-sr
So, this was indeed the initial password for the admin account, which I changed by now.
Next, in order to delete the secret argocd-initial-admin-secret, I used the following command on the Linux Command Prompt:
kubectl delete secret argocd-initial-admin-secret -n argocdsecret -n argocd
With the following output:
secret "argocd-initial-admin-secret" deleted
Then, I continued following the steps as described in the “Getting Started” part of the Argo CD documentation.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#getting-started]
Create An Application From A Git Repository
An example repository containing a guestbook application is available at https://github.com/argoproj/argocd-example-apps.git to demonstrate how Argo CD works.
I had a look at the URL, mentioned above:
I had a look at file README.md.
Next, I navigated to the guestbook application.
As you can see in the directory above, there is a file guestbook-ui-svc.yaml and a file guestbook-ui-deployment.yaml.
Below, you can see the content of file guestbook-ui-svc.yaml:
apiVersion: v1 kind: Service metadata: name: guestbook-ui spec: ports: - port: 80 targetPort: 80 selector: app: guestbook-ui
Below, you can see the content of file guestbook-ui-deployment.yaml:
apiVersion: apps/v1 kind: Deployment metadata: name: guestbook-ui spec: replicas: 1 revisionHistoryLimit: 3 selector: matchLabels: app: guestbook-ui template: metadata: labels: app: guestbook-ui spec: containers: - image: gcr.io/google-samples/gb-frontend:v5 name: guestbook-ui ports: - containerPort: 80
Create An Application From A Git Repository, Creating Apps Via CLI
I continued with reading the documentation.
First we need to set the current namespace to argocd running the following command:
kubectl config set-context --current --namespace=argocd
Create the example guestbook application with the following command:
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
[https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-cli]
So, in order to set the current namespace to argocd, I used the following command on the Linux Command Prompt:
sudo kubectl config set-context --current --namespace=argocd
With the following output:
Context "default" modified.
Next, in order to log in to Argo CD, I used the following command on the Linux Command Prompt:
argocd login --insecure localhost:8086
With the following output:
Username: admin Password: 'admin:login' logged in successfully Context 'localhost:8086' updated
Then, in order to create the example guestbook application, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_create/]
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
With the following output:
application 'guestbook' created
So this command will create the following in Argo CD:
- APPNAME
Application name: guestbook - –repo
Repository URL: https://github.com/argoproj/argocd-example-apps.git (this GitHub repository has many directories, including directory guestbook with 2 files guestbook-ui-svc.yaml and guestbook-ui-deployment.yaml) - –path
Path in repository to the app directory: guestbook - –dest-server
K8s cluster URL: https://kubernetes.default.svc - –dest-namespace
K8s target namespace: default
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_create/]
Next, in order to list Argo CD applications, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_list/]
argocd app list
With the following output:
NAME CLUSTER NAMESPACE PROJECT STATUS HEALTH SYNCPOLICY CONDITIONS REPO PATH TARGET argocd/guestbook https://kubernetes.default.svc default default OutOfSync Missing Manual <none> https://github.com/argoproj/argocd-example-apps.git guestbook
Remark about the application name:
For the CLI and UI, applications are now referred to and displayed as in the format <namespace>/<name>.
For backwards compatibility, if the namespace of the Application is the control plane’s namespace (i.e. argocd), the <namespace> can be omitted from the application name when referring to it. For example, the application names argocd/someapp and someapp are semantically the same and refer to the same application in the CLI and the UI.
[https://argo-cd.readthedocs.io/en/stable/operator-manual/app-any-namespace/#application-names]
Next, in order to list Argo CD projects, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_proj/]
argocd proj list
With the following output:
NAME DESCRIPTION DESTINATIONS SOURCES CLUSTER-RESOURCE-WHITELIST NAMESPACE-RESOURCE-BLACKLIST SIGNATURE-KEYS ORPHANED-RESOURCES DESTINATION-SERVICE-ACCOUNTS default *,* * */* <none> <none> disabled <none>
By the way, in my next article I will go in to more detail on the components Argo CD application and Argo CD project.
Sync (Deploy) The Application, Syncing via CLI
I continued with reading the documentation.
Once the guestbook application is created, you can now view its status:
$ argocd app get guestbook Name: guestbook Server: https://kubernetes.default.svc Namespace: default URL: https://10.97.164.88/applications/guestbook Repo: https://github.com/argoproj/argocd-example-apps.git Target: Path: guestbook Sync Policy: <none> Sync Status: OutOfSync from (1ff8a67) Health Status: Missing GROUP KIND NAMESPACE NAME STATUS HEALTH apps Deployment default guestbook-ui OutOfSync Missing Service default guestbook-ui OutOfSync Missing
The application status is initially in OutOfSync state since the application has yet to be deployed, and no Kubernetes resources have been created. To sync (deploy) the application, run:
argocd app sync guestbook
This command retrieves the manifests from the repository and performs a kubectl apply of the manifests. The guestbook app is now running and you can now view its resource components, logs, events, and assessed health status.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#syncing-via-cli]
So, in order to get the Argo CD guestbook application details, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_get/]
argocd app get guestbook
With the following output:
Name: argocd/guestbook Project: default Server: https://kubernetes.default.svc Namespace: default URL: https://argocd.example.com/applications/guestbook Source: - Repo: https://github.com/argoproj/argocd-example-apps.git Target: Path: guestbook SyncWindow: Sync Allowed Sync Policy: Manual Sync Status: OutOfSync from (0d521c6) Health Status: Missing GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE Service default guestbook-ui OutOfSync Missing apps Deployment default guestbook-ui OutOfSync Missing
Next, in order to Sync the Argo CD guestbook application to its target state, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_sync/]
argocd app sync guestbook
With the following output:
TIMESTAMP GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE 2026-01-13T13:54:12+00:00 Service default guestbook-ui OutOfSync Missing 2026-01-13T13:54:12+00:00 apps Deployment default guestbook-ui OutOfSync Missing 2026-01-13T13:54:12+00:00 Service default guestbook-ui OutOfSync Healthy 2026-01-13T13:54:12+00:00 Service default guestbook-ui OutOfSync Healthy service/guestbook-ui created 2026-01-13T13:54:12+00:00 apps Deployment default guestbook-ui OutOfSync Missing deployment.apps/guestbook-ui created 2026-01-13T13:54:12+00:00 Service default guestbook-ui Synced Healthy service/guestbook-ui created Name: argocd/guestbook Project: default Server: https://kubernetes.default.svc Namespace: default URL: https://argocd.example.com/applications/guestbook Source: - Repo: https://github.com/argoproj/argocd-example-apps.git Target: Path: guestbook SyncWindow: Sync Allowed Sync Policy: Manual Sync Status: Synced to (0d521c6) Health Status: Progressing Operation: Sync Sync Revision: 0d521c6e049889134f3122eb32d7ed342f43ca0d Phase: Succeeded Start: 2026-01-13 13:54:12 +0000 UTC Finished: 2026-01-13 13:54:12 +0000 UTC Duration: 0s Message: successfully synced (all tasks run) GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE Service default guestbook-ui Synced Healthy service/guestbook-ui created apps Deployment default guestbook-ui Synced Progressing deployment.apps/guestbook-ui created
Again, in order to get Argo CD guestbook application details, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_get/]
argocd app get guestbook
With the following output:
Name: argocd/guestbook Project: default Server: https://kubernetes.default.svc Namespace: default URL: https://argocd.example.com/applications/guestbook Source: - Repo: https://github.com/argoproj/argocd-example-apps.git Target: Path: guestbook SyncWindow: Sync Allowed Sync Policy: Manual Sync Status: Synced to (0d521c6) Health Status: Healthy GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE Service default guestbook-ui Synced Healthy service/guestbook-ui created apps Deployment default guestbook-ui Synced Healthy deployment.apps/guestbook-ui created
Now, instead of creating and syncing an application via the Argo CD CLI, let’s repeat these steps, but this time we will be using the UI. In order to be able to do this, first we have to delete the application via the CLI.
So, in order to delete the Argo CD guestbook application, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_delete/]
argocd app delete guestbook
With the following output:
Are you sure you want to delete 'guestbook' and all its resources? [y/n] y application 'guestbook' deleted
Again, in order to get the Argo CD guestbook application details, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_get/]
argocd app list
With the following output:
NAME CLUSTER NAMESPACE PROJECT STATUS HEALTH SYNCPOLICY CONDITIONS REPO PATH TARGET
Finally, in order to log out from Argo CD, I used the following command on the Linux Command Prompt:
[https://argo-cd.readthedocs.io/en/latest/user-guide/commands/argocd_logout/]
argocd logout localhost:8086
With the following output:
Logged out from 'localhost:8086'
Create An Application From A Git Repository, Creating Apps Via UI
I continued with reading the documentation, and followed the steps as described.
Open a browser to the Argo CD external UI, and login by visiting the IP/hostname in a browser and use the credentials set in step 4 or locally as explained in Try Argo CD Locally.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-ui]
First, in the Web Browser on my Windows laptop, I entered the URL:
Remark about the connection:
As you may remember from my previous article, the Argo CD API Server uses a self-signed certificate and cannot be accessed without a bit of extra work.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#1-install-argo-cd]
Next, I clicked on “Advanced“.
Then, I clicked on “Proceed to localhost (unsafe)”.
Next, I entered the username and password for the Argo CD API Server.
After logging in, click the + New App button as shown below:
[https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-ui]
So, I clicked on “NEW APP”.
Give your app the name guestbook, use the project default, and leave the sync policy as Manual.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-ui]
I followed the steps as described.
Connect the https://github.com/argoproj/argocd-example-apps.gitrepo to Argo CD by setting repository url to the github repo url, leave revision as HEAD, and set the path to guestbook.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-ui]
For Destination, set cluster URL to https://kubernetes.default.svc (or in-cluster for cluster name) and namespace to default.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-ui]
After filling out the information above, click Create at the top of the UI to create the guestbook application.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-ui]
So, I clicked on “CREATE”.
Above you can see that the Argo CD guestbook application was created.
Sync (Deploy) The Application, Syncing via UI
I continued with reading the documentation, and followed the steps as described.
On the Applications page, click on Sync button of the guestbook application.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#syncing-via-ui]
So, I clicked on “SYNC”.
A panel will be opened and then, click on Synchronize button.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#syncing-via-ui]
Next, I clicked on “SYNCHRONIZE”.
You can see more details by clicking at the guestbook application.
[https://argo-cd.readthedocs.io/en/stable/getting_started/#syncing-via-ui]
Then, I clicked on the Argo CD guestbook application.
In the overview above, you can see (from left to right) the Argo CD guestbook Application, the
guestbook-ui Service, the guestbook-ui Deployment, the guestbook-ui-85db984648 ReplicaSet and the guestbook-ui-85db984648-cpfj2 Pod.
Finally, I clicked on “ Log out”.
Next, in the Web Browser on my Windows laptop, again I entered the URL:
Then, I clicked on “Not secure”.
Finally, I clicked on “Turn on warnings” and closed the Web Browser.
Now, I wanted to check the created service in Kubernetes.
In order to set the current namespace back to default, I used the following command on the Linux Command Prompt:
sudo kubectl config set-context --current --namespace=default
With the following output:
Context "default" modified
I used the following command, to list the Services:
kubectl get services
With the following output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE guestbook-ui ClusterIP 10.43.245.240 <none> 80/TCP 5m56s kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 153d
Above, you can see the guestbook-ui Service.
So, all these steps (using the Argo CD CLI and UI in combination with an example GitHub repository containing a guestbook application) as described in the “Getting Started” part of the Argo CD documentation, gave me a good idea about how to work with Argo CD.
I conclude this part 2 article.
In this article, I continued following some of the steps as described in the “Getting Started” part of the Argo CD documentation:
- Login Using The CLI
- Create An Application From A Git Repository, Creating Apps Via CLI
- Create An Application From A Git Repository, Creating Apps Via UI
- Sync (Deploy) The Application, Syncing via CLI
- Sync (Deploy) The Application, Syncing via UI
[https://argo-cd.readthedocs.io/en/stable/getting_started/#getting-started]
As a base for this, I used my already existing Linux demo environment, including Quarkus and K3s (a lightweight certified Kubernetes distribution) and setup via Vagrant.
In my next article (part 3), I will continue with the “Getting started” part of the “Argo CD Extension for Quarkus”, in order to generate an Argo CD Application or Project as part of the Quarkus build or by using the Quarkus CLI.
