| Foreman is designed to specify the processes necessary for running your app in all environments, including production. The production workflow is typically centered around using foreman export to create files for upstart or other process launching / monitoring systems based on the contents of your Procfile.
So yes, "foreman start" isn't intended for production, but Foreman itself is (via "foreman export" on deploy). The idea is that the Procfile should be the one and only place you specify which processes need to be running for your app to be usable.
Whether or not that's compatible or easy with Heroku, I don't know.
Wes On Nov 25, 2012, at 10:48 PM, Mathieu Martin <
">
> wrote: Hey Peter,
I have used foreman (the one you linked to) in the past as a development tool to work alongside Heroku. Its use was to run a single command to have "everything" running. In my case: Rails, a background job worker and a Solr search index. I always assumed the point of foreman was to make it easier for developers (esp. less experienced ones, or e.g. designers) to have a "production-like" environment running at all times.
Although the quality of the tool was excellent, I didn't get the impression it was meant to manage production deployments.
Note that foreman's Procfile is also used by Heroku to map out how to start each of your services when you deploy, but they don't use foreman for that.
The way Heroku works, each instance of your resources you request actually provisions a new VM. E.g. 5x web + 2x worker = 7 VMs (or dynos, in Heroku parlance). Foreman definitely doesn't do that kind of heavy lifting :-)
Mat On Sunday, November 25, 2012, Peter Donald wrote: Hi,
On Thu, Nov 22, 2012 at 5:37 AM, Jeffrey Hulten <
');" target="_blank">
> wrote:
There are multiple ways to keep a service up from runit to bluepill, but everyone uses something different. I don't know a lot about these tools, would there be a way to make a generalized resource or an extension to the service resource that managed this?
I suspect if you were to take an opinionated stance on services then it would be possible to do this. One of the main reasons I would like this is to make some of the cookbooks I write more compatible with RHEL systems - right now, most of the cookbooks we create use upstart which is one of the few things that stop them being RHEL compatible.
In the next month we plan on looking on replacing upstart usage with runit (or something else?) and I had it on my list to investigate [1] to see if that could be integrated into chef. Hearsay says they have already done most of the hardwork.
--
----
I'm web and mobile consultant. My main field of expertise is Ruby on Rails and everything web, including mobile web solutions. Let me know if you need a great software artist.
If you're a tech person, the following may make sense to you.
I'm the author of git_remote_branch. A tool that's been helping common mortals like me share git branches for 5 years. Downloaded 40 000 times.
I've also contributed to some of the popular libraries in the Rails, jQuery and PhoneGap ecosystems:
paperclip, active_admin, AssetSync, jquery-ujs, jquery-rails, phonegap-plugin-facebook-connect, kaminari, shoulda, woulda, jeweler.
If you visit them on GitHub you'll see my face in the "Contributors" section :-)
|