Re: [capistrano] Deploying to self-same server

1,207 views
Skip to first unread message

Lee Hambley

unread,
Jun 6, 2012, 10:51:25 AM6/6/12
to capis...@googlegroups.com
Hi JD,

From the docs:
Capistrano is a developer tool for deploying web applications. It is typically installed on a workstation, and used to deploy code from your source code management (SCM) to one, or more servers.
It can be used with some horrible hacks to do loopback ssh on locally bound IP/ports, but frankly you should take a look at rake or make for that kind of thing.

- Lee Hambley, Maintainer,

On Wednesday, June 6, 2012 at 4:48 PM, jdgriffith wrote:

I am curious about using capistrano to deploy to the selfsame server on which the recipe lives on without doing an ssh connection since it is not needed. Is this something capistrano can do easily or is it mostly used for remote deployments?

Regards,
Jdgriffith

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

Donovan Bray

unread,
Jun 6, 2012, 11:38:34 AM6/6/12
to capis...@googlegroups.com
Possibly if you override the sudo, run, and make them call run_locally

That being said I've deployed to localhost by setting up a specific key for the deploy user, and it worked fine and preserved the ability to deploy to stages that weren't localhost. 

What's so bad about ssh'ing to itself?

Other ideas can be found here



On Jun 6, 2012, at 7:48 AM, jdgriffith <justin.dea...@gmail.com> wrote:

Lee Hambley

unread,
Jun 6, 2012, 11:40:27 AM6/6/12
to capis...@googlegroups.com
Donovan,

Kudos for giving a longer answer, but when you are "deploying" to a local server, what you are really doing is building the app, deploying, sort of by definition is getting something from somewhere, and putting it somewhere else…

I'd argue rake is the correct tool for a *lot* of what people misuse capistrano for; and particularly in this case, Rake fits the bill perfectly for building/releasing when everything is in one place.

- Lee

Donovan Bray

unread,
Jun 6, 2012, 9:34:06 PM6/6/12
to capis...@googlegroups.com
I have a much more liberal view I guess of what capistrano can be leveraged for. If you know you have to build a deployment tool to reach remote servers; and deploying to localhost allows you to test that pattern before you pay for that server then by all means do it with cap. 

However I agree many maintenance tasks are written directly in cap when they should be written in rake. I create a rake cmd wrapper that I use in those situations so I can easily call the rake task from cap just as easily as I could run rake directly on the server via the console.  If you ONLY have those tasks in cap then that is a deployment smell. 

Always leave yourself options. 

Lee Hambley

unread,
Jun 7, 2012, 3:48:23 AM6/7/12
to capis...@googlegroups.com
I have a much more liberal view I guess of what capistrano can be leveraged for. If you know you have to build a deployment tool to reach remote servers; and deploying to localhost allows you to test that pattern before you pay for that server then by all means do it with cap. 

I'd say misused, additional use cases outside of the intended make it increasingly difficult for me to change anything, because I am then breaking mis-features, and mis-uses of the library; but in open source that's not something one can ever prevent.

However I agree many maintenance tasks are written directly in cap when they should be written in rake.

I'm seriously considering adding a `rake()` command, that's effectively `run("#{rake} #{task}")` - to encourage this technique, and make it seem more like someone actually thought about it.

- Lee

Michael Richardson

unread,
Jun 7, 2012, 9:31:03 AM6/7/12
to capis...@googlegroups.com

>>>>> "Donovan" == Donovan Bray <donn...@gmail.com> writes:
Donovan> That being said I've deployed to localhost by setting up a
Donovan> specific key for the deploy user, and it worked fine and
Donovan> preserved the ability to deploy to stages that weren't
Donovan> localhost.

Donovan> What's so bad about ssh'ing to itself?

Yeah, this just seems like the best way.

I've wanted to hack the git recipes to add a --reference argument so
that git clones go super-fast, and this would also rock for ::1.

--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.

Donovan Bray

unread,
Jun 7, 2012, 11:22:41 AM6/7/12
to capis...@googlegroups.com
I don't see how it's misused; ssh is ssh whether your doing it to localhost or otherwise it requires no particular support from capistrano.  In both cases you only need to ensure that your ssh client and server are properly configured. 

That's the beauty of capistrano being built in ruby; you are free to make the necessary changes to support your core concept. If that isn't what I want out of capistrano I'm free to monkey patch it.  

As much as I'm a proponent for bending cap where it makes sense; I'm also your biggest supporter of making capistrano narrowly focused on delivering a reliable deployment system. The inspired architecture and openness to be extended will continue to allow me to use it for provisioning. You shouldn't be shackled by anything outside your core concept, I say change what you must and be brutal about adhering to your core concept. 
Reply all
Reply to author
Forward
0 new messages