 |
Forums |
Admin Discussion Forums: help Start New Thread
By: Ann Lewis
 RE: Running skynet with a rails app in prod [ reply ]
2008-06-11 22:29
|
Just updated to skynet 0.9.3, and the daemonized start/stop works great. There's still no support for passing in RAILS_ENV, but I found that I could add this functionality with these two steps:
1. add to the top of bin/skynet:
if rails_env_arg = ARGV.detect {|i| i =~ /RAILS_ENV/ }
RAILS_ENV=rails_env_arg.split('=').last
ENV['RAILS_ENV'] = RAILS_ENV
end
2. add to the top of your config/skynet_config.rb:
RAILS_ENV=ENV['RAILS_ENV']
Seems like these changes wouldn't affect existing functionality, since the rest of skynet is rails-agnostic. Could these changes be added into skynet?
|
By: Adam Pisoni
RE: Running skynet with a rails app in prod [ reply ]
2008-05-06 04:33
|
If you just gem install skynet, you won't see it. It's only in the SVN trunk. Most of the forking code is in lib/skynet.rb, though the manager actually daemonizes itself in skynet_manager. you should just be able to say ./script/skynet start
If you do not pass 'start' it won't daemonize.
|
By: Adam Pisoni
RE: Running skynet with a rails app in prod [ reply ]
2008-05-05 18:03
|
|
Good news! I just merged all of my changes into the Skynet trunk (which I swear to release soon). One of the biggest changes is Skynet now daemonizes properly and has proper start/stop functionality. It may not be perfect, but it's a lot better. Shutdown is also much faster now. Give it a try!
|
By: Adam Pisoni
RE: Running skynet with a rails app in prod [ reply ]
2008-05-01 18:45
|
Yeah, I've been working on getting the skynet runner to daemonize properly. You're right that start/stop does not do what you'd expect (stop doesn't do anything). You have to send a kill sig to shut down skynet right now and it does take a while to shut down all the workers. I've tried several times to have skynet use the Daemon library, but failed due to logging issues as well as problems with how skynet runs sub-processes. In that branch I'm working on, Skynet is a little better at being daemonizable (releasing files and the TTY), but not perfect. I'm hoping someone with some experience with this might be able to step in and help. Wanna be that person?
|
By: Adam Pisoni
RE: Running skynet with a rails app in prod [ reply ]
2008-04-30 19:16
|
Hmm... Good question. We run skynet under rails in development and production where RAILS_ENV=production is required as well. I was trying to think of how we do that differently. I think the problem is, once you run ./script/skynet it has to re-run all the workers which it does without passing RAILS_ENV=production. I actually remember that code was in there at one point until we de-railsified Skynet. The way we do it is to put RAILS_ENV=production in the user's environment who will be running skynet on production.
The other suggestion would be to take your PRODUCTION ./script/skynet and hardcode RAILS_ENV=production in it, though that doesn't feel as good. Remember, all of skynet's processes will be run through your ./script/skynet so as long as that is run with the right RAILS_ENV then all the processes will run right.
Let me know if that helps.
|
By: Ann Lewis
Running skynet with a rails app in prod [ reply ]
2008-04-30 16:58
|
Hi all,
I'm trying out skynet along with several other distributed computation frameworks with the goal of horizontally scaling out a computationally intensive rails application.
So far, skynet was the easiest to use and most powerful of the frameworks I've tried, (and of course the best-named). Installation was easy, and it took less than a day to create and run a job on my development machine.
So now I'm trying to run this same application in a production environment, and I'm finding that skynet seems to be defaulting to using RAILS_ENV=development all through the app, which causes my rails application to run in unintended ways. Perhaps this is to be expected- skynet is a ruby app, not a rails app. But I'm wondering if anyone has any advice on what the best way is to make skynet play nice with my RAILS environment-specific configuration.
One brute force solution is to litter script/skynet and my skynet job ruby file with RAILS_ENV='production', but this is a bit of a hack. Any better ideas?
|
|
|
