# ArgoCD-/Mandanten-Migrationsmatrix — Stand 2026-06-15 15:45 UTC

Quelle: read-only Inventur über DMZ-K3s (`192.168.20.40`), IT15-ArgoCD (`192.168.1.121`) und Nginx Proxy Host (`192.168.20.20`). Keine Secrets ausgegeben. Keine Cluster-Änderungen durchgeführt.

## Zielbild

- Neues führendes Argo CD: IT15 Management-K3s, Namespace `argocd`.
- DMZ-ArgoCD in `infra-argocd` wird schrittweise abgelöst.
- Mandantentrennung über ArgoCD AppProjects + Namespace-Konventionen:
  - `platform-*`: Plattformdienste, Ingress, Storage, Observability, Security, ArgoCD/Infisical-Integration.
  - `tenant-cattaro`: Cattaro-Fachanwendungen.
  - `tenant-pidoka`: Pidoka/Heckenfels-Fachanwendungen.
- Infisical-Struktur soll parallel zu AppProjects/Namespaces aufgebaut werden; keine Klartext-Secrets in Git/Slack/Logs.
- Migration App-für-App, kein Big Bang.

## Aktueller ArgoCD-Stand

### IT15 ArgoCD — Zielsystem

| App | Project | Zielcluster | Namespace | Status | Bewertung |
| --- | --- | --- | --- | --- | --- |
| `demo-guestbook-cattaro-stage` | `default` | `https://192.168.20.40:6443` | `tenant-cattaro-stage` | Synced/Healthy | Pilot-Durchstich grün; sollte später in `tenant-cattaro` Project überführt werden. |

Vorhandene IT15 AppProjects: `default`, `tenant-cattaro`.

### Altes DMZ-ArgoCD — Quellsystem

| App | Project | Repo/Chart | Ziel-Namespace | Status | Migrationsbewertung |
| --- | --- | --- | --- | --- | --- |
| `n8n` | `default` | Helm Chart `8gears.container-registry.com/library/n8n`, target `2.0.1` | `hf-n8n` | Synced/Healthy | Pidoka/Heckenfels App; gute frühe Migration, weil aktuell gesund. Secrets/PVC prüfen. |
| `hf-mautic` | `default` | `https://github.com/GitMasterOne/ArgoCD.git`, path `charts/mautic` | `hf-mautic` | Synced/Healthy, aber Jobs warnen | Pidoka/Heckenfels App; vor Migration CronJob-/CLI-Warnungen klären. |
| `hf-espocrm` | `default` | `https://github.com/GitMasterOne/ArgoCD.git`, path `espocrm` | `hf-espocrm` | OutOfSync/Healthy | Pidoka/Heckenfels App; Drift zuerst analysieren, dann migrieren. |
| `suitecrm` | `default` | `https://github.com/GitMasterOne/ArgoCD.git`, path `charts/suitecrm` | `hf-suitecrm` | Synced/Progressing | Pidoka/Heckenfels App; nicht als erste migrieren, da App aktuell nicht gesund/ImagePullBackOff sichtbar. |
| `apps` | `default` | `https://github.com/GitMasterOne/ArgoCD`, path `applications` | `infra-argocd` | OutOfSync/Healthy | App-of-apps/Bootstrap des alten DMZ-ArgoCD; erst nach Einzelmigrationen stilllegen. |

## Laufende DMZ-Workloads nach grober Zuordnung

### Platform / Infrastruktur

| Namespace | Komponenten | Status / Risiko | Empfehlung |
| --- | --- | --- | --- |
| `kube-system` | Traefik, CoreDNS, metrics-server, ServiceLB, sealed-secrets | Basisdienste laufen; `svclb-keycloak` Pending alt | Platform-Inventar behalten; Keycloak LB-Konflikt separat prüfen. |
| `longhorn-system` | Longhorn Manager/UI/CSI | läuft, bekanntes Replica-Thema bei 2 Nodes | Vor produktiver App-Migration Backup/Restore/Replica-Konzept sauberziehen. |
| `infra-argocd` | altes DMZ-ArgoCD | mehrere Apps verwaltet; öffentlich via `argocd.cattaro.eu` Ingress | Nach Migration deaktivieren/entfernen nur mit explizitem OK. |
| `portainer` | Portainer + Agent | LoadBalancer/NodePorts offen | Exposure/Rolle prüfen; ggf. später absichern/abbauen. |
| `kubernetes-dashboard` | Dashboard + Metrics Scraper | NodePort `31351` | Admin-Oberfläche; Exposure prüfen und reduzieren. |

### Cattaro / interne Dienste / Legacy

| Namespace | Komponenten | Indizien | Empfehlung |
| --- | --- | --- | --- |
| `tenant-cattaro-stage` | `guestbook-ui` | IT15-ArgoCD Pilot, Synced/Healthy | Pilot behalten bis echte Cattaro-App bereit; später ins `tenant-cattaro` Project verschieben. |
| `dashy` | Dashy | Domain/Service unklar, NodePort | Mandant/Rolle klären: Dashboard intern? Dann eher Cattaro/Platform. |
| `homarr` | Homarr | `dashboard.heckenfels.com` zeigt laut NPM auf NodePort `30718` | Vermutlich Pidoka/Heckenfels oder Shared Dashboard; fachlich klären. |
| `bitwarden` | Namespace vorhanden, Proxy `bitwarden.cattaro.eu` zeigt auf `192.168.20.20:8080` | Nicht im aktuellen K8s Workload-Auszug sichtbar | Prüfen, ob Docker auf Raspi oder K8s Altlast. |
| `keycloak`, `default/my-release-keycloak` | Keycloak/PostgreSQL mehrfach | Legacy/unklare Zuordnung | Vor Migration fachlich klären; keine erste Migration. |
| `zammad` | Zammad Stack | LoadBalancer `8080`; NPM `service.heckenfels.com` zeigt auf `192.168.20.40:8080` | Vermutlich Pidoka/Heckenfels Service; gesund wirkend, aber Storage local-path. |

### Pidoka / Heckenfels Fachanwendungen

| Namespace | App | Ingress/Domain | Status | Migrationspriorität |
| --- | --- | --- | --- | --- |
| `hf-n8n` | n8n | `n8n.heckenfels.com` | Running, Argo Synced/Healthy | P1 — guter erster echter Kandidat nach Secret/PVC-Check. |
| `hf-matomo` | Matomo + DB | `matomo.heckenfels.com` | Running, nicht als DMZ-ArgoCD-App sichtbar | P2 — erst GitOps-Quelle herstellen/finden. |
| `hf-mautic` | Mautic + MariaDB/Redis | `mautic.heckenfels.com` | App healthy, CronJobs warnen | P2 — erst CronJob-/CLI-Warnungen analysieren. |
| `hf-espocrm` | EspoCRM + MariaDB | `crm.heckenfels.com` | Running, Argo OutOfSync | P2 — Drift analysieren. |
| `hf-suitecrm` | SuiteCRM + MariaDB | `suitecrm.heckenfels.com` | Deployment 0/1, ImagePullBackOff/Progressing | P3 — erst reparieren/entscheidet ob migrieren oder ablösen. |
| `zammad` | Zammad | `service.heckenfels.com` via NPM auf `192.168.20.40:8080` | Running | P2 — Quelle/Owner prüfen, Storage local-path beachten. |

## Nginx Proxy Manager — relevante Proxy Hosts

| Domain | Forward | Enabled | SSL forced | Zuordnung / Hinweis |
| --- | --- | --- | --- | --- |
| `nextcloud.cattaro.eu` | `http://192.168.20.30:80` | ja | ja | Nicht K3s, Cattaro/Nextcloud. |
| `office.cattaro.eu` | `http://office.cattaro.eu:80` | ja | nein | Nicht direkt K3s; DNS/Loop prüfen. |
| `service.heckenfels.com` | `http://192.168.20.40:8080` | ja | nein | Vermutlich Zammad LoadBalancer. |
| `meshcentral.cattaro.eu` | `https://192.168.188.42:2087` | ja | ja | Nicht K3s, Intranet/Management. |
| `dashboard.heckenfels.com` | `http://192.168.20.40:30718` | ja | ja | Homarr NodePort. |
| `bitwarden.cattaro.eu` | `http://192.168.20.20:8080` | ja | ja | Raspi/Docker oder lokaler Dienst; nicht K3s-Traefik. |

## Haupt-Risiken vor Migration

1. DMZ-K3s Version-Mismatch: Control-Plane `v1.28.4+k3s2`, Worker `v1.29.3+k3s1`.
2. Longhorn mit bekanntem Replica-/Degraded-Thema bei nur zwei Nodes.
3. Alte DMZ-ArgoCD-AppProjects sind faktisch alles `default`; keine Mandantentrennung.
4. Mehrere Admin-/Management-Oberflächen sind exponiert oder direkt per NodePort/LoadBalancer erreichbar: ArgoCD alt, Portainer, Dashboard, NPM UI.
5. Einige Apps sind nicht gesund oder haben Drift (`suitecrm`, `hf-espocrm`, Mautic CronJobs).
6. Mix aus `local-path` und `longhorn` Storage; Migration darf PVCs/Backups nicht beiläufig anfassen.

## Empfohlener Migrationsplan

### Phase A — Zielstruktur vorbereiten (read-only/low-risk + spätere OKs)

1. IT15 ArgoCD AppProjects finalisieren:
   - `platform-core`, `platform-security`, `platform-observability` oder schlanker Start mit `platform`
   - `tenant-cattaro`
   - `tenant-pidoka`
2. Infisical Struktur parallel definieren:
   - `platform-kubernetes/prod:/platform/...`
   - `platform-kubernetes/prod:/tenants/cattaro/...`
   - `platform-kubernetes/prod:/tenants/pidoka/...`
3. Repository-Struktur festlegen:
   - entweder bestehendes `GitMasterOne/ArgoCD` restrukturieren
   - oder neues sauberes GitOps-Repo.

### Phase B — Pilot nach Mandantenmodell

1. Bestehende Demo-App `demo-guestbook-cattaro-stage` vom IT15 `default` Project in `tenant-cattaro` überführen.
2. Kein Public Ingress nötig; nur ArgoCD/RBAC-Modell validieren.
3. Danach Demo-App optional entfernen oder als Testfixture behalten — nur mit OK.

### Phase C — erste echte App migrieren

Empfohlener erster Kandidat: `hf-n8n`.

Begründung:
- aktuell `Synced/Healthy`
- überschaubarer Scope: Deployment/Service/Ingress/PVC
- fachlich klar Pidoka/Heckenfels
- weniger kaputt als `suitecrm`, weniger Drift als `hf-espocrm`

Vor Migration zwingend read-only prüfen:
- aktuelle Manifeste/Helm-Werte aus altem ArgoCD
- Secrets/Env ohne Werte auszugeben
- PVC/Longhorn Zustand + Backup-Punkt
- Ingress/NPM/TLS Pfad
- Rollback: altes DMZ-ArgoCD bleibt bis Cutover eingefroren/verfügbar.

### Phase D — restliche Apps

Reihenfolge nach Risiko:
1. `hf-n8n`
2. `hf-matomo` oder `zammad` nach Quellenklärung
3. `hf-mautic` nach CronJob-Analyse
4. `hf-espocrm` nach Drift-Analyse
5. `hf-suitecrm` erst nach Health-/ImagePull-Fix oder Ablöseentscheidung
6. Altes `infra-argocd/apps` zuletzt deaktivieren/entfernen.

## Nächster konkreter Schritt

Empfehlung: Phase B starten — Demo-App im IT15-ArgoCD vom `default` Project in `tenant-cattaro` überführen bzw. neu sauber im `tenant-cattaro` Project deklarieren. Das ist der kleinste sichere Schritt, um Mandantenmodell und DMZ-Zielclusterzugriff zu validieren.

Needs OK für schreibende Änderung in ArgoCD: AppProject-/Application-Anpassung der Demo-App.

## Update — Mandanten-Pilot umgesetzt — 2026-06-15 15:48 UTC

- `tenant-cattaro` AppProject auf IT15 ArgoCD erlaubt jetzt zusätzlich das DMZ-Ziel `https://192.168.20.40:6443` für Namespace `tenant-cattaro-stage`.
- `demo-guestbook-cattaro-stage` wurde vom Project `default` ins Project `tenant-cattaro` verschoben.
- Status nach Änderung: `Synced/Healthy`.
- DMZ-Verifikation: `guestbook-ui` läuft weiterhin im Namespace `tenant-cattaro-stage`.
- Ergebnis: Das Mandantenmodell ist technisch mit dem DMZ-Zielcluster validiert.

## Update — GitHub-/Repository-Credentials Check — 2026-06-15 15:50 UTC

- Neues IT15-ArgoCD hat aktuell keine Repository-/Repo-Creds-Secrets.
- Öffentliche GitHub-Repos funktionieren ohne Credentials, wie die Demo-App zeigt.
- Altes DMZ-ArgoCD hat ein Repository-Credential für `https://github.com/GitMasterOne/ArgoCD.git` mit Username/Password; Secretwerte wurden nicht ausgegeben.
- Migrationsblocker vor echten Apps: GitHub Credential/Repo-Zugriff für IT15-ArgoCD sauber einrichten, idealerweise über Infisical verwaltet und nicht aus dem alten ArgoCD-Secret blind kopiert.

## Update — neues GitOps-Repo angebunden — 2026-06-15 16:18 UTC

- Neues privates Repo: `https://github.com/GitMasterOne/platform-gitops.git`.
- Initiale Zielstruktur wurde gepusht, Commit `ae57069`.
- IT15-ArgoCD Repository-Credential `repo-platform-gitops` wurde erstellt.
- Bootstrap-App `platform-argocd-projects` ist `Synced/Healthy`.
- Damit ist die Basis für Mandanten-Apps im neuen Repo gelegt.