rails job ruby-on-rails rake daemon cron runner

ruby on rails - job - Un trabajo cron para los rieles: ¿mejores prácticas?



schedule cron rails (20)

Ambos funcionarán bien. Suelo usar script / runner.

Aquí hay un ejemplo:

0 6 * * * cd /var/www/apps/your_app/current; ./script/runner --environment production ''EmailSubscription.send_email_subscriptions'' >> /var/www/apps/your_app/shared/log/send_email_subscriptions.log 2>&1

También puede escribir un script puro de Ruby para hacer esto si carga los archivos de configuración correctos para conectarse a su base de datos.

Una cosa que se debe tener en cuenta si la memoria es valiosa es que el script / corredor (o una tarea de Rake que depende del "entorno") cargará todo el entorno de Rails. Si solo necesita insertar algunos registros en la base de datos, utilizará la memoria que realmente no necesita. Si escribes tu propio script, puedes evitar esto. En realidad no he necesitado hacer esto todavía, pero lo estoy considerando.

¿Cuál es la mejor manera de ejecutar tareas programadas en un entorno Rails? Script / corredor? ¿Rastrillo?


Así es como he configurado mis tareas cron. Tengo uno para hacer copias de seguridad diarias de la base de datos SQL (usando rake) y otro para caducar el caché una vez al mes. Cualquier salida se registra en un archivo log / cron_log. Mi crontab se ve así:

crontab -l # command to print all cron tasks crontab -e # command to edit/add cron tasks # Contents of crontab 0 1 * * * cd /home/lenart/izziv. whiskas.si/current; /bin/sh cron_tasks >> log/cron_log 2>&1 0 0 1 * * cd /home/lenart/izziv.whiskas.si/current; /usr/bin/env /usr/local/bin/ruby script/runner -e production lib/monthly_cron.rb >> log/cron_log 2>&1

La primera tarea cron hace copias de seguridad diarias de db. Los contenidos de cron_tasks son los siguientes:

/usr/local/bin/rake db:backup RAILS_ENV=production; date; echo "END OF OUTPUT ----";

La segunda tarea se configuró más tarde y utiliza script / runner para caducar el caché una vez al mes (lib / month_cron.rb):

#!/usr/local/bin/ruby # Expire challenge cache Challenge.force_expire_cache puts "Expired cache for Challenges (Challenge.force_expire_cache) #{Time.now}"

Supongo que podría hacer una copia de seguridad de la base de datos de otra manera, pero hasta ahora me funciona :)

Los caminos para rastrillar y ruby ​​pueden variar en diferentes servidores. Puedes ver dónde están usando:

whereis ruby # -> ruby: /usr/local/bin/ruby whereis rake # -> rake: /usr/local/bin/rake


El problema con el momento (y cron) es que vuelve a cargar el entorno de los rieles cada vez que se ejecuta, lo cual es un problema real cuando sus tareas son frecuentes o tienen mucho trabajo de inicialización por hacer. He tenido problemas en la producción debido a esto y debo advertirle.

El programador de Rufus lo hace por mí ( https://github.com/jmettraux/rufus-scheduler )

Cuando tengo trabajos largos para ejecutar, lo uso con delayed_job ( https://github.com/collectiveidea/delayed_job )

¡Espero que esto ayude!


En nuestro proyecto utilizamos por primera vez cada gema, pero enfrentamos algunos problemas.

Luego cambiamos a la gema SCHFULER RUFUS , que resultó ser muy fácil y confiable para programar tareas en Rails.

Lo hemos utilizado para enviar correos semanales y diarios, e incluso para ejecutar algunas tareas periódicas de rake o cualquier otro método.

El código utilizado en esto es como:

require ''rufus-scheduler'' scheduler = Rufus::Scheduler.new scheduler.in ''10d'' do # do something in 10 days end scheduler.at ''2030/12/12 23:30:00'' do # do something at a given point in time end scheduler.every ''3h'' do # do something every 3 hours end scheduler.cron ''5 0 * * *'' do # do something every day, five minutes after midnight # (see "man 5 crontab" in your terminal) end

Para obtener más información: https://github.com/jmettraux/rufus-scheduler


Eso es interesante, nadie mencionó el Sidetiq . Es bueno agregar si ya usas Sidekiq.

Sidetiq proporciona una API simple para definir trabajadores recurrentes para Sidekiq.

El trabajo se verá así:

class MyWorker include Sidekiq::Worker include Sidetiq::Schedulable recurrence { hourly.minute_of_hour(15, 45) } def perform # do stuff ... end end


Estoy usando el método de rake (como lo admite heroku )

Con un archivo llamado lib / tasks / cron.rake ..

task :cron => :environment do puts "Pulling new requests..." EdiListener.process_new_messages puts "done." end

Para ejecutar desde la línea de comandos, esto es solo "rake cron". Este comando se puede colocar en el programador de tareas / cron del sistema operativo como se desee.

Actualizar esta es una vieja pregunta y respuesta! Alguna nueva información:

  • El servicio cron de heroku al que hice referencia ya ha sido reemplazado por heroku
  • para las tareas frecuentes (especialmente cuando se quiere evitar el costo de inicio del entorno Rails), mi enfoque preferido es usar el sistema cron para llamar a un script que (a) introducirá una API de webhook segura / privada para invocar la tarea requerida en segundo plano o (b) poner en cola directamente una tarea en el sistema de colas de su elección

He utilizado el extremadamente popular Whenever en proyectos que dependen en gran medida de las tareas programadas, y es genial. Le brinda un buen DSL para definir sus tareas programadas en lugar de tener que lidiar con el formato crontab. Desde el README:

Siempre que sea una gema de Ruby que proporcione una sintaxis clara para escribir e implementar trabajos cron.

Ejemplo desde el README:

every 3.hours do runner "MyModel.some_process" rake "my:rake:task" command "/usr/bin/my_great_command" end every 1.day, :at => ''4:30 am'' do runner "MyModel.task_to_run_at_four_thirty_in_the_morning" end


Las tareas de script / runner y rake están perfectamente bien para ejecutarse como trabajos cron.

Aquí hay una cosa muy importante que debe recordar al ejecutar trabajos cron. Probablemente no serán llamados desde el directorio raíz de su aplicación. Esto significa que todo lo que necesita para los archivos (a diferencia de las bibliotecas) debe hacerse con la ruta explícita: por ejemplo, File.dirname (__ FILE__) + "/ other_file". Esto también significa que debe saber cómo llamarlos explícitamente desde otro directorio :-)

Compruebe si su código admite la ejecución desde otro directorio con

# from ~ /path/to/ruby /path/to/app/script/runner -e development "MyClass.class_method" /path/to/ruby /path/to/rake -f /path/to/app/Rakefile rake:task RAILS_ENV=development

Además, las tareas cron probablemente no se ejecuten como usted, así que no dependa de ningún acceso directo que ponga en .bashrc. Pero eso es sólo un consejo cron estándar ;-)


No estoy realmente seguro, creo que depende de la tarea: la frecuencia de ejecución, la complejidad y la comunicación directa que se necesita con el proyecto de los rieles, etc. Supongo que si hubiera una "Una mejor manera" de hacer algo , no habría tantas maneras diferentes de hacerlo.

En mi último trabajo en un proyecto de Rails, necesitábamos hacer un envío por correo de invitación por lotes (invitaciones a encuestas, no spam) que debería enviar los correos planificados cada vez que el servidor tenía tiempo. Creo que íbamos a usar herramientas daemon para ejecutar las tareas de rake que había creado.

Desafortunadamente, nuestra empresa tuvo algunos problemas de dinero y fue "comprada" por el rival principal, por lo que el proyecto nunca se completó, por lo que no sé qué habríamos usado.


Probablemente la mejor manera de hacerlo es usando rake para escribir las tareas que necesita y simplemente ejecutarlo a través de la línea de comandos.

Puedes ver un video muy útil en railscasts

También eche un vistazo a estos otros recursos:



Recientemente he creado algunos trabajos cron para los proyectos en los que he estado trabajando.

Me pareció que la gema de relojería muy útil.

require ''clockwork'' module Clockwork every(10.seconds, ''frequent.job'') end

Incluso puedes programar tu trabajo de fondo con esta gema. Para obtener documentación y ayuda adicional, consulte https://github.com/Rykian/clockwork


Soy un gran fan de resque / resque planificador . No solo puede ejecutar tareas similares a cron, sino también tareas en momentos específicos. El inconveniente es que requiere un servidor Redis.


Suponiendo que sus tareas no tarden demasiado en completarse, simplemente cree un nuevo controlador con una acción para cada tarea. Implemente la lógica de la tarea como código del controlador, luego configure un cronjob en el nivel del sistema operativo que use wget para invocar la URL de este controlador y la acción en los intervalos de tiempo apropiados. Las ventajas de este método son ustedes:

  1. Tenga acceso completo a todos sus objetos Rails como en un controlador normal.
  2. Puede desarrollarse y probarse al igual que hace las acciones normales.
  3. También puede invocar sus tareas adhoc desde una página web simple.
  4. No consuma más memoria activando procesos adicionales de ruby ​​/ rails.

Una vez tuve que tomar la misma decisión y hoy estoy muy contento con esa decisión. Use Resque Scheduler porque no solo un redis separado eliminará la carga de su base de datos, sino que también tendrá acceso a muchos complementos como Resque-Web, que proporciona una excelente interfaz de usuario. A medida que su sistema se desarrolle, tendrá que programar cada vez más tareas para que pueda controlarlas desde un solo lugar.


Usar algo Sidekiq o Resque es una solución mucho más robusta. Ambos admiten el reintento de trabajos, la exclusividad con un bloqueo REDIS, el monitoreo y la programación.

Tenga en cuenta que Resque es un proyecto muerto (no se mantiene activamente), por lo que Sidekiq es una alternativa mucho mejor. También es más eficaz: Sidekiq ejecuta varios trabajadores en un solo proceso de multiproceso, mientras que Resque ejecuta cada trabajador en un proceso separado.


Utilicé la gema del github.com/tomykaira/clockwork y funciona bastante bien para mí. También hay una gema clockworkd que permite que un script se ejecute como un demonio.


Utilice Craken (trabajos de cron de rake centric)


Yo uso backgroundrb.

http://backgroundrb.rubyforge.org/

Lo uso para ejecutar tareas programadas, así como tareas que toman demasiado tiempo para la relación cliente / servidor normal.


Yo uso script para ejecutar cron, esa es la mejor manera de ejecutar un cron. Aquí hay algunos ejemplos para cron,

Abra CronTab -> sudo crontab -e

Y pegar las líneas de abajo:

00 00 * * * wget https://your_host/some_API_end_point

Aquí hay algún formato cron, te ayudará

::CRON FORMAT::

Examples Of crontab Entries 15 6 2 1 * /home/melissa/backup.sh Run the shell script /home/melissa/backup.sh on January 2 at 6:15 A.M. 15 06 02 Jan * /home/melissa/backup.sh Same as the above entry. Zeroes can be added at the beginning of a number for legibility, without changing their value. 0 9-18 * * * /home/carl/hourly-archive.sh Run /home/carl/hourly-archive.sh every hour, on the hour, from 9 A.M. through 6 P.M., every day. 0 9,18 * * Mon /home/wendy/script.sh Run /home/wendy/script.sh every Monday, at 9 A.M. and 6 P.M. 30 22 * * Mon,Tue,Wed,Thu,Fri /usr/local/bin/backup Run /usr/local/bin/backup at 10:30 P.M., every weekday.

Espero que esto te ayudará :)