I have a server with apache + passenger.
How will I run sidekiq in production? Any configuration needed to run the
bundle exec sidekiq
Thanks
bundle exec sidekiq -d -L log/sidekiq.log -C config/sidekiq.yml -e production
-d, Daemonize process
-L, path to writable logfile
-C, path to YAML config file
-e, Application environment
A better solution than using the daemonization -d flag is to leverage the process supervisor provided by your OS. This is also the recommendation given by the sidekiq gem's wiki:
I strongly recommend people not to use the -d flag but instead use a process supervisor like systemd or upstart to manage Sidekiq (or any other server daemon). This ensures Sidekiq will immediately restart if it crashes for some reason.
The wiki provides a example config files for both upstart and systemd found in the "examples" directory of the repo.
NOTE
On my CentOS 7 server I use rvm (Ruby Version Manger). I had to perform an extra step to ensure that my systemd script (/etc/systemd/system/sidekiq.service) could reliably start and stop sidekiq, even in the case where my ruby and/or gemset paths change in the future. The most important directive is "ExecStart", which looks like the following in my script:
ExecStart=/usr/local/rvm/wrappers/surveil/bundler exec sidekiq -e production -L log/sidekiq.log -C config/sidekiq.yml
The part of the path "/usr/local/rvm/wrappers/surveil", is actually a symlink, which I recreate with the assistance of 'rvm alias' during deployment to ensure that it always points to the app's ruby version and gemset, both of which could feasibly change from one deployment to another. This is achieved by creating a rake task that runs during deployment and does the equivalent of the following:
rvm alias delete surveil
rvm alias create surveil ruby-#{new_ruby_version}##{new_gemset_name}
By setting up this alias/symlink during deployment, I can safely leave the systemd script untouched and it will keep working fine. This is because the path "/usr/local/rvm/wrappers/surveil/bundler" always points to the correct version of bundler and thus beneifts from the bundler magic that causes its targets to run in the app's configured ruby/gem environment.
You should be able to start Sidekiq as a background process (daemon) by passing the -d argument when you start it up:
bundle exec sidekiq -d.
Although this answer should work for you now, please be aware that if the sidekiq process crashes for any reason the process will have to be manually restarted. A good starting place for finding out about more robust ways to run sidekiq in production is here: https://github.com/mperham/sidekiq/wiki/Deployment
Related
Suppose there's a task
rake startupscript
that should run whenever the app boots, how can we automate that on heroku?
I know there's a heroku scheduler but that will run the task every 10 minutes instead of just once at boot. I also know of the Procfile and believe this can be a solution, although I do not yet know how to implement (and probably more importantly, I don't want to risk breaking anything else that can be configured via a Procfile, e.g. webserver etc). A lot of the Procfile docs focus on using it to alter web servers rather than app level rake tasks.
How can a rake task be made to run at boot?
You can add something like this to Procfile before you start your application services
# Run pre-release-tasks here
release: bundle exec rails db:migrate
# Then run your application
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}
Anything tagged as release will run before the startup script runs
https://devcenter.heroku.com/articles/release-phase
I have two ruby scripts that need to be running while the server is.
Currently I am running them separately using detached screens, but I would like to launch them at the same time the rails server is starting.
How can I integrate them so that I can achieve this behavior?
Have you tried Foreman gem? It will allow you to create a simple file (Procfile) where you can specify all the process that should be started simultaneously.
I usually create a file named Procfile.dev in the project's root, that would look like for example:
web: bundle exec rails server thin start -p 4000
mail: mailcatcher -f
your_script: instructions
Then you start your Rails app as:
foreman start -f Procfile.dev
With that command, Foreman will execute all the processes on the file.
You should install the gem locally and not in the Gemfile.
Foreman Gem
I have a Rails application running in Ruby 2.0.0 and Rails 3.2.16. I'm using Sidekiq for setting up background jobs for a lot of automated processes like email delivery, cancellation etc.
Now, I'm starting the rails in one terminal and in next I'm starting the sidekiq.
Rails: rails server -e production
Sidekiq: bundle exec sidekiq -q critical, -q high, -q default, -q low -e production
But, I need to know whether we can start Sidekiq when we start rails itself not running the second command.
Any help would be appreciated. Thanks :)
Look in to foreman and using a Procfile. Then you would use the command foreman start
New to Rails and very new to Delayed Jobs.
Got one that's supposed to be triggered after 5 minutes. I finally got it to work so that if I run
rake jobs:work
in my terminal, the job starts up and works correctly. If I CTRL-C and exit that action in my terminal, the delayed job stops working correctly. This is one thing on my local server and another on Heroku, where I have to start up the delayed job using
heroku run rake jobs:work
I looked into the new Heroku toolbelt and downloaded the gem they suggest for worker maintenance, foreman, but when I run "foreman start", I get this error
ERROR: procfile does not exist
I don't know what a procfile is, I'm afraid of breaking things after spending pretty much a day debugging my delayed_jobs actions, and I want to do this right to make sure it works instead of figuring out some hacky fix that breaks down later -- so I figured I should ask this question, however obnoxiously vague it may be.
Should I be using foreman for this? Or workless? (Saw that in another SO question). Where's my procfile? Should I do anything with it?
Thanks,
Sasha
You should be using a procfile to set up your Heroku processes, this is the standard method that Heroku uses to define and control the processes.
If you haven't utilised a procfile to this point everything will probably still work as Heroku adds some default processes when you push a Rails app, including both the web and worker processes. The default worker process is set to delayed job.
Foreman was developed in order to set up your local machine to use the same approach but, unlike the Heroku service, Foreman actually requires a procfile to be present to control the services that are started when Foreman is started as it doesn't know how to setup defaults.
I would suggest creating a procfile, placed in the root directory of your project, to ensure that your processes are set up and operating in the same manner on your local machine as on Heroku. If you want to mimic what Heroku sets up automatically you add the following to the procfile depending on whether you are using the Thin web server (which Heroku recommends) or not.
With Thin in your gemfile:
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
worker: bundle exec rake jobs:work
Without a special web server (eg you are using webrick, the rails default):
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
Once this file is in place you can run foreman on your local machine and it will start your web server and delayed_job workers automatically.
Running through this process will only impact starting delayed_job on the local machine. As you are running the exact same command bundle exec rake jobs:work as you are currently using there should be no impact on your dj actions in either locally or on Heroku. Obviously some testing is required to make suer this is actually the case.
Workless is designed to scale workers on Heroku so that you don't have to pay for them when there is no work available. It has no bearing on the procfile or defining how to actually start a dj worker process.
as far as I know, there are 2 version of delayed_job:
original(tobi's) https://github.com/tobi/delayed_job
collectiveidea's fork: https://github.com/collectiveidea/delayed_job
when using the collectiveidea version, you should start it as below:
# Runs two workers in separate processes.
$ RAILS_ENV=production script/delayed_job -n 2 start
I am not familiar with delayed_job on Heroku, please follow its instructions.
I am using Ruby on Rails 3.0.9 and I am trying to setup the delay_job gem for my web application in order to send emails in this way:
Notifier.delay.send_email(#user)
As well as written in the official gem documentation, to start my "delayed jobs" I should use one of the following line of code
$ RAILS_ENV=production script/delayed_job start
$ RAILS_ENV=production script/delayed_job stop
# Runs two workers in separate processes.
$ RAILS_ENV=production script/delayed_job -n 2 start
$ RAILS_ENV=production script/delayed_job stop
or invoke the rake jobs:work task.
In production mode I prefer to use one of the RAILS_ENV=... statements, but I would like to know where (that is, in which file) I should add that code in order to start the workers on application start (BTW: at this time I am not using Capistrano to deploy my application).
More, I would like to know what exactly "workers" are and if my VPS hosting (running Ubuntu 10.04 LTS) can run multiple of those or how to know how many workers my server can run.
Finally, I would like to know what options can I add in the config/initializers/delayed_job.rb file and if there are some advices or tricks about the Delay Job gem.
To start your workers on application start I would just call the proper command from an initalizer. The code to do this would look like:
system "RAILS_ENV=production #{Rails.root.join('script','delayed_job')} stop"
system "RAILS_ENV=production #{Rails.root.join('script','delayed_job')} -n 2 start"
The path might be a little off and there most likely is a cleaner way to do it but I dont know of anything off of the top of my head.