I'm attempting to mimic, as close as possible, the Heroku deployment environment but in actual development mode for a Rails app. In other words, I'd like more verbose output from the thin console logs web and worker processes and I'd like for the assets pipeline to be refreshed appropriately vs having to run a command to refresh them.
The reason I have to do this is due to some testing of additional workers that need to function during development and testing phases.
Currently I have foreman running a procfile locally which spawns thin. Here are the commands that it steps through:
First I start it via Foreman with RACK_ENV=development PORT=3000 foreman start --port $PORT
Second, in my Procfile I have:
`web: bundle exec thin start -p $PORT -e $RACK_ENV`
`worker: bundle exec ruby worker.rb`
These execute just fine, however I have two seeming problems that I'd like to overcome:
A) I have to run bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile so it seems as though thin does not honor a development mode that does not require asset precompilation. I tried to add config.assets.compile = true into my config/environments/development.rb, but that did not seemingly help the situation. The real problem seems to be that actual images in the assets folder are not refreshed without this manual preocompile step.
B) I am not seeing any more verbose development level logging in the output console. I would like to see a verbose request log as well as the debug print statements that I have in my worker script. None of these propagate back up to the console log where the foreman command is initially run.
The thought has come to mind that perhaps I should just have a Procfile.development and in there have webrick instead of thin, however that only resolves point A and leaves the question of point B above.
Thus my question, how can I accomplish my original designs using foreman + thin?
I ended up approaching this at a little different slant and got through the issue. The core problem I was having was the the logging facility was being overridden by one of gem's we've been using and therefore had to force logging to use the Rails logger with more verbosity:
How to increase Heroku log drain verbosity to include all Rails app details?
Related
With the delayed_jobs gem(https://github.com/collectiveidea/delayed_job) in rails, I am able to queue my notifications. But I don't quite understand how can I run the queued jobs on the production server. I knew I can just run
$ rake jobs:work
in the console for the local server. As the documentation said,
You can then do the following:
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
# Set the --queue or --queues option to work from a particular queue.
RAILS_ENV=production script/delayed_job --queue=tracking start
RAILS_ENV=production script/delayed_job --queues=mailers,tasks start
# Runs all available jobs and the exits
RAILS_ENV=production script/delayed_job start --exit-on-complete
# or to run in the foreground
RAILS_ENV=production script/delayed_job run --exit-on-complete
My question is how to integrate it with my Rails app?I was thinking to create a file called delayed_jobs.rb in config/initializers as:
# in config/initializers/delayed_jobs
script/delayed_job start if Rails.env.production?
But I am not sure if it is the right way to do with it. Thanks
The workers run as separate processes, not as part of your Rails application. The simplest way would be to run the rake task in a screen session to prevent it from quitting when you log out of the terminal session. But there are better ways:
You would use a system such as monit or God or run the worker script provided by delayed_job. You'll find more information in the answers to this question.
In my experiencie I've found my solution using capistrano gem, which in words of the official doc
It supports the scripting and execution of arbitrary tasks, and includes a set of sane-default deployment workflows.
Basically it is a tool that helps you to deploy your app, including all of those task like starting/stoping queues, migrating the database, bundle new gems, and all of those thing that we usually do with ssh connection.
Here is a beutifull tutorial about capistrano and webfaction as hosting. And here is a nice module to blend capistrano and delayed_job. At the end you should only be concern about the development environment, because every time that you need to deploy to production, you'll do a commit to your repository and then
$ cap production deploy
Which will manage the whole production environment, stoping/restarting those queues, restarting the app, installing gems and everything that you can perform through the capistrano scripting way.
I am running a Rails 4 app on a VPS with Ubuntu, NginX and Unicorn.
When I SSL into my server and update the app via git or run rake tasks on the database, my app always switches to development mode and I can't get it into production mode.
Typing RAILS_ENV=production seems to have no effect at all.
When I do
$ rails console
$ Rails.env
I get
--> development
all the time.
What must I do to force NginX into production mode?
Actually, I don't want Nginx to ever run in development mode.
How can this be achieved?
Thanks for any help.
Your application is probably running in production mode by default. What you're doing is engaging a shell, something using a different environment.
Normally on a production server you'd put this into your profile script:
# Add to ~/.bash_profile
export RAILS_ENV=production
That way when you power up rails c you will get the correct environment.
As a note, the only way this shell is engaging in the first place is that you have a development setting in your config/database.yml. That shouldn't be there, as the configuration for your production server should be production-only.
nginx doesn't run in development or production mode - your app does, via your unicorn configuration and/or the RAILS_ENV environment variable when you launch your unicorn instances.
You should be launching your unicorn instances with the RAILS_ENV variable prefixed to the command, eg:
RAILS_ENV=production bundle exec unicorn -c config/unicorn.rb -D
rails console launches a completely different instance which may be in an different environment - it is unrelated to your unicorn instances. If you want to launch a production console instance, then either invoke RAILS_ENV=production rails console or rails console production. Note that this has no bearing on the environment that your application runs in.
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.
Here's what my Procfile looks like:
web: bundle exec rails server thin -p $PORT -e $RACK_ENV
worker: bundle exec rake jobs:work
I intend to add a worker process because I wish to run some background jobs. I'm following these instructions
This is what I noticed:
No problems encountered if the worker is started separately.
When I keep the second line in the Procfile and don't not change anything else, the rails server serves a couple of requests and hangs after that
As mentioned here , I've added STDOUT.sync = true to config/environments/development.rb and verified the same in the rails console. Did not work.
Tailed log/development.log and compared it against the stuff that foreman outputted to the shell and noticed that both matched for a couple of requests and then foreman stopped printing out stuff to the shell - the next request would then hang
I updated foreman using foreman.pkg as mentioned here and verified the same with [6]
It was mentioned here that this might be caused due to a stray debug statement. I'm not using the debugger and I do not have the pry gem or the ruby-debug gem in my Gemfile.lock
I believe the symptoms are similar to this related unanswered question
Please help!
[6]:
which foreman
/usr/bin/foreman
ls -lah /usr/bin/foreman # checked the updated date
Tracked and resolved here:
https://github.com/ddollar/foreman/issues/244
TL;DR: Install the gem, don't use foreman.pkg
I'll add than if you're using Heroku, the foreman version included with the heroku toolbelt has the same issue.
Use the one you can get with gem install foreman instead.
I set up my rails app on my linode VPS, phusion passenger is installed and working, so is mysql (I know this cause my friend currently is running 2 production apps on it with the same set up). The VPS is running Ubuntu 10.10 and I'm using apache2 with passenger.
I SFTP'd the app to the server, bundle updated, set up my virtual host and specified RailsEnv to be production and paths are all accurate.
I then restarted the server (as root) with
apachectl -k restart
tried to rake db:migrate and it didn't do anything, so I figured it was because the environment didn't get changed, which is exactly what happend. If I go into the rails console and type Rails.env it gives me development.
I have no idea why, I did everything that should set it to production? Anyone know what I may have missed? Is there somewhere in the app where I'm supposed to change something to say production environment? I thought that only had to be done in rails 2.x
Thanks in advance for any and all help.
The RailsEnv setting is only for Passenger's use. It doesn't affect the commands you type in the shell.
Use
RAILS_ENV=production rake db:migrate
and
RAILS_ENV=production rails console
Or set the RAILS_ENV environment variable in your login shell to production so that you don't have to append RAILS_ENV=production to the commands you issue:
export RAILS_ENV=production
(exact command may vary depending on which shell you use; the above works in bash)
You were on the right track; all you need to do to actually run the app in production mode is set the RailsEnv as you did, assuming you are running the app using Passenger. However, to run the database migrations you need to tell Rails what environment to run within.
The rails console command defaults to the 'development' environment by default. The same goes for running database migrations.
To run the migrations on your production environment you need to run the command as such:
RAILS_ENV=production rake db:migrate
And to run the console in production mode, you need to run the console using the command:
rails console production
If you want this variable to be set automatically, put RAILS_ENV=productionat the end of your ~/.bashrc file. (This only works with a bash terminal)
Then open a new terminal, or restart your ssh connection.