I need to start thin aus user - not as root. So I changed the whole environment to run the server in user-mode. Problem is, that I wanna start different thin's for different apps. But I'ld love to use bundle exec instead of gemsets - because I don't wanna update the gemsets all the time when updating the app.
So how could I change the init.d - script to start thin in bundler environment?
I tried this:
su - rubyuser -c "bundle exec /var/www/myapp/deploy/shared/bundle/ruby/1.9.1/bin/thin start -C /etc/thin/myapp.yml"
but it ends up in "Could not locate Gemfile"
Related
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 foreman app with a Procfile like this
web: bundle exec rails s
custom_process: bundle exec rake custom:process
faking_custom_process: bundle exec rake custom:faking_process
And I want to run custom_process or faking custom_process depends on my needs:
foreman start # run web & custom_process
FAKING_PROCESS # run web & faking_custom_process
Yes, I know about ability of running like that foreman start -c faking_custom_process=0, but this is more difficult than I expect, right?
There's no option in foreman to just skip a process. I think you'd need to extend your start invocation to do something different too if you want to run the other processes. Otherwise you're just telling it to run zero copies of faking_custom_process and nothing else:
foreman start -m web=1,custom_process=1,faking_custom_process=0
or for the faking version:
foreman start -m web=1,custom_process=0,faking_custom_process=1
You could of course script that so you've got two scripts running those different versions.
An alternative would be to switch faking on or off using a variable in the environment (I'm not convinced it's any easier but it's an alternative):
web: bundle exec rails d
custom_process: PROCESS=$FAKING"process" && bundle exec rake custom:$PROCESS
A normal foreman start will just run bundle exec rake custom:process.
For the faking equivalent you can do:
export FAKING="faking_"
which will mean that from then on foreman start it will call bundle exec rake custom:faking_process instead.
You can return to the normal process by clearing the FAKING variable with:
export FAKING=
You could of course encapsulate that into a shell script too.
You can use .profile to store default options for foreman start:
concurrency: web=1,custom_process=1,faking_custom_process=0
or using shortcut:
concurrency: all=1,faking_custom_process=0
And then you override this default option to switch to fake process:
foreman start -c all=1,custom_process=0
See: http://ddollar.github.io/foreman/#DEFAULT-OPTIONS
I recently added the dokku-shoreman plugin and a Procfile so that my app runs both a worker and web process when I deploy. It looks like this:
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
However, now I when I use dokku run <app> <cmd> such as ...rake db:migrate a server and worker start running instead.
Currently the only way I know how to run the worker is with the Procfile. It's not a big issue to start it manually after I deploy - only I don't know how.
Though the ideal would still be to have the both the Procfile and dokku run working.
Update 2 Dokku now supports this http://dokku.viewdocs.io/dokku/deployment/process-management/
Update: checkout dokku-alt (no longer maintained) first - it's what I've switched to instead.
This is a known issue with dokku.
This was a temporary solution detailed in the issue discussion that worked for me:
rename actualProcfile to Procfile.real
create a new Procfile with the following content:
web: bundle exec foreman start -f Procfile.real
add gem 'foreman' as a dep in Gemfile
run bundle install
commit Procfile* and Gemfile*
push
I want to monitor my app with upstart. I'm exporting using
rvmsudo foreman export upstart /etc/init -a <my_app_name> -u ubuntu -l /var/<my_app_name>/log
It finishes successfully, but when i do
sudo start <my_app_name>
I get the following output and nothing happens
<my_app_name> start/running
my procfile
web: rvmsudo passenger start -p80 -e production
worker: rvmsudo bundle exec rake jobs:work RAILS_ENV=production
Its really frustrating because i can run the web and worker commands on different terminals individually. So I tried to just do a foreman start and this fails with the following error
*** ERROR ***
Please install daemon_controller first:
/usr/local/rvm/gems/ruby-2.0.0-p594/wrappers/gem install daemon_controller
The frustrating bit is that daemon controller is installed and i can see it when i do gem list
Maybe my whole approach to this is wrong can someone please point me in the right direction?
Here's the line in passenger that returns that error, so it looks as though it really can't find daemon_controller as it's rescuing a LoadError. Try updating your web process to run via bundle exec also:
web: rvmsudo bundle exec passenger start -p80 -e production
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