## Enterprise Auto-Upgrade Playbook für SLES & RHEL

### Übersicht
Modulares, Enterprise-taugliches Ansible-Playbook für automatisierte Upgrades/Patching von SLES und RHEL. Enthält:
- Automatische OS-Erkennung und OS-spezifische Rollen (RHEL/SLES)
- Upgrade nach Hersteller-Best-Practices (dnf/yum, zypper)
- VMware-Snapshots für Backup/Rollback (vCenter API)
- SUSE Manager API: dynamische CLM-Zuweisung via `target_clm_version`
- Wartungsfenster-Handling, Preflight-Checks
- Smoke-Tests (HTTP/Port/DB, inkl. Oracle SID/Listener-Erkennung)
- Self-Healing (Service-Restarts, Cleanup, Netzwerk)
- Compliance-Checks (OpenSCAP, Lynis)
- Logging, Mail-Benachrichtigung (mailx), optional Slack
- CI/CD via Gitea + Woodpecker (OAuth), Collections-Lint + Dry-Run

### Verzeichnisstruktur (Auszug)
```
os-upgrade-automation/
├── ansible.cfg
├── docs/
│   ├── README.md
│   ├── CHANGELOG.md
│   └── Runbook_SelfService.md
├── playbook/
│   ├── group_vars/
│   │   ├── all.yml
│   │   └── vault.yml            # Mit Ansible Vault verschlüsseln
│   ├── host_vars/
│   ├── playbook.yml
│   ├── requirements.yml
│   ├── servicenow_inventory.yml # Dynamic Inventory (ServiceNow)
│   └── roles/
│       ├── common/
│       ├── preflight_check/
│       ├── vmware_snapshot/
│       ├── suma_api_assign_clm/
│       ├── rhel_upgrade/
│       ├── sles_upgrade/
│       ├── post_upgrade/
│       ├── smoke_tests/
│       ├── self_healing/
│       └── compliance_check/
├── scripts/
│   ├── install_collections.sh
│   └── run_patch.sh
└── .woodpecker.yml
```

### Voraussetzungen
- Ansible (empfohlen ≥ 2.14)
- Collections: `community.vmware`, `servicenow.servicenow`, `community.general`
- vCenter-Zugriff (API), SUSE Manager API-Zugang
- Zielsysteme: SLES oder RHEL (ggf. via SUSE Manager, venv-salt-minion)
- Ansible Vault für Secrets (zwingend empfohlen) [[Speicherpräferenz]]

Installation Collections:
```
make deps
```

### Konfiguration
1) Secrets sicher ablegen (Vault)
- `playbook/group_vars/vault.yml` befüllen (ServiceNow, SUSE Manager, vCenter, SMTP, Slack, DB)
- Datei sofort verschlüsseln:
```
ansible-vault encrypt playbook/group_vars/vault.yml
```

2) Globale Variablen prüfen
- `playbook/group_vars/all.yml` enthält Standardwerte (u.a. Skip-Flags, Mail-Empfänger, Wartungsfenster, Log-Verzeichnis).

3) Dynamic Inventory (ServiceNow)
- `playbook/servicenow_inventory.yml` nutzt den ServiceNow-Inventory-Plugin.
- Erwartet in Vault: `servicenow_instance`, `servicenow_user`, `servicenow_pass`.

### Nutzung (lokal)
- Lint:
```
make lint
```

- Playbook ausführen (Beispiele):
```
# App-Gruppe patchen, Ziel-CLM setzen
make run APP=pdp-portal CLM=prod-2024-06 EXTRA="debug_mode=true"

# Direkter Aufruf
./scripts/run_patch.sh pdp-portal prod-2024-06 "skip_compliance=true skip_smoke_tests=false"
```

Wichtige Extra-Variablen / Skip-Flags:
- `target_clm_version` (z.B. `prod-2024-06`)
- `debug_mode=true|false`
- `skip_vmware_snapshot`, `skip_suma_api`, `skip_post_upgrade`
- `skip_smoke_tests`, `skip_self_healing`, `skip_compliance`
- `upgrade_security_only=true|false`

### Rollenüberblick
- `preflight_check`: Diskspace, Wartungsfenster, Erreichbarkeit, Channel-Sync, pyVmomi-Check
- `vmware_snapshot`: Snapshot anlegen, optional Revert, optional Cleanup
- `suma_api_assign_clm`: System dynamisch CLM-Channel zuordnen
- `rhel_upgrade` / `sles_upgrade`: OS-spezifisches Upgrade, Kernel-Erkennung, Reboot-Flag
- `post_upgrade`: Reboot (optional), Health-Check kritischer Dienste
- `smoke_tests`: HTTP/Port/DB, Oracle (SIDs/Listener dynamisch erkannt)
- `self_healing`: Dienst-Restarts, Disk-Cleanup, Netzwerk-Remediation
- `compliance_check`: OpenSCAP, Lynis, Reporting & Mail
- `common`: Logging, mailx-Konfiguration, Admin-Mail inkl. Log-Anhänge, Slack (optional)

### VMware Snapshot & Rollback
- Vor dem Upgrade wird ein Snapshot mit Zeitstempel erstellt.
- Bei Fehlern kann automatisch ein Rollback getriggert werden (`rollback: true`).
- Optionales automatisches Löschen alter Snapshots nach erfolgreichem Lauf (`snapshot_cleanup`).

### Logging & Benachrichtigung
- Logs in `log_dir` (Standard: `/var/log/auto-upgrade`).
- Admin-Mail an `linux_admins_mail` mit Log-Summary + Anhängen.
- Failsafe-Mail an App- und Host-Kontakte bei Fehler.
- Optional Slack-Benachrichtigung (wenn `slack_enabled` und `slack_token`).

### CI/CD (Gitea + Woodpecker)
1) Repo in Woodpecker aktivieren
- In `https://ci.pp1l.de` auf “Repos” → “Sync” → `os-upgrade-automation` (oder `PurePowerPh1l/os-upgrade-automation`) “Enable”.

2) Secrets in Woodpecker setzen
- Mindestens `ANSIBLE_VAULT_PASSWORD` (für CI-Läufe ohne Interaktion).
- Optional: `SERVICENOW_*`, `SUMA_*`, `VCENTER_*`, `SLACK_TOKEN`, SMTP-Variablen, DB-Testdaten.

3) Pipelines
- `.woodpecker.yml` enthält: `lint`, `dryrun`, manuell `run_preflight`, `run_patch`.
- Hinweis: Interaktive Prompts (`--ask-vault-pass`) funktionieren in CI nicht. Nutze stattdessen eine Secret-basierte Lösung (z.B. Secret als Datei schreiben und `--vault-password-file` verwenden). Passe die Pipeline bei Bedarf an.

4) OAuth/Troubleshooting
- “Unregistered Redirect URI”: Stelle sicher, dass die Gitea-OAuth-App `https://ci.pp1l.de/authorize` als Redirect-URI nutzt.
- “PKCE is required for public clients”: Gitea-OAuth-App als Confidential Client anlegen.
- “registration_closed”: In Woodpecker `WOODPECKER_OPEN=false`, erlaubte Nutzer via `WOODPECKER_ADMIN=<user1,user2>` whitelisten.

### Sicherheit
- Keine Secrets im Klartext: Alles in `playbook/group_vars/vault.yml` ablegen und per Vault verschlüsseln [[Speicherpräferenz]].
- Zugriffsdaten in CI ausschließlich als Secrets verwalten.

### Nützliche Links
- Gitea: `https://git.pp1l.de`
- Woodpecker CI: `https://ci.pp1l.de`
- Ansible VMware Snapshot Modul: `https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_guest_snapshot_module.html`
- SUSE Manager: `https://documentation.suse.com/suma/`

—
Fragen oder Wünsche? Gerne melden.