README.md in testlab-1.21.1 vs README.md in testlab-1.22.0
- old
+ new
@@ -1,17 +1,11 @@
[](http://badge.fury.io/rb/testlab)
-[](https://gemnasium.com/zpatten/testlab)
+[](https://gemnasium.com/lookout/testlab)
[](http://travis-ci.org/lookout/testlab)
[](https://coveralls.io/r/lookout/testlab)
-[](https://codeclimate.com/github/zpatten/testlab)
+[](https://codeclimate.com/github/lookout/testlab)
-# A Quick Note on Versioning
-
-I attempt to keep TestLab in line with Semantic Versioning when incrementing version numbers. I am human so I may screw this up on, hopefully rare, occasion. Semantic Versioning is delicious and everyone should be following this schema, especially when it comes to Ruby Gems which have a habit of pushing your projects into "dependency hell".
-
-* http://semver.org/
-
# What is TestLab?
Simply put; a toolkit for building virtual computer labs.
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 build and demolish this virtual infrastructure as you have dictated in the `Labfile`.
@@ -63,10 +57,11 @@
When supplying container names you actually have three options. When you do not supply a container name, it is inferred that you want to run the action against all containers. Alternately you can supply a single container name or a comma delimited list of container names. For example:
tl container build # build all containers
tl container build -n chef-client # only build the chef-client container
tl container build -n chef-server,chef-client # build the chef-server and chef-client container (NOTE: list order dictates execution order)
+ tl container build -n \!chef-server # build all containers, except the chef-server container
# Installation
* Install the latest version of VirtualBox: https://www.virtualbox.org/wiki/Downloads
* Install the latest version of Vagrant: http://www.vagrantup.com/downloads.html
@@ -83,10 +78,14 @@
The `Labfile` defines your virtual computer lab. It defines where you want to run your computer lab (i.e. VirtualBox/OpenStack/Bare Metal), what the network topology of that computer lab is and what servers are connect to those networks.
You can override the default `Labfile` by setting the path to your alternate `Labfile` via the environment variable `LABFILE` or via a command line argument (see `tl help` for more details) directly to TestLab.
+For some examples of Labfiles check out:
+
+* https://github.com/zpatten/testlab-repo
+
## Building your Lab
You should build your TestLab node (i.e. VirtualBox VM) and TestLab networks first. This is the foundation which the containers run on. You should attempt to keep your TestLab node intact and only cycle your containers.
**The follow commands assume you have functioning VirtualBox, Vagrant and RVM installations.**
@@ -110,34 +109,77 @@
### Building Containers
You should import containers because it saves a lot of time. Building containers from scratch is a time consuming process. Using shipping container images and ultimately lab images greatly accelerates the speed at which you can move.
-**The follow commands assume you have a functioning TestLab node.**
-
tl container build --force # Force all defined containers to build even if some can be imported
tl container build # Attempts to import all defined containers, building those which can not be imported
tl container build -n chef-client --force # Force the 'chef-client' container to build from scratch even if it can be imported
+ tl container build -n \!chef-server # Build all containers, except the 'chef-server' container
### Importing Containers
You should import containers because it saves a lot of time. Building containers from scratch is a time consuming process. Using shipping container images and ultimately lab images greatly accelerates the speed at which you can move.
-**The follow commands assume you have a functioning TestLab node.**
+ tl container import # Import all defined containers
+ tl container import -n chef-client # Import the 'chef-client' container
+ tl container import -n chef-server,chef-client # Import the 'chef-server' and 'chef-client' container
+ tl container import -n \!chef-server # Import all containers, except the 'chef-server' container
- tl container import # Attempts to import all defined containers
- tl container import -n chef-client # Attempts to only import the 'chef-client' container
- tl container import -n chef-server,chef-client # Attempts to only import the 'chef-server' and 'chef-client' container
-
### Demolishing Containers
You can easily remove all the containers your have defined in your `Labfile` as well as single containers. You should generally demolish your containers instead of destroying them because the demolish action involves decommissioning.
-**The follow commands assume you have a functioning TestLab node with running containers.**
-
tl container demolish # Demolish all defined containers
tl container demolish -n chef-client # Only demolish the 'chef-client' container
tl container demolish -n chef-client,chef-server # Only demolish the 'chef-client' and 'chef-server' containers
+ tl container demolish -n \!chef-server # Demolish all containers, except the 'chef-server' container
+
+### Recycle Containers
+
+You can demolish and build containers all in one motion by recycling them. If a container can be imported, recycle will attempt to do so during the build phase unless the force options is specified.
+
+ tl container recycle # Recycle all defined containers
+ tl container recycle -n chef-client # Only recycle the 'chef-client' container
+ tl container recycle -n chef-client --force # Only recycle the 'chef-client' container and force building; do not import
+ tl container recycle -n chef-client,chef-server # Only recycle the 'chef-client' and 'chef-server' containers
+ tl container recycle -n \!chef-server # Recycle all containers, except the 'chef-server' container
+
+### Bounce Containers
+
+You can easily restart (i.e. bounce) your containers, for example:
+
+ tl container bounce # Bounce all defined containers
+ tl container bounce -n chef-client # Only bounce the 'chef-client' container
+ tl container bounce -n chef-client,chef-server # Only bounce the 'chef-client' and 'chef-server' containers
+ tl container bounce -n \!chef-server # Bounce all containers, except the 'chef-server' container
+
+### Start Containers
+
+You can easily start your containers, for example:
+
+ tl container up # Start all defined containers
+ tl container up -n chef-client # Only start the 'chef-client' container
+ tl container up -n chef-client,chef-server # Only start the 'chef-client' and 'chef-server' containers
+ tl container up -n \!chef-server # Start all containers, except the 'chef-server' container
+
+### Stop Containers
+
+You can easily stop your containers, for example:
+
+ tl container down # Stop all defined containers
+ tl container down -n chef-client # Only stop the 'chef-client' container
+ tl container down -n chef-client,chef-server # Only stop the 'chef-client' and 'chef-server' containers
+ tl container down -n \!chef-server # Stop all containers, except the 'chef-server' container
+
+### Container Status
+
+You can get the status of all, some or a single container, for example (-q silences all of the STDOUT log output):
+
+ tl -q container status # Get status for all defined containers
+ tl -q container status -n chef-client # Get status only for the 'chef-client' container
+ tl -q container status -n chef-client,chef-server # Get status only for the 'chef-client' and 'chef-server' containers
+ tl -q container status -n \!chef-server # Get the status of all containers, except the 'chef-server' container
### Connecting to Containers
**The follow commands assume you have a functioning TestLab node with running containers.**