cloudnative-pg VS argo-helm

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.

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.

plugin: name: argocd-vault-helm env: - name: release_name value: argocd - name: chart_name value: argo-cd - name: chart_repo value: https://argoproj.github.io/argo-helm - name: chart_version value: 5.17.1 - name: chart_values value: -f applicationset.yaml -f configs.yaml -f controller.yaml -f dex.yaml -f redis.yaml -f reposerver.yaml -f server.yaml -f notifications.yaml - name: args value: --include-crds

Another folder I want to discuss shortly is the Terraform folder. This project was installed by terraform basically but it can deployed easily with simple helm installation of ArgoCD . In the next attachment we can see the relevant values neccesary to apply our ArgoCD system : values-override.tpl

Finally, we have to install ArgoCD from the official Helm Chart but with extra configuration that provides modifications required to install Vault plugin via sidecar container.