Skip to Content
Last modified by Ralf Schuchardt on 2020/11/17 19:23
From version 5.1
edited by Pascal Robert
on 2009/03/05 20:37
Change comment: There is no comment for this version
To version 19.1
edited by Ralf Schuchardt
on 2020/11/17 19:23
Change comment: Changed links to the correct site, because the old one is about UK gambling now

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Web Applications-Deployment-Capistrano (Overview)
1 +Automating Application Deployment with Capistrano (Overview)
Parent
... ... @@ -1,0 +1,1 @@
1 +Deployment
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.probert
1 +XWiki.ralf_schuchardt
Tags
... ... @@ -1,0 +1,1 @@
1 +deployment
Content
... ... @@ -1,17 +6,10 @@
1 -{{warning}}
2 -February 25th, 2009 by jamisbuck
3 -
4 -Capistrano has been a fantastically fun and varied project to work on, and it's taught me a lot. However, it's time for me to say goodbye, and move on. You can read the full announcement on Jamis' blog, but the gist of it is that I'm no longer going to be updating or maintaining Capistrano (or related libraries). Thanks to everyone who offered their support and encouragement over the last couple of years. It's been great!
5 -
6 6  Capistrano is a deployment system written on Ruby. Actually you don't have to know ruby if you want to use Capistrano - you'll still be able to implement your basic tasks. But if you want to gain real power and control on your deployment scenarios, some knowledge or ruby will greatly help.
7 -{{/warning}}
8 8  
9 9  = How to install Capistrano =
10 10  
11 -Here is the official Capistrano installation instructon page: http:~/~/www.capify.org/install. On Leopard all you need to do is to run the following command with root privileges:
5 +Here is the official Capistrano installation instruction page: [[https:~~/~~/capistranorb.com/documentation/getting-started/installation/>>url:https://capistranorb.com/documentation/getting-started/installation/||shape="rect"]]. On Leopard all you need to do is to run the following command with root privileges:
12 12  
13 13  {{noformat}}
14 -
15 15  gem install -y capistrano
16 16  
17 17  {{/noformat}}
... ... @@ -20,7 +20,7 @@
20 20  
21 21  = Must-read article about Capistrano =
22 22  
23 -Basics of using Capistrano are well described on its official site: http:~/~/www.capify.org/getting-started/basics
16 +Basics of using Capistrano are well described on its official site: [[https:~~/~~/capistranorb.com>>url:https://capistranorb.com||shape="rect"]]
24 24  
25 25  = Writing simple deployment recipe =
26 26  
... ... @@ -35,7 +35,6 @@
35 35  So let's start our recipe file:
36 36  
37 37  {{code}}
38 -
39 39  task :deploy, roles => :app do
40 40  end
41 41  
... ... @@ -44,7 +44,6 @@
44 44  This is the empty definition of task "deploy" that will run on application servers (see, roles :app). We need to define the :app role in order to make the recipe usable:
45 45  
46 46  {{code}}
47 -
48 48  role :app, "localhost"
49 49  task :deploy, roles => :app do
50 50  end
... ... @@ -54,7 +54,6 @@
54 54  Ok - this is not much, but at least something. Capistrano recipes are executed using "cap" command. So now you should be able to execute the following:
55 55  
56 56  {{noformat}}
57 -
58 58  cap -f BugTracker.cap deploy
59 59  
60 60  {{/noformat}}
... ... @@ -62,7 +62,6 @@
62 62  The output should be:
63 63  
64 64  {{noformat}}
65 -
66 66   * executing `deploy'
67 67  
68 68  {{/noformat}}
... ... @@ -79,10 +79,9 @@
79 79  == 1. Pack the BugTracker.woa into tar.gz archive. ==
80 80  
81 81  This step should be done locally - we don't need to use Capistrano's main feature of executing ssh-commands in parallel on multiple servers.
82 -So the code will be:
71 + So the code will be:
83 83  
84 84  {{code}}
85 -
86 86  system "tar -C build -czvf BugTracker.woa.tar.gz BugTracker.woa"
87 87  raise "failed to create an archive" unless $?.exitstatus == 0
88 88  
... ... @@ -98,7 +98,6 @@
98 98  Here's how it can be done:
99 99  
100 100  {{code}}
101 -
102 102  upload "BugTracker.woa.tar.gz", "/tmp/BugTracker.woa.tar.gz"
103 103  
104 104  {{/code}}
... ... @@ -110,12 +110,11 @@
110 110  This will look like this:
111 111  
112 112  {{code}}
113 -
114 114  run "rm -rf /Library/WebObjects/Applications/BugTracker.woa"
115 115  
116 116  {{/code}}
117 117  
118 -This will remove the /Library/WebObjects/Applications/BugTracker.woa folder on all servers specified for :app role. Notice that we've used "run" instead of "system". There is a great difference between these commands. "system" executes commands locally whereas "run" executes them on all remote servers specified for the current role. Another thing to notice the --f flag used for rm command. Capistrano will throw an exception and exit immediately if one of the commands executed on remote servers fail. Without --f flag rm will fail when there's no "/Library/WebObjects/Applications/BugTracker.woa" folder. This can happen during the first deployment, for example.
104 +This will remove the /Library/WebObjects/Applications/BugTracker.woa folder on all servers specified for :app role. Notice that we've used "run" instead of "system". There is a great difference between these commands. "system" executes commands locally whereas "run" executes them on all remote servers specified for the current role. Another thing to notice the -f flag used for rm command. Capistrano will throw an exception and exit immediately if one of the commands executed on remote servers fail. Without -f flag rm will fail when there's no "/Library/WebObjects/Applications/BugTracker.woa" folder. This can happen during the first deployment, for example.
119 119  
120 120  == 4. Unpack the archive. ==
121 121  
... ... @@ -122,7 +122,6 @@
122 122  Nothing new in this code:
123 123  
124 124  {{code}}
125 -
126 126  run "tar -C /Library/WebObjects/Applications -xzvf /tmp/BugTracker.woa.tar.gz"
127 127  
128 128  {{/code}}
... ... @@ -130,7 +130,6 @@
130 130  So, right now we have the following deployment script:
131 131  
132 132  {{code}}
133 -
134 134  role :app, "localhost"
135 135  task :deploy, roles => :app do
136 136   # creating BugTracker.woa.tar.gz
... ... @@ -156,7 +156,6 @@
156 156  Let's write a cleanup task in order not to leave tar.gz archives both on our local machine and on remote servers. The task can look like this:
157 157  
158 158  {{code}}
159 -
160 160  task :cleanup, roles => :app do
161 161   FileUtils.rm_f "BugTracker.woa.tar.gz"
162 162  
... ... @@ -165,11 +165,10 @@
165 165  
166 166  {{/code}}
167 167  
168 -The new part here is FileUtils.rm//f call. This is the way to delete files in ruby.
169 -Now we can check that :cleanup task actually works by executing the following command~://
151 +The new part here is FileUtils.rm_f call. This is the way to delete files in ruby.
152 + Now we can check that :cleanup task actually works by executing the following command:
170 170  
171 171  {{noformat}}
172 -
173 173  cap -f BugTracker.cap cleanup
174 174  
175 175  {{/noformat}}
... ... @@ -177,7 +177,6 @@
177 177  It's great to have a cleanup task, but it would be even better if it would run after the deployment. Capistrano has a "hooks" feature that will help us with that:
178 178  
179 179  {{code}}
180 -
181 181  after :deploy, :cleanup
182 182  
183 183  {{/code}}
... ... @@ -189,13 +189,11 @@
189 189  You can use variable in capistrano scripts. You can set then with the "set" command:
190 190  
191 191  {{noformat}}
192 -
193 193  set <variable name>, <variable value> - this commands says for itself. Some examples:
194 194  
195 195  {{/noformat}}
196 196  
197 197  {{code}}
198 -
199 199  set "var1", "some data"
200 200  set :var2, 10
201 201  
... ... @@ -204,7 +204,6 @@
204 204  Note also that you can use the identifiers starting with ":" as variable names. This is the ruby way of specifying unique identifiers (called symbols in ruby). Using symbols is a bit faster than using strings, besides you can easily see identifiers in your code, as they won't be quoted - and will not look like string literals. Anyway these calls are absolutely equal:
205 205  
206 206  {{code}}
207 -
208 208  set :var1, "some data"
209 209  set "var1", "some data"
210 210  
... ... @@ -213,7 +213,6 @@
213 213  After the variable is set, you can use it in string literals using in the traditional ruby way:
214 214  
215 215  {{code}}
216 -
217 217  run "echo #{var1}"
218 218  run "echo #{var2}"
219 219  
... ... @@ -222,7 +222,6 @@
222 222  So let's generalize our script with some variables usage:
223 223  
224 224  {{code}}
225 -
226 226  role :app, "localhost"
227 227  
228 228  set :app_name, "BugTracker.woa"
... ... @@ -255,12 +255,12 @@
255 255  
256 256  {{/code}}
257 257  
258 -Note that in //upload// and //FileUtils.rm//f// calls variable names are used without any additional symbols - that's because they're not the part of any string literal - so they're used as simple ruby variables (well actually things are much more complicated - but at least they look like simple ruby variables).//
234 +Note that in //upload// and //FileUtils.rm_f// calls variable names are used without any additional symbols - that's because they're not the part of any string literal - so they're used as simple ruby variables (well actually things are much more complicated - but at least they look like simple ruby variables).
259 259  
260 260  == Moving global definitions to /etc/capistrano.conf ==
261 261  
262 -Capistrano processes /etc/capistrano.conf file before processing any recipe. If you use several recipes for multiple projects that are hosted on the same deployment server, you will still have to specify :app role in every recipe. To avoid such duplication you can move the role definition to /etc/capistrano.conf. Also some general variable definitions can be moved there. In our case it's the :wo//apps//path variable.
238 +Capistrano processes /etc/capistrano.conf file before processing any recipe. If you use several recipes for multiple projects that are hosted on the same deployment server, you will still have to specify :app role in every recipe. To avoid such duplication you can move the role definition to /etc/capistrano.conf. Also some general variable definitions can be moved there. In our case it's the :wo_apps_path variable.
263 263  
264 264  = Conclusion =
265 265  
266 -Actually, with this brief overview of Capistrano features, you'll be able to write quite complicated deployment recipes. But it won't come as a surprise if I say that Capistrano can do a lot more. You can embed capistrano scripts into the ruby code, define multiple deployment configurations in single capistrano file, process output from servers and more and more... I'll write about these topics as soon as possible.
242 +Actually, with this brief overview of Capistrano features, you'll be able to write quite complicated deployment recipes. But it won't come as a surprise if I say that Capistrano can do a lot more. You can embed capistrano scripts into the ruby code, define multiple deployment configurations in single capistrano file, process output from servers and more and more... I'll write about these topics as soon as possible.