AITM erlaubt es, eigene periodische Wartungs- und Automatisierungsskripte direkt in der laufenden Instanz auszuführen — ohne Neuaufbau des Docker-Images, ohne erneutes Deployment, nur mit einem Neustart des Containers.

User Jobs (geplante Plugin-Jobs)

Wo der Plugins-Ordner liegt

Jeder AITM-Release-Build (die Docker-Varianten full, online und thin) liefert eine in das Image eingebackene Schicht plugins-runtime/ mit. Der Ordner, auf den es tatsächlich ankommt, ist jedoch das persistente, per Bind-Mount eingebundene Datenvolumen: plugins innerhalb des Datenverzeichnisses — typischerweise $AITM_DATA_DIR/plugins im laufenden Container, kein Pfad innerhalb des Images.

• Er ist bei der Erstinstallation leer.
• Beim ersten Start befüllt der Entrypoint des Containers ihn mit dem Referenz-Plugin example-scheduled-job — aber nur, wenn dieses Unterverzeichnis noch nicht existiert, sodass eigene Änderungen an diesem Ordner Upgrades und Neustarts überstehen.
• AITM durchsucht das Plugins-Verzeichnis bei jedem Container-Start erneut — nach dem Hinzufügen oder Bearbeiten eines Jobs muss daher der Container neu gestartet werden, damit er erkannt wird (ein Rebuild ist nicht nötig).

Einen eigenen Job hinzufügen

1. Unterhalb des eingebundenen Pfads plugins/ wird ein neues Unterverzeichnis angelegt (ein Verzeichnis pro Job/Plugin).
2. Darin wird eine Datei plugin.json mit einem Array aitm.jobs angelegt.
3. Die Skriptdatei, auf die handler.path des Jobs verweist, wird hinzugefügt.
4. Der AITM-Container wird neu gestartet.

Aufbau von plugin.json

Feld	Beschreibung
name	Eindeutige Job-Kennung.
label	Menschenlesbarer Name, der in der Oberfläche angezeigt wird.
intervalMs	Wie oft der Job wiederholt wird, in Millisekunden.
priority	Scheduling-Priorität — siehe den Sicherheitshinweis unten; "high" ist den internen Jobs von AITM vorbehalten.
timeoutMs	Maximale Laufzeit, bevor der Job beendet wird.
onTimeout	Was beim Erreichen des Timeouts geschieht.
heavy	Kennzeichnet den Job als ressourcenintensiv.
parallel	Ob er gleichzeitig mit anderen Jobs laufen darf.
concurrencyGroup	Gruppe, innerhalb derer Jobs nie gleichzeitig laufen.
after	Jobs, die abgeschlossen sein müssen, bevor dieser läuft.
next	Job, der nach erfolgreichem Abschluss dieses Jobs läuft.
minFreeRamMb / minFreeCpuPercent	Mindestmenge freier Ressourcen, die zum Ausführen nötig ist.
kind	'in-process' | 'child-process' | 'remote' — wie der Job ausgeführt wird.
allowedModes	Servermodi, in denen der Job laufen darf.
handler	{ type: 'script', path, args, env } — was läuft und wie.

Durchgespieltes Beispiel

Eine veranschaulichende Struktur, die mit dem mitgelieferten example-scheduled-job übereinstimmt:

{
  "aitm": {
    "jobs": [
      {
        "name": "example-scheduled-job",
        "label": "Example Scheduled Job",
        "intervalMs": 3600000,
        "priority": "normal",
        "timeoutMs": 60000,
        "kind": "child-process",
        "handler": {
          "type": "script",
          "path": "./run.js",
          "args": [],
          "env": {}
        }
      }
    ]
  }
}

Einen Job ohne erneutes Deployment anpassen

Ein Operator kann Intervall, Priorität oder Aktivierungszustand eines laufenden Jobs per REST überschreiben, ohne den Container neu zu starten oder erneut zu deployen:

• GET /api/scheduler/jobs/:name/override
• PUT /api/scheduler/jobs/:name/override

Die vollständige technische Referenz (Interna des Job-Manifest-Schemas, Semantik von kind/allowedModes, Timeout-/Retry-Mechanik) befindet sich in der eigenen Dokumentation von AITM.