argo-helm VS cloudnative-pg

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

In this blog post, we'll explore how to combine CloudNative-PG (a PostgreSQL operator) and Ceph Rook (a storage orchestrator) to create a PostgreSQL cluster that scales easily, recovers from failures, and ensures data persistence - all within an Amazon Elastic Kubernetes Service EKS cluster.

My holiday project was doing another pass at my Homelab Kubernetes cluster, part of which involved switching to a proper operator to manage Postgres. Coincidentally, I setup cloudnative-pg (https://github.com/cloudnative-pg/cloudnative-pg) yesterday.

https://github.com/cloudnative-pg/cloudnative-pg/issues/13

/? logical replication:

https://www.google.com/search?q=logical+replication

pgadmin docs > Publication Dialog; logical replication: https://www.pgadmin.org/docs/pgadmin4/development/publicatio...

https://github.com/dalibo/pg_activity#faq ; pip install `pg_activity[psychopg]` :

> FAQ: I can't see my queries only TPS is shown

Only the TPS

(How) Do any ~pg_top tools delineate logical replication activity?

pgcenter > PostgreSQL statistics [virtual tables] (and also /proc)

We already had backup and recovery using object storage, but we are working to support VolumeSnapshots taking care to properly shut down the instance first! This awesome PR is laying the foundation for it, it's adding a subcommand to our kubectl plugin to manually perform a backup using VolumeSnapshots and adding support for restoring a Cluster from it, next step will be adding it to the ScheduledBackup/Backup resources too!

I'll ask in their slack channel later. I've also opened a discussion regarding this on github if you are interesed. https://github.com/cloudnative-pg/cloudnative-pg/discussions/2030

This has a bunch of side-effects that break usual expectations around scheduling. For instance, cluster scale-down (for maintenance etc.) is blocked unless a specific taint has been added to each database pod. In addition, if the underlying node does fail, your cluster will be stuck in fail-over state until you manually delete the underlying pods. I think there are definitely other gotchas around this decision to use a custom controller but I have only tested this on GKE.

Another option would be https://github.com/cloudnative-pg/cloudnative-pg I got to see this talk at Kubecon last month that might be of use to you too -> https://www.youtube.com/watch?v=99uSJXkKpeI That talk is run in part by EDB, who are the company behind CloudNativePG, they are talking about their commercial offering, but the principle is the same.

Following another post on this sub, I was checking out the Github project and landed on this 2864 lined CRD https://github.com/cloudnative-pg/cloudnative-pg/blob/main/config/crd/bases/postgresql.cnpg.io_clusters.yaml. How are sane people reading these files?

**NOTE**: I am a maintainer of CloudNativePG.