argo-helm VS spring-boot-debug-app

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

resource "helm_release" "argocd" { name = "${var.environment}-argocd" namespace = "${var.environment}-argocd" create_namespace = true repository = "https://argoproj.github.io/argo-helm" version = "${var.helm_version}" chart = "argo-cd" set { name = "server.service.type" value = "LoadBalancer" } set { name = "server.service.loadBalancerIP" value = "${var.loadBalancerIP}" } values = [ <<-YAML --- global: image: tag: "${var.image_tag}" configs: repositories: gitops-homelab: url: [email protected]:myprivaterepo/gitops-homelab.git name: private-repo type: git sshPrivateKey: file("${path.module}/sa_keys/private/${var.environment}_id_rsa") server: extraArgs: - --insecure YAML ] } output "file_location" { value = file("${path.module}/sa_keys/private/${var.environment}_id_rsa") }

"argo-cd" = { repository = "https://argoproj.github.io/argo-helm", chart = "argo-cd", namespace = "argocd" values_file = templatefile("./values/argocd.yml", { ingress_scheme = "internal" #internet-facing or internal elb_name = aws_lb.this["${local.name}-int-a"].name })

repository = "https://argoproj.github.io/argo-helm" chart = "argo-cd" namespace = "argo" version = "5.34.5"

I think your example with the ArgoCD Helm chart says it all. It can get incredibly complicated, and I had tremendous trouble getting it working, it broke all the time, getting the indentation right was a nightmare ... very unpleasant experience. I mean look at that chart, the authors have to constantly specify the indentation level everywhere.

This is a GitHub link to my demo app. It’s simple Spring Boot web app used to debugging various stuff. There are many ways to configure JSON logging in Spring Boot. I decided to use Logback because it is easy to configure and one of the most widely used logging library in the Java Community. To enable JSON logging we need to add below dependencies.

My demo app (GitHub Link) uses Spring Boot version 3, or more precisely the latest release from 2022, i.e. 3.0.1. The core monitoring component in Spring Boot is Actuator. If you remember the migration of Spring Boot from version 1 to 2, you’ll probably remember that update brought a lot of breaking changes in Actuator. Fortunately, in the case of version 3, no such changes have been made, so you can apply the following configurations to Spring Boot version 2.x.x

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: demo spec: destination: namespace: sandbox server: https://kubernetes.default.svc project: default source: path: infra/helm repoURL: https://github.com/luafanti/spring-boot-debug-app targetRevision: main plugin: env: - name: HELM_VALUES value: | serviceAccount: create: true image: repository: luafanti/spring-boot-debug-app tag: main pullPolicy: IfNotPresent replicaCount: 1 resources: memoryRequest: 256Mi memoryLimit: 512Mi cpuRequest: 500m cpuLimit: 1 probes: liveness: initialDelaySeconds: 15 path: /actuator/health/liveness failureThreshold: 3 successThreshold: 1 timeoutSeconds: 3 periodSeconds: 5 readiness: initialDelaySeconds: 15 path: /actuator/health/readiness failureThreshold: 3 successThreshold: 1 timeoutSeconds: 3 periodSeconds: 5 ports: http: name: http value: 8080 management: name: management value: 8081 envs: - name: VAULT_SECRET_USER value: - name: VAULT_SECRET_PASSWORD value: log: level: spring: "info" service: "info" syncPolicy: {}