Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten
If your needs are basic process management then runit is great. We use
it everywhere we need to manage processes and it’s much prefered to
shipping init scripts in cookbooks.
Bluepill is used by a lot of the ruby/rails shops we work with. It
generally works well, but has caused occasional frustration by loosing
track of the unicorn child processes it’s supposed to keep watch on.
An alternative is god, which bluepill started as a fork of due to a
memory issue. Both god and bluepill have a similar interface to process
monitoring.
Given a choice between those 3 I’d always prefer runit, unless you need
to monitor memory and cpu usage of process, in which case something like
god or bluepill is what you need.
Jeff,
Are you considering a generic LWRP w/ multiple providers (sub resources?)
for each of the common supervisors?
I could see this being useful for cases where you'd like to switch from one
to the other, but there are enough nuanced aspects of each of the
prevailing supervisors that I'd be worried about the brittleness/complexity
of the implementation.
--AJ
On 22 November 2012 07:37, Jeffrey Hulten jeffh@automatedlabs.com 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?Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten
On Nov 21, 2012, at 1:37 PM, Jeffrey Hulten 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 would really love to find some tuits to make the service resource truly a generic interface for "here is something that should be running". Right now it is kind of generic except for the things people actually use (except upstart which is included). service "whatever" do provider :runit end should totally be a thing.
--Noah
On Thu, Nov 22, 2012 at 12:31 AM, Noah Kantrowitz noah@coderanger.netwrote:
On Nov 21, 2012, at 1:37 PM, Jeffrey Hulten 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 would really love to find some tuits to make the service resource truly
a generic interface for "here is something that should be running". Right
now it is kind of generic except for the things people actually use (except
upstart which is included). service "whatever" do provider :runit end
should totally be a thing.
+1
On Thu, Nov 22, 2012 at 12:31 AM, AJ Christensen aj@junglist.gen.nz wrote:
Are you considering a generic LWRP w/ multiple providers (sub resources?)
for each of the common supervisors?
I would love to see that. One of my pet peeves is that a lot of cookbooks
have a giant "case node[:init_style]", and most only support a minority of
distros.
A resource for that would be very useful, whether that's part of service or
not. Totally non-trivial, but very useful.
Hi,
On Thu, Nov 22, 2012 at 5:37 AM, Jeffrey Hulten jeffh@automatedlabs.com
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.
[1] GitHub - ddollar/foreman: Manage Procfile-based applications
--
Cheers,
Peter Donald
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 <jeffh@automatedlabs.com<javascript:_e({}, 'cvml', 'jeffh@automatedlabs.com');>
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.[1] GitHub - ddollar/foreman: Manage Procfile-based applications
--
Cheers,Peter Donald
--
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.
Follow me on twitter @webmat http://twitter.com/webmat, get in touch on
LinkedIn http://ca.linkedin.com/in/mathieumartin, or check out my blog at
programblings.com http://www.programblings.com?utm_source=email+signature.
If you're a tech person, the following may make sense to you.
I'm the author of
git_remote_branchhttps://rubygems.org/gems/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
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 webmat@gmail.com 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 jeffh@automatedlabs.com 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.
[1] GitHub - ddollar/foreman: Manage Procfile-based applications
--
Cheers,Peter Donald
--
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.
Follow me on twitter @webmat, get in touch on LinkedIn, or check out my blog at programblings.com.
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
On Nov 25, 2012, at 4:20 PM, Peter Donald wrote:
Hi,
On Thu, Nov 22, 2012 at 5:37 AM, Jeffrey Hulten jeffh@automatedlabs.com 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.
[1] GitHub - ddollar/foreman: Manage Procfile-based applications
--
Cheers,Peter Donald
A lot of my thinking is based on our discussions at the community summit. Cookbook dependencies are become more important as we use tools like Berkshelf, but many cookbooks depend on things that are not required in every case.
For instance the nginx cookbook depends on both runit and bluepill. You are not going to use both at the same time, but the tools don't know that.
If, however, we had a way to tell the service resource to use runit or bluepill based on an attribute and defaulted to the standard OS method otherwise then we could eliminate the dependency on the tool we aren't using.
--
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten
One of the reasons I have been a huge advocate of setting all dependencies that your cookbook may leverage as explicit dependencies in the metadata is that Berkshelf just handles the retrieval and uploading of that dependency for you. It does nothing more than take up a minimal amount of disk space on your nodes and the only danger is if a cookbook was written so unfortunately that it stomps on other cookbooks.
With ruby gems, if you have platform specific gem dependencies then you package different gems with different dependencies. This could potentially be another solution for us but would require quite a bit of additional legwork around cookbook packaging and distribution.
--
Jamie Winsor
@resetexistence
On Monday, November 26, 2012 at 10:01 AM, Jeffrey Hulten wrote:
On Nov 25, 2012, at 4:20 PM, Peter Donald wrote:
Hi,
On Thu, Nov 22, 2012 at 5:37 AM, Jeffrey Hulten <jeffh@automatedlabs.com (mailto:jeffh@automatedlabs.com)> 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.
[1] GitHub - ddollar/foreman: Manage Procfile-based applications
--
Cheers,Peter Donald
A lot of my thinking is based on our discussions at the community summit. Cookbook dependencies are become more important as we use tools like Berkshelf, but many cookbooks depend on things that are not required in every case.
For instance the nginx cookbook depends on both runit and bluepill. You are not going to use both at the same time, but the tools don't know that.
If, however, we had a way to tell the service resource to use runit or bluepill based on an attribute and defaulted to the standard OS method otherwise then we could eliminate the dependency on the tool we aren't using.
--
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com (mailto:jeffh@automatedlabs.com) 206-853-5216
Skype: jeffhulten