capper 0.8.0 → 0.8.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/README.rst +280 -0
- data/capper.gemspec +1 -2
- data/lib/capper/delayed_job.rb +3 -3
- data/lib/capper/resque.rb +3 -1
- metadata +4 -6
- data/README.md +0 -16
- data/lib/capper/utils/load.rb +0 -6
data/README.rst
ADDED
@@ -0,0 +1,280 @@
|
|
1
|
+
======
|
2
|
+
capper
|
3
|
+
======
|
4
|
+
|
5
|
+
:Author: `Benedikt Böhm <bb@xnull.de>`_
|
6
|
+
:Web: http://github.com/zenops/capper
|
7
|
+
:Git: ``git clone https://github.com/zenops/capper``
|
8
|
+
|
9
|
+
Capper is a collection of opinionated Capistrano recipes.
|
10
|
+
|
11
|
+
Rationale
|
12
|
+
=========
|
13
|
+
|
14
|
+
Most Ruby (on Rails) applications are deployed the same way. While capistrano
|
15
|
+
itself is already quite opinionated, maintaining a multitude of applications
|
16
|
+
feels like copy&paste very fast.
|
17
|
+
|
18
|
+
Capper provides sane defaults and many recipes for technologies typically used
|
19
|
+
with Ruby (on Rails) deployments to make ``config/deploy.rb`` much more
|
20
|
+
declarative and terse.
|
21
|
+
|
22
|
+
Usage
|
23
|
+
=====
|
24
|
+
|
25
|
+
Capper recipes should be loaded via ``Capfile`` like this::
|
26
|
+
|
27
|
+
require "capper"
|
28
|
+
|
29
|
+
load "capper/git"
|
30
|
+
load "capper/rails"
|
31
|
+
load "capper/unicorn"
|
32
|
+
|
33
|
+
load "config/deploy"
|
34
|
+
|
35
|
+
load "capper/multistage"
|
36
|
+
|
37
|
+
Note: capper takes care of loading capistranos default deploy recipe, no need
|
38
|
+
to load it again in your ``Capfile``.
|
39
|
+
|
40
|
+
Multistage
|
41
|
+
----------
|
42
|
+
|
43
|
+
Capper provides a clean DSL syntax for multistage support. In contrast to
|
44
|
+
capistrano-ext you don't have to create a bunch of tiny files in
|
45
|
+
``config/deploy/`` but instead use DSL sugar in ``config/deploy.rb``::
|
46
|
+
|
47
|
+
stage :production do
|
48
|
+
server "app1.example.com", :app, :db, :primary => true
|
49
|
+
server "app2.example.com", :app
|
50
|
+
end
|
51
|
+
|
52
|
+
stage :staging do
|
53
|
+
server "staging.example.com", :app, :db, :primary => true
|
54
|
+
set :rails_env, "staging"
|
55
|
+
set :branch, "staging"
|
56
|
+
end
|
57
|
+
|
58
|
+
Note: the multistage recipe must be loaded after ``config/deploy`` otherwise
|
59
|
+
it cannot know the defined stages.
|
60
|
+
|
61
|
+
Templates
|
62
|
+
---------
|
63
|
+
|
64
|
+
Capper provides a powerful yet simple mechanism to upload scripts and config
|
65
|
+
files rendered from templates during deploy. Template files are stored in
|
66
|
+
``config/deploy/templates`` but are rarely needed since capper recipes already
|
67
|
+
contain required template files.
|
68
|
+
|
69
|
+
To upload a custom template create an ERb file and upload it with
|
70
|
+
``upload_template_file``::
|
71
|
+
|
72
|
+
upload_template_file("myscript.sh", "#{bin_path}/myscript", :mode => "0755")
|
73
|
+
|
74
|
+
The above command will upload ``config/deploy/templates/myscript.sh.erb`` to
|
75
|
+
the specified path. Inside the template all capistrano options (current_path,
|
76
|
+
application, etc) are available.
|
77
|
+
|
78
|
+
Monit integration
|
79
|
+
-----------------
|
80
|
+
|
81
|
+
Capper provides DSL syntax for monit integration. Many recipes shipped with
|
82
|
+
capper already contain monit configuration. These configuration snippets are
|
83
|
+
not enabled unless you include the monit recipe in your ``Capfile``.
|
84
|
+
|
85
|
+
Custom monit configuration snippets can be created with ``monit_config``::
|
86
|
+
|
87
|
+
monit_config "myprocess", <<EOF, :roles => :app
|
88
|
+
check process myprocess
|
89
|
+
with pidfile ...
|
90
|
+
start program = ...
|
91
|
+
stop program = ...
|
92
|
+
EOF
|
93
|
+
|
94
|
+
The above call will create the specified monit snippet for monit instances
|
95
|
+
running on servers in the ``:app`` role.
|
96
|
+
|
97
|
+
Recipes
|
98
|
+
=======
|
99
|
+
|
100
|
+
The following recipes are included in capper.
|
101
|
+
|
102
|
+
base
|
103
|
+
----
|
104
|
+
|
105
|
+
The base recipe is automatically loaded and provides the basic opinions capper
|
106
|
+
has about deployment:
|
107
|
+
|
108
|
+
- The application is deployed to a dedicated user account with the same name as
|
109
|
+
the application.
|
110
|
+
|
111
|
+
- The parent path for these user accounts defaults to ``/var/app``.
|
112
|
+
|
113
|
+
- No sudo privileges are ever needed.
|
114
|
+
|
115
|
+
- Releases are cleaned up by default.
|
116
|
+
|
117
|
+
Additionally a ``deploy:symlink`` task is provided to make symlinks declarative
|
118
|
+
in ``config/deploy.rb``::
|
119
|
+
|
120
|
+
set :symlink, {
|
121
|
+
"config/database.yml" => "config/database.yml",
|
122
|
+
"shared/uploads" => "public/uploads"
|
123
|
+
}
|
124
|
+
|
125
|
+
The above snippet will create symlinks from
|
126
|
+
``#{shared_path}/config/database.yml`` to
|
127
|
+
``#{release_path}/config/database.yml`` and from
|
128
|
+
``#{shared_path}/uploads`` to
|
129
|
+
``#{release_path}/public/uploads`` after ``deploy:update_code`` has run.
|
130
|
+
|
131
|
+
|
132
|
+
bundler
|
133
|
+
-------
|
134
|
+
|
135
|
+
The bundler recipe is an extension of bundlers native capistrano integration:
|
136
|
+
|
137
|
+
- During ``deploy:setup`` it is ensured that a known-to-work bundler version
|
138
|
+
(specified via ``bundler_version``) is installed.
|
139
|
+
|
140
|
+
- When used together with the rvm recipe bundles are not installed globally to
|
141
|
+
``shared/bundle`` but instead a gemset specific location is used
|
142
|
+
(``shared/bundle/#{gemset}``).
|
143
|
+
|
144
|
+
- The option ``ruby_exec_prefix`` is set to ``bundle exec`` for convenience.
|
145
|
+
|
146
|
+
config
|
147
|
+
------
|
148
|
+
|
149
|
+
The config recipe adds support for a dedicated repository with configuration
|
150
|
+
files. It is very preliminary right now and only supports git. The repository
|
151
|
+
specified with ``config_repo`` will be cloned into ``shared/config`` and all
|
152
|
+
files specified in the ``config_files`` array are copied to
|
153
|
+
``#{release_path}/config``.
|
154
|
+
|
155
|
+
delayed_job
|
156
|
+
-----------
|
157
|
+
|
158
|
+
The delayed_job recipe provides integration with DelayedJob. A script to
|
159
|
+
start/stop delayed job workers is uploaded to ``#{bin_path}/delayed_job``. The
|
160
|
+
script supports multiple instances and priority ranges.
|
161
|
+
|
162
|
+
If monit integration has been enabled via ``capper/monit`` workers are
|
163
|
+
automatically (re)started during deploy and can be specified via
|
164
|
+
``delayed_job_workers``::
|
165
|
+
|
166
|
+
set :delayed_jobs_workers, {
|
167
|
+
:important => 0..1,
|
168
|
+
:worker1 => 2..10,
|
169
|
+
:worker2 => 2..10
|
170
|
+
}
|
171
|
+
|
172
|
+
git
|
173
|
+
---
|
174
|
+
|
175
|
+
The git recipe will simply set capistrano to use the git strategy with
|
176
|
+
remote_cache::
|
177
|
+
|
178
|
+
set(:scm, :git)
|
179
|
+
set(:deploy_via, :remote_cache)
|
180
|
+
|
181
|
+
hoptoad
|
182
|
+
-------
|
183
|
+
|
184
|
+
The hoptoad recipe is merely a copy of hoptoads native capistrano integration
|
185
|
+
without after/before hooks, so hoptoad notifications can be enabled on-demand
|
186
|
+
in stage blocks::
|
187
|
+
|
188
|
+
stage :production do
|
189
|
+
...
|
190
|
+
after "deploy", "hoptoad:notify"
|
191
|
+
end
|
192
|
+
|
193
|
+
monit
|
194
|
+
-----
|
195
|
+
|
196
|
+
The monit recipe will collect all snippets declared via ``monit_config`` and
|
197
|
+
render them into the file specified via ``monitrc`` (default:
|
198
|
+
``~/.monitrc.local``, this file should be included in your ``~/.monitrc``).
|
199
|
+
|
200
|
+
rails
|
201
|
+
-----
|
202
|
+
|
203
|
+
The rails recipe sets the default ``rails_env`` to production and includes
|
204
|
+
tasks for deploying the asset pipeline for rails 3.1 applications. The recipe
|
205
|
+
will automatically determine if your asset timestamps need to be normalized.
|
206
|
+
|
207
|
+
resque
|
208
|
+
------
|
209
|
+
|
210
|
+
The resque recipe provides integration with Resque. A script to
|
211
|
+
start/stop resque workers is uploaded to ``#{bin_path}/resque``. The
|
212
|
+
script supports multiple instances with queue names.
|
213
|
+
|
214
|
+
If monit integration has been enabled via ``capper/monit`` workers are
|
215
|
+
automatically (re)started during deploy and can be specified via
|
216
|
+
``resque_workers``::
|
217
|
+
|
218
|
+
set :resque_workers, {
|
219
|
+
:important => :important,
|
220
|
+
:worker1 => :default,
|
221
|
+
:worker2 => :default
|
222
|
+
}
|
223
|
+
|
224
|
+
rvm
|
225
|
+
---
|
226
|
+
|
227
|
+
The rvm recipe is an extension to RVMs native capistrano integration. The
|
228
|
+
recipe forces the ``rvm_type`` to ``:user`` and will automatically determine
|
229
|
+
the ruby version and gemset via the projects ``.rvmrc``.
|
230
|
+
|
231
|
+
A ``deploy:setup`` hook is provided to ensure the correct ruby and rubygems
|
232
|
+
version is installed on all servers.
|
233
|
+
|
234
|
+
unicorn
|
235
|
+
-------
|
236
|
+
|
237
|
+
The unicorn recipe provides integration with Unicorn. A script to manage the
|
238
|
+
unicorn process is uploaded to ``#{bin_path}/unicorn``. Additionally this
|
239
|
+
recipe also manages the unicorn configuration file (in ``config/unicorn.rb``).
|
240
|
+
|
241
|
+
If monit integration has been enabled via ``capper/monit`` unicorn is
|
242
|
+
automatically (re)started during ``deploy:restart`` using unicorns in-place,
|
243
|
+
no-downtime upgrade method.
|
244
|
+
|
245
|
+
The following configuration options are provided:
|
246
|
+
|
247
|
+
``unicorn_worker_processes``
|
248
|
+
Number of unicorn workers (default: 4)
|
249
|
+
|
250
|
+
``unicorn_timeout``
|
251
|
+
Timeout after which workers are killed (default: 30)
|
252
|
+
|
253
|
+
whenever
|
254
|
+
--------
|
255
|
+
|
256
|
+
The whenever recipe is a simplified version of whenevers native capistrano
|
257
|
+
integration. With one application per user account the whole crontab can be
|
258
|
+
used for whenever. Additionally this recipe take the ``ruby_exec_prefix``
|
259
|
+
setting into account.
|
260
|
+
|
261
|
+
Contributing to capper
|
262
|
+
======================
|
263
|
+
|
264
|
+
- Check out the latest master to make sure the feature hasn't been implemented
|
265
|
+
or the bug hasn't been fixed yet
|
266
|
+
|
267
|
+
- Check out the issue tracker to make sure someone already hasn't requested it
|
268
|
+
and/or contributed it
|
269
|
+
|
270
|
+
- Fork the project
|
271
|
+
|
272
|
+
- Start a feature/bugfix branch
|
273
|
+
|
274
|
+
- Commit and push until you are happy with your contribution
|
275
|
+
|
276
|
+
Copyright
|
277
|
+
=========
|
278
|
+
|
279
|
+
Copyright (c) 2011 Benedikt Böhm. See LICENSE.txt for
|
280
|
+
further details.
|
data/capper.gemspec
CHANGED
@@ -2,7 +2,7 @@
|
|
2
2
|
|
3
3
|
Gem::Specification.new do |s|
|
4
4
|
s.name = "capper"
|
5
|
-
s.version = "0.8.
|
5
|
+
s.version = "0.8.1"
|
6
6
|
s.platform = Gem::Platform::RUBY
|
7
7
|
s.licenses = ["MIT"]
|
8
8
|
s.authors = ["Benedikt Böhm"]
|
@@ -21,5 +21,4 @@ Gem::Specification.new do |s|
|
|
21
21
|
s.test_files = `git ls-files -- {test,spec,features}/*`.split("\n")
|
22
22
|
s.executables = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
|
23
23
|
s.require_paths = ["lib"]
|
24
|
-
s.extra_rdoc_files = ["LICENSE", "README.md"]
|
25
24
|
end
|
data/lib/capper/delayed_job.rb
CHANGED
@@ -1,5 +1,3 @@
|
|
1
|
-
load 'capper/monit'
|
2
|
-
|
3
1
|
# configuration variables
|
4
2
|
_cset(:delayed_job_workers, {})
|
5
3
|
|
@@ -35,6 +33,8 @@ namespace :delayed_job do
|
|
35
33
|
|
36
34
|
desc "Restart DelayedJob workers"
|
37
35
|
task :restart, :roles => :worker, :except => { :no_release => true } do
|
38
|
-
|
36
|
+
if fetch(:monitrc, false)
|
37
|
+
run "monit -g delayed_job restart all"
|
38
|
+
fi
|
39
39
|
end
|
40
40
|
end
|
data/lib/capper/resque.rb
CHANGED
metadata
CHANGED
@@ -2,7 +2,7 @@
|
|
2
2
|
name: capper
|
3
3
|
version: !ruby/object:Gem::Version
|
4
4
|
prerelease:
|
5
|
-
version: 0.8.
|
5
|
+
version: 0.8.1
|
6
6
|
platform: ruby
|
7
7
|
authors:
|
8
8
|
- "Benedikt B\xC3\xB6hm"
|
@@ -64,9 +64,8 @@ executables: []
|
|
64
64
|
|
65
65
|
extensions: []
|
66
66
|
|
67
|
-
extra_rdoc_files:
|
68
|
-
|
69
|
-
- README.md
|
67
|
+
extra_rdoc_files: []
|
68
|
+
|
70
69
|
files:
|
71
70
|
- .document
|
72
71
|
- .gitignore
|
@@ -74,7 +73,7 @@ files:
|
|
74
73
|
- Gemfile
|
75
74
|
- Gemfile.lock
|
76
75
|
- LICENSE
|
77
|
-
- README.
|
76
|
+
- README.rst
|
78
77
|
- Rakefile
|
79
78
|
- capper.gemspec
|
80
79
|
- lib/capper.rb
|
@@ -96,7 +95,6 @@ files:
|
|
96
95
|
- lib/capper/templates/unicorn.rb.erb
|
97
96
|
- lib/capper/templates/unicorn.sh.erb
|
98
97
|
- lib/capper/unicorn.rb
|
99
|
-
- lib/capper/utils/load.rb
|
100
98
|
- lib/capper/utils/monit.rb
|
101
99
|
- lib/capper/utils/multistage.rb
|
102
100
|
- lib/capper/utils/templates.rb
|
data/README.md
DELETED
@@ -1,16 +0,0 @@
|
|
1
|
-
# capper
|
2
|
-
|
3
|
-
Capper is a collection of opinionated Capistrano recipes
|
4
|
-
|
5
|
-
## Contributing to capper
|
6
|
-
|
7
|
-
* Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet
|
8
|
-
* Check out the issue tracker to make sure someone already hasn't requested it and/or contributed it
|
9
|
-
* Fork the project
|
10
|
-
* Start a feature/bugfix branch
|
11
|
-
* Commit and push until you are happy with your contribution
|
12
|
-
|
13
|
-
## Copyright
|
14
|
-
|
15
|
-
Copyright (c) 2011 Benedikt Böhm. See LICENSE.txt for
|
16
|
-
further details.
|