AITM consente di eseguire script periodici di manutenzione e automazione personalizzati direttamente all'interno dell'istanza in esecuzione — nessuna ricostruzione dell'immagine Docker, nessun nuovo deploy, solo il riavvio del container.

User Jobs (job di plugin pianificati)

Dove si trova la cartella dei plugin

Ogni build di release di AITM (varianti Docker full, online e thin) include un livello plugins-runtime/ incorporato nell'immagine. La cartella che conta davvero, però, è il volume dati persistente montato (bind mount): plugins all'interno della directory dei dati — in genere $AITM_DATA_DIR/plugins dentro il container in esecuzione, non un percorso all'interno dell'immagine.

• Alla prima installazione è vuota.
• Al primo avvio, l'entrypoint del container la popola con il plugin di riferimento example-scheduled-job — ma solo se tale sottodirectory non esiste già, così le modifiche personali a quella cartella sopravvivono ad aggiornamenti e riavvii.
• AITM esegue nuovamente la scansione della directory dei plugin a ogni avvio del container — quindi, dopo aver aggiunto o modificato un job, occorre riavviare il container perché venga rilevato (non serve alcuna ricostruzione).

Aggiungere un proprio job

1. Creare una nuova sottodirectory nel percorso plugins/ montato (una directory per ogni job/plugin).
2. Aggiungervi un file plugin.json contenente un array aitm.jobs.
3. Aggiungere il file di script a cui punta il handler.path del job.
4. Riavviare il container AITM.

Struttura di plugin.json

Campo	Descrizione
name	Identificatore univoco del job.
label	Nome leggibile mostrato nell'interfaccia.
intervalMs	Ogni quanto il job si ripete, in millisecondi.
priority	Priorità di pianificazione — vedere la nota di sicurezza più sotto; "high" è riservata ai job interni di AITM.
timeoutMs	Tempo massimo di esecuzione prima che il job venga terminato.
onTimeout	Cosa accade quando si raggiunge il timeout.
heavy	Contrassegna il job come impegnativo in termini di risorse.
parallel	Se può essere eseguito in contemporanea con altri job.
concurrencyGroup	Gruppo all'interno del quale i job non vengono mai eseguiti in contemporanea.
after	Job che devono terminare prima dell'esecuzione di questo.
next	Job da eseguire dopo il completamento riuscito di questo.
minFreeRamMb / minFreeCpuPercent	Risorse libere minime richieste per l'esecuzione.
kind	'in-process' | 'child-process' | 'remote' — come viene eseguito il job.
allowedModes	Modalità del server in cui il job può essere eseguito.
handler	{ type: 'script', path, args, env } — cosa viene eseguito e come.

Esempio pratico

Una struttura illustrativa coerente con il example-scheduled-job fornito:

{
  "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": {}
        }
      }
    ]
  }
}

Regolare un job senza nuovo deploy

Un operatore può sovrascrivere via REST l'intervallo, la priorità o lo stato di abilitazione di un job attivo, senza riavviare il container né rifare il deploy:

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

Il riferimento tecnico completo (dettagli interni dello schema del manifest dei job, semantica di kind/allowedModes, meccanica di timeout/retry) si trova nella documentazione di AITM stessa.