AITM pozwala uruchamiać własne okresowe skrypty konserwacyjne i automatyzujące bezpośrednio w działającej instancji — bez przebudowy obrazu Docker i bez ponownego wdrożenia, wystarczy restart kontenera.

User Jobs (zaplanowane zadania wtyczek)

Gdzie znajduje się folder wtyczek

Każdy build wydania AITM (warianty full, online i thin Docker) zawiera warstwę plugins-runtime/ wbudowaną w obraz. Folderem, który naprawdę ma znaczenie, jest jednak trwały wolumin danych montowany jako bind: plugins w katalogu danych — zwykle $AITM_DATA_DIR/plugins wewnątrz działającego kontenera, a nie ścieżka wewnątrz obrazu.

• Przy pierwszej instalacji jest pusty.
• Przy pierwszym uruchomieniu entrypoint kontenera zasila go referencyjną wtyczką example-scheduled-job — ale tylko jeśli ten podkatalog jeszcze nie istnieje, więc własne zmiany w tym folderze przetrwają aktualizacje i restarty.
• AITM skanuje katalog wtyczek ponownie przy każdym uruchomieniu kontenera — dlatego po dodaniu lub edycji zadania trzeba zrestartować kontener, aby zostało wykryte (przebudowa nie jest wymagana).

Dodawanie własnego zadania

1. Należy utworzyć nowy podkatalog w zamontowanej ścieżce plugins/ (jeden katalog na zadanie/wtyczkę).
2. Należy dodać w nim plik plugin.json zawierający tablicę aitm.jobs.
3. Należy dodać plik skryptu, na który wskazuje handler.path zadania.
4. Należy zrestartować kontener AITM.

Struktura plugin.json

Pole	Opis
name	Unikalny identyfikator zadania.
label	Czytelna nazwa wyświetlana w UI.
intervalMs	Jak często zadanie się powtarza, w milisekundach.
priority	Priorytet planowania — zob. uwaga o bezpieczeństwie poniżej; "high" jest zarezerwowany dla wewnętrznych zadań AITM.
timeoutMs	Maksymalny czas działania, po którym zadanie jest przerywane.
onTimeout	Co się dzieje po osiągnięciu limitu czasu.
heavy	Oznacza zadanie jako zasobochłonne.
parallel	Czy może działać równolegle z innymi zadaniami.
concurrencyGroup	Grupa, w której zadania nigdy nie działają równocześnie.
after	Zadania, które muszą się zakończyć przed uruchomieniem tego.
next	Zadanie do uruchomienia po pomyślnym zakończeniu tego.
minFreeRamMb / minFreeCpuPercent	Minimalne wolne zasoby wymagane do uruchomienia.
kind	'in-process' | 'child-process' | 'remote' — sposób wykonania zadania.
allowedModes	Tryby serwera, w których zadanie może działać.
handler	{ type: 'script', path, args, env } — co jest uruchamiane i w jaki sposób.

Przykład praktyczny

Przykładowa struktura zgodna z dostarczaną wtyczką example-scheduled-job:

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

Dostrajanie zadania bez ponownego wdrożenia

Operator może nadpisać interwał, priorytet lub stan włączenia działającego zadania przez REST, bez restartowania kontenera i bez ponownego wdrażania:

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

Pełna dokumentacja techniczna (szczegóły schematu manifestu zadania, semantyka kind/allowedModes, mechanika limitów czasu i ponowień) znajduje się we własnej dokumentacji AITM.