argo-helm VS argo-cd

locals { services = { argocd = { namespace = "argocd" repository = "https://argoproj.github.io/argo-helm" chart = "argo-cd" version = var.argocd_chart_version kftray = { server = { alias = "argocd" local_port = "16080" target_port = "http" } } } # ... other services ... } services_values = { for service_name, service in local.services : service_name => templatefile("${path.module}/templates/${service_name}-values.yaml.tpl", { kftray = service.kftray }) } }

resource "helm_release" "argocd" { name = "argocd" repository = "https://argoproj.github.io/argo-helm" chart = "argo-cd" namespace = "argocd" create_namespace = true version = "4.0.0" values = [file("./argo.yaml")] }

# Ensure you're in the Kind cluster. This command should return 'kind-gitops-argocd' context. kubectl config current-context # Add the ArgoCD Helm repository helm repo add argo https://argoproj.github.io/argo-helm # Update the local Helm chart cache helm repo update # Install the ArgoCD Helm chart helm install argocd --namespace argocd --create-namespace argo/argo-cd # Create context for the ArgoCD namespace kubectl config set-context kind-ns-argocd --namespace argocd --cluster kind-gitops-argocd --user kind-gitops-argocd # Set the current context for the argocd namespace kubectl config use-context kind-ns-argocd # Grant cluster-admin role to the ArgoCD service account (use with caution in production) kubectl apply -f argocd/rbac/argocd-svc-account-clusterrole-admin-binding.yaml # Get the admin password via kubectl kubectl get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d # Access the ArgoCD UI (http://localhost:8080) using 'admin' as the username and the copied password kubectl port-forward service/argocd-server 8080:443

dry_run: false create_namespace: true wait: false timeout: false # If true, defaults to 20 mins charts: - release_name: nginx chart_name: nginx chart_repo: oci://registry-1.docker.io/bitnamicharts values_file: values/nginx-values.yaml - release_name: argocd chart_name: argo-cd chart_repo: https://argoproj.github.io/argo-helm values_file: values/argo-cd.yaml version: 6.4.0 namespace: argo-cd

$ helm repo add boris https://boris.github.io/kubernetes/helm/charts $ helm repo list NAME URL ealenn https://ealenn.github.io/charts bitnami https://charts.bitnami.com/bitnami kubernetes-dashboard https://kubernetes.github.io/dashboard/ argo https://argoproj.github.io/argo-helm boris https://boris.github.io/kubernetes/helm/charts/ $ helm install mychart boris/mychart

data "aws_eks_cluster_auth" "main" { name = aws_eks_cluster.main.name } resource "helm_release" "argocd" { depends_on = [aws_eks_node_group.main] name = "argocd" repository = "https://argoproj.github.io/argo-helm" chart = "argo-cd" version = "4.5.2" namespace = "argocd" create_namespace = true set { name = "server.service.type" value = "LoadBalancer" } set { name = "server.service.annotations.service\\.beta\\.kubernetes\\.io/aws-load-balancer-type" value = "nlb" } } data "kubernetes_service" "argocd_server" { metadata { name = "argocd-server" namespace = helm_release.argocd.namespace } }

FWIW: The Helm chart has network policy in place:

https://github.com/argoproj/argo-helm/blob/main/charts/argo-...

If you're using a CNI that supports network policy (e.g. AWS VPC CNI on EKS, Calico, etc.), I think this should more or less cover you, but I haven't personally tested it.

I think it's also probably a better practice to install "control plane" type software like Argo on a different, dedicated cluster. Argo supports this concept (and can in fact manage deployments in multiple clusters remotely). This way your main mission workloads are completely segmented from your privileged control plane software. Just as another defense-in-depth measure

resource "helm_release" "image_updater" { name = "argocd-image-updater" repository = "https://argoproj.github.io/argo-helm" chart = "argocd-image-updater" namespace = "argocd" values = [ <

kubectl create namespace argocd helm repo add argo https://argoproj.github.io/argo-helm helm repo update helm install argocd argo/argo-cd --namespace argocd

We will use Helm to install Argo CD with the community-maintained chart from argoproj/argo-helm because The Argo project doesn't provide an official Helm chart. We will render thier helm chart for argocd locally on our side, manipulate it and overrides its default values, and also we can helm lint the chart and templating to see if there is some errors or not, We gonna use the chart version 5.50.0 which matches appVersion: v2.8.6 you can find all details for the chart and also we gonna override some values @ default-values.yaml

Tekton Pipelines ArgoCD User Guide

cd ~/environment VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/') sudo curl --silent --location -o /usr/local/bin/argocd [https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64](https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64) sudo chmod +x /usr/local/bin/argocd

ArgoCD is another popular GitOps tool designed for managing Kubernetes clusters. ArgoCD stands out with its intuitive UI and ability to manage multiple applications across clusters visually, making it a strong contender in multi-cluster management.

Visit ArgoCD releases for the latest version. Explore the GitHub repo for newer release if necessary.

- You can trigger the process manually or automatically (PR, GH actions, cli tool, API, etc).

For example, the ArgoCD project uses Bunnyshell to create ephemeral envs on each PR. https://github.com/argoproj/argo-cd/pull/18851

Disclaimer: I work for Bunnyshell

In our case, we were trying to communicate across EKS clusters to allow ArgoCD to manage multiple clusters and there is a pretty mammoth GitHub issue with people struggling (and succeeding!) with this. That GitHub issue partly inspired this blog post - if it was an easy topic people would not struggle and a blog would not be necessary ;)

The code above will create the argocd Kubernetes namespace and deploy the latest stable manifest. If you would like to install a specific manifest, have a look here.

In this blog post, we will demonstrate how easy and fast it is to deploy Sveltos on an RKE2 cluster with the help of ArgoCD, register two RKE2 Cluster API (CAPI) clusters and create a ClusterProfile to deploy Prometheus and Grafana Helm charts down the managed CAPI clusters.

Argo CD