Wie es funktioniert

Die Architektur, von vorne bis hinten

ip·Solis ist ein Repository: eine Web-App, ein Celery-Worker mit eingebettetem PowerShell-7-Runtime und Beat — dahinter Redis und Postgres. Die meisten Teams sind binnen eines Arbeitstags in Produktion.

Ein kleiner, klarer Stack

Die Web-App und ein Celery-Worker mit eingebettetem PowerShell-7-Runtime, dazu Beat. Redis als Broker, Postgres als Speicher. Reverse Proxy nach Wahl.

  • Web-App — FastAPI (Python 3.12), server-rendered Admin und Portal mit HTMX + Jinja2 + Tailwind
  • Celery-Worker — orchestriert Runbook-Ausführung und Async-Jobs und führt die PowerShell-7-Schritte in-process aus
  • PowerShell 7 — führt Skript-Schritte nativ im Worker aus, auf Linux, mit Kerberos / GSSAPI
  • Beat — plant cron-getriebene Runbooks und die tägliche Kosten-Schwellwertprüfung
  • Redis — Celery-Broker und RedBeat-Schedule-Lock
  • Flower — für Queue-Inspektion in Entwicklung und Incident-Response
Reverse proxyIngress · TLS
FastAPIWeb-App
Celery + PowerShell 7Runbook-Engine
BeatScheduler
RedisBroker
PostgreSQLSpeicher

Flower · Queue-Inspektion (Dev)

PowerShell-7-Worker, auf Linux

Nativ, kein Wrapper. Nutzen Sie die Module und Idiome, die Sie bereits kennen.

  • Kerberos- / GSSAPI-Authentifizierung für SCCM
  • PSGallery-Installs und manueller Zip-Upload zur Laufzeit — über den PS-Module-Store, persistiert im Docker-Volume
  • Pro Schritt: Timeout, Retry und Log-Capture bei Standalone-Runbooks
  • Live-Streaming ins Schritt-Protokoll bei Standalone-Runbooks (bei Order-Provisionierung je Schritt erfasst)

Celery + Beat für die Planung

Standard-Cron-Ausdrücke. Überlappungsschutz, damit ein Standalone-Runbook keinen neuen Lauf startet, solange der vorherige noch aktiv ist, plus Pool-Reservierungen, die dasselbe Asset nie an zwei Aufträge geben.

  • Cron-Pläne pro Runbook
  • Zeitzonen-bewusste Planung für die täglichen Schwellwertprüfungen
  • Skip-if-running-Schutz bei Standalone-Runbooks
  • Drift-Abgleich nach Zeitplan — AD-Änderungen erkennen oder automatisch korrigieren
  • Verlängerungs-, Zertifizierungs- und Attestierungs-Erinnerungen als geplante Beat-Tasks
  • Flower-UI für Live-Inspektion

Joiner, Mover, Leaver — SCIM 2.0 und HR

Ein Identitäts-Lebenszyklus. Ihr IdP oder HRIS steuert ihn; ip·Solis provisioniert, gleicht ab und widerruft.

  1. 01Joiner: Ein neuer Nutzer trifft Ihre Zuweisungsregeln — die zugeordneten Bundles werden automatisch bestellt.
  2. 02Mover: Eine Attributänderung wertet die Regeln neu aus; neue Berechtigungen kommen hinzu, verlorene werden optional widerrufen.
  3. 03Leaver: active=false über /scim/v2/Users oder /hr/leaver widerruft jedes Asset des Nutzers.
  4. 04Jedes Asset startet sein Deprovision-Runbook; regelbasiert vergebener Zugriff wird automatisch zurückgeholt.
  5. 05Jeder Schritt wird im append-only Audit-Log mit voller Zuordnung festgehalten.

Die Auftrags-State-Machine

Jeder Auftrag durchläuft diese Zustandsmaschine. Fehler und Entzüge sind eigene, sichtbare Zustände — nichts wird stillschweigend übergangen.

  1. Pending Approval

    Wartet auf Manager-Genehmigung.

  2. Scheduled

    Genehmigt und in der Worker-Queue.

  3. Processing

    Runbook-Schritte werden ausgeführt.

  4. Provisioned

    Das Asset ist für die Person live.

  5. Failed

    Ein Critical Step ist fehlgeschlagen. Log prüfen.

  6. Rejected

    Ein Manager hat die Anfrage abgelehnt.

  7. Cancelled

    Vor der Verarbeitung storniert.

  8. Revoked

    Zugriff entzogen, Asset zurückgeführt.

  9. Expired

    Gültigkeit abgelaufen; Asset zurückgeführt.

Die Architektur, von vorne bis hinten — ip·Solis