Capistrano for Systems administrators

[william pink]

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

[Lee Hambley]

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...@gmail.com>

[will]

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!
>
> - Lee
>

> 2009/7/2 william pink <will.p...@gmail.com>

[Joe McDonagh]

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 McDonagh
Operations Engineer
www.colonfail.com

[Lee Hambley]

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...@gmail.com>

[Joe McDonagh]

Lee Hambley wrote:
> 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...@gmail.com

> <mailto:joseph.e...@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:will.p...@gmail.com>>

> www.colonfail.com <http://www.colonfail.com>
>
>
>
>
>
> >
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.

[Lee Hambley]

Joe,

Thanks for the resources, that's great to know - wiki search always sucks!

[Donovan Bray]

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.

[Joe McDonagh]

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]

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.

- Lee

2009/7/2 Donovan Bray <donn...@gmail.com>

[Lee Hambley]

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...@gmail.com>

[Joe McDonagh]

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...@gmail.com

> <mailto:joseph.e...@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...@gmail.com

> <mailto:will...@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: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.
>
> --
> Joe McDonagh
> Operations Engineer

> www.colonfail.com <http://www.colonfail.com>
>
>
>
>
>
> >
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.

[Donovan Bray]

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.

[Donovan Bray]

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...@gmail.com>
wrote:

[Peter Booth]

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)

[Gaveen Prabhasara]

Will & Lee,

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).

Gaveen Prabhasara
http://gaveen.owain.org
http://twitter.com/gaveen

[Rafael G.]

+1

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.

> <mailto:will...@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
>
>
>
>
>
>
>
> >

--
Rafa