GSD Ops...
I recently got around to open sourcing some useful system utilities. Took this as an opportunity to add tests, and get introduced to Opscode’s new test-kitchen.
The following cookbooks work under CentOS, Debian, and Ubuntu in most cases. Will add the remaning rhel platform family once I build Vagrant boxes, or the OpenStack runner is released.
I have become quite a fan of Ohai plugins. My plugins can be found on bitbucket.
Remember to be cautious with the amount of data the plugins generate. For those of you running your own Chef Server, you can easily exhaust solr’s maxFieldLength. This will result in various clients not returning in search results. Have a look at this bug.
Having written a lot of non-infrastructure tests in the past, I have felt a deep desire to write tests for infrastructure provisioning we are working on.
Not being a fan of Cucumber or RSpec, decided to use Rye with MiniTest for assertions.
Below is an example of how to use Rye with MiniTest. The tests are invoked over SSH, and can optionally be run through a “jump host”. The tests are a bit contrived, but verify Chef was installed/configured properly. The tests are easy to understand and update, which is key. Not everyone who builds infrastructure has used Cucumber or test suites, even in this age of DevOps. IMO, this method provides a reasonable way to get up to speed with Ruby and testing, while adding value (tests).
Recently I wanted to create forward and reverse DNS for specific chef nodes. Using the dynect community cookbook, resulted in the following gist.
In a continued attempt to add additional nventory type information about our systems, the following Ohai plugin plugin can be used to collect a system’s LLDP information.
The community page already has such a plugin, but the systems we are using experience odd behavior when running ladvd. Plus who doesn’t want an excuse to write recursive code. :)
Usage is as follows:
Obviously we all love github. I found myself needing a lot of private repositories. I opted to go with bitbucket. I plan to privately prototype in bitbucket for things I am not ready to release, and push to github for official release. Taking advantage of issue tracking, pull request functionality, and the larger community.
A simple Ohai plugin plugin to collect a metal system’s IPMI address. Debian systems require the ‘ipmitool’ package and the following modules loaded.
Usage is as follows:
I am currently automating the deployment and configuration of a moderately complex service architecture. Ohai, currently has no way to discover a systems public (floating) ip address in an OpenStack environment. The ability to discover this information helps with additional automation (eg. Provisioning dns in DynECT).
This Ohai plugin Ohai plugin is a semi-poor attempt at discovering a guest’s public ipaddress.
Update: Sat March 3 2011
Looks like Ohai already attempts to capture this information from the meta-data server. However, this fails due to MAC address not matching. Updated the previously discussed plugin to capture the floating IP from the meta-data server. Also, have it following the same API as the eucalyptus plugin.
Usage is as follows:
I find it useful to easily open a port, to test access controls. Configuring a webserver or iptables to redirect to a known running port is cumbersome. The following has proved useful many times.
$ echo "open port" |nc -l 8080
Verification can be done with telnet or netcat.
$ telnet example.com 8080
Trying example.com...
Connected to example.com.
Escape character is '^]'.
open port
Connection closed by foreign host.
$ nc example.com 8080
open port