Idealogic Production Cluster
This documentation covers the ArgoCD-managed Kubernetes deployments for the Idealogic Production cluster hosted at Xneelo in the Johannesburg data centre.
Cluster overview
Cluster ID |
|
Location |
Xneelo Johannesburg Data Centre |
Management |
Rancher |
GitOps |
ArgoCD with App-of-Apps pattern |
Storage |
Longhorn |
Ingress |
ingress-nginx packaged by RKE2, behind a kube-vip virtual IP (details) |
The cluster is bootstrapped via the cluster-bootstrap.yml manifest, which deploys the root ArgoCD Application. This application monitors the argocd/ directory and automatically deploys all child applications defined there.
Why App-of-Apps?
This cluster uses the App-of-Apps pattern recommended by ArgoCD for cluster bootstrapping. Key benefits:
-
Declarative management - A single root application manages all child applications, enabling consistent deployment across the cluster
-
Automated operations - With automated sync and pruning, applications are created, updated, and removed automatically when manifests change in Git
-
Cascading deletion - Proper cleanup through finalizers ensures child applications and their resources are removed when the parent is deleted
-
Version control integration - All infrastructure changes follow standard Git workflows with code review before deployment
Bootstrapped applications
The following applications are deployed via ArgoCD from the argocd/ directory.
Infrastructure
| Application | Description | Namespace | Source |
|---|---|---|---|
certificates |
TLS certificate resources managed by cert-manager |
Various |
Git: |
external-dns |
Automatic DNS record management with Cloudflare |
|
Helm: |
ssh-bastion |
SSH tunnel access to internal cluster services (details) |
|
Git: |
storage |
Longhorn storage class configurations |
Various |
Git: |
Database infrastructure
| Application | Description | Namespace | Source |
|---|---|---|---|
mysql-operator |
MySQL Operator for Kubernetes (Oracle) |
|
Helm: |
mysql-idealogic-prod |
MySQL InnoDB Cluster for production workloads (details) |
|
Git: |
postgresql-prod |
PostgreSQL database for Chatwoot and SonarQube |
|
Helm: |
redis-prod |
Redis cache in standalone mode |
|
Helm: |
memcache-prod |
Memcached for WordPress object caching |
|
Helm: |
Applications
| Application | Description | Namespace | Source |
|---|---|---|---|
wordpress-wpca-prod |
WP Cycling production WordPress site (wpcycling.com) |
|
Helm: |
wordpress-wpca-test |
WP Cycling test WordPress environment |
|
Helm: |
wp-wpcycling |
WP Cycling WordPress site, immutable Bedrock image on PHP 8.5 ( |
|
Helm (OCI, private): |
jasper-reports |
JasperReports Server for report generation |
|
Helm: |
chatwoot-prod |
Chatwoot customer engagement platform (chat.idealogic.co.za) |
|
Helm: |
event-membership-stage |
Event Membership application staging environment |
|
Git: |
greenmail-dev / greenmail-stage |
SMTP sink for the Event Membership non-production namespaces — no route off the cluster. See Mail Sink |
|
Git: |
snappymail-dev / snappymail-stage |
Webmail onto GreenMail (event-mail-dev / event-mail-stage.idealogic.co.za) |
|
Git: |
idealogic-docs |
Antora documentation site (docs.idealogic.co.za) |
|
Git: doc-site/k8s/ |
Observability
| Application | Description | Namespace | Source |
|---|---|---|---|
opentelemetry-collector |
OpenTelemetry Collector for traces, metrics, and logs |
|
Helm: |
The OpenTelemetry Collector exports telemetry to:
-
Grafana Cloud - Traces (Tempo), metrics (Prometheus), and logs (Loki)
-
Elastic Cloud - APM traces, metrics, and logs
Application dependencies
The following diagram shows the key dependencies between applications:
wordpress-wpca-prod ──┬──> mysql-idealogic-prod (database)
└──> memcache-prod (object cache)
wordpress-wpca-test ────> mysql-idealogic-prod (database)
wp-wpcycling ─────────┬──> mysql-idealogic-prod (database wp_wpcycling)
└──> smtp-relay.gmail.com (outbound mail; admits 197.189.214.88/29, AD-01)
jasper-reports ─────────> mysql-idealogic-prod (database)
chatwoot-prod ──────┬──> postgresql-prod (database)
└──> redis-prod (cache/queues)
event-admin-service ──┐
registration-portal ──┼──> greenmail (SMTP, dev + stage only)
membership-ui ──┘
registration-portal ────> redis-prod (register-session rate-limit counters, stage only)
snappymail ─────────────> greenmail (IMAP + SMTP)Registration portal hostnames
The registration portal is multi-tenant: one deployment per environment serves every
organisation, and each tenant is a hostname on that deployment’s ingress. A hostname only serves
the portal once a tenant row in the portal’s gateway schema maps it to a registration system;
without the row it returns 404.
Production
| Hostname | ArgoCD application | Tenant |
|---|---|---|
|
|
Default tenant (ingress |
|
|
Tour de Worcester |
|
|
Western Cape Schools Cycling (public participant list) |
|
|
WP Cycling. DNS is a CNAME to |
|
|
Myriad Events (ingress |
|
|
Helderberg Nature Reserve |
|
|
Western Cape Schools Cycling |
|
|
HNR VC |
Stage and dev
| Hostname | ArgoCD application | Tenant |
|---|---|---|
|
|
Tour de Worcester (ingress |
|
|
Myriad Events |
|
|
Helderberg Nature Reserve |
|
|
Western Cape Schools Cycling |
|
|
HNR VC |
|
|
WP Cycling |
|
|
Dev (ingress |
The stage database is refreshed from production every night. A stage tenant row survives that refresh, but a registration system created only on stage does not, so a stage-only tenant stops resolving until its registration system exists on production too.
Sync policies
Most applications use automated sync with:
-
prune: true- Remove resources deleted from Git -
selfHeal: true- Revert manual changes to match Git state -
CreateNamespace=true- Automatically create target namespaces
|
The |
Additional resources
-
Source Repository - ArgoCD configuration repository
-
Rancher Manager - Cluster management UI
-
Grafana Cloud - Observability dashboards