Sì - pila di cedro di Heroku consente di eseguire quello che vuoi.
Il blocco base dello stack Cedar è il banco. Ogni banco di prova riceve una copia effimera dell'applicazione, 512 MB di RAM e un po 'di tempo di CPU condiviso. Si prevede che i dynos Web colleghino un server HTTP alla porta specificata nella variabile di ambiente $PORT, poiché è lì che Heroku invierà le richieste HTTP, ma a parte questo, i web dynos sono identici ad altri tipi di dynos.
L'applicazione comunica a Heroku come eseguire i vari componenti definendoli nello Procfile. (Vedere Declaring and Scaling Process Types with Procfile.) L'articolo Processi di clock dimostra un pattern in cui si utilizza un dyno worker (cioè non Web) per accodare il lavoro in base a criteri arbitrari. Di nuovo, puoi fare tutto ciò che vuoi qui - basta definirlo in un Procfile e Heroku lo gestirà felicemente. Se segui un processo di clock (ad esempio un 24x7 whenever), utilizzerai un intero banco di prova ($ 0,05/ora) per non fare altro che programmare il lavoro.
Nel tuo caso, prenderei in considerazione il passaggio da Whenever a Heroku Scheduler. Scheduler è fondamentalmente un cron di Heroku, dove le voci di crontab sono "spin up a dyno ed esegui questo comando". Pagherete ancora $ 0,05/ora per i dynos extra, ma a differenza del setup di clock + worker, pagherete solo il tempo che effettivamente spenderanno in esecuzione. Separa in modo pulito le attività periodiche dal traffico web + worker allo stato stazionario e di solito è anche significativamente più economico.
L'unica altra parola di avviso è che l'esecuzione di attività periodiche in sistemi distribuiti è complessa e presenta modalità di errore complesse. Alcuni degli incidenti di piattaforma (corrispondenti alle grandi interruzioni EC2) hanno portato a cose come 2 processi di clock simultanei e sessioni di scheduler duplicate. Se stai facendo qualcosa che deve essere eseguito in serie (come inviare email alle persone una volta al giorno), considera la possibilità di proteggerlo con il blocco RDBMS e verifica che siano effettivamente trascorse circa 23 ore dal tuo lavoro quotidiano.
Sì, sto sicuramente cercando di passare le mie attività ogni volta a scheduler, ma abbiamo ancora bisogno del processo in background costante per eseguire la coda di lavoro in ritardo. Ora il mio unico problema è il DJ q sta eseguendo tutte le attività in una volta ogni giorno quando si riavvia, Heroku UTC v le volte EST nel problema del DB probabilmente ... Hai mai avuto problemi con i tempi su Heroku? – TheIrishGuy
Ho trasferito alcune app a Heroku da ambienti che presuppongono un determinato fuso orario. Puoi dire "heroku config: set TZ =" per impostare l'ora locale per i processi dell'applicazione e dire "ALTER USER Timezone SET = " per modificare il fuso orario del database tramite una variabile di sessione. –
willglynn
Vorrei solo chiarire che non penso che 'everytime' sia un gioiello del processo di clock' '24x7'. È solo uno strumento per generare crontabs (che non penso lavori su Heroku). Altre gemme, tuttavia, come i processi di clockwork' _are_ 24x7, che sarebbero costosi da utilizzare solo per il lavoro occasionale in background. –