Cron-Jobs und Background-Worker ohne separaten Dyno
Die übliche PaaS-Darstellung behandelt einen Cron-Job und einen Background-Worker als separate Produkte neben deiner Web-App, einen anderen Dashboard-Tab, manchmal eine andere Preisposition. Sie sind eigentlich keine separaten Dinge. Sie sind Prozesse derselben App, und das ist der Teil, den man ernst nehmen sollte statt ihn als Technikalität abzutun.
Was der Workers-Tab tatsächlich bietet
Er zeigt nur Job-Runner, die er tatsächlich in deinem Repository finden kann, keine generische Liste, die du von Grund auf konfigurierst: Prozesse, die in Procfile/Procfile.dev/app.json deklariert sind, oder Runner, die schon in deinen Dependencies stecken (Sidekiq, Solid Queue, GoodJob, Resque, Celery, RQ, Laravels Queue oder Horizon, ein npm run worker-Skript). Füge einen mit einem Klick hinzu, oder zeig selbst auf irgendeinen lang laufenden Befehl, falls nichts erkannt wird. Jeder Worker läuft im eigenen Image der App und skaliert unabhängig vom Web-Prozess.
Dieser letzte Punkt ist wichtiger, als er klingt: Ein Worker ist kein kleineres, separates Deployment, das aus der Synchronisation mit Web driftet, es ist derselbe Build, derselbe Release, derselbe Rollback, nur ein anderer Prozesstyp, der unabhängig skaliert wird.
Worker, die auch schlafen
Eine App nur mit Worker, kein Web-Prozess überhaupt, nur ein Queue-Consumer, kann trotzdem Sleep when idle unter Settings → General nutzen. Sie stoppt, sobald ihre gemeldete CPU-Auslastung lange genug untätig war, und Railyard weckt sie nach seinem eigenen Zeitplan, speziell um alles abzuarbeiten, was sich angesammelt hat, und lässt sie dann wieder einschlafen. Das Muster, das normalerweise von Hand gebaut wird (ein Cron-Job, der einen Worker aufweckt, eine Lambda, die eine Queue-Tiefe prüft), ist hier nur eine Checkbox.
Cron, separat
Cron führt einen Befehl im eigenen Image der App nach einem Zeitplan aus (0 3 * * *), mit aufbewahrter Run-History, kein separater Container, kein separates Image, das mit dem tatsächlichen Code der App synchron gehalten werden muss, weil es wortwörtlich dasselbe Image ist, auf dem alles andere läuft.
Warum das bemerkenswert ist
Die Alternative, ein Cron-Job, der irgendwo außerhalb der Deploy-Pipeline der App definiert ist und auf ein altes Image zeigt, weil niemand es beim letzten Deploy der App aktualisiert hat, ist ein spezifischer, verbreiteter Fehlerfall in Plattformen, die geplante Arbeit als Bürger zweiter Klasse behandeln. Cron und Worker als Prozesstypen einer einzigen App laufen zu lassen bedeutet, dass ein Deploy, der die App fixt, konstruktionsbedingt gleichzeitig ihre geplanten Jobs und ihre Worker fixt, nicht weil man sich daran erinnert hat.
Vollständige Referenz: Workers und geplante Jobs.