cucumber-chef 3.0.0.rc.0 → 3.0.0.rc.1

Sign up to get free protection for your applications and to get access to all the features.
data/WIKI.md CHANGED
@@ -1,786 +1,313 @@
1
- [![Build Status](https://secure.travis-ci.org/jovelabs/cucumber-chef.png)](http://travis-ci.org/jovelabs/cucumber-chef) [![Dependency Status](https://gemnasium.com/jovelabs/cucumber-chef.png)](https://gemnasium.com/jovelabs/cucumber-chef)
1
+ [![Dependency Status](https://gemnasium.com/jovelabs/cucumber-chef.png)](https://gemnasium.com/jovelabs/cucumber-chef)
2
2
 
3
- Cucumber-chef is a library of tools to enable the emerging discipline of infrastructure as code to practice test driven development. It provides a testing platform within which Cucumber tests can be run which provision virtual machines, configure them by applying the appropriate Chef roles to them, and then run acceptance and integration tests against the environment.
4
-
5
- ## Overview
6
-
7
- Cucumber-chef begins with a very simple premise. If we are framing our infrastructure as code - if we're writing cookbooks, recipes and other pieces of automation in a high level programming language, such as Ruby, then it makes sense to follow the current wisdom across the software development world to maximise the quality, maintainability and reusability of our code, providing maximum chance that we'll deliver value with it. One area which has been shown to have a very positive effect is the practive of 'test-driven' development. In this paradigm, the developer begins by writing a test that captures the intended behaviour of the code they are going to write. This test will start out by failing. The developer then writes code to make the test pass, and iterates thereafter.
8
-
9
- Cucumber-chef provides a framework to make it easier to do test-driven development for infrastructure. It does this by providing a test infrastructure, which we call the "test lab", within which a number of different scenarios can be set up, and against which Cucumber features can we run. From the outset, Cucumber-chef's design was to provide a fast, lightweight and cheap way to fire up virtual machines for testing. At present this is achieved using Linux Containers on Amazon EC2. Supporting alternative provisioning backends is planned, which will allow the user to opt to test using local machines, alternative cloud providers, and ultimatey alternative virtualization technologies.
10
-
11
- For node convergence, Cucumber-Chef uses the open-source Chef server. It can be configured to use Hosted Chef or Private Chef. Supoprt for Chef-solo will be included in a future relase.
12
-
13
- As you might have guessed from the name, we're going to write high level acceptance tests using Cucumber. Cucumber-Chef provides step definitions and helper methods to make it easy to provision and manage machines with Chef, and then build end-to-end tests.
14
-
15
- ## Getting Started
16
-
17
- *LISTEN UP*
18
-
19
- Here's the headline:
20
-
21
- With a /single command/ Cucumber-Chef will provision a machine, set up an open source Chef server, bootstrap it to support the creation of Linux containers, set up an environment from which to run tests, and automatically configure your system to use it.
22
-
23
- This means getting started with Cucumber-Chef is a simple, two step process.
24
-
25
- 1. Install Cucumber-Chef
26
-
27
- 2. Run `cucumber-chef init` to configure Cucumber-Chef.
28
-
29
- 3. Run `cucumber-chef setup` to build your test lab.
30
-
31
- ### Installing Cucumber-Chef
32
-
33
- Cucumber-Chef is distributed as a RubyGem. To install it you have two options - stable or development.
34
-
35
- #### Installing the stable version
36
-
37
- Simply install from RubyGems:
38
-
39
- $ gem install cucumber-chef
40
-
41
- Depending on your local setup (ie whether you're using RVM or rbenv, or distribution-provided Ruby), you may need to run this with superuser privileges.
42
-
43
- #### Installing the development version
3
+ [![Build Status](https://secure.travis-ci.org/jovelabs/cucumber-chef.png)](http://travis-ci.org/jovelabs/cucumber-chef)
44
4
 
45
- If you want to try a development version, simply clone this repo, and build the gem yourself:
5
+ I was not particularly happy with the state of the 2.x documents and considering workflow changes, etc it made sense to me to start over with the documentation. Since most things are the same the 2.x documentation will remain available in the repo as `WIKI.2.x.md`. This is WIP.
46
6
 
47
- $ git clone git://github.com/Atalanta/cucumber-chef -b BRANCH
48
- $ cd cucumber-chef
49
- $ bundle
50
- $ rake build
51
- $ gem install pkg/cucumber-chef-VERSION.gem
7
+ # Cucumber-Chef 3.x Documentation
52
8
 
53
- Again, depending on your local setup (ie whether you're using RVM or rbenv, or distribution-provided Ruby), you may need to run parts of this process with superuser privileges.
54
-
55
- ### Running `cucumber-chef init`
56
-
57
- Cucumber-Chef ships with an initialization task, which will interactively generate configuration file. This requires you to have, and know your Amazon Web Services credntials. On completion of the interactive configuration, it will provision a machine on EC2, and set up the entire infrastructure, using Chef.
58
-
59
- Cucumber-Chef doesn't demand where you keep your configuration file. By default, the config will be created in `~/.cucumber-chef`, but this can be overridden. Cucumber-Chef is clever enough to find your config, so it's all cool.
60
-
61
- The two obvious places to keep this config, are in the top level of your Chef repository, or in a dedicated Cucumber-Chef repository, but you're free to do whatever works for you.
62
-
63
- You can view and verify the current config at any time by running `cucumber-chef displayconfig`. If Cucumber-Chef thinks your config is incorrect, or incomplete, it'll tell you.
64
-
65
- ## Using Cucumber-Chef
66
-
67
- Once installed, you can run `cucumber-chef` on the command line to get an overview of the tasks it can carry out.
9
+ Cucumber-chef is a library of tools to enable the emerging discipline of infrastructure as code to practice test driven development. It provides a testing platform within which Cucumber tests can be run which provision virtual machines, configure them by applying the appropriate Chef roles to them, and then run acceptance and integration tests against the environment.
68
10
 
69
- $ cucumber-chef
11
+ # Prerequsites/Recommendations
12
+
13
+ Your Chef-Repo should be setup in a manner as follows:
14
+
15
+ * Use something like RVM for your ruby with your chef-repo
16
+ * Use something like bundler for your rubygems with your chef-repo
17
+ * Use something like berkshelf for your chef cookbooks with your chef-repo
18
+
19
+ If you do not use these patterns you will have an unplesant time in general.
20
+
21
+ When using Cucumber-Chef, especially at first, I highly recommend you tail the log. Open another terminal, naviagate to your Chef-Repo root directory and run `tail -f .cucumber-chef/cucumber-chef.log`. You'll have a much better idea what's going on in the background this way, especially during bootstrapping and provisioning. And root causes of issues that are not so obvious on the console will hopefully be very obvious in the log.
22
+
23
+ # Workflow
24
+
25
+ 1. `cucumber`/`rspec` is executed; cucumber-chef is called
26
+ 2. `cucumber-chef` (re)creates the ecosystem from the `Labfile` (optionally executed)
27
+ 3. `cucumber-chef` runs the chef-client across the ecosystem using attributes from the `Labfile` (optionally executed)
28
+ 4. `cucumber`/`rspec` resumes execution
29
+
30
+ # Configuration
31
+
32
+ Cucumber-Chef creates a home directory for itself named `.cucumber-chef` off the root of your Chef-Repo. Here you can find the configuration files as well as logs and artifacts from test runs. There are two main configuration files for Cucumber-Chef. The `Labfile` in the Chef-Repo directory and `config.rb` in the Cucumber-Chef home directory.
33
+
34
+ ## `Labfile`
35
+
36
+ When doing integration testing it makes sense that one generally wants to test across an entire ecosystem of servers. You typically acquire a set of virtual or bare metal servers, provision those servers acordingly, put them into play then rinse and repeat. I introduce the `Labfile`, the concept is simple if you haven't already guessed it. You define a set of servers, i.e. an ecosystem, also dictating the settings and configuration. Part of this change is because a) it makes alot of sense to me and b) it greatly decreases runtimes. Also in cucumber-chef 2.x, we had insane background sections which bothered me tremendously and this change cleans up all of that mess as well. The ultimate goal is to support configuration of multiple ecosystems, but we've got other ground to cover first so that feature will have to wait for a bit. The `Labfile` should reside in the root of your Chef-Repo.
37
+
38
+ Here is a sample of what a `Labfile` might look like:
39
+
40
+ #!/usr/bin/env ruby
41
+ #^syntax detection
42
+
43
+ ecosystem "mockup-app-1" do
44
+
45
+ container "nginx-lb-test-1" do # or apache-lb-test-1
46
+ distro "ubuntu"
47
+ release "lucid"
48
+ persist true
49
+ ip "192.168.32.100"
50
+ mac "00:00:5e:d1:fa:08"
51
+ chef_client ({ :environment => "test",
52
+ :run_list => [
53
+ "role[base]",
54
+ "role[nginx_lb_server]"
55
+ ]
56
+ })
57
+ end
58
+
59
+ container "nginx-unicorn-test-1" do # or apache-passenger-test-1
60
+ distro "ubuntu"
61
+ release "lucid"
62
+ persist true
63
+ ip "192.168.32.200"
64
+ mac "00:00:5e:eb:8d:d3"
65
+ chef_client ({ :environment => "test",
66
+ :run_list => [
67
+ "role[base]",
68
+ "role[nginx_unicorn_server]"
69
+ ]
70
+ })
71
+ end
72
+
73
+ container "redis-test-1" do
74
+ distro "ubuntu"
75
+ release "lucid"
76
+ persist true
77
+ ip "192.168.32.210"
78
+ mac "00:00:5e:eb:8d:a3"
79
+ chef_client ({ :environment => "test",
80
+ :run_list => [
81
+ "role[base]",
82
+ "role[redis_server]"
83
+ ]
84
+ })
85
+ end
86
+
87
+ container "mysql-test-1" do
88
+ distro "ubuntu"
89
+ release "lucid"
90
+ persist true
91
+ ip "192.168.32.220"
92
+ mac "00:00:5e:ea:fe:28"
93
+ chef_client ({ :environment => "test",
94
+ :run_list => [
95
+ "role[base]",
96
+ "role[mysql_server]"
97
+ ]
98
+ })
99
+ end
100
+
101
+ end
102
+
103
+ ## `config.rb`
104
+
105
+ # Cucumber-Chef Tasks
106
+
107
+ All tasks should function in a similar manner across all providers.
108
+
109
+ ## `cucumber-chef help`
110
+
111
+ $ cucumber-chef help
70
112
  Tasks:
71
- cucumber-chef create <project> # Create a project template for testing an infrastructure.
72
- cucumber-chef diagnose <container> # Provide diagnostics from the chef-client on the specified container.
73
- cucumber-chef displayconfig # Display the current cucumber-chef config.
74
- cucumber-chef down # Shutdown the cucumber-chef test lab
75
- cucumber-chef help [TASK] # Describe available tasks or one specific task
76
- cucumber-chef info # Display information about the current test lab.
77
- cucumber-chef init # Initalize cucumber-chef configuration
78
- cucumber-chef ps [ps-options] # Snapshot of the current cucumber-chef test lab container processes.
79
- cucumber-chef setup # Setup cucumber-chef test lab in Amazon EC2
80
- cucumber-chef ssh [container] # SSH to cucumber-chef test lab or [container] if specified.
81
- cucumber-chef teardown # Teardown cucumber-chef test lab in Amazon EC2
82
- cucumber-chef up # Startup the cucumber-chef test lab
83
-
84
- Running just `cucumber` on the command line will run your tests.
85
-
86
- After running setup, which takes about 15 minutes, you'll have a fully funtioning platform available for you to use. Let's just quickly review what that means. You will have an EC2 machine, fully managed by Chef, and providing the following:
87
-
88
- * The ability to provision LXC containers
89
- * The ability to run tests against LXC containers
90
- * A dedicated environment for certain kinds of testing scenarios
91
-
92
- The next stage is to set up a project. A project is simply a directory structure for containing your cucumber features and steps, already set up with an appropriate environment to make use of the step definitions provided with Cucumber-Chef. Cucumber-chef provides a task which will create a the directory for you, and populate it with a README and an example feature and steps. These represent futher documentation, and provide a model and steps to get you up and running with your testing as quickly as possible.
93
-
94
- $ cd /path/to/chef-repo
95
- $ cucumber-chef create myproject
96
-
97
- This will create a directory, cucumber-chef, and a subdirectory, `myproject`.
98
-
99
- chef-repo/
100
- ├── .chef
101
- ├── cookbooks
102
- ├── .cucumber-chef
103
- │ ├── aws
104
- │ │ └── checksums
105
- │ ├── checksums
106
- │ └── vagrant
107
- │ ├── artifacts
108
- │ └── checksums
109
- ├── data_bags
110
- ├── environments
111
- ├── features
112
- │ ├── support
113
- │ │ ├── cc-hooks.rb
114
- │ │ ├── env.rb
115
- │ │ ├── data_bags
116
- │ │ ├── environments
117
- │ │ ├── keys
118
- │ │ └── roles
119
- ├── roles
120
- └── site-cookbooks
121
-
122
-
123
- └── myproject
124
- ├── README
125
- └── features
126
- ├── myproject.feature
127
- ├── step_definitions
128
- │   └── myproject_steps.rb
129
- └── support
130
- └── env.rb
131
-
132
- ### General Tasks
133
-
134
- #### `up`
135
-
136
- If you are using an EBS volume, you can start and stop your test lab. This task will attempt to start your Cucumber-Chef test lab if it is currently stopped.
137
-
138
- #### `down`
139
-
140
- If you are using an EBS volume, you can start and stop your test lab. This task will attempt to stop your Cucumber-Chef test lab if it is currently running.
141
-
142
- ## Writing Tests
143
-
144
- Once you've got your test lab set up, and you've generated a project, it's time to crack on with writing a test. The basic idea is this:
145
-
146
- 1. An infrastructure requirement is established
147
- 2. Write a cucumber feature that expresses the required behaviour of the infrastructure requirement
148
- 3. Write steps that will build this infrastructure environment on the test lab, using the step definitions provided - these include the ability to create a container, apply roles to it, and destroy it again.
149
- 4. Write cookbooks and recipes and supporting code to make the test pass
150
-
151
- ### Container Details
152
-
153
- All containers operate off a bridged interface on the test-lab. All outbound, non-local traffic from the LXC containers are NAT'd through the test-lab and off to the outside world. This bridged interface on the test-lab is configured as follows:
154
-
155
- CIDR: 192.168.0.0/16
156
- IP Address: 192.168.255.254
157
- Netmask: 255.255.255.0
158
- Broadcast: 192.168.255.255
159
-
160
- You are free to use any IP in this /24, with the exception of the test-lab itself, which is at `192.168.255.254`.
161
-
162
- ### Built In Test Steps
163
-
164
- #### Provisioning<a id="provisioning"></a>
165
-
166
- We provide several built in steps to help you with provisioning. It is suggested you build a `Background` section for your features so these are not repeated with each scenario. This example `Background` section does the following:
167
-
168
- * Sets up a server called `devopserver`.
169
- * Makes the server persistant (it will remain up after the test finishes, which is the default behaviour).
170
- * Assigns what linux distro and release to use for the container.
171
- * Assigns it an IP address on the test lab network (this can be omitted for an auto-assigned IP).
172
- * Tells Cucumber-Chef to provision the server.
173
- * Adds the `chef-client::service` recipe in to the chef-client's run list.
174
- * Executes `chef-client` with the generated run list.
175
- * Starts an SSH session to the server so you can execute commands and test the output of those commands in the scenarios.
176
-
177
- Here is the `Background` section as you might write it in a feature:
178
-
179
- Background:
180
- * I have a server called "devopserver"
181
- * "devopserver" should be persistant
182
- * "devopserver" is running "ubuntu" "lucid"
183
- * "devopserver" has an IP address of "192.168.73.31"
184
- * "devopserver" has been provisioned
185
- * "devopserver" is in the "foobar" environment
186
- * the "chef-client::service" recipe has been added to the "devopserver" run list
187
- * the chef-client has been run on "devopserver"
188
- * I ssh to "devopserver" with the following credentials:
189
- | username | password |
190
- | root | root |
191
-
192
- To get a persistent server with an auto-assigned IP address using the generated and populated test lab SSH key pairs for SSH authentication you could write something like this. Remember the tests run on the test lab, so we can just back out a directory and reference our test lab SSH private key directly:
193
-
194
- Background:
195
- * I have a server called "devopserver"
196
- * "devopserver" is running "ubuntu" "lucid"
197
- * "devopserver" has been provisioned
198
- * "devopserver" is in the "foobar" environment
199
- * the "chef-client::service" recipe has been added to the "devopserver" run list
200
- * the chef-client has been run on "devopserver"
201
- * I ssh to "devopserver" with the following credentials:
202
- | username | keyfile |
203
- | root | ../.ssh/id_rsa |
204
-
205
- You can add roles to the run list by writing:
206
-
207
- * the "chef-client" role has been added to the "devopserver" run list
208
-
209
- Here's an example `Scenario` section you might have to test if the chef-client is actually running as a daemon:
210
-
211
- Scenario: Chef-Client is running as a daemon
212
- When I run "ps aux | grep [c]hef-client"
213
- Then I should see "chef-client" in the output
214
- And I should see "-d" in the output
215
- And I should see "-i 1800" in the output
216
- And I should see "-s 20" in the output
217
-
218
- See the section below label *Example Test Run* for more examples.
219
-
220
- ##### List of Provisioning Steps
221
-
222
- Create a server profile:
223
-
224
- I have a server called "(server)"
225
-
226
- Set a (server) to persist or not:
227
-
228
- "(server)" should( not) be persistant
229
-
230
- Set (server) to run linux of type (distro), using (release).
231
-
232
- "(server)" is running "(distro)" "(release)"
233
-
234
- Supported (distro -> releases):
235
-
236
- ubuntu -> lucid, maverick, natty, oneiric, precise
237
- fedora -> (release number)
238
-
239
- Fedora releases 12, 13, 14 tested OK.
240
-
241
- Assign (server) a specific IP address (must be on the test lab network segment):
242
-
243
- "(server)" has an IP address of "(ip)"
244
-
245
- Assign (server) a specific MAC address:
246
-
247
- "(server)" has a MAC address of "(mac)"
248
-
249
- Initiate the provision of a (server). All attributes of the server need to be set before this:
250
-
251
- "(server)" has been provisioned
252
-
253
- #### Chef Steps
254
-
255
- To prep a server with a role and data bag:
256
-
257
- * the following roles have been updated:
258
- | role | role_path |
259
- | users | ./features/support/roles/ |
260
- * the "users" role has been added to the "users" run list
261
- * the following databags have been updated:
262
- | databag | databag_path |
263
- | users | ./features/support/data_bags/users |
264
-
265
- ##### List of Chef Steps
266
-
267
- Update/push cookbooks to the chef-server:
268
-
269
- * the following cookbooks have been uploaded:
270
- | cookbook | cookbook_path |
271
- | users | ./cookbooks/ |
272
-
273
- Update/push roles to the chef-server:
274
-
275
- * the following roles have been updated:
276
- | role | role_path |
277
- | users | ./features/support/roles/ |
278
-
279
- or
280
-
281
- * the following roles have been updated:
282
- | role | role_path |
283
- | users | ./roles/ |
284
-
285
- Update/push data bags to the chef-server:
286
-
287
- * the following databags have been updated:
288
- | databag | databag_path |
289
- | users | ./features/support/data_bags/users |
290
-
291
- or
113
+ cucumber-chef create <project> # Create a project template for testing an infrastructure.
114
+ cucumber-chef destroy [container] [...] # Destroy the cucumber-chef test lab or a single or multiple containers if specified
115
+ cucumber-chef diagnose <container> # Provide diagnostics from the chef-client on the specified container.
116
+ cucumber-chef displayconfig # Display the current cucumber-chef config.
117
+ cucumber-chef down # Power off the cucumber-chef test lab
118
+ cucumber-chef genip # Generate an RFC compliant private IP address
119
+ cucumber-chef genmac # Generate an RFC compliant private MAC address
120
+ cucumber-chef help [TASK] # Describe available tasks or one specific task
121
+ cucumber-chef info # *DEPRECIATED* - You should execute the 'status' task instead.
122
+ cucumber-chef init # Initalize cucumber-chef configuration
123
+ cucumber-chef log # Streams the cucumber-chef local and test lab logs to the terminal.
124
+ cucumber-chef ps [ps-options] # Snapshot of the current cucumber-chef test lab container processes.
125
+ cucumber-chef reload # Reload the cucumber-chef test lab
126
+ cucumber-chef setup # Setup the cucumber-chef test lab
127
+ cucumber-chef ssh [container] # SSH to cucumber-chef test lab or [container] if specified
128
+ cucumber-chef status # Displays the current status of the test lab.
129
+ cucumber-chef teardown # *DEPRECIATED* - You should execute the 'destroy' task instead.
130
+ cucumber-chef test # *DEPRECIATED* - You should execute 'cucumber' or 'rspec' directly.
131
+ cucumber-chef up # Power up the cucumber-chef test lab
132
+
133
+
134
+ ## `cucumber-chef setup`
135
+
136
+ Setup the cucumber-chef test lab:
137
+
138
+ $ cucumber-chef setup
139
+ cucumber-chef v3.0.0.rc.0
140
+ Creating VAGRANT instance completed in 53.2361 seconds.
141
+ Bootstrapping VAGRANT instance completed in 757.4014 seconds.
142
+ Waiting for the chef-server completed in 0.1007 seconds.
143
+ Waiting for the chef-server-webui completed in 0.1007 seconds.
144
+ Downloading chef-server credentials completed in 1.2088 seconds.
145
+ Uploading 'cucumber-chef' cookbooks completed in 6.8571 seconds.
146
+ Uploading 'cucumber-chef' roles completed in 5.5413 seconds.
147
+ Performing chef-client run completed in 45.9874 seconds.
148
+ Downloading proxy SSH credentials completed in 0.3013 seconds.
149
+ Rebooting the test lab completed in 21.2672 seconds.
150
+ Waiting for the chef-server completed in 0.1008 seconds.
151
+ Waiting for the chef-server-webui completed in 0.1009 seconds.
152
+
153
+ If you are using AWS, be sure to log into the chef-server webui and change the default admin password at least.
154
+
155
+ Your test lab has now been provisioned! Enjoy!
156
+
157
+ +-------------------------------------------------------------------+
158
+ | PROVIDER: Cucumber::Chef::Provider::Vagrant |
159
+ | ID: default |
160
+ | STATE: running |
161
+ | USERNAME: vagrant |
162
+ | IP ADDRESS: 127.0.0.1 |
163
+ | PORT: 2222 |
164
+ | CHEF-SERVER API: http://127.0.0.1:4000 |
165
+ | CHEF-SERVER WEBUI: http://127.0.0.1:4040 |
166
+ | CHEF-SERVER DEFAULT USER: admin |
167
+ | CHEF-SERVER DEFAULT PASSWORD: p@ssw0rd1 |
168
+ +-------------------------------------------------------------------+
169
+
170
+ ## `cucumber-chef destroy [container] [...]`
171
+
172
+ Destroy the cucumber-chef test lab:
173
+
174
+ $ cucumber-chef destroy
175
+ cucumber-chef v3.0.0.rc.0
176
+ +-------------------------------------------------------------------+
177
+ | PROVIDER: Cucumber::Chef::Provider::Vagrant |
178
+ | ID: default |
179
+ | STATE: running |
180
+ | USERNAME: vagrant |
181
+ | IP ADDRESS: 127.0.0.1 |
182
+ | PORT: 2222 |
183
+ | CHEF-SERVER API: http://127.0.0.1:4000 |
184
+ | CHEF-SERVER WEBUI: http://127.0.0.1:4040 |
185
+ | CHEF-SERVER DEFAULT USER: admin |
186
+ | CHEF-SERVER DEFAULT PASSWORD: p@ssw0rd1 |
187
+ +-------------------------------------------------------------------+
188
+ Are you sure you want to destroy the test lab? y
189
+
190
+ You have 5 seconds to abort!
191
+
192
+ 5...4...3...2...1...BOOM!
193
+
194
+ Destroy VAGRANT instance 'default' completed in 7.4898 seconds.
195
+
196
+ Destroy single or multiple containers:
197
+
198
+ $ cucumber-chef destroy nginx-lb-test-1
199
+ cucumber-chef v3.0.0.rc.0
200
+ Are you sure you want to destroy the container 'nginx-lb-test-1'? y
201
+
202
+ You have 5 seconds to abort!
203
+
204
+ 5...4...3...2...1...BOOM!
205
+
206
+ Destroy container 'nginx-lb-test-1' completed in 24.4092 seconds.
207
+
208
+ ## `cucumber-chef up`
209
+
210
+ Power up the cucumber-chef test lab:
211
+
212
+ $ cucumber-chef up
213
+ cucumber-chef v3.0.0.rc.0
214
+ Booting VAGRANT instance 'default' completed in 37.2031 seconds.
215
+
216
+ ## `cucumber-chef down`
292
217
 
293
- * the following databags have been updated:
294
- | databag | databag_path |
295
- | users | ./data_bags/users |
218
+ Power off the cucumber-chef test lab:
296
219
 
297
- Add a role to the chef-client run list:
220
+ $ cucumber-chef down
221
+ cucumber-chef v3.0.0.rc.0
222
+ Downing VAGRANT instance 'default' completed in 31.1460 seconds.
298
223
 
299
- the "(role)" role has been added to the "(server)" run list
224
+ ## `cucumber-chef ssh [container]`
300
225
 
301
- Add a recipe to the chef-client run list:
226
+ SSH to cucumber-chef test lab:
302
227
 
303
- the "(recipe)" recipe has been added to the "(server)" run list
304
-
305
- Place the node in a specific chef environment:
306
-
307
- "(server)" is in the "(environment)" environment
308
-
309
- Run the chef-client:
310
-
311
- the chef-client has been run on "(server)"
312
-
313
- In order to push data bags/roles/cookbooks to the chef-server using one of the above steps, you will have to create a `cucumber.yml` file in the root of your `chef-repo` with the following contents (see [issue 88](https://github.com/Atalanta/cucumber-chef/issues/88)):
314
-
315
- ---
316
- default: -c -v --exclude support/data_bags --exclude support/roles --exclude support/cookbooks
317
-
318
- Alternatively, you can simply reference the normal data bags/roles/cookbooks directory like so:
319
-
320
- * the following roles have been updated:
321
- | role | role_path |
322
- | users | ./roles/ |
323
-
324
- #### SSH Steps
325
-
326
- Here is how you might setup and initate an SSH session using password authentication to a server named `devopserver`:
327
-
328
- * I have no public keys set
329
- * I ssh to "devopserver" with the following credentials:
330
- | username | password |
331
- | root | root |
332
-
333
- Here is how you might setup and initate an SSH session using public key authentication to a server named `users`:
334
-
335
- * I ssh to "users" with the following credentials:
336
- | username | keyfile |
337
- | root | ../.ssh/id_rsa |
338
-
339
- Since the cukes run on the test lab, we can directly reference the public key pairs already there and populated for us.
340
-
341
- Suppose we have a cookbook that creates new users. After it runs we should be able to SSH in with our public keys. Let's test this. First we'll do our setup in the `Background`:
342
-
343
- Background:
344
- * I have a server called "users"
345
- * "users" is running "ubuntu" "lucid"
346
- * "users" has been provisioned
347
- * the following roles have been updated:
348
- | role | role_path |
349
- | users | ./features/support/roles/ |
350
- * the "users" role has been added to the "users" run list
351
- * the following databags have been updated:
352
- | databag | databag_path |
353
- | users | ./features/support/data_bags/users |
354
- * the chef-client has been run on "users"
355
-
356
- And now for the `Scenario`:
357
-
358
- Scenario: The user can ssh in to the system with their key pair
359
- * I ssh to "users" with the following credentials:
360
- | username | keyfile |
361
- | bdobbs | ./features/support/keys/bdobbs |
362
- When I run "hostname"
363
- Then I should see "users" in the output
364
-
365
-
366
- ##### List of SSH Steps
367
-
368
- Sets the authentication method to password:
369
-
370
- I have no public keys set
371
-
372
- Start an SSH session to the server (server) using password authentication:
373
-
374
- I ssh to "(server)" with the following credentials:
375
- | username | password |
376
- | root | root |
377
-
378
- Start an SSH session to the server (server) using public key authentication:
379
-
380
- I ssh to "(server)" with the following credentials:
381
- | username | keyfile |
382
- | root | id_rsa |
383
-
384
- Executes (command) over the previously established SSH session on the server (server):
385
-
386
- I run "(command)"
387
-
388
- Check (command) output for an (expected) or (not-expected) string:
389
-
390
- I should( not) see "(expected)" in the output
391
-
392
- Check (command) output for existance of or lack of (server) settings:
393
-
394
- I should( not) see the "(ip|mac)" of "(server)" in the output
395
-
396
- Check for a (running) or (not-running) (process)
397
-
398
- service "(nginx)" should( not) be running
399
-
400
- #### Minitest
401
-
402
- ##### List of Minitest Steps
403
-
404
- I enable the running of MiniTest suites for "(server)"
405
-
406
- the tests should run and pass on "(server)"
407
-
408
- #### Cucumber Before Hook Centric Helpers
409
-
410
- * `chef_set_client_config(config={})`
411
-
412
- This method configures the chef-client's `client.rb` file. Currently you can specify `:orgname`, `:log_level`, `:log_location`, `:chef_server_url` and `:validation_client_name`. See your `env.rb` file if you need to change this to point it at a Hosted Chef Server or need to modify any of these values.
413
-
414
- ##### Examples
415
-
416
- # for Opscode Hosted chef-server use this:
417
- #chef_set_client_config(:orgname => "cucumber-chef")
418
-
419
- # for Opscode OS chef-server on the Cucumber-Chef test lab use this:
420
- chef_set_client_config(:chef_server_url => "http://192.168.255.254:4000",
421
- :validation_client_name => "chef-validator")
422
-
423
- ## Running Tests
424
-
425
- You can write the tests and Chef code wherever you like. We're assuming you prefer working on your local machine, and checking into version control. But we don't really care. When it's time to run tests, Cucumber provides a task which handles this:
426
-
427
- $ cucumber
428
-
429
- Containers are now persisted by default. This means faster run times on average but if things get screwy, or you want to test from a clean slate, you can easily reset your containers.
430
-
431
- $ cucumber-chef help teardown
432
- Usage:
433
- cucumber-chef teardown [container]
434
-
435
- Teardown the cucumber-chef test lab in Amazon EC2 or a test lab [container] if specified.
436
-
437
- Since to run a test you simply run cucumber, you can now pass in options for cucumber or even setup profiles via `cucumber.yml`. For example:
438
-
439
- $ cucumber --tags @wip -c -v -b
440
-
441
- To take advantage of cucumber profiles, create a `cucumber.yml` configuration file in the root of your chef-repo; just as you would with any other project using cucumber. In this file you can take full advantage of the Cucumber profiles as definied on their wiki, https://github.com/cucumber/cucumber/wiki/cucumber.yml.
442
-
443
- Here is an example default project for `cucumber.yml` which turns on colored output, verbosity and full backtraces for all test runs:
228
+ $ cucumber-chef ssh
229
+ cucumber-chef v3.0.0.rc.0
230
+ Attempting SSH connection to the 'test lab'...
231
+ _____ _ _____ _ __
232
+ / ____| | | / ____| | / _|
233
+ | | _ _ ___ _ _ _ __ ___ | |__ ___ _ __| | | |__ ___| |_
234
+ | | | | | |/ __| | | | '_ ` _ \| '_ \ / _ \ '__| | | '_ \ / _ \ _|
235
+ | |___| |_| | (__| |_| | | | | | | |_) | __/ | | |____| | | | __/ |
236
+ \_____\__,_|\___|\__,_|_| |_| |_|_.__/ \___|_| \_____|_| |_|\___|_|
444
237
 
445
- ---
446
- default: -c -v -b
447
238
 
448
- Running the test task will upload your current project to the test lab, and run the tests, reporting the results back to the screen. Cucumber-chef also provides an upload task, so you can push the current project to the test lab, and then connect to test lab yourself to run tests in a more granular way. To do this, you need to know the IP of the test lab. You can find this out by running:
239
+ Welcome to the Cucumber Chef Test Lab v3.0.0.rc.0
449
240
 
450
- $ cucumber-chef info
241
+ Last login: Fri Sep 14 06:23:18 2012 from 10.0.2.2
242
+ vagrant@cucumber-chef:~$
451
243
 
452
- At present, Cucumber-Chef only allows one test lab per AWS account. In practice, this has not been a constraint. LXC is incredibly lightweight, and a large number of containers can be provisioned on even a small EC2 instance.
244
+ SSH to a container:
453
245
 
454
- ### When Things Go Oh So Wrong
246
+ $ cucumber-chef ssh nginx-lb-test-1
247
+ cucumber-chef v3.0.0.rc.0
248
+ Attempting proxy SSH connection to the container 'nginx-lb-test-1'...
249
+ _____ _ _____ _ __
250
+ / ____| | | / ____| | / _|
251
+ | | _ _ ___ _ _ _ __ ___ | |__ ___ _ __| | | |__ ___| |_
252
+ | | | | | |/ __| | | | '_ ` _ \| '_ \ / _ \ '__| | | '_ \ / _ \ _|
253
+ | |___| |_| | (__| |_| | | | | | | |_) | __/ | | |____| | | | __/ |
254
+ \_____\__,_|\___|\__,_|_| |_| |_|_.__/ \___|_| \_____|_| |_|\___|_|
455
255
 
456
- We have put in a few tasks to help you diagnose any issues you may come across with the test lab, containers or your cookbooks and recipes. There are two main tasks available to help you with this: `ssh` and `diagnose`.
457
256
 
458
- #### `ssh`
257
+ Welcome to the Cucumber Chef Test Lab v3.0.0.rc.0
459
258
 
460
- $ cucumber-chef help ssh
461
- Usage:
462
- cucumber-chef ssh [container]
259
+ You are now logged in to the nginx-lb-test-1 container!
463
260
 
464
- Options:
465
- [--test] # INTERNAL USE ONLY
261
+ root@nginx-lb-test-1:~#
466
262
 
467
- SSH to cucumber-chef test lab or [container] if specified.
263
+ ## `cucumber-chef genmac`
468
264
 
469
- This command provides you with a rapid way to connect to either your test lab or containers. Think `vagrant ssh`; we took a queue from their wonderful gem and realized we want our gem to provide the same sort of functionality. The main difference between our `ssh` task and the way Vagrant's task works is that we generate a fresh ssh key pair whenever a test lab is setup; so you can rest assured no one else has a copy of the credientials. You also do not have to worry about generating or specifying your own key pair to override a default key pair as is the case with Vagrant if you do not want to use the one shipped with Vagrant.
265
+ Generate an RFC compliant private MAC address for use in a `Labfile`:
470
266
 
471
- $ cucumber-chef ssh
472
- Attempting SSH connection to cucumber-chef 'test lab'...
473
- _____ _ _____ _ __
474
- / ____| | | / ____| | / _|
475
- | | _ _ ___ _ _ _ __ ___ | |__ ___ _ __| | | |__ ___| |_
476
- | | | | | |/ __| | | | '_ ` _ \| '_ \ / _ \ '__| | | '_ \ / _ \ _|
477
- | |___| |_| | (__| |_| | | | | | | |_) | __/ | | |____| | | | __/ |
478
- \_____\__,_|\___|\__,_|_| |_| |_|_.__/ \___|_| \_____|_| |_|\___|_|
267
+ $ cucumber-chef genmac
268
+ cucumber-chef v3.0.0.rc.0
269
+ 00:00:5e:4f:96:b0
479
270
 
271
+ ## `cucumber-chef genip`
480
272
 
481
- Welcome to the Cucumber Chef Test Lab v2.0.0.rc1
273
+ Generate an RFC compliant private IP address for use in a `Labfile`:
482
274
 
483
- Last login: Mon Jun 4 07:56:40 2012 from [REDACTED]
484
- ubuntu@cucumber-chef:~$
275
+ $ cucumber-chef genip
276
+ cucumber-chef v3.0.0.rc.0
277
+ 192.168.244.120
485
278
 
486
- Keep in mind with Amazon's EC2 the base `ubuntu` user is already in the sudoers file; so you can `sudo su -` without needing the password.
279
+ ## `cucumber-chef status`
487
280
 
488
- ubuntu@cucumber-chef:~$ sudo su -
489
- root@cucumber-chef:~#
281
+ Displays information on the status of the current test lab:
490
282
 
491
- You can also specify a container name to SSH directly into that container. For now you are always logged in as `root` when you SSH to a container.
283
+ $ cucumber-chef status
284
+ cucumber-chef v3.0.0.rc.0
285
+ +-------------------------------------------------------------------+
286
+ | PROVIDER: Cucumber::Chef::Provider::Vagrant |
287
+ | ID: default |
288
+ | STATE: running |
289
+ | USERNAME: vagrant |
290
+ | IP ADDRESS: 127.0.0.1 |
291
+ | PORT: 2222 |
292
+ | CHEF-SERVER API: http://127.0.0.1:4000 |
293
+ | CHEF-SERVER WEBUI: http://127.0.0.1:4040 |
294
+ | CHEF-SERVER DEFAULT USER: admin |
295
+ | CHEF-SERVER DEFAULT PASSWORD: p@ssw0rd1 |
296
+ +-------------------------------------------------------------------+
492
297
 
493
- $ cucumber-chef ssh devopserver
494
- Attempting SSH connection to cucumber-chef container 'devopserver'...
495
- _____ _ _____ _ __
496
- / ____| | | / ____| | / _|
497
- | | _ _ ___ _ _ _ __ ___ | |__ ___ _ __| | | |__ ___| |_
498
- | | | | | |/ __| | | | '_ ` _ \| '_ \ / _ \ '__| | | '_ \ / _ \ _|
499
- | |___| |_| | (__| |_| | | | | | | |_) | __/ | | |____| | | | __/ |
500
- \_____\__,_|\___|\__,_|_| |_| |_|_.__/ \___|_| \_____|_| |_|\___|_|
298
+ Displays information on the status of the current test lab containers:
501
299
 
300
+ $ cucumber-chef status --containers
301
+ cucumber-chef v3.0.0.rc.0
302
+ +----------------------+-------+--------+---------------+-------------------+---------------+---------+
303
+ | NAME | ALIVE | DISTRO | IP | MAC | CHEF VERSION | PERSIST |
304
+ +----------------------+-------+--------+---------------+-------------------+---------------+---------+
305
+ | nginx-lb-test-1 | true | ubuntu | 192.168.0.100 | 00:00:5e:35:ea:d5 | Chef: 10.18.2 | true |
306
+ | nginx-unicorn-test-1 | true | ubuntu | 192.168.0.200 | 00:00:5e:d1:fa:08 | Chef: 10.18.2 | true |
307
+ | redis-test-1 | true | ubuntu | 192.168.0.210 | 00:00:5e:eb:8d:a3 | Chef: 10.18.2 | true |
308
+ | mysql-test-1 | true | ubuntu | 192.168.0.220 | 00:00:5e:ea:fe:28 | Chef: 10.18.2 | true |
309
+ +----------------------+-------+--------+---------------+-------------------+---------------+---------+
502
310
 
503
- Welcome to the Cucumber Chef Test Lab v2.0.0.rc1
504
-
505
- You are now logged in to the LXC 'devopserver'
506
-
507
- root@devopserver:~#
508
-
509
- #### `diagnose`
510
-
511
- This command provides you with a rapid way to get to the chef-client logs without needing to SSH into a container. There are a few basic options with this task, let's take a look at them.
512
-
513
- $ cucumber-chef help diagnose
514
- Usage:
515
- cucumber-chef diagnose <container>
516
-
517
- Options:
518
- -n, [--lines=N] # output the last N lines of the chef-client 'chef.log'
519
- # Default: 1
520
- -s, [--strace] # output the chef-client 'chef-stacktrace.out'
521
- # Default: true
522
- -l, [--log] # output the chef-client 'chef.log'
523
- # Default: true
524
-
525
- Provide diagnostics from the chef-client on the specified container.
526
-
527
- With the default options in effect, this task will output the `chef-stacktrace.out` file along with the last line of the `chef.log` file. You can of course request as many lines as you desire from the `chef.log` file. For example to look at the last 1000 lines of only the `chef.log` file you would likely run the task as follows.
528
-
529
- $ cucumber-chef diagnose devopserver --no-strace -n 1000
530
-
531
- Maybe you only want to view the `chef-stacktrace.out` file?
532
-
533
- $ cucumber-chef diagnose devopserver --no-log
534
-
535
- Maybe you want to run it with the default options in play; you would likely get some output as follows.
536
-
537
- $ cucumber-chef diagnose devopserver
538
- Attempting to collect diagnostic information on cucumber-chef container 'sysopserver'...
539
- ----------------------------------------------------------------------------
540
- chef-stacktrace.out:
541
- ----------------------------------------------------------------------------
542
- Generated at 2012-06-04 08:30:20 +0000
543
- Net::HTTPServerException: 412 "Precondition Failed"
544
- /opt/opscode/embedded/lib/ruby/1.9.1/net/http.rb:2303:in `error!'
545
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/rest.rb:264:in `block in api_request'
546
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/rest.rb:328:in `retriable_rest_request'
547
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/rest.rb:240:in `api_request'
548
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/rest.rb:139:in `post_rest'
549
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/client.rb:313:in `sync_cookbooks'
550
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/client.rb:194:in `setup_run_context'
551
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/client.rb:162:in `run'
552
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/application/client.rb:254:in `block in run_application'
553
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/application/client.rb:241:in `loop'
554
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/application/client.rb:241:in `run_application'
555
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/lib/chef/application.rb:70:in `run'
556
- /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.10/bin/chef-client:26:in `<top (required)>'
557
- /usr/bin/chef-client:19:in `load'
558
- /usr/bin/chef-client:19:in `<main>'
559
- ----------------------------------------------------------------------------
560
- chef.log:
561
- ----------------------------------------------------------------------------
562
- [Mon, 04 Jun 2012 08:30:20 +0000] FATAL: Net::HTTPServerException: 412 "Precondition Failed"
563
-
564
-
565
- #### `ps`
566
-
567
- This command provides you with a snapshot of all the container processes running on the Cucumber-Chef test lab. You can pass in `ps` command line options to customize the output as you desire.
568
-
569
- $ cucumber-chef help ps
570
- Usage:
571
- cucumber-chef ps [ps-options]
572
-
573
- Snapshot of the current cucumber-chef test lab container processes.
574
-
575
- Standard usage using `aux` options:
576
-
577
- $ cucumber-chef ps aux
578
- cucumber-chef v2.0.0.rc1
579
-
580
- Getting container processes from cucumber-chef test lab...
581
-
582
- ============================================================================
583
- CONTAINER USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
584
- sudo root 375 0.0 0.0 2368 608 ? S Jun21 0:00 upstart-udev-bridge --daemon
585
- sudo syslog 384 0.0 0.0 27296 1264 ? Sl Jun21 0:00 rsyslogd -c4
586
- sudo root 396 0.0 0.0 2236 388 ? S<s Jun21 0:00 udevd --daemon
587
- sudo root 406 0.0 0.0 1840 556 pts/19 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty4
588
- sudo root 410 0.0 0.0 1840 560 pts/17 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty2
589
- sudo root 412 0.0 0.0 1840 560 pts/18 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty3
590
- sudo root 416 0.0 0.0 2428 812 ? Ss Jun21 0:00 cron
591
- sudo root 453 0.0 0.0 1840 564 pts/16 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty1
592
- sudo root 455 0.0 0.0 1840 556 pts/20 Ss+ Jun21 0:00 /sbin/getty -8 38400 /dev/console
593
- sudo root 477 0.0 0.0 2288 576 ? Ss Jun21 0:00 dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0
594
- sudo root 493 0.0 0.1 5600 2132 ? Ss Jun21 0:00 /usr/sbin/sshd -D
595
- users root 20777 0.0 0.0 2720 1484 ? Ss Jun21 0:02 /sbin/init
596
- users syslog 20876 0.0 0.0 27296 1172 ? Sl Jun21 0:02 rsyslogd -c4
597
- users root 20877 0.0 0.0 2368 560 ? S Jun21 0:00 upstart-udev-bridge --daemon
598
- users root 20883 0.0 0.0 2236 516 ? S<s Jun21 0:00 udevd --daemon
599
- users root 20914 0.0 0.0 1840 544 pts/4 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty4
600
- users root 20918 0.0 0.0 1840 540 pts/2 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty2
601
- users root 20921 0.0 0.0 1840 544 pts/3 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty3
602
- users root 20925 0.0 0.0 2428 788 ? Ss Jun21 0:00 cron
603
- users root 20953 0.0 0.0 1840 544 pts/1 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty1
604
- users root 20954 0.0 0.0 1840 544 pts/5 Ss+ Jun21 0:00 /sbin/getty -8 38400 /dev/console
605
- users root 20970 0.0 0.0 2288 572 ? Ss Jun21 0:00 dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0
606
- users root 20987 0.0 0.1 5600 2128 ? Ss Jun21 0:01 /usr/sbin/sshd -D
607
- users root 21308 0.0 0.0 1848 488 ? S Jun21 0:07 tail -n 250 -f client.log
608
- users root 21519 0.0 0.0 1848 484 ? S 02:19 0:02 tail -n 250 -f /var/log/auth.log
609
- users root 21851 0.0 0.0 1848 484 ? S 02:20 0:02 tail -n 250 -f /var/log/chef/client.log
610
- chef-client root 27226 0.0 0.0 2728 1524 ? Ss Jun21 0:00 /sbin/init
611
- chef-client syslog 27328 0.0 0.0 27296 1244 ? Sl Jun21 0:00 rsyslogd -c4
612
- chef-client root 27329 0.0 0.0 2368 584 ? S Jun21 0:00 upstart-udev-bridge --daemon
613
- chef-client root 27340 0.0 0.0 2236 520 ? S<s Jun21 0:00 udevd --daemon
614
- chef-client root 27364 0.0 0.0 1840 548 pts/9 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty4
615
- chef-client root 27368 0.0 0.0 1840 548 pts/7 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty2
616
- chef-client root 27369 0.0 0.0 1840 548 pts/8 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty3
617
- chef-client root 27371 0.0 0.0 2428 804 ? Ss Jun21 0:00 cron
618
- chef-client root 27401 0.0 0.0 1840 548 pts/6 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty1
619
- chef-client root 27402 0.0 0.0 1840 548 pts/10 Ss+ Jun21 0:00 /sbin/getty -8 38400 /dev/console
620
- chef-client root 27420 0.0 0.0 2288 572 ? Ss Jun21 0:00 dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0
621
- chef-client root 27437 0.0 0.1 5600 2128 ? Ss Jun21 0:00 /usr/sbin/sshd -D
622
- chef-client root 27616 0.2 1.2 26292 22128 ? Sl Jun21 6:00 /opt/opscode/embedded/bin/ruby /usr/bin/chef-client -d -P /var/run/chef/client.pid -L /var/log/chef/client.log -c /etc/chef/client.rb -i 1800 -s 20
623
- timezone root 28244 0.0 0.0 2724 1568 ? Ss Jun21 0:00 /sbin/init
624
- timezone root 28355 0.0 0.0 2368 600 ? S Jun21 0:00 upstart-udev-bridge --daemon
625
- timezone syslog 28356 0.0 0.0 27296 1268 ? Sl Jun21 0:00 rsyslogd -c4
626
- timezone root 28366 0.0 0.0 2236 504 ? S<s Jun21 0:00 udevd --daemon
627
- timezone root 28385 0.0 0.0 1840 556 pts/14 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty4
628
- timezone root 28388 0.0 0.0 1840 560 pts/12 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty2
629
- timezone root 28390 0.0 0.0 1840 556 pts/13 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty3
630
- timezone root 28397 0.0 0.0 2428 812 ? Ss Jun21 0:00 cron
631
- timezone root 28423 0.0 0.0 1840 564 pts/11 Ss+ Jun21 0:00 /sbin/getty -8 38400 tty1
632
- timezone root 28426 0.0 0.0 1840 560 pts/15 Ss+ Jun21 0:00 /sbin/getty -8 38400 /dev/console
633
- timezone root 28449 0.0 0.0 2288 576 ? Ss Jun21 0:00 dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0
634
- timezone root 28466 0.0 0.1 5600 2124 ? Ss Jun21 0:00 /usr/sbin/sshd -D
635
- sudo root 32737 0.0 0.0 2720 1580 ? Ss Jun21 0:00 /sbin/init
636
- users root 32741 0.0 0.0 2232 280 ? S< Jun21 0:00 udevd --daemon
637
- users root 32742 0.0 0.0 2232 280 ? S< Jun21 0:00 udevd --daemon
638
- chef-client root 32745 0.0 0.0 2232 280 ? S< Jun21 0:00 udevd --daemon
639
- chef-client root 32747 0.0 0.0 2232 280 ? S< Jun21 0:00 udevd --daemon
640
- timezone root 32754 0.0 0.0 2232 272 ? S< Jun21 0:00 udevd --daemon
641
- timezone root 32755 0.0 0.0 2232 272 ? S< Jun21 0:00 udevd --daemon
642
-
643
- ### Example Test Run
644
-
645
- Here is an example of using Cucumber-Chef to do a basic test. In this test we will provision a server called `devopserver` and apply the `chef-client::service` recipe from the `chef-client` community cookbook. This example assumes you have your test lab provisioned and up and running. First things first, make sure you've downloaded the `chef-client` community cookbook and placed it in your chef-repo.
646
-
647
- Now upload the `chef-client` community cookbook to your Cucumber-Chef test lab.
648
-
649
- $ cc-knife cookbook upload chef-client
650
- Uploading chef-client [1.1.2]
651
- Uploaded 1 cookbook.
652
-
653
- Next create your `devopserver` feature.
654
-
655
- $ cucumber-chef create devopserver
656
-
657
- Here is the feature we'll be using. This feature has some extra scenarios to illustrate how you might go about testing other parts of a system. Go into the features directory of your chef-repo and replace the contents of the `devopserver.feature` file with the text below.
658
-
659
- @devopserver @wip
660
- Feature: Perform test driven infrastructure with Cucumber-Chef
661
- In order to learn how to develop test driven infrastructure
662
- As an infrastructure developer
663
- I want to better understand how to use Cucumber-Chef
664
-
665
- Background:
666
- * I have a server called "devopserver"
667
- * "devopserver" is running "ubuntu" "lucid"
668
- * "devopserver" has been provisioned
669
- * the "chef-client::service" recipe has been added to the "devopserver" run list
670
- * the chef-client has been run on "devopserver"
671
- * I ssh to "devopserver" with the following credentials:
672
- | username | keyfile |
673
- | root | ../.ssh/id_rsa |
674
-
675
- Scenario: Can connect to the provisioned server via SSH password authentication
676
- And I run "hostname"
677
- Then I should see "devopserver" in the output
678
-
679
- Scenario: Default root shell is bash
680
- And I run "echo $SHELL"
681
- Then I should see "bash" in the output
682
-
683
- Scenario: Default gateway and resolver are using Cucumber-Chef Test Lab
684
- And I run "route -n | grep 'UG'"
685
- Then I should see "192.168.255.254" in the output
686
- And I run "cat /etc/resolv.conf"
687
- Then I should see "192.168.255.254" in the output
688
- And I should see "8.8.8.8" in the output
689
- And I should see "8.8.4.4" in the output
690
-
691
- Scenario: Primary interface is configured with my IP address and MAC address
692
- And I run "ifconfig eth0"
693
- Then I should see the "IP" of "devopserver" in the output
694
- And I should see the "MAC" of "devopserver" in the output
695
-
696
- Scenario: Local interface is not configured with my IP address or MAC address
697
- And I run "ifconfig lo"
698
- Then I should see "127.0.0.1" in the output
699
- And I should not see the "IP" of "devopserver" in the output
700
- And I should not see the "MAC" of "devopserver" in the output
701
-
702
- Scenario: Chef-Client is running as a daemon
703
- When I run "ps aux | grep [c]hef-client"
704
- Then I should see "chef-client" in the output
705
- And I should see "-d" in the output
706
- And I should see "-i 1800" in the output
707
- And I should see "-s 20" in the output
708
-
709
- Now we're going to execute the test. Created features are pre tagged with the name of the feature (i.e. `@<name>`) and `@wip`. Be sure to pass that to the test runner so Cucumber knows to only run tests tagged with that, unless you want to test all your features.
710
-
711
- $ cucumber --tags @devopserver
712
- Using features directory: /home/couldbeyou/chef-repo/features
713
- Cucumber-Chef Test Runner Initalized!
714
- Cleaning up any previous test runs...done.
715
- Uploading files required for this test run...done.
716
- Executing Cucumber-Chef Test Runner
717
- Using the default profile...
718
- Code:
719
- * ./support/env.rb
720
- * ./devopserver/step_definitions/devopserver_steps.rb
721
- * ./sample/step_definitions/sample_steps.rb
722
-
723
- Features:
724
- * ./devopserver/devopserver.feature
725
- Parsing feature files took 0m0.076s
726
-
727
- @devopserver @wip
728
- Feature: Perform test driven infrastructure with Cucumber-Chef
729
- In order to learn how to develop test driven infrastructure
730
- As an infrastructure developer
731
- I want to better understand how to use Cucumber-Chef
732
-
733
- Background: # ./devopserver/devopserver.feature:7
734
- * all servers are being destroyed
735
- * I have a server called "devopserver" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/provision_steps.rb:1
736
- * "devopserver" is running "ubuntu" "lucid" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/provision_steps.rb:5
737
- * devopserver is being provisioned
738
- * "devopserver" has been provisioned # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/provision_steps.rb:25
739
- * the "chef-client::service" recipe has been added to the "devopserver" run list # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/provision_steps.rb:33
740
- * the chef-client has been run on "devopserver" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/provision_steps.rb:37
741
- * I ssh to "devopserver" with the following credentials: # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:57
742
- | username | keyfile |
743
- | root | ../.ssh/id_rsa |
744
-
745
- Scenario: Can connect to the provisioned server via SSH password authentication # ./devopserver/devopserver.feature:17
746
- And I run "hostname" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:77
747
- Then I should see "devopserver" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
748
-
749
- Scenario: Default root shell is bash # ./devopserver/devopserver.feature:21
750
- And I run "echo $SHELL" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:77
751
- Then I should see "bash" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
752
-
753
- Scenario: Default gateway and resolver are using Cucumber-Chef Test Lab # ./devopserver/devopserver.feature:25
754
- And I run "route -n | grep 'UG'" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:77
755
- Then I should see "192.168.255.254" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
756
- And I run "cat /etc/resolv.conf" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:77
757
- Then I should see "192.168.255.254" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
758
- And I should see "8.8.8.8" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
759
- And I should see "8.8.4.4" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
760
-
761
- Scenario: Primary interface is configured with my IP address and MAC address # ./devopserver/devopserver.feature:33
762
- And I run "ifconfig eth0" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:77
763
- Then I should see the "IP" of "devopserver" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:90
764
- And I should see the "MAC" of "devopserver" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:90
765
-
766
- Scenario: Local interface is not configured with my IP address or MAC address # ./devopserver/devopserver.feature:38
767
- And I run "ifconfig lo" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:77
768
- Then I should see "127.0.0.1" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
769
- And I should not see the "IP" of "devopserver" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:90
770
- And I should not see the "MAC" of "devopserver" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:90
771
-
772
- Scenario: Chef-Client is running as a daemon # ./devopserver/devopserver.feature:44
773
- When I run "ps aux | grep [c]hef-client" # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:77
774
- Then I should see "chef-client" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
775
- And I should see "-d" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
776
- And I should see "-i 1800" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
777
- And I should see "-s 20" in the output # cucumber-chef-2.0.0.rc1/lib/cucumber/chef/steps/ssh_steps.rb:81
778
-
779
- 6 scenarios (6 passed)
780
- 58 steps (58 passed)
781
- 2m45.515s
782
-
783
- If all goes well you should see output similar to what's above! Enjoy and have fun!
784
311
 
785
312
  # RESOURCES
786
313
 
@@ -794,19 +321,23 @@ Issues:
794
321
 
795
322
  Wiki:
796
323
 
797
- * https://github.com/Atalanta/cucumber-chef/wiki
324
+ * https://github.com/Atalanta/cucumber-chef/blob/master/WIKI.md
325
+
326
+ Forums:
327
+
328
+ * https://groups.google.com/d/forum/cucumber-chef
798
329
 
799
330
  Chat:
800
331
 
801
- * #cucumber-chef on irc.freenode.net
332
+ * #cucumber-chef @ irc.freenode.net
802
333
 
803
334
  # LICENSE
804
335
 
805
336
  Cucumber-Chef - A test driven infrastructure system
806
337
 
807
338
  * Author: Stephen Nelson-Smith <stephen@atalanta-systems.com>
808
- * Author: Zachary Patten <zachary@jovelabs.com>
809
- * Copyright: Copyright (c) 2011-2012 Atalanta Systems Ltd
339
+ * Author: Zachary Patten <zachary@jovelabs.com> [![endorse](http://api.coderwall.com/zpatten/endorsecount.png)](http://coderwall.com/zpatten)
340
+ * Copyright: Copyright (c) 2011-2013 Atalanta Systems Ltd
810
341
  * License: Apache License, Version 2.0
811
342
 
812
343
  Licensed under the Apache License, Version 2.0 (the "License");
@@ -820,3 +351,4 @@ distributed under the License is distributed on an "AS IS" BASIS,
820
351
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
821
352
  See the License for the specific language governing permissions and
822
353
  limitations under the License.
354
+