Changes for page Automating Application Deployment with Capistrano (Overview)

Summary

• Page properties (4 modified, 0 added, 0 removed)

Details

Page properties

Parent

...	...	@@ -1,0 +1,1 @@
	1	+Deployment

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.avendasora
	1	+XWiki.ralf_schuchardt

Tags

...	...	@@ -1,0 +1,1 @@
	1	+deployment

Content

...	...	@@ -2,10 +2,9 @@
2	2
3	3	= How to install Capistrano =
4	4
5		-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:
6	6
7	7	{{noformat}}
8		-
9	9	gem install -y capistrano
10	10
11	11	{{/noformat}}
...	...	@@ -14,7 +14,7 @@
14	14
15	15	= Must-read article about Capistrano =
16	16
17		-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"]]
18	18
19	19	= Writing simple deployment recipe =
20	20
...	...	@@ -29,7 +29,6 @@
29	29	So let's start our recipe file:
30	30
31	31	{{code}}
32		-
33	33	task :deploy, roles => :app do
34	34	end
35	35
...	...	@@ -38,7 +38,6 @@
38	38	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:
39	39
40	40	{{code}}
41		-
42	42	role :app, "localhost"
43	43	task :deploy, roles => :app do
44	44	end
...	...	@@ -48,7 +48,6 @@
48	48	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:
49	49
50	50	{{noformat}}
51		-
52	52	cap -f BugTracker.cap deploy
53	53
54	54	{{/noformat}}
...	...	@@ -56,7 +56,6 @@
56	56	The output should be:
57	57
58	58	{{noformat}}
59		-
60	60	* executing `deploy'
61	61
62	62	{{/noformat}}
...	...	@@ -73,10 +73,9 @@
73	73	== 1. Pack the BugTracker.woa into tar.gz archive. ==
74	74
75	75	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.
76		-So the code will be:
	71	+ So the code will be:
77	77
78	78	{{code}}
79		-
80	80	system "tar -C build -czvf BugTracker.woa.tar.gz BugTracker.woa"
81	81	raise "failed to create an archive" unless $?.exitstatus == 0
82	82
...	...	@@ -92,7 +92,6 @@
92	92	Here's how it can be done:
93	93
94	94	{{code}}
95		-
96	96	upload "BugTracker.woa.tar.gz", "/tmp/BugTracker.woa.tar.gz"
97	97
98	98	{{/code}}
...	...	@@ -104,12 +104,11 @@
104	104	This will look like this:
105	105
106	106	{{code}}
107		-
108	108	run "rm -rf /Library/WebObjects/Applications/BugTracker.woa"
109	109
110	110	{{/code}}
111	111
112		-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.
113	113
114	114	== 4. Unpack the archive. ==
115	115
...	...	@@ -116,7 +116,6 @@
116	116	Nothing new in this code:
117	117
118	118	{{code}}
119		-
120	120	run "tar -C /Library/WebObjects/Applications -xzvf /tmp/BugTracker.woa.tar.gz"
121	121
122	122	{{/code}}
...	...	@@ -124,7 +124,6 @@
124	124	So, right now we have the following deployment script:
125	125
126	126	{{code}}
127		-
128	128	role :app, "localhost"
129	129	task :deploy, roles => :app do
130	130	# creating BugTracker.woa.tar.gz
...	...	@@ -150,7 +150,6 @@
150	150	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:
151	151
152	152	{{code}}
153		-
154	154	task :cleanup, roles => :app do
155	155	FileUtils.rm_f "BugTracker.woa.tar.gz"
156	156
...	...	@@ -159,11 +159,10 @@
159	159
160	160	{{/code}}
161	161
162		-The new part here is FileUtils.rm//f call. This is the way to delete files in ruby.
163		-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:
164	164
165	165	{{noformat}}
166		-
167	167	cap -f BugTracker.cap cleanup
168	168
169	169	{{/noformat}}
...	...	@@ -171,7 +171,6 @@
171	171	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:
172	172
173	173	{{code}}
174		-
175	175	after :deploy, :cleanup
176	176
177	177	{{/code}}
...	...	@@ -183,13 +183,11 @@
183	183	You can use variable in capistrano scripts. You can set then with the "set" command:
184	184
185	185	{{noformat}}
186		-
187	187	set <variable name>, <variable value> - this commands says for itself. Some examples:
188	188
189	189	{{/noformat}}
190	190
191	191	{{code}}
192		-
193	193	set "var1", "some data"
194	194	set :var2, 10
195	195
...	...	@@ -198,7 +198,6 @@
198	198	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:
199	199
200	200	{{code}}
201		-
202	202	set :var1, "some data"
203	203	set "var1", "some data"
204	204
...	...	@@ -207,7 +207,6 @@
207	207	After the variable is set, you can use it in string literals using in the traditional ruby way:
208	208
209	209	{{code}}
210		-
211	211	run "echo #{var1}"
212	212	run "echo #{var2}"
213	213
...	...	@@ -216,7 +216,6 @@
216	216	So let's generalize our script with some variables usage:
217	217
218	218	{{code}}
219		-
220	220	role :app, "localhost"
221	221
222	222	set :app_name, "BugTracker.woa"
...	...	@@ -249,12 +249,12 @@
249	249
250	250	{{/code}}
251	251
252		-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).
253	253
254	254	== Moving global definitions to /etc/capistrano.conf ==
255	255
256		-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.
257	257
258	258	= Conclusion =
259	259
260		-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.