mirror of
https://github.com/capistrano/capistrano
synced 2023-03-27 23:21:18 -04:00
Commit this stuff before I lose it all
This commit is contained in:
Lee Hambley
commit
61aec364b2
26 changed files with 1094 additions and 0 deletions
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
|
|
@ -0,0 +1 @@
|
|||
_site
|
||||
6
Gemfile
Normal file
6
Gemfile
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
source "https://rubygems.org"
|
||||
|
||||
gem "debugger"
|
||||
gem "jekyll"
|
||||
gem "redcarpet"
|
||||
gem "git"
|
||||
50
Gemfile.lock
Normal file
50
Gemfile.lock
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
classifier (1.3.3)
|
||||
fast-stemmer (>= 1.0.0)
|
||||
colorator (0.1)
|
||||
columnize (0.3.6)
|
||||
commander (4.1.3)
|
||||
highline (~> 1.6.11)
|
||||
debugger (1.6.0)
|
||||
columnize (>= 0.3.1)
|
||||
debugger-linecache (~> 1.2.0)
|
||||
debugger-ruby_core_source (~> 1.2.1)
|
||||
debugger-linecache (1.2.0)
|
||||
debugger-ruby_core_source (1.2.2)
|
||||
directory_watcher (1.4.1)
|
||||
fast-stemmer (1.0.2)
|
||||
git (1.2.5)
|
||||
highline (1.6.19)
|
||||
jekyll (1.0.2)
|
||||
classifier (~> 1.3)
|
||||
colorator (~> 0.1)
|
||||
commander (~> 4.1.3)
|
||||
directory_watcher (~> 1.4.1)
|
||||
kramdown (~> 1.0.2)
|
||||
liquid (~> 2.3)
|
||||
maruku (~> 0.5)
|
||||
pygments.rb (~> 0.5.0)
|
||||
safe_yaml (~> 0.7.0)
|
||||
kramdown (1.0.2)
|
||||
liquid (2.5.0)
|
||||
maruku (0.6.1)
|
||||
syntax (>= 1.0.0)
|
||||
posix-spawn (0.3.6)
|
||||
pygments.rb (0.5.0)
|
||||
posix-spawn (~> 0.3.6)
|
||||
yajl-ruby (~> 1.1.0)
|
||||
redcarpet (2.2.2)
|
||||
safe_yaml (0.7.1)
|
||||
syntax (1.0.0)
|
||||
yajl-ruby (1.1.0)
|
||||
|
||||
PLATFORMS
|
||||
ruby
|
||||
|
||||
DEPENDENCIES
|
||||
debugger
|
||||
git
|
||||
jekyll
|
||||
redcarpet
|
||||
7
_config.yml
Normal file
7
_config.yml
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
name: Capistrano
|
||||
pygments: true
|
||||
markdown: redcarpet
|
||||
redcarpet:
|
||||
extensions: ["no_intra_emphasis", "fenced_code_blocks", "autolink", "tables", "with_toc_data"]
|
||||
table_of_contents:
|
||||
dirs: [documentation]
|
||||
28
_includes/footer.html
Normal file
28
_includes/footer.html
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
<div class="bottom-menu">
|
||||
<div class="container">
|
||||
<div class="row">
|
||||
<div class="span2 brand">
|
||||
<a href="http://capistranorb.com/" class="capistrano-logo"></a>
|
||||
</div>
|
||||
|
||||
<div class="span8">
|
||||
<ul class="bottom-links">
|
||||
<li><a href="#fakelink">About Capistrano</a></li>
|
||||
<li><a href="#fakelink">Contributing</a></li>
|
||||
<li><a href="#fakelink">Releases</a></li>
|
||||
<li><a href="#fakelink">Upgrading</a></li>
|
||||
<li><a href="#fakelink">StackOverflow</a></li>
|
||||
<li><a href="#fakelink">Mailing List</a></li>
|
||||
<li><a href="#fakelink">Support</a></li>
|
||||
<li><a href="#fakelink">Links</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="span2">
|
||||
<ul class="bottom-icons">
|
||||
<li><a href="#fakelink" class="fui-twitter"></a></li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
5
_includes/header.html
Normal file
5
_includes/header.html
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
<div class="header pure-u-1-1">
|
||||
<a href="/" class="brand">
|
||||
<img src="/images/CapistranoLogo.png" />
|
||||
</a>
|
||||
</div>
|
||||
31
_includes/navigation.html
Normal file
31
_includes/navigation.html
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
<div class="pure-menu pure-menu-open">
|
||||
<ul class="nav nav-list">
|
||||
<li><a href="http://www.harrow.io/" class="advertisment"><span class="label label-important">New</span> Hosted Capistrano for Teams</a></li>
|
||||
<li class="pure-menu-heading">Overview</li>
|
||||
<li><a href="/documentation/overview/what-is-capistrano/">What is Capistrano?</a></li>
|
||||
<li><a href="/documentation/overview/introductory-demo-video/">Introductory Demo Video</a></li>
|
||||
<li class="pure-menu-heading">Getting Started</li>
|
||||
<li><a href="/documentation/getting-started/installation/">Installation</a></li>
|
||||
<li><a href="/documentation/getting-started/preparing-your-application/">Preparing Your Application</a></li>
|
||||
<li><a href="/documentation/getting-started/authentication-and-authorisation/">Authentication & Authorisation</a></li>
|
||||
<li><a href="/documentation/getting-started/cold-start/">Cold Start</a></li>
|
||||
<li><a href="/documentation/getting-started/rollbacks/">Rollbacks</a></li>
|
||||
<li class="pure-menu-heading">Troubleshooting</li>
|
||||
<li><a href="/documentation/troubleshooting/authentication/">SCM (Git, SVN, etc) Authentication</a></li>
|
||||
<li><a href="/documentation/troubleshooting/connectivity/">Connectivity</a></li>
|
||||
<li><a href="/documentation/troubleshooting/gateway-servers/">Gateway Servers</a></li>
|
||||
<li><a href="/documentation/troubleshooting/agent-forwarding/">Agent Forwarding</a></li>
|
||||
<li><a href="/documentation/troubleshooting/sudo-password/">`sudo` Password</a></li>
|
||||
<li><a href="/documentation/troubleshooting/rvm-rbenv-nvm/">RVM, `rbenv` And `nvm`</a></li>
|
||||
<li class="pure-menu-heading">FAQ</li>
|
||||
<li><a href="/documentation/faq/why-does-something-work-in-my-ssh-session-but-not-in-capistrano/">Why Does Something Work In An SSH Session, But Not In Capistrano</a></li>
|
||||
<li><a href="/documentation/faq/should-i-use-capistrano-to-provision-my-servers/">Should I Use Capistrano To Provision My Servers?</a></li>
|
||||
<li class="pure-menu-heading">Power Use-Cases</li>
|
||||
<li><a href="/documentation/power-use-cases/integration-with-rake/">Integration With Rake</a></li>
|
||||
<li><a href="/documentation/power-use-cases/driving-tools-such-as-chef-solo/">Driving Tools Such As <em>Chef Solo</em></a></li>
|
||||
<li class="pure-menu-heading">Recent Announcements</li>
|
||||
{% for post in site.posts %}
|
||||
<li><a href="{{ post.url }}"><span class="post-date">{{ post.date | date_to_string }}</span> {{ post.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
</div>
|
||||
47
_layouts/default.html
Normal file
47
_layouts/default.html
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>{{ page.title }}</title>
|
||||
<script type="text/javascript" src="//use.typekit.net/itm5ubu.js"></script>
|
||||
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>
|
||||
<link href='http://fonts.googleapis.com/css?family=Open+Sans:400,300' rel='stylesheet' type='text/css'>
|
||||
<link href='http://fonts.googleapis.com/css?family=Montserrat' rel='stylesheet' type='text/css'>
|
||||
<link href='http://fonts.googleapis.com/css?family=Enriqueta' rel='stylesheet' type='text/css'>
|
||||
<link href="http://vjs.zencdn.net/4.0.2/video-js.css" rel="stylesheet">
|
||||
<script src="http://vjs.zencdn.net/4.0.2/video.js"></script>
|
||||
<link rel="stylesheet" href="http://yui.yahooapis.com/pure/0.1.0/pure-min.css">
|
||||
<link rel="stylesheet" href="/css/syntax.css">
|
||||
<link rel="stylesheet" href="/css/capistrano.css">
|
||||
</head>
|
||||
<body>
|
||||
|
||||
{% include header.html %}
|
||||
|
||||
<div class="pure-g-r">
|
||||
<div class="pure-u-1-3">
|
||||
{% include navigation.html %}
|
||||
</div>
|
||||
<div class="pure-u-2-3">
|
||||
<div class="content">
|
||||
<h2>{{ page.title }}</h2>
|
||||
{{ content }}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--<div class="container"> -->
|
||||
<!-- <h1 class="title"><a href="/">{{ site.name }}</a></h1>-->
|
||||
<!-- <a class="extra" href="/">home</a> -->
|
||||
<!-- </div> -->
|
||||
|
||||
<!-- {{ content }} -->
|
||||
|
||||
<!--</div> [> /container <] -->
|
||||
|
||||
{% include footer.html %}
|
||||
|
||||
</body>
|
||||
</html>
|
||||
8
_layouts/post.html
Normal file
8
_layouts/post.html
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
layout: default
|
||||
---
|
||||
<p class="meta">{{ page.date | date_to_string }}</p>
|
||||
|
||||
<div id="post">
|
||||
{{ content }}
|
||||
</div>
|
||||
1
_layouts/table_of_contents.html
Normal file
1
_layouts/table_of_contents.html
Normal file
|
|
@ -0,0 +1 @@
|
|||
Why is this here?
|
||||
32
_plugins/gitactivity.rb
Normal file
32
_plugins/gitactivity.rb
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
require 'git'
|
||||
|
||||
module Jekyll
|
||||
class GitActivityTag < Liquid::Tag
|
||||
|
||||
def initialize(tag_name, text, tokens)
|
||||
super
|
||||
end
|
||||
|
||||
def render(context)
|
||||
result = ""
|
||||
g = Git.open(File.join(Dir.getwd, ".."))
|
||||
|
||||
index = 0
|
||||
g.log.each do |log|
|
||||
if(index < 10)
|
||||
result << "<li>"
|
||||
result << log.date.strftime("%d %b")
|
||||
result << " - <a href='https://github.com/capistrano/capistrano-documentation/commit/"
|
||||
result << log.sha
|
||||
result << "/'>"
|
||||
result << log.message
|
||||
result << "</a></li>"
|
||||
index += 1
|
||||
end
|
||||
end
|
||||
"<ul>#{result}</ul>"
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
Liquid::Template.register_tag('gitactivity', Jekyll::GitActivityTag)
|
||||
30
_plugins/table_of_contents.rb
Normal file
30
_plugins/table_of_contents.rb
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
require 'git'
|
||||
|
||||
module Jekyll
|
||||
class TableOfContentsTag < Liquid::Tag
|
||||
def initialize(tag_name, text, tokens)
|
||||
super
|
||||
end
|
||||
def render(context)
|
||||
result = ""
|
||||
g = Git.open(File.join(Dir.getwd, ".."))
|
||||
|
||||
index = 0
|
||||
g.log.each do |log|
|
||||
if(index < 10)
|
||||
result << "<li>"
|
||||
result << log.date.strftime("%d %b")
|
||||
result << " - <a href='https://github.com/capistrano/capistrano-documentation/commit/"
|
||||
result << log.sha
|
||||
result << "/'>"
|
||||
result << log.message
|
||||
result << "</a></li>"
|
||||
index += 1
|
||||
end
|
||||
end
|
||||
"<ul>#{result}</ul>"
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
Liquid::Template.register_tag('table_of_contents', Jekyll::TableOfContentsTag)
|
||||
24
_posts/2013-05-18-welcome-to-jekyll.markdown
Normal file
24
_posts/2013-05-18-welcome-to-jekyll.markdown
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
layout: post
|
||||
title: "Welcome to Jekyll!"
|
||||
date: 2013-05-18 15:09:49
|
||||
categories: jekyll update
|
||||
---
|
||||
|
||||
You'll find this post in your `_posts` directory - edit this post and re-build (or run with the `-w` switch) to see your changes!
|
||||
To add new posts, simply add a file in the `_posts` directory that follows the convention: YYYY-MM-DD-name-of-post.ext.
|
||||
|
||||
Jekyll also offers powerful support for code snippets:
|
||||
|
||||
{% highlight ruby %}
|
||||
def print_hi(name)
|
||||
puts "Hi, #{name}"
|
||||
end
|
||||
print_hi('Tom')
|
||||
#=> prints 'Hi, Tom' to STDOUT.
|
||||
{% endhighlight %}
|
||||
|
||||
Check out the [Jekyll docs][jekyll] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll's GitHub repo][jekyll-gh].
|
||||
|
||||
[jekyll-gh]: https://github.com/mojombo/jekyll
|
||||
[jekyll]: http://jekyllrb.com
|
||||
529
_posts/2013-06-01-release-announcement.markdown
Normal file
529
_posts/2013-06-01-release-announcement.markdown
Normal file
|
|
@ -0,0 +1,529 @@
|
|||
---
|
||||
layout: post
|
||||
title: "Capistrano Version 3 Release Announcement"
|
||||
date: 2013-06-01 00:00:00
|
||||
---
|
||||
|
||||
After what seems like years of work, the Capistrano team (that's Tom and I)
|
||||
are pleased to announce the first *major* release of Capistrano in almost 5
|
||||
years.
|
||||
|
||||
The reasons behind the length of time between the last architectural overhaul
|
||||
and this one are numerous, but it can be summrised to say that Capistrano is a
|
||||
widely used tool, and when working around software deployment it's really a
|
||||
question of downtime. If we had changed something significant in Capistrano we
|
||||
could have taken a lot of sites offline, and made a lot of people very
|
||||
unhappy. Until this point we haven't felt that the time has been ripe where
|
||||
the benefits of a slightly rocky upgrade path are worth the risks of downtime.
|
||||
|
||||
It also hasn't helped historically that we've only just gotten to grips with
|
||||
Ruby 1.9, and that Bundler's near ubuquity means that now it's trivial to lock
|
||||
a Gem at a specific version. With other tools in the Ruby eco system it's
|
||||
become easier for us to make significant changes to a tool upon which many
|
||||
hundreds of thousands of people rely.
|
||||
|
||||
### Design Goals
|
||||
|
||||
We had a few goals for this release, in no particular order they were:
|
||||
|
||||
* **Get away from our own DSL solution.** Great DSL alternatives (Rake, Sake, Thor,
|
||||
etc) are already widely used.
|
||||
* **Better modularisation.** to enable people outside the Rails community to
|
||||
benefit from Capistrano's *best-practice* workflow, and to enable people in
|
||||
the Rails community to pick and choose support for components they use
|
||||
(Database Migrations, Asset Pipeline, etc)
|
||||
* **Easier Debugging.** A lot of problems with Capistrano come from weirdness
|
||||
surrounding environmental issues around PTY vs non-TTY environments, login
|
||||
and non-login shells not to mention *environment managers* such as rvm,
|
||||
rbenv and nvm.
|
||||
* **Speed.** We know that in a lot of environments speed of deploment is a
|
||||
huge factor, since Rails introduced the *Asset Pipeline* it's not uncommon
|
||||
for a deploy that formerly took 5 seconds now takes 5 minutes. This really
|
||||
is mostly out of our control, but with improved support for parallelism,
|
||||
rolling restarts we feel confident that things are bettwe not.
|
||||
* **Applicability.** We've always maintained that Capistrano is a terrible
|
||||
tool for system provisioning, and that more often than not servers are
|
||||
better being setup with Chef, Puppet or similar, whilst we still agree with
|
||||
that, the new features in Capistrano really lend themselves to integrating
|
||||
with these kinds of tools.
|
||||
|
||||
### What's missing?
|
||||
|
||||
Before we get too carried away it's worth shortlisting the things that don't
|
||||
exist in version three, *yet*.
|
||||
|
||||
* *Run Locally.* `run_locally` was always a bit of the poor relation in the
|
||||
family, it didn't quite work the same way as other things, and I never liked
|
||||
the idea that you were binding a tool that in principle should be cross
|
||||
platform (Ruby, and Capistrano) to locally executing shell commands which
|
||||
probably only work on POSIX-like operating systems. I hope that
|
||||
`run_locally` will stay gone, and that as a community we can find better
|
||||
ways of doing things that always relied on locally creating tarballs, or
|
||||
writing configuration files, or similar.
|
||||
* *SSH Gateway Support.* SSH Gateway support hasn't been implemented in
|
||||
version three yet, I hope that this will be done soon. As I have no direct
|
||||
need for it, I haven't the means to test it with a view to implementing it,
|
||||
yet.
|
||||
* *Mecurial, Subversion, and CVS Support.* These have been removed as we've
|
||||
been able to implement the Git SCM in an incredibly neat way that isn't
|
||||
compatible with the others. We wanted to break the cycle of always sticking
|
||||
with the lowest common denominator, so we are **actively** looking for
|
||||
people who are interested in contributing, or sharing expertise on the
|
||||
*best-practice* way of speedily deploying from your respective choice of
|
||||
source control.
|
||||
* *`HOSTFILTER` ,`ROLEFILTER` and friends.* These have gone away because I
|
||||
always felt they were indemic of a bad design desision about using
|
||||
Environmental Variables. These will be coming back as flags passed to `cap`
|
||||
on the CLI, and options that can be set on the Capistrano::Application Ruby
|
||||
class.
|
||||
* *Shell.* The shell has been removed temporarily pending a neater
|
||||
implementation, we've got something that we are playing with internally, but
|
||||
it needs better readline support, and some more controls around what to do
|
||||
when things go badly on some servers, but not others.
|
||||
* *Cold Deploy.* The `cap deploy:cold` is a really old legacy component,
|
||||
orignally from the days of the `script/spinner` where deploying cold
|
||||
(starting workers that weren't running), and deploying a *warm* system were
|
||||
different (restarting existing worker pools, which wasn't fun!) By and large
|
||||
these things have gone away, and it's time `deploy:cold` went away. It's
|
||||
safe in every case we could find to call setup, and seed and other Rake
|
||||
tasks without things blowing up, and that should be the approach we take.
|
||||
Tasks on the server should be idempotent, and if something is called twice,
|
||||
let it be.
|
||||
* *Coloured Output.*✝ The capistrano-colours Gem was (fairly) recently merged
|
||||
into Capistrano v2, this has gone away in favour of a IO streaming model
|
||||
inspired by MiniTest/Pride. Read more below in new features.
|
||||
|
||||
### What's new?
|
||||
|
||||
Each section here really deserves it's own sub-heading as some of the new
|
||||
features are awesome.
|
||||
|
||||
#### Rake Integration
|
||||
|
||||
We have moved away from our own DSL implemenation to implement Capistrano as a
|
||||
Rake application.
|
||||
|
||||
Rake has always supported being sub-classed, so to speak as a
|
||||
*sub-application*; it is however poorly documented. By subclassing
|
||||
Rake::Application one can specify what the *Rakefile* should look like, where
|
||||
to search for it, and how to load other *Rakefiles*.
|
||||
|
||||
The *Rake* DSL is widely used, well known and very powerful. As Rake is
|
||||
essentially a dependency resolution system, it offers a lot of nice ways to,
|
||||
for example build a tarball as a dependency of uploading it and deploying it.
|
||||
|
||||
This has allowed us to do away with the *copy* strategy all together, as it
|
||||
can now be implemented from scratch in fewer than ten lines of code. You can
|
||||
check out the [replicating the copy strategy][] screencast and acompanying
|
||||
documentation if you want to explore that any further.
|
||||
|
||||
The guiding principle is dependency resolution, and interoperability with
|
||||
other tools, for example:
|
||||
|
||||
{% highlight ruby %}
|
||||
# No description, this is an internal method
|
||||
task :notify do
|
||||
this_release_tag = sh("git describe --abbrev=0 --tags")
|
||||
last_ten_commits = sh("git log #{this_release_tag}~10..#{this_release_tag}")
|
||||
Mail.deliver do
|
||||
to "team@example.com"
|
||||
subject "Releasing #{this_release_tag} Now!"
|
||||
body last_ten_commits
|
||||
end
|
||||
end
|
||||
|
||||
namespace :deploy
|
||||
task default: :notify
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
The last three lines rely on Rake's additive task declaration, by redefining the
|
||||
`deploy:default` task by adding another dependency. Rake will automatically
|
||||
resolve this dependency at Runtime, mailing the recent changelog to your team,
|
||||
assuming everything is setup correctly.
|
||||
|
||||
#### Built In Stage Support
|
||||
|
||||
#### Parallelism
|
||||
|
||||
In former versions of Capistrano there was a *parallel* option to run
|
||||
different tasks differently on groups of servers, it looked something like
|
||||
this:
|
||||
|
||||
{% highlight ruby %}
|
||||
task :restart do
|
||||
parallel do |session|
|
||||
session.when "in?(:app)", "/u/apps/social/script/restart-mongrel"
|
||||
session.when "in?(:web)", "/u/apps/social/script/restart-apache"
|
||||
session.else "echo nothing to do"
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
This always felt a little unclean, and indeed it's a hack that was originally
|
||||
implemeted to facilitate rolling deployments at a large German firm by a
|
||||
couple of freelancers who were consulting with them. (Hint, one of those guys
|
||||
went on to found Travis-CI!)
|
||||
|
||||
The equivilent code in under Capistrano v3 would look like this:
|
||||
|
||||
{% highlight ruby %}
|
||||
task :restart do
|
||||
on :all, in: :parallel do |host|
|
||||
if host.roles.include?(:app)
|
||||
execute "/u/apps/social/script/restart-mongrel"
|
||||
elsif host.roles.include?(:web)
|
||||
execute "/u/apps/social/script/restart-web"
|
||||
else
|
||||
info "Nothing to do for #{host} with roles #{host.properties.roles}."
|
||||
end
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
The second block of code, that representing the new Rake derived DSL and
|
||||
demonstrating how to use the parallel execution mode is a little longer, but I
|
||||
think it's clearer, more idiomatic Ruby code which relies less on an intimate
|
||||
knowledge of how the Capistrano DSL happens to work. It also hints at the
|
||||
built-in logging subsystem, keep reading to learn more.
|
||||
|
||||
Other modes for parallelism include:
|
||||
|
||||
{% highlight ruby %}
|
||||
on :all, in: :groups, max: 3, wait: 5 do
|
||||
# Take all servers, in groups of three which execute in parallel
|
||||
# wait five seconds between groups of servers.
|
||||
# This is perfect for rolling restarts
|
||||
end
|
||||
|
||||
on :all, in: :sequence, wait: 15 do
|
||||
# This takes all servers, in sequence and waits 15 seconds between
|
||||
# each server, this might be perfect if you are afraid about
|
||||
# overloading a shared resource, or want to defer the asset compilation
|
||||
# over your cluster owing to worries about load
|
||||
end
|
||||
|
||||
on :all, in: :parallel do
|
||||
# This will simply try and execute the commands contained within
|
||||
# the block in parallel on all servers. This might be perfect for kicking
|
||||
# off something like a Git checkout or similar.
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
The internal tasks, for standard deploy recipes make use of all of these as is
|
||||
appropriate for the normal case, no need to be afraid of scary slow deploys
|
||||
again!
|
||||
|
||||
#### Streaming IO
|
||||
|
||||
This IO streaming model means that results from commands, the commands
|
||||
themselves and any other arbitrary output are sent as objects to a class with
|
||||
an `IO`ish interface, the class knows what to do with these things. There's a
|
||||
*progress* formatter which prints dots for each command that is called, as
|
||||
well as a *pretty* formatter which prints the full command, it's output on
|
||||
standard out and standard error, as well as the final return status. It would
|
||||
be trivial to implement HTML formatters, or formatters that reported to your
|
||||
IRC room, or to email. I look forward to seeing more of these cropping up in
|
||||
the community.
|
||||
|
||||
#### Host Definition Access
|
||||
|
||||
If you didn't skim over the *Parallism* section above, you might have noticed we
|
||||
did something clever that wasn't possible in Capistrano v2; we accessed the
|
||||
`host` inside the execution block.
|
||||
|
||||
For a lot of reasons in Capistrano v2 is wasn't possible to do this, the block
|
||||
was essentially evaluated once and called verbatim on each host. This lead to
|
||||
disappointing missing features such as not being able to pull the host list
|
||||
out of Capistrano and examine the roles to do something like controlling chef
|
||||
solo, or similar.
|
||||
|
||||
In Capistrano v3 the `host` object is the same object that is created when a
|
||||
server is defined, and is internally used, for example to pass to an ERB
|
||||
template for rendering a last-deploy message that is dumped onto each server
|
||||
after a successful deployment. The last deploy log includes everything
|
||||
Capistrano knew about that server during the deployment.
|
||||
|
||||
> Users of Capistrano v2 may be familiar with the perenial `cap deploy:cleanup`
|
||||
problem which came to light when servers differed in their old releases list,
|
||||
imagine a scenario with two servers, one has been your bread-and-butter since
|
||||
you launched, it has hundreds of old releases from all your wonderful deploys
|
||||
over the months or years. The second server has been in the cluster for about
|
||||
a month, it didn't quite slot-in cleanly, so the list of old releases looks a
|
||||
bit weird, you deleted a few by hand, and anyway there might only be ten-or-so
|
||||
releases there.
|
||||
|
||||
> Now imagine that you call `cap deploy:cleanup`, old `capture()`
|
||||
implementations silently only ran on the first server that matched the
|
||||
properties defined, so server one returned a list of ~95 old timestamped
|
||||
release directories. Next Capistrano v2 would call `rm -rf
|
||||
release1..release95` on **both** servers, causing server two to err our, and
|
||||
leaving an undefined state on server one, as Capistrano would simply hang up
|
||||
both connections.
|
||||
|
||||
This cleanup routine can now be better implemented as follows (which is
|
||||
actually more or less the actual implenetation in the the new Gem):
|
||||
|
||||
{% highlight ruby %}
|
||||
desc "Cleanup all old releases (keeps #{fetch(:releases_to_keeo_on_cleanup)}
|
||||
old releases"
|
||||
task :cleanup do
|
||||
keep_releases = fetch(:releases_to_keeo_on_cleanup)
|
||||
releases = capture(:ls, fetch(:releases_directory))
|
||||
release_to_delete = releases.sort_by { |r| rn.to_i }.slice(1..-(keep_releases + 1))
|
||||
releases_to_delete.each do |r|
|
||||
execute :rm, fetch(:releases_directory).join(r)
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
Some handy things to note here are that both server one and server two in our
|
||||
contrived example will both evaluate that independently, and when both servers
|
||||
are finished removing old releases the `task :cleanup` block will have
|
||||
finished.
|
||||
|
||||
Also in Capistrano v3 most path varaibles are [`Pathname`] objects, so they natively
|
||||
respond to things like `#basename`, `#expand_path`, `#join` and similar.
|
||||
|
||||
**Warning:** `#expand_path` probably won't do what you expect, it will execute
|
||||
on your *workstation* machine, and not on the remote host, so it's possible
|
||||
that it will return an error in the case of paths which exist remotely but not
|
||||
locally.
|
||||
|
||||
#### Host Properties
|
||||
|
||||
As the `host` object is now available to the task blocks, it made sense to make
|
||||
it possible to store arbitrarty values against them.
|
||||
|
||||
Enter `host.properties`. This is a simple [*OpenStruct*][] which can be used to
|
||||
store any additional properties which are important for your application.
|
||||
|
||||
An example of it's usage might be:
|
||||
|
||||
{% highlight ruby %}
|
||||
h = SSHKit::Host.new 'example.com'
|
||||
h.properties.roles ||= %i{wep app}
|
||||
{% endhighlight %}
|
||||
|
||||
#### More Expressive Command Language
|
||||
|
||||
In Capistrano v2, it wasn't uncommon to find commands such as:
|
||||
|
||||
{% highlight ruby %}
|
||||
task :precompile, :roles => lambda { assets_role }, :except => { :no_release => true } do
|
||||
run <<-CMD.compact
|
||||
cd -- #{latest_release} &&
|
||||
RAILS_ENV=#{rails_env.to_s.shellescape} #{asset_env} #{rake} assets:precompile
|
||||
CMD
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
In Capistrano v3 this looks more like this:
|
||||
|
||||
{% highlight ruby %}
|
||||
task :precompile do
|
||||
on :sprockets_asset_host, reject: lambda { |h| h.properties.no_release } do
|
||||
within fetch(:latest_release_directory)
|
||||
with rails_env: fetch(:rails_env) do
|
||||
execute :rake, 'assets:precompile'
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
Again, with other examples this format is a little longer, but much more
|
||||
expressive, and all the nightmare of shell escaping is handled interally for
|
||||
you, environmental variables are capitalised and applied at the correct point
|
||||
(i.e between the `cd` and `rake` calls in this case).
|
||||
|
||||
Other options here include `as :a_user` and
|
||||
|
||||
#### Better *magic* Variable Support
|
||||
|
||||
In Capistrano v2 there were certain bits of magic where if calling a variable
|
||||
and NoMethodError would have been raised (for example the
|
||||
`latest_release_directory` varaible). This variable never existed on the
|
||||
global namespace, as a fall-back the list of `set()` variables would be
|
||||
consulted.
|
||||
|
||||
This magic lead to times when people were not recognising that magic variables
|
||||
were even being used. The magic variable system of Capistrano v2 did also
|
||||
include a way to `fetch(:some_variable, 'with a default value')` incase the
|
||||
variable might not be set already, but it wasn't widely used, and more often
|
||||
than not people just used things like `latest_release_directory` never knowing
|
||||
that behind the scenes an exception was raised, then rescued, and that
|
||||
`:latest_release_directory` in the variable map was actually a continuation
|
||||
that was evaluated the first time it was used, and the value then cached until
|
||||
the end of the script.
|
||||
|
||||
The system has now 100% less magic. If you set a variable using `set()`, it
|
||||
can be fetched with `fetch()`, if the value you set into the variable responds
|
||||
to `#call` then it will be executed in the current context whenever it is
|
||||
used, the values will not be cached, unless your continuation does some
|
||||
explicit caching. *Again, we are favoring clarity over micro optimisation*.
|
||||
|
||||
#### SSHKit
|
||||
|
||||
Many of the new features in Capistrano whch relate to logging, formatting,
|
||||
SSH, connection management and pooling, parallism, batch execution and more
|
||||
are from a library that fell out of the Capistrano v3 development process.
|
||||
|
||||
[*SSHKit*][] is a lower level toolkit, a level higher than *Net::SSH*, still
|
||||
but lacking the roles, environments, rollbacks and other higher level features
|
||||
from Capistrano.
|
||||
|
||||
SSHkit is ideal for use if you need to just connect to a machine and run some
|
||||
arbitrary command, for example:
|
||||
|
||||
{% highlight ruby %}
|
||||
# Rakefile
|
||||
require 'sshkit'
|
||||
desc "Check the uptime of example.com"
|
||||
task :uptime do |h|
|
||||
execute :uptime
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
There is much more than can be done with SSHKit, and we have quite an
|
||||
extensive [list of examples][]. For the most part with Capistrano v3, anything
|
||||
that happens inside of an `on()` block is happening in SSHkit, and the
|
||||
documentation from that library is the place to go to find more information.
|
||||
|
||||
#### Command Mapping
|
||||
|
||||
This is another feature from SSHKit, designed to remove a little ambiguity
|
||||
from preceedings, there is a so-called command map for commands.
|
||||
|
||||
When executing something like:
|
||||
|
||||
{% highlight ruby %}
|
||||
execute "git clone ........ ......."
|
||||
{% endhighlight %}
|
||||
|
||||
The command is passed through to the remote server *completely unchanged*.
|
||||
This includes the options which might be set, such as user, directory, and
|
||||
environmental variables. **This is by design.** This feature is designed to
|
||||
allow people to write non-trivial commands in [heredocs][] when the need
|
||||
arises.
|
||||
|
||||
The idiomatic way to write that command in Capistrano v3 is to use the
|
||||
separated variadaric method to specify the command:
|
||||
|
||||
{% highlight ruby %}
|
||||
execute :git, :clone, "........", "......."
|
||||
{% endhighlight %}
|
||||
|
||||
In this way the *command map* is consulted, the command map maps all unknown
|
||||
commands (which in this case is `git`, the rest of the line are *arguments* to
|
||||
`git` ) are mapped to `/usr/bin/env ...`. Meaning that this command would be
|
||||
expanded to `/usr/bin/env git clone ...... ......` which is what happens when
|
||||
`git` is called without a full path, the `env` program is consulted (perhaps
|
||||
indirectly) to determine which `git` to run.
|
||||
|
||||
Commands such as `rake` and `rails` are often better prefixed by `bundle
|
||||
exec`, and in this case could be mapped to:
|
||||
|
||||
{% highlight ruby %}
|
||||
SSHKit.config.command_map[:rake] = "bundle exec rake"
|
||||
SSHKit.config.command_map[:rails] = "bundle exec rails"
|
||||
{% endhighlight %}
|
||||
|
||||
There can also be a lamda or Proc applied in place of the mapping like so:
|
||||
|
||||
{% highlight ruby %}
|
||||
SSHKit.config.command_map = Hash.new do |hash, key|
|
||||
if %i{rails rake bundle clockwork heroku}.include?(key.to_sym)
|
||||
hash[key] = "/usr/bin/env bundle exec #{key}"
|
||||
else
|
||||
hash[key] = "/usr/bin/env #{key}"
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
Between these two options there should be quite powerful options to map
|
||||
commands in your environment without having to override internal tasks from
|
||||
Capistrano just because a path is different, or a binary has a different name.
|
||||
|
||||
This can also be *slightly* abused in environments where *shim* executables
|
||||
are used, for example `rbenv` *wrappers*:
|
||||
|
||||
{% highlight ruby %}
|
||||
SSHKit.config.command_map = Hash.new do |hash, key|
|
||||
if %i{rails rake bundle clockwork heroku}.include?(key.to_sym)
|
||||
hash[key] = "/usr/bin/env myproject_bundle exec myproject_#{key}"
|
||||
else
|
||||
hash[key] = "/usr/bin/env #{key}"
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
The above assumes that you have done something like `rbenv wrapper default
|
||||
myproject` which creates wrapper binaries which correctly set up the Ruby
|
||||
environment without requiring an interactive login shell.
|
||||
|
||||
#### Testing
|
||||
|
||||
The old test suite for Capistrano was purely unit tests, and didn't cover a
|
||||
wide varity of problem cases, specifically nothing in the `deploy.rb` (that is
|
||||
the actual *deployment* code) was tested at all; because of having our own DSL
|
||||
implementation, and other slightly odd design points, it was painful to test
|
||||
the actual *recipes*.
|
||||
|
||||
Testing has been a focus of Capistrano v3. The *integration* test suite uses
|
||||
Vagrant to boot a machine, configures certain scenarios using portable shell
|
||||
script, and then executes commands against them, deploying common
|
||||
configurations to typical Linux systems. This is slow to execute, but offers
|
||||
stronger guarantees that nothing is broken that we've ever been able to give
|
||||
before.
|
||||
|
||||
Capistrano v3 also offers a possibility to swap out backend implementations.
|
||||
This is interesting because for the purpose of testing your *own* recipes you
|
||||
can use a *printer* backend, and verify that the output matched what you
|
||||
expected, or use a stubbed backend upon which you can verify that calls were
|
||||
made, or not made as expected.
|
||||
|
||||
#### Arbitrary Logging
|
||||
|
||||
Capistrano exposes the methods `debug()`, `info()`, `warn()`, `error()` and
|
||||
`fatal()` inside of `on()` blocks which can be used to log using the existing
|
||||
logging infrastructure and streaming IO formatters:
|
||||
|
||||
{% highlight ruby %}
|
||||
on hosts do |host|
|
||||
f = '/some/file'
|
||||
if test("[ -d #{f} ]")
|
||||
execute :touch, f
|
||||
else
|
||||
info "#{f} already exists on #{host}!"
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
### Upgrading
|
||||
|
||||
The best place to go here is the [upgrading documentation][] to get deeper
|
||||
into the specifics.
|
||||
|
||||
The simple version is to say that there is *no **direct** upgrade path*,
|
||||
versions two and three are incompatible.
|
||||
|
||||
This is partly by design, the old DSL was imprecise in places that would have
|
||||
made doing the right thing in most cases tricky, we opted to invest in more
|
||||
features and better reliability than investing in keeping a backwards
|
||||
compatible API.
|
||||
|
||||
There are a number of *gotchas* listed below, but the main points are the new
|
||||
names of the built-in roles, as well as that by default Capistrano v3 is
|
||||
platform agnostic, if you need Rails support, for migrations, asset pipeline
|
||||
and such like, then it's required to `require` the support files.
|
||||
|
||||
### Gotchas
|
||||
|
||||
#### Rake DSL Is Additive
|
||||
|
||||
In Capistrano v2 if you re-define a task then it replaces the original
|
||||
implemetation, this has been used by people to replace internal tasks
|
||||
piecemeal with their own implementations
|
||||
|
||||
#### `sudo` Behaviour
|
||||
4
changes.html
Normal file
4
changes.html
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Recent Site Changes"
|
||||
---
|
||||
66
css/capistrano.css
Normal file
66
css/capistrano.css
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
a {
|
||||
text-decoration: none;
|
||||
color: #52C1DB;
|
||||
}
|
||||
|
||||
body, p, a {
|
||||
font-family: 'Open-Sans', sans-serif;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
}
|
||||
|
||||
p, h1, h2, h3, h4, h5, h6 {
|
||||
color: #1C1B39;
|
||||
}
|
||||
|
||||
.header {
|
||||
height: 195px;
|
||||
background-color: #1C1B39;
|
||||
background-image: url('/images/CapistranoGraphicWireframe.png');
|
||||
background-repeat: no-repeat;
|
||||
background-size: 275px;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.header a {
|
||||
color: #52C1DB;
|
||||
}
|
||||
|
||||
pre {
|
||||
margin: 1.3em 0 1em;
|
||||
padding: 1.3em;
|
||||
}
|
||||
|
||||
code, kbd, pre, samp {
|
||||
font-family: 'droid-sans-mono', monospace, serif;
|
||||
background-color: rgb(250, 250, 250);
|
||||
}
|
||||
|
||||
.header a.brand img {
|
||||
margin: 6.5em auto auto 7em;
|
||||
width: 300px;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5 h6 {
|
||||
font-family: 'Enriqueta', serif;
|
||||
}
|
||||
|
||||
.post-date {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 36pt;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 18pt;
|
||||
}
|
||||
|
||||
.nav.nav-list {
|
||||
border-top: none;
|
||||
}
|
||||
|
||||
.content {
|
||||
margin: 1.3em 0 1em;
|
||||
padding: 1.3em;
|
||||
}
|
||||
60
css/syntax.css
Normal file
60
css/syntax.css
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
.highlight { background: #ffffff; }
|
||||
.highlight .c { color: #999988; font-style: italic } /* Comment */
|
||||
.highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */
|
||||
.highlight .k { font-weight: bold } /* Keyword */
|
||||
.highlight .o { font-weight: bold } /* Operator */
|
||||
.highlight .cm { color: #999988; font-style: italic } /* Comment.Multiline */
|
||||
.highlight .cp { color: #999999; font-weight: bold } /* Comment.Preproc */
|
||||
.highlight .c1 { color: #999988; font-style: italic } /* Comment.Single */
|
||||
.highlight .cs { color: #999999; font-weight: bold; font-style: italic } /* Comment.Special */
|
||||
.highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */
|
||||
.highlight .gd .x { color: #000000; background-color: #ffaaaa } /* Generic.Deleted.Specific */
|
||||
.highlight .ge { font-style: italic } /* Generic.Emph */
|
||||
.highlight .gr { color: #aa0000 } /* Generic.Error */
|
||||
.highlight .gh { color: #999999 } /* Generic.Heading */
|
||||
.highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */
|
||||
.highlight .gi .x { color: #000000; background-color: #aaffaa } /* Generic.Inserted.Specific */
|
||||
.highlight .go { color: #888888 } /* Generic.Output */
|
||||
.highlight .gp { color: #555555 } /* Generic.Prompt */
|
||||
.highlight .gs { font-weight: bold } /* Generic.Strong */
|
||||
.highlight .gu { color: #aaaaaa } /* Generic.Subheading */
|
||||
.highlight .gt { color: #aa0000 } /* Generic.Traceback */
|
||||
.highlight .kc { font-weight: bold } /* Keyword.Constant */
|
||||
.highlight .kd { font-weight: bold } /* Keyword.Declaration */
|
||||
.highlight .kp { font-weight: bold } /* Keyword.Pseudo */
|
||||
.highlight .kr { font-weight: bold } /* Keyword.Reserved */
|
||||
.highlight .kt { color: #445588; font-weight: bold } /* Keyword.Type */
|
||||
.highlight .m { color: #009999 } /* Literal.Number */
|
||||
.highlight .s { color: #d14 } /* Literal.String */
|
||||
.highlight .na { color: #008080 } /* Name.Attribute */
|
||||
.highlight .nb { color: #0086B3 } /* Name.Builtin */
|
||||
.highlight .nc { color: #445588; font-weight: bold } /* Name.Class */
|
||||
.highlight .no { color: #008080 } /* Name.Constant */
|
||||
.highlight .ni { color: #800080 } /* Name.Entity */
|
||||
.highlight .ne { color: #990000; font-weight: bold } /* Name.Exception */
|
||||
.highlight .nf { color: #990000; font-weight: bold } /* Name.Function */
|
||||
.highlight .nn { color: #555555 } /* Name.Namespace */
|
||||
.highlight .nt { color: #000080 } /* Name.Tag */
|
||||
.highlight .nv { color: #008080 } /* Name.Variable */
|
||||
.highlight .ow { font-weight: bold } /* Operator.Word */
|
||||
.highlight .w { color: #bbbbbb } /* Text.Whitespace */
|
||||
.highlight .mf { color: #009999 } /* Literal.Number.Float */
|
||||
.highlight .mh { color: #009999 } /* Literal.Number.Hex */
|
||||
.highlight .mi { color: #009999 } /* Literal.Number.Integer */
|
||||
.highlight .mo { color: #009999 } /* Literal.Number.Oct */
|
||||
.highlight .sb { color: #d14 } /* Literal.String.Backtick */
|
||||
.highlight .sc { color: #d14 } /* Literal.String.Char */
|
||||
.highlight .sd { color: #d14 } /* Literal.String.Doc */
|
||||
.highlight .s2 { color: #d14 } /* Literal.String.Double */
|
||||
.highlight .se { color: #d14 } /* Literal.String.Escape */
|
||||
.highlight .sh { color: #d14 } /* Literal.String.Heredoc */
|
||||
.highlight .si { color: #d14 } /* Literal.String.Interpol */
|
||||
.highlight .sx { color: #d14 } /* Literal.String.Other */
|
||||
.highlight .sr { color: #009926 } /* Literal.String.Regex */
|
||||
.highlight .s1 { color: #d14 } /* Literal.String.Single */
|
||||
.highlight .ss { color: #990073 } /* Literal.String.Symbol */
|
||||
.highlight .bp { color: #999999 } /* Name.Builtin.Pseudo */
|
||||
.highlight .vc { color: #008080 } /* Name.Variable.Class */
|
||||
.highlight .vg { color: #008080 } /* Name.Variable.Global */
|
||||
.highlight .vi { color: #008080 } /* Name.Variable.Instance */
|
||||
.highlight .il { color: #009999 } /* Literal.Number.Integer.Long */
|
||||
86
documentation/getting-started/installation/index.markdown
Normal file
86
documentation/getting-started/installation/index.markdown
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
title: Installation
|
||||
layout: default
|
||||
---
|
||||
|
||||
Capistrano is bundled as a Ruby Gem. **It requires Ruby 1.9 or newer.**
|
||||
|
||||
Capistrano can be installed as a standalone Gem, or bundled into your
|
||||
application.
|
||||
|
||||
<div class="alert">
|
||||
It is recommended to fix the version number when using Capistrano, and is
|
||||
therefore recommended to use an appropriate bundler.
|
||||
</div>
|
||||
|
||||
### General Usage
|
||||
|
||||
The following commands will clone Capistrano at the latest `v3` revision, and
|
||||
will build the gem and install it locally. **The Gem is not yet availalble via
|
||||
Rubygems.org.**
|
||||
|
||||
{% highlight bash %}
|
||||
$ git clone -b v3 https://github.com/capistrano/capistrano.git
|
||||
$ cd capistrano
|
||||
$ gem build *.gemspec
|
||||
$ gem install *.gem
|
||||
{% endhighlight %}
|
||||
|
||||
### Usage in a Rails project
|
||||
|
||||
Add the following lines to the Gemfile, to the group `:development` ideally.
|
||||
|
||||
{% highlight ruby %}
|
||||
group :development do
|
||||
gem 'capistrano-rails', github: 'capistrano/capistrano-rails', branch: 'v3'
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
There will be a Gem released via [rubygems.org][rubygems], but as most people
|
||||
are still using Capistrano v2.x, the v3 release will not be pushed to
|
||||
[rubygems.org][rubygems] just yet give people a chance to lock their version
|
||||
in their `Gemfile`.
|
||||
|
||||
The *Capistrano-Rails* Gem includes extras specifically designed for Ruby on
|
||||
Rails, specifically:
|
||||
|
||||
* Asset Pipeline Support
|
||||
* Gem Bundler Support
|
||||
* Database Migration Support
|
||||
|
||||
The documentation for these components can be found in
|
||||
[their][capistrano-rails-asset-pipeline-readme],
|
||||
[respective][capistrano-rails-gem-bundler-readme],
|
||||
[READMEs][capistrano-rails-database-migrations-readme]. However for the most
|
||||
part, to get the best, and most sensible results, simply `require` these
|
||||
files:
|
||||
|
||||
{% highlight ruby %}
|
||||
require 'capistrano/rails/assets'
|
||||
require 'capistrano/rails/gem-bundler'
|
||||
require 'capistrano/rails/database-migrations'
|
||||
{% endhighlight %}
|
||||
|
||||
<div class="alert alert-info">
|
||||
<h5>Help! I was using Capistrano `v2.x` and I didn't want to upgrade!</h5>
|
||||
|
||||
If you are using Capistrano `v2.x.x` and have also installed Capistrano `v3`
|
||||
by mistake, then you can lock your Gem version for Capistrano at something
|
||||
like:
|
||||
|
||||
{% highlight ruby %}
|
||||
gem 'capistrano', '~> 2.15' # Or whatever patch release you are using
|
||||
{% endhighlight %}
|
||||
|
||||
This is the [pessimistic operator][rubygems-pessimistic-operator] which
|
||||
installs the closest matching version, at the time of writing this would
|
||||
install `2.15.4`, and any other point-release in the `2.15.x` family without
|
||||
the risk of accidentally upgrading to `v3`.
|
||||
</div>
|
||||
|
||||
--
|
||||
[rubygems]: http://rubygems.org/
|
||||
[rubygems-pessimistic-operator]: http://docs.rubygems.org/read/chapter/16#page74
|
||||
[capistrano-rails-asset-pipeline-readme]: https://www.github.com/capistrano/asset-pipeline/bundler/README.md
|
||||
[capistrano-rails-database-migrations-readme]: https://www.github.com/capistrano/migrations/bundler/README.md
|
||||
[capistrano-rails-gem-bundler-readme]: https://www.github.com/capistrano/capistrano-rails/bundler/README.md
|
||||
1
documentation/index.html
Normal file
1
documentation/index.html
Normal file
|
|
@ -0,0 +1 @@
|
|||
FUCK YOU JEKYLL
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
title: Introductory Demo Video
|
||||
layout: default
|
||||
---
|
||||
|
||||
The video below was filmed on Mac OSX 10.8 using a more-or-less standard shell
|
||||
without much previous setup.
|
||||
|
||||
It covers using Capistrano to install an example Rails project on a previously
|
||||
unprepared server, covering all aspects of Github access, as well as
|
||||
privisioning the server using *Chef Solo* and Capistrano with *Rake*.
|
||||
|
||||
|
||||
|
||||
#### Show Notes
|
||||
|
||||
The *Chef Solo* recipes can be reached at [this repository at
|
||||
Github][capistrano-chef-solo-example-recipes], they rely on a fairly new
|
||||
version of *Chef Solo*, spefically any including the results of [this
|
||||
ticket][chef-issue-3365]. The aforementioned *Chef* issue adds environment
|
||||
support to *Chef Solo*.
|
||||
|
||||
The provisioning can also be done using any other mechanism, it's generally
|
||||
accepted however that there's not much point in automising your deploys,
|
||||
unless you are also automating provisioning of your servers for a known,
|
||||
consistent state.
|
||||
|
||||
Using `sudo` with any deployment can be tricky, so it's better to avoid it.
|
||||
Rebooting services without `sudo` is typically the first place people run into
|
||||
trouble using Capistrano. The [trouble shooting page for `sudo`
|
||||
problems][troubleshooting-sudo-password] may help.
|
||||
|
||||
**Note:** Some long sequences have been shortened (nobody needs to sit and watch me
|
||||
sitting and watching Ruby compile, for example!)
|
||||
|
||||
--
|
||||
[chef-issue-3365]: https://github.com/opscode/chef/pull/359
|
||||
[troubleshooting-sudo-password]: /troubleshooting/sudo-password/
|
||||
5
documentation/upgrading/index.html
Normal file
5
documentation/upgrading/index.html
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "Upgrading from v2.x.x"
|
||||
---
|
||||
|
||||
Lorem Ipsum
|
||||
BIN
images/CapistranoAvatar.png
Normal file
BIN
images/CapistranoAvatar.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 9 KiB |
BIN
images/CapistranoGraphic.png
Normal file
BIN
images/CapistranoGraphic.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
images/CapistranoGraphicWireframe.png
Normal file
BIN
images/CapistranoGraphicWireframe.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
BIN
images/CapistranoLogo.png
Normal file
BIN
images/CapistranoLogo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 9.6 KiB |
35
index.markdown
Normal file
35
index.markdown
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
layout: default
|
||||
title: A remote server automation and deployment tool written in Ruby.
|
||||
---
|
||||
|
||||
### A Simple Task
|
||||
|
||||
{% highlight ruby %}
|
||||
role :demo, %{example.com example.org, example.net}
|
||||
task :uptime do |host|
|
||||
on :demo, in: :parallel do
|
||||
uptime = capture(:uptime)
|
||||
puts "#{host.hostname} reports: #{uptime}"
|
||||
end
|
||||
end
|
||||
{% endhighlight %}
|
||||
|
||||
Capistrano extends the *Rake* DSL with methods specific to running commands
|
||||
`on()` servers.
|
||||
|
||||
### For Any Language
|
||||
|
||||
Capistrano is written in Ruby, but it can easily be used to deploy any
|
||||
language. Popular extensions add support for *Wordpress* blogs as well as
|
||||
*Symfony* and *Node.js* applications.
|
||||
|
||||
If your language has special deployment requirements, Capistrano can easily be
|
||||
extended to support them.
|
||||
|
||||
### Demo Video
|
||||
|
||||
<video id="demo" class="video-js vjs-default-skin" controls preload="auto" width="640" height="400" data-setup="{}">
|
||||
<source src="http://capistrano-screencasts.s3.amazonaws.com/Capistrano%20Introduction%20Video.mp4" type='video/mp4'>
|
||||
</video>
|
||||
|
||||
Loading…
Reference in a new issue