argo-helm VS crd-to-sample-yaml

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

Hello everyone!

Previously I wrote about cty[^1] that can be used to generate valid YAML samples from a CRD ( now, including things like, valid Pattern generated random string, enums, default values, minimum int, minimum number of items.. etc ).

It also has a website that can be used to achieve the same thing here: https://crdtoyaml.com/

This update https://github.com/Skarlso/crd-to-sample-yaml/releases/tag/v... brings a feature with it, which I think is super cool. If not, well, then no. :)

Basically, inspired by `helm unittest` the user can define a test like this:

    suite: test aws clusters infrastructure crds

Hello peeps.

I’ve wrote a tool to nicely display crds. I know of docs.crds how is this different? You can paste in the crd and it will generate a sample yaml to boot and you don’t need to point it at a repository. Also it has a cli version. Here is the repo https://github.com/Skarlso/crd-to-sample-yaml.

I hope someone finds this useful. Any feedback is always appreciated. :) Thanks.

Here is the link.

So, I wrote a tool. :D https://github.com/Skarlso/crd-to-sample-yaml