README.md in testlab-0.6.5 vs README.md in testlab-0.6.6

- old
+ new

@@ -4,40 +4,16 @@ [![Coverage Status](https://coveralls.io/repos/zpatten/testlab/badge.png?branch=master)](https://coveralls.io/r/zpatten/testlab) [![Code Climate](https://codeclimate.com/github/zpatten/testlab.png)](https://codeclimate.com/github/zpatten/testlab) # TestLab +A toolkit for building virtual computer labs. + What is TestLab? TestLab lets you iterate virtual infrastructure quickly. Using a `Labfile` you can define how you want your virtual infrastructure laid out. You can define multiple network segments and containers (i.e. boxen). TestLab will then setup and teardown this virtual infrastructure as you have dictated in the `Labfile`. 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. -# Using TestLab Programmatically - -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: - - log_file = File.join(Dir.pwd, "testlab.log") - @logger = ZTK::Logger.new(log_file) - @ui = ZTK::UI.new(:logger => @logger) - @testlab = TestLab.new(:ui => @ui) - -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`. - -There are several easy accessors available to grab the first container and execure the command `uptime` on it via and SSH connection: - - container = @testlab.containers.first - container.ssh.exec(%(uptime)) - -We can also execute this command via `lxc-attach`: - - container.lxc.attach(%(-- uptime)) - -You can access all the nodes for example: - - @testlab.nodes - -For more information see the TestLab Documentation, `testlab-repo`, command-line binary and it never hurts to look at the TestLab source itself. - # Using TestLab Interactively The TestLab command-line program `tl` follows in the style of git (using the GLI RubyGem). $ tl help @@ -46,11 +22,11 @@ SYNOPSIS tl [global options] command [command options] [arguments...] VERSION - 0.6.1 + 0.6.5 GLOBAL OPTIONS --version - --help - Show this message @@ -60,28 +36,29 @@ destroy - Destroy the test lab up - Online the test lab down - Offline the test lab setup - Setup the test lab infrastructure teardown - Teardown the test lab infrastructure + build - Build the test lab infrastructure status - Display information on the status of the test lab node - Manage nodes network - Manage networks container - Manage containers You stand up your lab with the following command: - tl setup + tl build You can down the entire lab: tl down You can also destroy it (only works for VM backed providers; this would be a NO-OP on the Local provider for example): tl destroy -# Interacting with Containers +## Interacting with Containers Most commands dealing will containers will take this argument: COMMAND OPTIONS -n, --name=container - Container ID or Name (default: none) @@ -112,11 +89,11 @@ You can recycle a container, effectively destroying then creating it again, provisioning it back to a "pristine" condition. tl container recycle -n server-www-1 -# Ephemeral Container Cloning +## Ephemeral Container Cloning 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. 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. @@ -155,11 +132,11 @@ We can even recycle it while it is in a cloned state: $ tl container recycle -n server-www-1 -# Network Routes +## Network Routes 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`. $ tl network route show -n labnet [TL] TestLab v0.6.1 Loaded @@ -181,17 +158,43 @@ COMMANDS add - Add routes to lab networks del - Delete routes to lab networks show - Show routes to lab networks -# Getting Help +## Getting Help TestLab uses the GLI RubyGem, which gives us a command line pattern similar to that of Git. Therefore help is easy to get: tl help tl help node tl help container tl help network + +# Using TestLab Programmatically + +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: + + log_file = File.join(Dir.pwd, "testlab.log") + @logger = ZTK::Logger.new(log_file) + @ui = ZTK::UI.new(:logger => @logger) + @testlab = TestLab.new(:ui => @ui) + +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`. + +There are several easy accessors available to grab the first container and execure the command `uptime` on it via and SSH connection: + + container = @testlab.containers.first + container.ssh.exec(%(uptime)) + +We can also execute this command via `lxc-attach`: + + container.lxc.attach(%(-- uptime)) + +You can access all the nodes for example: + + @testlab.nodes + +For more information see the TestLab Documentation, `testlab-repo`, command-line binary and it never hurts to look at the TestLab source itself. # REQUIREMENTS * Latest VirtualBox Package * Latest Vagrant Package (non-gem version)