ruby-on-rails - retry - sidekiq scheduler

¿Cómo ejecutar Sidekiq en el servidor de producción?

Question

Tengo un servidor con apache + pasajero.

¿Cómo voy a ejecutar sidekiq en producción? Cualquier configuración necesaria para ejecutar el

bundle exec sidekiq

Gracias

Answer 1

Debería poder iniciar Sidekiq como un proceso en segundo plano (daemon) pasando el argumento -d cuando lo inicie:

bundle exec sidekiq -d .

Aunque esta respuesta debería funcionar para usted ahora, tenga en cuenta que si el proceso de sidekiq falla por algún motivo, el proceso tendrá que reiniciarse manualmente . Un buen punto de partida para descubrir formas más robustas de ejecutar Sidekiq en producción es aquí: https://github.com/mperham/sidekiq/wiki/Deployment

Answer 2

Una mejor solución que usar la bandera daemonización -d es aprovechar el supervisor de procesos provisto por su sistema operativo. Esta es también la recomendación dada por la wiki de la gema sidekiq :

Recomiendo encarecidamente a las personas que no utilicen el distintivo -d, sino que utilicen un supervisor de procesos como systemd o upstart para gestionar Sidekiq (o cualquier otro daemon de servidor). Esto asegura que Sidekiq se reiniciará inmediatamente si falla por alguna razón.

El wiki proporciona un ejemplo de archivos de configuración para el upstart y el systemd encontrados en el directorio "examples" del repositorio .

NOTA En mi servidor CentOS 7 utilizo rvm (Ruby Version Manger). Tuve que realizar un paso adicional para asegurarme de que mi script systemd (/etc/systemd/system/sidekiq.service) pudiera iniciar y detener confiablemente sidekiq, incluso en el caso en que mis rutas ruby ​​y / o gemset cambien en el futuro. La directiva más importante es "ExecStart", que se parece a lo siguiente en mi script:

ExecStart=/usr/local/rvm/wrappers/surveil/bundler exec sidekiq -e production -L log/sidekiq.log -C config/sidekiq.yml

La parte de la ruta "/ usr / local / rvm / wrappers / surveil" es en realidad un enlace simbólico, que recreo con la ayuda de ''rvm alias'' durante la implementación para garantizar que siempre apunte a la versión ruby ​​y gemset de la aplicación, ambos podrían cambiar de manera factible de un despliegue a otro. Esto se logra creando una tarea de rake que se ejecuta durante la implementación y hace el equivalente de lo siguiente:

rvm alias delete surveil
rvm alias create surveil ruby-#{new_ruby_version}@#{new_gemset_name}

Al configurar este alias / enlace simbólico durante la implementación, puedo dejar intacto el script systemd y seguirá funcionando bien. Esto se debe a que la ruta "/ usr / local / rvm / wrappers / surveil / bundler" siempre apunta a la versión correcta de bundler y se beneficia de la magia del bundler que hace que sus objetivos se ejecuten en el entorno ruby ​​/ gem configurado de la aplicación.

Answer 3

bundle exec sidekiq -d -L log/sidekiq.log -C config/sidekiq.yml -e production

-d , proceso Daemonize

-L , ruta de archivo de registro escribible

-C , ruta al archivo de configuración YAML

-e , Entorno de aplicación