testlab 0.6.1 → 0.6.2
Sign up to get free protection for your applications and to get access to all the features.
- data/README.md +166 -0
- data/lib/testlab/version.rb +1 -1
- data/lib/testlab.rb +41 -37
- metadata +4 -4
data/README.md
CHANGED
@@ -10,6 +10,8 @@ What is TestLab? TestLab lets you iterate virtual infrastructure quickly. Usin
|
|
10
10
|
|
11
11
|
TestLab can be run directly on the command-line or can be interfaced with directly via code. Unlike the trend with some popular open-source software recently, I want you to build off this API interface and hopefully create tools I would of never dreamed up.
|
12
12
|
|
13
|
+
# Using TestLab Programmatically
|
14
|
+
|
13
15
|
Accessing TestLab via code is meant to be fairly easy and straightforward. To get an instance of TestLab you only need about four lines of code:
|
14
16
|
|
15
17
|
log_file = File.join(Dir.pwd, "testlab.log")
|
@@ -19,8 +21,172 @@ Accessing TestLab via code is meant to be fairly easy and straightforward. To g
|
|
19
21
|
|
20
22
|
Calling `TestLab.new` without a `:labfile` option will, by default, attempt to read `Labfile` from the current directory. This behaviour can be changed by passing the `:labfile` key with a path to your desired "Labfile" as the value to your `TestLab.new`.
|
21
23
|
|
24
|
+
There are several easy accessors available to grab the first container and execure the command `uptime` on it via and SSH connection:
|
25
|
+
|
26
|
+
container = @testlab.containers.first
|
27
|
+
container.ssh.exec(%(uptime))
|
28
|
+
|
29
|
+
We can also execute this command via `lxc-attach`:
|
30
|
+
|
31
|
+
container.lxc.attach(%(-- uptime))
|
32
|
+
|
33
|
+
You can access all the nodes for example:
|
34
|
+
|
35
|
+
@testlab.nodes
|
36
|
+
|
22
37
|
For more information see the TestLab Documentation, `testlab-repo`, command-line binary and it never hurts to look at the TestLab source itself.
|
23
38
|
|
39
|
+
# Using TestLab Interactively
|
40
|
+
|
41
|
+
The TestLab command-line program `tl` follows in the style of git (using the GLI RubyGem).
|
42
|
+
|
43
|
+
$ tl help
|
44
|
+
NAME
|
45
|
+
tl - A framework for building lightweight virtual infrastructure using LXC
|
46
|
+
|
47
|
+
SYNOPSIS
|
48
|
+
tl [global options] command [command options] [arguments...]
|
49
|
+
|
50
|
+
VERSION
|
51
|
+
0.6.1
|
52
|
+
|
53
|
+
GLOBAL OPTIONS
|
54
|
+
--version -
|
55
|
+
--help - Show this message
|
56
|
+
|
57
|
+
COMMANDS
|
58
|
+
help - Shows a list of commands or help for one command
|
59
|
+
create - Create the test lab
|
60
|
+
destroy - Destroy the test lab
|
61
|
+
up - Online the test lab
|
62
|
+
down - Offline the test lab
|
63
|
+
setup - Setup the test lab infrastructure
|
64
|
+
teardown - Teardown the test lab infrastructure
|
65
|
+
status - Display information on the status of the test lab
|
66
|
+
node - Manage nodes
|
67
|
+
network - Manage networks
|
68
|
+
container - Manage containers
|
69
|
+
|
70
|
+
You stand up your lab with the following command:
|
71
|
+
|
72
|
+
tl setup
|
73
|
+
|
74
|
+
You can down the entire lab:
|
75
|
+
|
76
|
+
tl down
|
77
|
+
|
78
|
+
You can also destroy it (only works for VM backed providers; this would be a NO-OP on the Local provider for example):
|
79
|
+
|
80
|
+
tl destroy
|
81
|
+
|
82
|
+
# Interacting with Containers
|
83
|
+
|
84
|
+
You can interact with containers via SSH:
|
85
|
+
|
86
|
+
tl container ssh -i <container ID>
|
87
|
+
|
88
|
+
You can pass an optional alternate username and/or identity to use. By default TestLab will attempt to SSH as the user defined in the `Labfile` for that container, otherwise the default user for the containers distro is used.
|
89
|
+
|
90
|
+
$ tl help container ssh
|
91
|
+
NAME
|
92
|
+
ssh - Open an SSH console to a container
|
93
|
+
|
94
|
+
SYNOPSIS
|
95
|
+
tl [global options] container ssh [command options]
|
96
|
+
|
97
|
+
COMMAND OPTIONS
|
98
|
+
-u, --user=username - Specify an SSH Username to use (default: none)
|
99
|
+
-k, --key=key - Specify an SSH Identity Key to use (default: none)
|
100
|
+
|
101
|
+
You can individually online, offline, create or destroy containers:
|
102
|
+
|
103
|
+
tl container down -i server-www-1
|
104
|
+
tl container up -i server-www-1
|
105
|
+
tl container setup -i server-www-1
|
106
|
+
tl container teardown -i server-www-1
|
107
|
+
|
108
|
+
You can recycle a container, effectively destroying then creating it again, provisioning it back to a "pristine" condition.
|
109
|
+
|
110
|
+
tl container recycle -i server-www-1
|
111
|
+
|
112
|
+
# Ephemeral Container Cloning
|
113
|
+
|
114
|
+
As it stands attempting to iterate infrastructure while developing with Vagrant is a slow and painful process. Enter LXC and it's ephemeral feature. The idea here is you have a container that is provisioned to a "pristine" state acording to the `Labfile`. You then clone this container and run actions against the container. After running your actions against the container you want to maybe tweak your Chef cookbook and re-run it against the container. As we all know running an ever changing cookbook in development against the same system over and over again causes drift and problems. With the cloning you can instantly reinstate the container as it was when you first cloned it.
|
115
|
+
|
116
|
+
Here we are cloning the container for the first time. It takes a bit longer than normal because TestLab is actually shutting down the container so it can be retained as the "pristine" copy of it, and starting up a ephemeral container in its place. Subsequent calls to clone are very fast.
|
117
|
+
|
118
|
+
$ tl container clone -i server-www-1
|
119
|
+
[TL] TestLab v0.6.1 Loaded
|
120
|
+
[TL] container server-www-1 clone # Completed in 13.0116 seconds!
|
121
|
+
$ tl container clone -i server-www-1
|
122
|
+
[TL] TestLab v0.6.1 Loaded
|
123
|
+
[TL] container server-www-1 clone # Completed in 0.9169 seconds!
|
124
|
+
$ tl container clone -i server-www-1
|
125
|
+
[TL] TestLab v0.6.1 Loaded
|
126
|
+
[TL] container server-www-1 clone # Completed in 1.0794 seconds!
|
127
|
+
$ tl container clone -i server-www-1
|
128
|
+
[TL] TestLab v0.6.1 Loaded
|
129
|
+
[TL] container server-www-1 clone # Completed in 1.0281 seconds!
|
130
|
+
|
131
|
+
We can also see the containers status reflects that it is a clone currently:
|
132
|
+
|
133
|
+
$ tl container status -i server-www-1
|
134
|
+
[TL] TestLab v0.6.1 Loaded
|
135
|
+
+----------------------------------------------+
|
136
|
+
| NODE_ID: vagrant |
|
137
|
+
| ID: server-www-1 |
|
138
|
+
| CLONE: true |
|
139
|
+
| FQDN: server-www-1.default.zone |
|
140
|
+
| STATE: running |
|
141
|
+
| DISTRO: ubuntu |
|
142
|
+
| RELEASE: precise |
|
143
|
+
| INTERFACES: labnet:eth0:10.10.0.21/16 |
|
144
|
+
| PROVISIONERS: Resolv/AptCacherNG/Apt/Shell |
|
145
|
+
+----------------------------------------------+
|
146
|
+
|
147
|
+
We can easily revert it back to a full container if we want to make changes to it:
|
148
|
+
|
149
|
+
$ tl container up -i server-www-1
|
150
|
+
|
151
|
+
We can even recycle it while it is in a cloned state:
|
152
|
+
|
153
|
+
$ tl container recycle -i server-www-1
|
154
|
+
|
155
|
+
# Network Routes
|
156
|
+
|
157
|
+
TestLab will add network routes for any networks defined in the `Labfile` with the route flag set to true. This will allow you to directly interact with containers. Here is an example of the routes added with the multi-network `Labfile`.
|
158
|
+
|
159
|
+
$ tl network route show -i labnet
|
160
|
+
[TL] TestLab v0.6.1 Loaded
|
161
|
+
TestLab routes:
|
162
|
+
10.10.0.0 192.168.33.239 255.255.0.0 UG 0 0 0 vboxnet0
|
163
|
+
10.11.0.0 192.168.33.239 255.255.0.0 UG 0 0 0 vboxnet0
|
164
|
+
|
165
|
+
These routes can be manually manipulated as well:
|
166
|
+
|
167
|
+
$ tl help network route
|
168
|
+
NAME
|
169
|
+
route - Manage routes
|
170
|
+
|
171
|
+
SYNOPSIS
|
172
|
+
tl [global options] network route [command options] add
|
173
|
+
tl [global options] network route [command options] del
|
174
|
+
tl [global options] network route [command options] show
|
175
|
+
|
176
|
+
COMMANDS
|
177
|
+
add - Add routes to lab networks
|
178
|
+
del - Delete routes to lab networks
|
179
|
+
show - Show routes to lab networks
|
180
|
+
|
181
|
+
# Getting Help
|
182
|
+
|
183
|
+
TestLab uses the GLI RubyGem, which gives us a command line pattern similar to that of Git. Therefore help is easy to get:
|
184
|
+
|
185
|
+
tl help
|
186
|
+
tl help node
|
187
|
+
tl help container
|
188
|
+
tl help network
|
189
|
+
|
24
190
|
# REQUIREMENTS
|
25
191
|
|
26
192
|
* Latest VirtualBox Package
|
data/lib/testlab/version.rb
CHANGED
data/lib/testlab.rb
CHANGED
@@ -169,15 +169,7 @@ class TestLab
|
|
169
169
|
#
|
170
170
|
# @return [Boolean] True if successful.
|
171
171
|
def up
|
172
|
-
|
173
|
-
node.up
|
174
|
-
node.networks.each do |network|
|
175
|
-
network.up
|
176
|
-
end
|
177
|
-
node.containers.each do |container|
|
178
|
-
container.up
|
179
|
-
end
|
180
|
-
end
|
172
|
+
method_proxy(:up)
|
181
173
|
|
182
174
|
true
|
183
175
|
end
|
@@ -189,15 +181,7 @@ class TestLab
|
|
189
181
|
#
|
190
182
|
# @return [Boolean] True if successful.
|
191
183
|
def down
|
192
|
-
|
193
|
-
node.containers.reverse.each do |container|
|
194
|
-
container.down
|
195
|
-
end
|
196
|
-
node.networks.reverse.each do |network|
|
197
|
-
network.down
|
198
|
-
end
|
199
|
-
node.down
|
200
|
-
end
|
184
|
+
reverse_method_proxy(:down)
|
201
185
|
|
202
186
|
true
|
203
187
|
end
|
@@ -209,15 +193,7 @@ class TestLab
|
|
209
193
|
#
|
210
194
|
# @return [Boolean] True if successful.
|
211
195
|
def setup
|
212
|
-
|
213
|
-
node.setup
|
214
|
-
node.networks.each do |network|
|
215
|
-
network.setup
|
216
|
-
end
|
217
|
-
node.containers.each do |container|
|
218
|
-
container.setup
|
219
|
-
end
|
220
|
-
end
|
196
|
+
method_proxy(:setup)
|
221
197
|
|
222
198
|
true
|
223
199
|
end
|
@@ -229,15 +205,7 @@ class TestLab
|
|
229
205
|
#
|
230
206
|
# @return [Boolean] True if successful.
|
231
207
|
def teardown
|
232
|
-
|
233
|
-
node.containers.reverse.each do |container|
|
234
|
-
container.teardown
|
235
|
-
end
|
236
|
-
node.networks.reverse.each do |network|
|
237
|
-
network.teardown
|
238
|
-
end
|
239
|
-
node.teardown
|
240
|
-
end
|
208
|
+
reverse_method_proxy(:teardown)
|
241
209
|
|
242
210
|
true
|
243
211
|
end
|
@@ -249,13 +217,49 @@ class TestLab
|
|
249
217
|
#
|
250
218
|
# @return [Boolean] True if successful.
|
251
219
|
def node_method_proxy(method_name, *method_args)
|
252
|
-
nodes.
|
220
|
+
nodes.each do |node|
|
253
221
|
node.send(method_name.to_sym, *method_args)
|
254
222
|
end
|
255
223
|
|
256
224
|
true
|
257
225
|
end
|
258
226
|
|
227
|
+
# Method Proxy
|
228
|
+
#
|
229
|
+
# Iterates all of the lab objects sending the supplied method name and
|
230
|
+
# arguments to each object.
|
231
|
+
#
|
232
|
+
# @return [Boolean] True if successful.
|
233
|
+
def method_proxy(method_name, *method_args)
|
234
|
+
nodes.each do |node|
|
235
|
+
node.send(method_name, *method_args)
|
236
|
+
node.networks.each do |network|
|
237
|
+
network.send(method_name, *method_args)
|
238
|
+
end
|
239
|
+
node.containers.each do |container|
|
240
|
+
container.send(method_name, *method_args)
|
241
|
+
end
|
242
|
+
end
|
243
|
+
end
|
244
|
+
|
245
|
+
# Reverse Method Proxy
|
246
|
+
#
|
247
|
+
# Iterates all of the lab objects sending the supplied method name and
|
248
|
+
# arguments to each object.
|
249
|
+
#
|
250
|
+
# @return [Boolean] True if successful.
|
251
|
+
def reverse_method_proxy(method_name, *method_args)
|
252
|
+
nodes.reverse.each do |node|
|
253
|
+
node.containers.reverse.each do |container|
|
254
|
+
container.send(method_name, *method_args)
|
255
|
+
end
|
256
|
+
node.networks.reverse.each do |network|
|
257
|
+
network.send(method_name, *method_args)
|
258
|
+
end
|
259
|
+
node.send(method_name, *method_args)
|
260
|
+
end
|
261
|
+
end
|
262
|
+
|
259
263
|
# TestLab Configuration Directory
|
260
264
|
#
|
261
265
|
# Returns the path to the test lab configuration directory which is located
|
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: testlab
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.6.
|
4
|
+
version: 0.6.2
|
5
5
|
prerelease:
|
6
6
|
platform: ruby
|
7
7
|
authors:
|
@@ -9,7 +9,7 @@ authors:
|
|
9
9
|
autorequire:
|
10
10
|
bindir: bin
|
11
11
|
cert_chain: []
|
12
|
-
date: 2013-06-
|
12
|
+
date: 2013-06-14 00:00:00.000000000 Z
|
13
13
|
dependencies:
|
14
14
|
- !ruby/object:Gem::Dependency
|
15
15
|
name: gli
|
@@ -293,7 +293,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
|
|
293
293
|
version: '0'
|
294
294
|
segments:
|
295
295
|
- 0
|
296
|
-
hash: -
|
296
|
+
hash: -1071907971600767403
|
297
297
|
required_rubygems_version: !ruby/object:Gem::Requirement
|
298
298
|
none: false
|
299
299
|
requirements:
|
@@ -302,7 +302,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
302
302
|
version: '0'
|
303
303
|
segments:
|
304
304
|
- 0
|
305
|
-
hash: -
|
305
|
+
hash: -1071907971600767403
|
306
306
|
requirements: []
|
307
307
|
rubyforge_project:
|
308
308
|
rubygems_version: 1.8.25
|