# ArgoCD Adoption Inventory — DMZ Cluster

Stand: 2026-06-19 12:55 UTC

## Ziel

Alle noch benoetigten Services im DMZ-K3s sollen perspektivisch ueber IT15-ArgoCD / `GitMasterOne/platform-gitops` verwaltet werden.

Dieser Stand ist read-only erhoben. Es wurden keine Cluster-Ressourcen veraendert.

## Bereits ueber IT15-ArgoCD gemanaged

### PIDOKA Fachanwendungen

- `pidoka-n8n`
  - Namespace: `hf-n8n`
  - Status: `Synced / Healthy`
  - Ressourcen: Deployment, Service, Ingress, PVC, ConfigMap, ServiceAccount
  - Secrets-App: `pidoka-n8n-secrets`, `Synced / Healthy`

- `pidoka-hf-matomo`
  - Namespace: `pidoka-hf-matomo`
  - Status: `Synced / Healthy`
  - Ressourcen: Deployments, Services, Ingress, PVCs
  - Secrets-App: `pidoka-hf-matomo-secrets`, `Synced / Healthy`

- `pidoka-hf-mautic`
  - Namespace: `hf-mautic`
  - Status: `Synced / Healthy`
  - Ressourcen: Deployment, Cron Deployment, StatefulSet, Services, Ingress, PVCs
  - Secrets-App: `pidoka-hf-mautic-secrets`, `Synced / Healthy`

- `pidoka-hf-suitecrm`
  - Namespace: `hf-suitecrm`
  - Status: `Synced / Healthy`
  - Ressourcen: Deployment, StatefulSet, Services, Ingress, PVCs
  - Secrets-App: `pidoka-hf-suitecrm-secrets`, `Synced / Healthy`

- `pidoka-hf-zammad`
  - Namespace: `zammad`
  - Status: `Synced / Healthy`
  - Ressourcen: StatefulSets, Deployment, Services, PVCs, ConfigMaps, ServiceAccount
  - Secrets-App: `pidoka-hf-zammad-secrets`, `Synced / Healthy`

- `pidoka-hf-homarr`
  - Namespace: `homarr`
  - Status: `Synced / Healthy`
  - Rolle: produktives Dashboard fuer PIDOKA/HF Anwendungen.
  - Ressourcen: Deployment `my-homarr`, Service `my-homarr`, aktive PVCs `my-homarr-config`, `my-homarr-icons`, `my-homarr-data`.
  - Hinweis: Ressourcennamen wurden bewusst nicht umbenannt, um Service/NodePort/PVCs stabil zu halten.

### Plattform

- `platform-infisical-dmz`
  - Namespace: `platform-infisical`
  - Status: `Synced / Healthy`
  - Ressourcen: Infisical, PostgreSQL, Redis, Services, NetworkPolicies, ServiceAccounts, Role/RoleBinding

- `platform-external-secrets`
  - Namespace: `external-secrets`
  - Status: `Synced / Degraded`
  - Funktional live gruen; Degraded kommt von ungenutzten ESO Generator-CRDs mit `ShortNamesConflict`.
  - ESO-Upgrade-Plan liegt in `/home/node/.openclaw/workspace/ESO_UPGRADE_PLAN_20260619.md`.

- `platform-argocd-projects`
  - Namespace: `argocd`
  - Status: `Synced / Healthy`

## Noch nicht sauber in IT15-ArgoCD

### Hohe Prioritaet: Fach-/Nutzerservices oder sichtbar exponierte Tools

1. `homarr` Alt-/Restthemen nach Adoption
   - Namespace: `homarr`
   - Produktiver Teil ist jetzt IT15-ArgoCD-managed via `pidoka-hf-homarr`.
   - Weiter offen:
     - Secret `my-homarr-homarr-secrets` ist noch als bestehendes Kubernetes Secret referenziert, nicht via ESO/Infisical modelliert. Es enthaelt `NEXTAUTH_SECRET`, den Homarr fuer NextAuth-/Session-Signatur nutzt.
   - Bereinigt 2026-06-19:
     - Alte PVCs `my-homarr-data-new` und `my-homarr-data-mb` wurden geprueft und geloescht.
     - Beide enthielten nur je eine alte `db.sqlite` Kopie plus `lost+found`.
     - Beide alten DB-Kopien hatten dieselbe Checksum, unterschieden sich aber von der aktiven `/data/db.sqlite`.
     - Zugehoerige PVs/Longhorn-Volumes sind nicht mehr sichtbar.
     - Alte Migration-Jobs `volume-migration*` wurden geloescht.
     - Altes Helm Release Secret `sh.helm.release.v1.my-homarr.v1` wurde geloescht.
   - Empfehlung:
     - Secret spaeter nach Infisical/ESO ueberfuehren.

### Mittlere Prioritaet: Plattform-Komponenten

2. `longhorn-system`
   - Bestand: Longhorn Manager, UI, CSI Komponenten, Webhooks, Engine Image.
   - Aktueller Ursprung: alt/manuell, nicht IT15-ArgoCD.
   - Risiko:
     - Storage-Komponente; Adoption/Upgrade braucht eigenen Backup-/Rollback-Plan.
   - Empfehlung:
     - Nicht als erstes anfassen. Separaten Longhorn GitOps-/Upgrade-Plan erstellen.

3. `sealed-secrets-controller`
   - Namespace: `kube-system`
   - Bestand: `deployment/sealed-secrets-controller`, Services.
   - Aktueller Ursprung: alt/manuell, nicht IT15-ArgoCD.
   - Bewertung:
     - Da ESO/Infisical jetzt Zielmodell ist, Bedarf klaeren. Wenn keine SealedSecrets mehr genutzt werden: spaeter dekommissionieren statt adoptieren.

4. K3s System-Komponenten
   - `traefik`: K3s HelmChart, nicht direkt ArgoCD.
   - `coredns`, `metrics-server`, `local-path-provisioner`: K3s/System.
   - Empfehlung:
     - Nicht blind nach ArgoCD ziehen. Diese gehoeren eher in K3s-Konfigurations-/Cluster-Bootstrap-Management.

### Altlasten / Cleanup-Kandidaten

5. Alte/local-path PVCs
   - Mehrere PVCs aus frueheren Releases/Umzuegen sind weiterhin vorhanden.
   - Empfehlung:
     - Nicht pauschal loeschen. Erst pro Service Daten-/Backup-Entscheidung.

## Empfohlene Reihenfolge

1. Homarr Secret spaeter nach Infisical/ESO ueberfuehren.
2. Longhorn separat planen.
3. K3s-Systemkomponenten separat behandeln, nicht als normale App-Migration.

## Bereinigt 2026-06-19

- `dashy`
  - Mislav bestaetigte: Dashy wird nicht mehr benoetigt und kann komplett entfernt werden.
  - Vor Cleanup gefunden:
    - Namespace `dashy`
    - Deployment/Pod `my-dashy`
    - Service `my-dashy` NodePort `32399`
    - PVC `my-dashy-icons`
    - Helm Release Secret `sh.helm.release.v1.my-dashy.v1`
  - Cleanup:
    - Namespace `dashy` geloescht.
  - Verifikation:
    - Namespace `dashy` nicht mehr vorhanden.
    - Dashy Ressourcen nicht mehr abrufbar.
    - PV `pvc-343a1a01-c7ac-4150-9401-fc497826be6e` fuer `my-dashy-icons` nicht mehr sichtbar.
    - Nginx Proxy Manager hat keinen Proxy-Host mit `dashy` und keinen Forward auf Port `32399`.

- `portainer`
  - Mislav bestaetigte: Portainer ist alt und kann weg.
  - Vor Cleanup gefunden:
    - Namespace `portainer`
    - Deployments/Pods `portainer` und `portainer-agent`
    - LoadBalancer Services `portainer` und `portainer-agent`
    - PVC `portainer`
    - Helm Release Secrets `sh.helm.release.v1.portainer.v1` und `sh.helm.release.v1.portainer.v2`
  - Cleanup:
    - Namespace `portainer` geloescht.
  - Verifikation:
    - Namespace `portainer` nicht mehr vorhanden.
    - Portainer Kubernetes Services nicht mehr sichtbar.
    - PV `pvc-cd93bea7-94f0-490c-969d-5125ac827f4b` fuer PVC `portainer` nicht mehr sichtbar.
    - Nginx Proxy Manager hat keinen Proxy-Host mit `portainer` und keinen Forward auf die alten Cluster-Portainer-Ports.
  - Hinweis:
    - Separater Docker-Portainer auf dem Nginx-Proxy-Host `192.168.20.20` wurde nur erkannt, aber nicht veraendert.

- `bitwarden`
  - Mislav gab OK: leerer Namespace kann weg.
  - Vor Cleanup gefunden:
    - Namespace `bitwarden`
    - Keine Workloads, Services, PVCs oder eigenen Secrets; nur `kube-root-ca.crt`.
  - Cleanup:
    - Namespace `bitwarden` geloescht.
  - Verifikation:
    - Namespace `bitwarden` nicht mehr vorhanden.
    - Keine Ressourcen mehr abrufbar.

- `kubernetes-dashboard`
  - Mislav gab OK: altes Dashboard kann weg.
  - Vor Cleanup gefunden:
    - Namespace `kubernetes-dashboard`
    - Deployments/Pods `kubernetes-dashboard` und `dashboard-metrics-scraper`
    - Service `kubernetes-dashboard` NodePort `31351`
    - Dashboard ConfigMaps/Secrets
    - Keine PVCs
  - Cleanup:
    - Namespace `kubernetes-dashboard` geloescht.
  - Verifikation:
    - Namespace `kubernetes-dashboard` nicht mehr vorhanden.
    - Dashboard Ressourcen nicht mehr abrufbar.
    - Nginx Proxy Manager hat keinen Proxy-Host mit `dashboard`/`bitwarden` und keinen Forward auf Port `31351`.

- `keycloak`
  - Mislav bestaetigte: Keycloak war nur Test und kann weg.
  - Vor Cleanup gefunden:
    - Namespace `keycloak`
    - StatefulSets/Pods `keycloak` und `keycloak-postgresql`
    - LoadBalancer Service `keycloak` mit NodePort `32184`
    - PVC `data-keycloak-postgresql-0`
    - Helm Release Secret `sh.helm.release.v1.keycloak.v1`
  - Cleanup:
    - Namespace `keycloak` geloescht.
  - Verifikation:
    - Namespace `keycloak` nicht mehr vorhanden.
    - Keycloak Services im Namespace nicht mehr sichtbar.
    - PV `pvc-31e58295-bbc8-4db6-8045-14a9875ac012` fuer `data-keycloak-postgresql-0` nicht mehr sichtbar.
    - Nginx Proxy Manager hat keinen Proxy-Host mit `keycloak`.
- `default/my-release`
  - Mislav bestaetigte: der separate alte Keycloak-Teststack kann auch weg.
  - Vor Cleanup gefunden:
    - StatefulSets/Pods `my-release-keycloak` und `my-release-postgresql`
    - Services `my-release-keycloak`, `my-release-keycloak-headless`, `my-release-postgresql`, `my-release-postgresql-hl`
    - PVC `data-my-release-postgresql-0`
    - ConfigMap `my-release-keycloak-env-vars`
    - Secrets `my-release-keycloak`, `my-release-postgresql`, `sh.helm.release.v1.my-release.v1`
  - Cleanup:
    - Alle Ressourcen mit Label `app.kubernetes.io/instance=my-release` im Namespace `default` geloescht.
    - Helm Release Secret `sh.helm.release.v1.my-release.v1` geloescht.
  - Verifikation:
    - Keine Ressourcen mit Label `app.kubernetes.io/instance=my-release` mehr sichtbar.
    - PV `pvc-c6424e75-9924-42d0-87fb-8596eb7eb069` fuer `data-my-release-postgresql-0` nicht mehr sichtbar.
    - Keine `my-release`-/Keycloak-Services mehr sichtbar.

- `hf-matomo`
  - Mislav bestaetigte: alter Rollback-Pfad wird nicht mehr benoetigt.
  - Einordnung:
    - `hf-matomo` war die alte Produktion und kurzfristiger Rollback-Bestand nach Cutover auf `pidoka-hf-matomo`.
    - Sicherheitskopien liegen weiter auf der Control-Plane, u.a. `/home/kube-bot/backups/matomo-20260617T060849Z/` und `/home/kube-bot/backups/matomo-cutover-20260617T135148Z/`.
  - Vor Cleanup gefunden:
    - Namespace `hf-matomo`
    - Deployment `matomo` skaliert auf `0/0`
    - Deployment/Pod `matomo-db` laufend `1/1`
    - Services `matomo`, `matomo-db`
    - PVCs `matomo-pvc`, `matomo-db-pvc`
  - Cleanup:
    - Namespace `hf-matomo` geloescht.
    - Released PVs `pvc-f6714be0-39b1-47e6-baa2-2e1ae801d907` und `pvc-61155551-a7de-4c0c-b558-f86437232148` geloescht.
    - Uebrig gebliebene Longhorn Volume-CRs fuer diese beiden PVs geloescht.
  - Verifikation:
    - Namespace `hf-matomo` nicht mehr vorhanden.
    - Alte PVs und Longhorn-Volumes nicht mehr sichtbar.
    - Neuer Stack `pidoka-hf-matomo` laeuft weiter: Matomo und DB Pods `1/1`, aktive PVCs gebunden.
    - `https://matomo.heckenfels.com/` antwortet HTTP `200`.

## Needs OK

- Diese Inventur ist read-only abgeschlossen.
- Jede Adoption bedeutet GitOps-Commit und ArgoCD-Application-Anlage oder Ressourcentransfer und braucht explizites OK.
- Jede Bereinigung alter Namespaces/PVCs/Services braucht separates OK.