Many people have mentioned Capistrano as being a great tool for system administration but I am finding it hard to find any reasons on why it would be? Many of the tasks can be done with a much simpler Bash script but maybe I don't know of the fantastic features Capistrano is capable of because of the somewhat lacking documentation.
Will,
People say that largely because it's handy to be able to tell an existing
list of servers that you deploy to, to run a command - some people (like
myself) choose to ship a bash script with their app, to provision the
server.
Others use software like Deprec, Chap, Puppet or Sprinkle to do something
similar, using the pre-existing lists of servers, and their roles via
Capistrano to manage configurations.
That's my take on it, and there's a post on the capistrano-dev list that
says as much as "server provisioning isn't what we're good at" - so we won't
be getting anymore involved I don't think... mostly what people are saying
when they refer to provisioning with Capistrano is provisioning with
Net::SSH with a list of servers that happens to be in your deploy.rb..
> Many people have mentioned Capistrano as being a great tool for system
> administration but I am finding it hard to find any reasons on why it would
> be? Many of the tasks can be done with a much simpler Bash script but maybe
> I don't know of the fantastic features Capistrano is capable of because of
> the somewhat lacking documentation.
Makes sense, I am still yet to look into Chef or Puppet for server
provisioning but it maybe a task for the future and Capistrano may
have a role to play there.
Thanks for replying,
Will
On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
> Will,
> People say that largely because it's handy to be able to tell an existing
> list of servers that you deploy to, to run a command - some people (like
> myself) choose to ship a bash script with their app, to provision the
> server.
> Others use software like Deprec, Chap, Puppet or Sprinkle to do something
> similar, using the pre-existing lists of servers, and their roles via
> Capistrano to manage configurations.
> That's my take on it, and there's a post on the capistrano-dev list that
> says as much as "server provisioning isn't what we're good at" - so we won't
> be getting anymore involved I don't think... mostly what people are saying
> when they refer to provisioning with Capistrano is provisioning with
> Net::SSH with a list of servers that happens to be in your deploy.rb..
> > Many people have mentioned Capistrano as being a great tool for system
> > administration but I am finding it hard to find any reasons on why it would
> > be? Many of the tasks can be done with a much simpler Bash script but maybe
> > I don't know of the fantastic features Capistrano is capable of because of
> > the somewhat lacking documentation.
will wrote:
> Makes sense, I am still yet to look into Chef or Puppet for server
> provisioning but it maybe a task for the future and Capistrano may
> have a role to play there.
> Thanks for replying,
> Will
> On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
>> Will,
>> People say that largely because it's handy to be able to tell an existing
>> list of servers that you deploy to, to run a command - some people (like
>> myself) choose to ship a bash script with their app, to provision the
>> server.
>> Others use software like Deprec, Chap, Puppet or Sprinkle to do something
>> similar, using the pre-existing lists of servers, and their roles via
>> Capistrano to manage configurations.
>> That's my take on it, and there's a post on the capistrano-dev list that
>> says as much as "server provisioning isn't what we're good at" - so we won't
>> be getting anymore involved I don't think... mostly what people are saying
>> when they refer to provisioning with Capistrano is provisioning with
>> Net::SSH with a list of servers that happens to be in your deploy.rb..
>>> Many people have mentioned Capistrano as being a great tool for system
>>> administration but I am finding it hard to find any reasons on why it would
>>> be? Many of the tasks can be done with a much simpler Bash script but maybe
>>> I don't know of the fantastic features Capistrano is capable of because of
>>> the somewhat lacking documentation.
>>> Any views on this?
>>> Will
Puppet is the future of IT. I really, really suggest getting into it. Chef is a little young, gaining momentum but from what I've seen its DSL is not as sexy as puppet's. Some people like it, so to each his own I guess.
However, capistrano serves a different purpose. I think you'd be interested in "cap shell". Lets you run cap tasks OR arbitrary shell commands on arbitrary, or defined hosts. You can do something like:
cap> with puppetmasters sudo /etc/init.d/apache2 restart
Or, my favorite is a cap task I have called aptup. Since I may have to perform apt upgrades at times I don't always know in advance, I can update locations like:
cap> with myoffice !aptup
Every server in the myoffice role then gets updated. Or a one-off command on a few servers:
cap> on server1,server2,server3 uptime
So, it's pretty cool and a bit more elegant than a bash script I'd say.
Joe,
Puppet looks great, but I'm pretty switched-on, and I still have no idea if
I could use it on Gentoo.... their disparate docs are worse than
Capistrano's complete lack!
- Lee
2009/7/2 Joe McDonagh <joseph.e.mcdon...@gmail.com>
> will wrote:
> > Makes sense, I am still yet to look into Chef or Puppet for server
> > provisioning but it maybe a task for the future and Capistrano may
> > have a role to play there.
> > Thanks for replying,
> > Will
> > On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
> >> Will,
> >> People say that largely because it's handy to be able to tell an
> existing
> >> list of servers that you deploy to, to run a command - some people (like
> >> myself) choose to ship a bash script with their app, to provision the
> >> server.
> >> Others use software like Deprec, Chap, Puppet or Sprinkle to do
> something
> >> similar, using the pre-existing lists of servers, and their roles via
> >> Capistrano to manage configurations.
> >> That's my take on it, and there's a post on the capistrano-dev list that
> >> says as much as "server provisioning isn't what we're good at" - so we
> won't
> >> be getting anymore involved I don't think... mostly what people are
> saying
> >> when they refer to provisioning with Capistrano is provisioning with
> >> Net::SSH with a list of servers that happens to be in your deploy.rb..
> >> Hope that clears up my take on this at least!
> >>> Many people have mentioned Capistrano as being a great tool for system
> >>> administration but I am finding it hard to find any reasons on why it
> would
> >>> be? Many of the tasks can be done with a much simpler Bash script but
> maybe
> >>> I don't know of the fantastic features Capistrano is capable of because
> of
> >>> the somewhat lacking documentation.
> >>> Any views on this?
> >>> Will
> Puppet is the future of IT. I really, really suggest getting into it.
> Chef is a little young, gaining momentum but from what I've seen its DSL
> is not as sexy as puppet's. Some people like it, so to each his own I
> guess.
> However, capistrano serves a different purpose. I think you'd be
> interested in "cap shell". Lets you run cap tasks OR arbitrary shell
> commands on arbitrary, or defined hosts. You can do something like:
> cap> with puppetmasters sudo /etc/init.d/apache2 restart
> Or, my favorite is a cap task I have called aptup. Since I may have to
> perform apt upgrades at times I don't always know in advance, I can
> update locations like:
> cap> with myoffice !aptup
> Every server in the myoffice role then gets updated. Or a one-off
> command on a few servers:
> cap> on server1,server2,server3 uptime
> So, it's pretty cool and a bit more elegant than a bash script I'd say.
> Puppet looks great, but I'm pretty switched-on, and I still have no > idea if I could use it on Gentoo.... their disparate docs are worse > than Capistrano's complete lack!
> - Lee
> 2009/7/2 Joe McDonagh <joseph.e.mcdon...@gmail.com > <mailto:joseph.e.mcdon...@gmail.com>>
> will wrote:
> > Makes sense, I am still yet to look into Chef or Puppet for server
> > provisioning but it maybe a task for the future and Capistrano may
> > have a role to play there.
> > Thanks for replying,
> > Will
> > On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com
> <mailto:lee.hamb...@gmail.com>> wrote:
> >> Will,
> >> People say that largely because it's handy to be able to tell
> an existing
> >> list of servers that you deploy to, to run a command - some
> people (like
> >> myself) choose to ship a bash script with their app, to
> provision the
> >> server.
> >> Others use software like Deprec, Chap, Puppet or Sprinkle to do
> something
> >> similar, using the pre-existing lists of servers, and their
> roles via
> >> Capistrano to manage configurations.
> >> That's my take on it, and there's a post on the capistrano-dev
> list that
> >> says as much as "server provisioning isn't what we're good at"
> - so we won't
> >> be getting anymore involved I don't think... mostly what people
> are saying
> >> when they refer to provisioning with Capistrano is provisioning
> with
> >> Net::SSH with a list of servers that happens to be in your
> deploy.rb..
> >> Hope that clears up my take on this at least!
> >> - Lee
> >> 2009/7/2 william pink <will.p...@gmail.com
> <mailto:will.p...@gmail.com>>
> >>> Hi,
> >>> Just a general question
> >>> Many people have mentioned Capistrano as being a great tool
> for system
> >>> administration but I am finding it hard to find any reasons on
> why it would
> >>> be? Many of the tasks can be done with a much simpler Bash
> script but maybe
> >>> I don't know of the fantastic features Capistrano is capable
> of because of
> >>> the somewhat lacking documentation.
> >>> Any views on this?
> >>> Will
> Puppet is the future of IT. I really, really suggest getting into it.
> Chef is a little young, gaining momentum but from what I've seen
> its DSL
> is not as sexy as puppet's. Some people like it, so to each his
> own I guess.
> However, capistrano serves a different purpose. I think you'd be
> interested in "cap shell". Lets you run cap tasks OR arbitrary shell
> commands on arbitrary, or defined hosts. You can do something like:
> cap> with puppetmasters sudo /etc/init.d/apache2 restart
> Or, my favorite is a cap task I have called aptup. Since I may have to
> perform apt upgrades at times I don't always know in advance, I can
> update locations like:
> cap> with myoffice !aptup
> Every server in the myoffice role then gets updated. Or a one-off
> command on a few servers:
> cap> on server1,server2,server3 uptime
> So, it's pretty cool and a bit more elegant than a bash script I'd
> say.
Lee, there are pretty good docs on the wiki, but the wiki's search sucks badly. If you go to http://reductivelabs.com/trac/puppet , on the right pane there are links to most docs you would ever need. It's no Gentoo wiki though heh. You can use it on Gentoo btw, I haven't personally but the providers are there and I've talked to guys on #puppet here and there who use it on gentoo... if you're really interested in puppet, there is also a short book available called "Pulling Strings With Puppet" that is pretty good.
> > Puppet looks great, but I'm pretty switched-on, and I still have no
> > idea if I could use it on Gentoo.... their disparate docs are worse
> > than Capistrano's complete lack!
> > - Lee
> > 2009/7/2 Joe McDonagh <joseph.e.mcdon...@gmail.com
> > <mailto:joseph.e.mcdon...@gmail.com>>
> > will wrote:
> > > Makes sense, I am still yet to look into Chef or Puppet for server
> > > provisioning but it maybe a task for the future and Capistrano may
> > > have a role to play there.
> > > Thanks for replying,
> > > Will
> > > On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com
> > <mailto:lee.hamb...@gmail.com>> wrote:
> > >> Will,
> > >> People say that largely because it's handy to be able to tell
> > an existing
> > >> list of servers that you deploy to, to run a command - some
> > people (like
> > >> myself) choose to ship a bash script with their app, to
> > provision the
> > >> server.
> > >> Others use software like Deprec, Chap, Puppet or Sprinkle to do
> > something
> > >> similar, using the pre-existing lists of servers, and their
> > roles via
> > >> Capistrano to manage configurations.
> > >> That's my take on it, and there's a post on the capistrano-dev
> > list that
> > >> says as much as "server provisioning isn't what we're good at"
> > - so we won't
> > >> be getting anymore involved I don't think... mostly what people
> > are saying
> > >> when they refer to provisioning with Capistrano is provisioning
> > with
> > >> Net::SSH with a list of servers that happens to be in your
> > deploy.rb..
> > >> Hope that clears up my take on this at least!
> > >> - Lee
> > >> 2009/7/2 william pink <will.p...@gmail.com
> > <mailto:will.p...@gmail.com>>
> > >>> Hi,
> > >>> Just a general question
> > >>> Many people have mentioned Capistrano as being a great tool
> > for system
> > >>> administration but I am finding it hard to find any reasons on
> > why it would
> > >>> be? Many of the tasks can be done with a much simpler Bash
> > script but maybe
> > >>> I don't know of the fantastic features Capistrano is capable
> > of because of
> > >>> the somewhat lacking documentation.
> > >>> Any views on this?
> > >>> Will
> > Puppet is the future of IT. I really, really suggest getting into it.
> > Chef is a little young, gaining momentum but from what I've seen
> > its DSL
> > is not as sexy as puppet's. Some people like it, so to each his
> > own I guess.
> > However, capistrano serves a different purpose. I think you'd be
> > interested in "cap shell". Lets you run cap tasks OR arbitrary shell
> > commands on arbitrary, or defined hosts. You can do something like:
> > cap> with puppetmasters sudo /etc/init.d/apache2 restart
> > Or, my favorite is a cap task I have called aptup. Since I may have
> to
> > perform apt upgrades at times I don't always know in advance, I can
> > update locations like:
> > cap> with myoffice !aptup
> > Every server in the myoffice role then gets updated. Or a one-off
> > command on a few servers:
> > cap> on server1,server2,server3 uptime
> > So, it's pretty cool and a bit more elegant than a bash script I'd
> > say.
> Lee, there are pretty good docs on the wiki, but the wiki's search sucks
> badly. If you go to http://reductivelabs.com/trac/puppet , on the right
> pane there are links to most docs you would ever need. It's no Gentoo
> wiki though heh. You can use it on Gentoo btw, I haven't personally but
> the providers are there and I've talked to guys on #puppet here and
> there who use it on gentoo... if you're really interested in puppet,
> there is also a short book available called "Pulling Strings With
> Puppet" that is pretty good.
I call hogwash on not using capistrano for provisioning.
Yes. The default canned set of deploy tasks is not enough to bring up
a server from bare os.
But you do have a single hook that you can use. deploy:setup
Capistrano is just a framework of assumptions; and you can override
every assumption either by using the DSL or ruby.
We built a task chain started with deploy:setup to provision an entire
cluster; didn't override any of the standard assumptions, our only
requirement is that the boxes we are provisioning are a version of
ubuntu > 8
We use the same scripts to deploy to server clusters that are split
into 4 roles as well as all 4 roles on a single server.
Provisioning a cluster takes about 25 minutes to do all the apt-gets
and compile the stuff we build from source.
Creating a new cluster is cheap, without capistrano would be error
prone, time consuming, and expensive.
On Jul 2, 2009, at 5:54 AM, will <will.p...@gmail.com> wrote:
> Makes sense, I am still yet to look into Chef or Puppet for server
> provisioning but it maybe a task for the future and Capistrano may
> have a role to play there.
> Thanks for replying,
> Will
> On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
>> Will,
>> People say that largely because it's handy to be able to tell an
>> existing
>> list of servers that you deploy to, to run a command - some people
>> (like
>> myself) choose to ship a bash script with their app, to provision the
>> server.
>> Others use software like Deprec, Chap, Puppet or Sprinkle to do
>> something
>> similar, using the pre-existing lists of servers, and their roles via
>> Capistrano to manage configurations.
>> That's my take on it, and there's a post on the capistrano-dev list
>> that
>> says as much as "server provisioning isn't what we're good at" - so
>> we won't
>> be getting anymore involved I don't think... mostly what people are
>> saying
>> when they refer to provisioning with Capistrano is provisioning with
>> Net::SSH with a list of servers that happens to be in your
>> deploy.rb..
>>> Many people have mentioned Capistrano as being a great tool for
>>> system
>>> administration but I am finding it hard to find any reasons on why
>>> it would
>>> be? Many of the tasks can be done with a much simpler Bash script
>>> but maybe
>>> I don't know of the fantastic features Capistrano is capable of
>>> because of
>>> the somewhat lacking documentation.
Donovan Bray wrote:
> I call hogwash on not using capistrano for provisioning.
> Yes. The default canned set of deploy tasks is not enough to bring up
> a server from bare os.
> But you do have a single hook that you can use. deploy:setup
> Capistrano is just a framework of assumptions; and you can override
> every assumption either by using the DSL or ruby.
> We built a task chain started with deploy:setup to provision an entire
> cluster; didn't override any of the standard assumptions, our only
> requirement is that the boxes we are provisioning are a version of
> ubuntu > 8
> We use the same scripts to deploy to server clusters that are split
> into 4 roles as well as all 4 roles on a single server.
> Provisioning a cluster takes about 25 minutes to do all the apt-gets
> and compile the stuff we build from source.
> Creating a new cluster is cheap, without capistrano would be error
> prone, time consuming, and expensive.
> On Jul 2, 2009, at 5:54 AM, will <will.p...@gmail.com> wrote:
>> Makes sense, I am still yet to look into Chef or Puppet for server
>> provisioning but it maybe a task for the future and Capistrano may
>> have a role to play there.
>> Thanks for replying,
>> Will
>> On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
>>> Will,
>>> People say that largely because it's handy to be able to tell an
>>> existing
>>> list of servers that you deploy to, to run a command - some people
>>> (like
>>> myself) choose to ship a bash script with their app, to provision the
>>> server.
>>> Others use software like Deprec, Chap, Puppet or Sprinkle to do
>>> something
>>> similar, using the pre-existing lists of servers, and their roles via
>>> Capistrano to manage configurations.
>>> That's my take on it, and there's a post on the capistrano-dev list
>>> that
>>> says as much as "server provisioning isn't what we're good at" - so
>>> we won't
>>> be getting anymore involved I don't think... mostly what people are
>>> saying
>>> when they refer to provisioning with Capistrano is provisioning with
>>> Net::SSH with a list of servers that happens to be in your
>>> deploy.rb..
>>>> Many people have mentioned Capistrano as being a great tool for
>>>> system
>>>> administration but I am finding it hard to find any reasons on why
>>>> it would
>>>> be? Many of the tasks can be done with a much simpler Bash script
>>>> but maybe
>>>> I don't know of the fantastic features Capistrano is capable of
>>>> because of
>>>> the somewhat lacking documentation.
>>>> Any views on this?
>>>> Will
How do you ensure that during the maintenance part of the server life-cycle that your servers' configurations stay within your spec/standard?
Unless these are like throw away clusters of cloud nodes that you don't expect to live very long, I think cap isn't really the right tool.
Donovan,
I agree that it's useful, it's something that someone that wasn't using
Capistrano to deploy their application with, could happily use Net::SSH for
though.
The (brief) discussion between the Capistrano maintainers suggested we
weren't planning to add anything to Capistrano to build this in, sorry if
that wasn't clear... I agree completely that as an addition to an existing
deploy, the ability to provision a server is exceptionally useful, so much
so that I'll be writing about my experience of making gentoo work with Cap
and a PHP app over the next week or so... I'm also sold on the concept of
Puppet, but haven't had the time to use it.
With Joe being good enough to clarify a few things for me on the Puppet
front, I am certainly sold on the idea, and I honestly think that Cap is the
perfect piece of software for triggering a remote build, but how that build
is implemented shouldn't be our concern, we should aim to write about how to
make the most of Capistrano, and encourage people to come up with their own
solutions.
> I call hogwash on not using capistrano for provisioning.
> Yes. The default canned set of deploy tasks is not enough to bring up
> a server from bare os.
> But you do have a single hook that you can use. deploy:setup
> Capistrano is just a framework of assumptions; and you can override
> every assumption either by using the DSL or ruby.
> We built a task chain started with deploy:setup to provision an entire
> cluster; didn't override any of the standard assumptions, our only
> requirement is that the boxes we are provisioning are a version of
> ubuntu > 8
> We use the same scripts to deploy to server clusters that are split
> into 4 roles as well as all 4 roles on a single server.
> Provisioning a cluster takes about 25 minutes to do all the apt-gets
> and compile the stuff we build from source.
> Creating a new cluster is cheap, without capistrano would be error
> prone, time consuming, and expensive.
> On Jul 2, 2009, at 5:54 AM, will <will.p...@gmail.com> wrote:
> > Makes sense, I am still yet to look into Chef or Puppet for server
> > provisioning but it maybe a task for the future and Capistrano may
> > have a role to play there.
> > Thanks for replying,
> > Will
> > On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
> >> Will,
> >> People say that largely because it's handy to be able to tell an
> >> existing
> >> list of servers that you deploy to, to run a command - some people
> >> (like
> >> myself) choose to ship a bash script with their app, to provision the
> >> server.
> >> Others use software like Deprec, Chap, Puppet or Sprinkle to do
> >> something
> >> similar, using the pre-existing lists of servers, and their roles via
> >> Capistrano to manage configurations.
> >> That's my take on it, and there's a post on the capistrano-dev list
> >> that
> >> says as much as "server provisioning isn't what we're good at" - so
> >> we won't
> >> be getting anymore involved I don't think... mostly what people are
> >> saying
> >> when they refer to provisioning with Capistrano is provisioning with
> >> Net::SSH with a list of servers that happens to be in your
> >> deploy.rb..
> >> Hope that clears up my take on this at least!
> >>> Many people have mentioned Capistrano as being a great tool for
> >>> system
> >>> administration but I am finding it hard to find any reasons on why
> >>> it would
> >>> be? Many of the tasks can be done with a much simpler Bash script
> >>> but maybe
> >>> I don't know of the fantastic features Capistrano is capable of
> >>> because of
> >>> the somewhat lacking documentation.
Presumably Joe, my thought was that your Puppet master would inherit a
configuration from your application's code repository, and disseminate those
instructions down the the puppet nodes during a deploy.
But, you have to admit that deploying a server often isn't a one-step thing,
often new code adds to dependencies and requires alternate
configurations...?
- Lee
2009/7/2 Joe McDonagh <joseph.e.mcdon...@gmail.com>
> Donovan Bray wrote:
> > I call hogwash on not using capistrano for provisioning.
> > Yes. The default canned set of deploy tasks is not enough to bring up
> > a server from bare os.
> > But you do have a single hook that you can use. deploy:setup
> > Capistrano is just a framework of assumptions; and you can override
> > every assumption either by using the DSL or ruby.
> > We built a task chain started with deploy:setup to provision an entire
> > cluster; didn't override any of the standard assumptions, our only
> > requirement is that the boxes we are provisioning are a version of
> > ubuntu > 8
> > We use the same scripts to deploy to server clusters that are split
> > into 4 roles as well as all 4 roles on a single server.
> > Provisioning a cluster takes about 25 minutes to do all the apt-gets
> > and compile the stuff we build from source.
> > Creating a new cluster is cheap, without capistrano would be error
> > prone, time consuming, and expensive.
> > On Jul 2, 2009, at 5:54 AM, will <will.p...@gmail.com> wrote:
> >> Makes sense, I am still yet to look into Chef or Puppet for server
> >> provisioning but it maybe a task for the future and Capistrano may
> >> have a role to play there.
> >> Thanks for replying,
> >> Will
> >> On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
> >>> Will,
> >>> People say that largely because it's handy to be able to tell an
> >>> existing
> >>> list of servers that you deploy to, to run a command - some people
> >>> (like
> >>> myself) choose to ship a bash script with their app, to provision the
> >>> server.
> >>> Others use software like Deprec, Chap, Puppet or Sprinkle to do
> >>> something
> >>> similar, using the pre-existing lists of servers, and their roles via
> >>> Capistrano to manage configurations.
> >>> That's my take on it, and there's a post on the capistrano-dev list
> >>> that
> >>> says as much as "server provisioning isn't what we're good at" - so
> >>> we won't
> >>> be getting anymore involved I don't think... mostly what people are
> >>> saying
> >>> when they refer to provisioning with Capistrano is provisioning with
> >>> Net::SSH with a list of servers that happens to be in your
> >>> deploy.rb..
> >>> Hope that clears up my take on this at least!
> >>>> Many people have mentioned Capistrano as being a great tool for
> >>>> system
> >>>> administration but I am finding it hard to find any reasons on why
> >>>> it would
> >>>> be? Many of the tasks can be done with a much simpler Bash script
> >>>> but maybe
> >>>> I don't know of the fantastic features Capistrano is capable of
> >>>> because of
> >>>> the somewhat lacking documentation.
> >>>> Any views on this?
> >>>> Will
> How do you ensure that during the maintenance part of the server
> life-cycle that your servers' configurations stay within your
> spec/standard?
> Unless these are like throw away clusters of cloud nodes that you don't
> expect to live very long, I think cap isn't really the right tool.
Lee Hambley wrote:
> Presumably Joe, my thought was that your Puppet master would inherit a > configuration from your application's code repository, and disseminate > those instructions down the the puppet nodes during a deploy.
> But, you have to admit that deploying a server often isn't a one-step > thing, often new code adds to dependencies and requires alternate > configurations...?
> - Lee
> 2009/7/2 Joe McDonagh <joseph.e.mcdon...@gmail.com > <mailto:joseph.e.mcdon...@gmail.com>>
> Donovan Bray wrote:
> > I call hogwash on not using capistrano for provisioning.
> > Yes. The default canned set of deploy tasks is not enough to
> bring up
> > a server from bare os.
> > But you do have a single hook that you can use. deploy:setup
> > Capistrano is just a framework of assumptions; and you can override
> > every assumption either by using the DSL or ruby.
> > We built a task chain started with deploy:setup to provision an
> entire
> > cluster; didn't override any of the standard assumptions, our only
> > requirement is that the boxes we are provisioning are a version of
> > ubuntu > 8
> > We use the same scripts to deploy to server clusters that are split
> > into 4 roles as well as all 4 roles on a single server.
> > Provisioning a cluster takes about 25 minutes to do all the apt-gets
> > and compile the stuff we build from source.
> > Creating a new cluster is cheap, without capistrano would be error
> > prone, time consuming, and expensive.
> > On Jul 2, 2009, at 5:54 AM, will <will.p...@gmail.com
> <mailto:will.p...@gmail.com>> wrote:
> >> Makes sense, I am still yet to look into Chef or Puppet for server
> >> provisioning but it maybe a task for the future and Capistrano may
> >> have a role to play there.
> >> Thanks for replying,
> >> Will
> >> On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com
> <mailto:lee.hamb...@gmail.com>> wrote:
> >>> Will,
> >>> People say that largely because it's handy to be able to tell an
> >>> existing
> >>> list of servers that you deploy to, to run a command - some people
> >>> (like
> >>> myself) choose to ship a bash script with their app, to
> provision the
> >>> server.
> >>> Others use software like Deprec, Chap, Puppet or Sprinkle to do
> >>> something
> >>> similar, using the pre-existing lists of servers, and their
> roles via
> >>> Capistrano to manage configurations.
> >>> That's my take on it, and there's a post on the capistrano-dev
> list
> >>> that
> >>> says as much as "server provisioning isn't what we're good at"
> - so
> >>> we won't
> >>> be getting anymore involved I don't think... mostly what
> people are
> >>> saying
> >>> when they refer to provisioning with Capistrano is
> provisioning with
> >>> Net::SSH with a list of servers that happens to be in your
> >>> deploy.rb..
> >>> Hope that clears up my take on this at least!
> >>> - Lee
> >>> 2009/7/2 william pink <will.p...@gmail.com
> <mailto:will.p...@gmail.com>>
> >>>> Hi,
> >>>> Just a general question
> >>>> Many people have mentioned Capistrano as being a great tool for
> >>>> system
> >>>> administration but I am finding it hard to find any reasons
> on why
> >>>> it would
> >>>> be? Many of the tasks can be done with a much simpler Bash script
> >>>> but maybe
> >>>> I don't know of the fantastic features Capistrano is capable of
> >>>> because of
> >>>> the somewhat lacking documentation.
> >>>> Any views on this?
> >>>> Will
> How do you ensure that during the maintenance part of the server
> life-cycle that your servers' configurations stay within your
> spec/standard?
> Unless these are like throw away clusters of cloud nodes that you
> don't
> expect to live very long, I think cap isn't really the right tool.
Lee, you're 100% correct, that would be optimal, however because of the way Donovan had worded his post it didn't sound like there was SCM software involved.
Right now, I have to use a custom script for puppet pushes instead of cap, for a couple reasons:
(Keep in mind I barely know ruby, so hacking cap isn't something i've gotten into just yet)
1. To lock down the configuration somewhat in the event that the puppetmasterd is compromised, the puppet manifests are root:root mod 640, with a facl that gives the puppet user read-only access to the manifests. You can preserve facl's with -A in rsync, however problem 2 for me gets in the way of simplicity.
2. Because the root account is not used on any of my systems (sudo only), I have to have this interim step where the configuration is in my home directory where the facl's can be applied via a facl restore file. Then they are rsync'd with -A over to /etc/puppet. I know it seems a little weird, but security is pretty paramount to me, and I want to keep using FACLs because they allow for flexibility.
Previously I was using star (tar on Ubuntu 8.04 is compiled without support for facls), but it was too costly in terms of time to be rebuilding a star, transferring, untarring every time any change no matter how trivial was made.
Technically speaking capistrano is used to parallelize commands via
ssh. Meaning if I had 100 servers, I could cause the same command to
run on all 100 simultaneously and orderly summarize all of the output
that results.
Capistrano further can manage roles, so appropriate things would
happen on the right boxes if say 20 were SQL, 10 were proxies,10 were
memcache, and the rest were app servers.
Let's say you desired a cluster restart command.
In capistrano you would assign servers to the roles, create a restart
task specific to each role then hook those tasks to a single task say
deploy:restart
Now in cap if you just wanted to restart your memcache servers:
cap memcache:restart
If you wanted to restart everything
cap deploy:restart
Capistrano is also about centralizing all of your operational knowledge.
All tasks that we do on our clusters get embodied in cap tasks, so no
matter who came up with the set of commands any other maintainer can
execute them on the cluster, no one needs to memorize a 30 step
process, and we dont have to wait for the one person who knows how to
do x operation to show up.
Capistrano is documentation. Cap provides an natural integration of
creating task descriptions that are discoverable and expansive,
essentially as easy as an rdoc or remark format. When documentation
is easy and natural it tends to get done more often.
Capistrano is not a replacement for shell scripting; it's a beautiful
marriage of ruby, a role and task based DSL, and shell scripting.
The better you are at both; the more succesful you will be.
On Jul 2, 2009, at 4:55 AM, william pink <will.p...@gmail.com> wrote:
> Many people have mentioned Capistrano as being a great tool for
> system administration but I am finding it hard to find any reasons
> on why it would be? Many of the tasks can be done with a much
> simpler Bash script but maybe I don't know of the fantastic features
> Capistrano is capable of because of the somewhat lacking
> documentation.
Our primary target are ec2 instances using scalr as a management
platform, so ephemeral instances which are occasionaly synced.
We deploy to non-ephemeral boxes as well.
We also deploy the scripts to the boxes and they can run tasks against
themselves. Which as I understand is the basic premise of puppet, but
we are so heavily dependent on cap it made no sense to introduce a
different techonology just to rewrite a framework that we already had
working really well.
While I concur that it may not be the best tool; it's a sharp one non- the-less and perfectly capable of being used for complex provisioning
tasks.
On Jul 2, 2009, at 8:30 AM, Joe McDonagh <joseph.e.mcdon...@gmail.com>
wrote:
> Donovan Bray wrote:
>> I call hogwash on not using capistrano for provisioning.
>> Yes. The default canned set of deploy tasks is not enough to bring up
>> a server from bare os.
>> But you do have a single hook that you can use. deploy:setup
>> Capistrano is just a framework of assumptions; and you can override
>> every assumption either by using the DSL or ruby.
>> We built a task chain started with deploy:setup to provision an
>> entire
>> cluster; didn't override any of the standard assumptions, our only
>> requirement is that the boxes we are provisioning are a version of
>> ubuntu > 8
>> We use the same scripts to deploy to server clusters that are split
>> into 4 roles as well as all 4 roles on a single server.
>> Provisioning a cluster takes about 25 minutes to do all the apt-gets
>> and compile the stuff we build from source.
>> Creating a new cluster is cheap, without capistrano would be error
>> prone, time consuming, and expensive.
>> On Jul 2, 2009, at 5:54 AM, will <will.p...@gmail.com> wrote:
>>> Makes sense, I am still yet to look into Chef or Puppet for server
>>> provisioning but it maybe a task for the future and Capistrano may
>>> have a role to play there.
>>> Thanks for replying,
>>> Will
>>> On Jul 2, 1:45 pm, Lee Hambley <lee.hamb...@gmail.com> wrote:
>>>> Will,
>>>> People say that largely because it's handy to be able to tell an
>>>> existing
>>>> list of servers that you deploy to, to run a command - some people
>>>> (like
>>>> myself) choose to ship a bash script with their app, to provision
>>>> the
>>>> server.
>>>> Others use software like Deprec, Chap, Puppet or Sprinkle to do
>>>> something
>>>> similar, using the pre-existing lists of servers, and their roles
>>>> via
>>>> Capistrano to manage configurations.
>>>> That's my take on it, and there's a post on the capistrano-dev list
>>>> that
>>>> says as much as "server provisioning isn't what we're good at" - so
>>>> we won't
>>>> be getting anymore involved I don't think... mostly what people are
>>>> saying
>>>> when they refer to provisioning with Capistrano is provisioning
>>>> with
>>>> Net::SSH with a list of servers that happens to be in your
>>>> deploy.rb..
>>>> Hope that clears up my take on this at least!
>>>>> Many people have mentioned Capistrano as being a great tool for
>>>>> system
>>>>> administration but I am finding it hard to find any reasons on why
>>>>> it would
>>>>> be? Many of the tasks can be done with a much simpler Bash script
>>>>> but maybe
>>>>> I don't know of the fantastic features Capistrano is capable of
>>>>> because of
>>>>> the somewhat lacking documentation.
>>>>> Any views on this?
>>>>> Will
> How do you ensure that during the maintenance part of the server
> life-cycle that your servers' configurations stay within your spec/ > standard?
> Unless these are like throw away clusters of cloud nodes that you
> don't
> expect to live very long, I think cap isn't really the right tool.
Speaking for myself, as a Ruby programmer who also does sysadmin work,
Capistrano is great in part because I already know it. I suspect that
both Chef and Puppet will have some strengths over capistrano in some
SA applications but I havent had enough of a need so far to use them.
They are on my long list of technologies to master. (First comes
dtrace, R, Rightscale)
> Many people have mentioned Capistrano as being a great tool for
> system administration but I am finding it hard to find any reasons
> on why it would be? Many of the tasks can be done with a much
> simpler Bash script but maybe I don't know of the fantastic features
> Capistrano is capable of because of the somewhat lacking
> documentation.
There's a no doubt that Capistrano is a very useful tool. However it's
purpose
is a little different from Puppet (or Chef).
Puppet is a configuration management. It's a provisioning platform. So
basically
what we do is to take a system and bring it to a predefined state. It's not
the
perfect description, but a rough idea. So tell Puppet, in a declaration
(opposed
to a set of stepwise instructions) what state we need the server to be and
it
happily does the background work and leaves us with the server brought to
that
state. It also keep track of the servers and is able to revert any changes
done
manually (without using configuration management). It might sound simple,
but
Puppet is a great tool with a lot of potential.
Capistrano is the same light is not a configuration management system. It
never
was designed or developed to be. However it's very good at what it does;
deployment automation. I can't remember who said it, perhaps Jamis. A good
way to think about Capistrano is like automated/scripted SSH. It is possible
to
replace most of Capistranos work, with just SSH and shell scripts, but it
becomes a real pain. Capistrano makes deploying very easy and painless,
specially if what you are deploying is a Rails application. It also can
execute
any system commands in the process. Puppet is not used for this purpose. We
don't use Puppet to deploy a web app or such, because it's not what Puppet
does.
For an example I can use Capistrano to deploy a web application (taken from
a version control system), run migrations, etc. and have it running just by
issuing
one or two commands. I also can use Puppet to make sure I'm running a
specific Apache web server version (with a specific Passenger version) using
specific port number and running as a specific user, etc. You can use both
tools
to complement each other, once you know the quirks. Throw in a few more
things
like Cobbler (installation), Hudson (continuous integration), you can have a
fully
automated software infrastructure.
As you can see there are specific things these tools are very good at. Just
wanted to elaborate a bit on the difference. So I gave a rough overview. I
learned most of these in #puppet and #capistrano (Freenode).
On Thu, Jul 2, 2009 at 6:15 PM, Lee Hambley <lee.hamb...@gmail.com> wrote:
> Will,
> People say that largely because it's handy to be able to tell an existing
> list of servers that you deploy to, to run a command - some people (like
> myself) choose to ship a bash script with their app, to provision the
> server.
> Others use software like Deprec, Chap, Puppet or Sprinkle to do something
> similar, using the pre-existing lists of servers, and their roles via
> Capistrano to manage configurations.
> That's my take on it, and there's a post on the capistrano-dev list that
> says as much as "server provisioning isn't what we're good at" - so we won't
> be getting anymore involved I don't think... mostly what people are saying
> when they refer to provisioning with Capistrano is provisioning with
> Net::SSH with a list of servers that happens to be in your deploy.rb..
>> Many people have mentioned Capistrano as being a great tool for system
>> administration but I am finding it hard to find any reasons on why it would
>> be? Many of the tasks can be done with a much simpler Bash script but maybe
>> I don't know of the fantastic features Capistrano is capable of because of
>> the somewhat lacking documentation.
The purpose of these tools is different, I think they're complementary in system administrators field. I see Chef/puppet for configure machines and capistrano to deploy applications.
> There's a no doubt that Capistrano is a very useful tool. However it's > purpose
> is a little different from Puppet (or Chef).
> Puppet is a configuration management. It's a provisioning platform. So > basically
> what we do is to take a system and bring it to a predefined state. > It's not the
> perfect description, but a rough idea. So tell Puppet, in a > declaration (opposed
> to a set of stepwise instructions) what state we need the server to be > and it
> happily does the background work and leaves us with the server brought > to that
> state. It also keep track of the servers and is able to revert any > changes done
> manually (without using configuration management). It might sound > simple, but
> Puppet is a great tool with a lot of potential.
> Capistrano is the same light is not a configuration management system. > It never
> was designed or developed to be. However it's very good at what it does;
> deployment automation. I can't remember who said it, perhaps Jamis. A good
> way to think about Capistrano is like automated/scripted SSH. It is > possible to
> replace most of Capistranos work, with just SSH and shell scripts, but it
> becomes a real pain. Capistrano makes deploying very easy and painless,
> specially if what you are deploying is a Rails application. It also > can execute
> any system commands in the process. Puppet is not used for this > purpose. We
> don't use Puppet to deploy a web app or such, because it's not what Puppet
> does.
> For an example I can use Capistrano to deploy a web application (taken > from
> a version control system), run migrations, etc. and have it running > just by issuing
> one or two commands. I also can use Puppet to make sure I'm running a
> specific Apache web server version (with a specific Passenger version) > using
> specific port number and running as a specific user, etc. You can use > both tools
> to complement each other, once you know the quirks. Throw in a few > more things
> like Cobbler (installation), Hudson (continuous integration), you can > have a fully
> automated software infrastructure.
> As you can see there are specific things these tools are very good at. > Just
> wanted to elaborate a bit on the difference. So I gave a rough overview. I
> learned most of these in #puppet and #capistrano (Freenode).
> On Thu, Jul 2, 2009 at 6:15 PM, Lee Hambley <lee.hamb...@gmail.com > <mailto:lee.hamb...@gmail.com>> wrote:
> Will,
> People say that largely because it's handy to be able to tell an
> existing list of servers that you deploy to, to run a command -
> some people (like myself) choose to ship a bash script with their
> app, to provision the server.
> Others use software like Deprec, Chap, Puppet or Sprinkle to do
> something similar, using the pre-existing lists of servers, and
> their roles via Capistrano to manage configurations.
> That's my take on it, and there's a post on the capistrano-dev
> list that says as much as "server provisioning isn't what we're
> good at" - so we won't be getting anymore involved I don't
> think... mostly what people are saying when they refer to
> provisioning with Capistrano is provisioning with Net::SSH with a
> list of servers that happens to be in your deploy.rb..
> Hope that clears up my take on this at least!
> - Lee
> 2009/7/2 william pink <will.p...@gmail.com
> <mailto:will.p...@gmail.com>>
> Hi,
> Just a general question
> Many people have mentioned Capistrano as being a great tool
> for system administration but I am finding it hard to find any
> reasons on why it would be? Many of the tasks can be done with
> a much simpler Bash script but maybe I don't know of the
> fantastic features Capistrano is capable of because of the
> somewhat lacking documentation.
|
