Test Kitchen is an integration test framework for, among other things, Chef development. To create its testing environment, it builds on virtualization tools and cloud providers such as Docker, EC2, Rackspace and Vagrant. My own contribution – currently in 0.0.1 release, but undergoing active development – is kitchen-gce, a driver for Google Compute Engine (GCE).
Compared to other cloud providers, for use with Test Kitchen GCE has a couple of advantages, namely:
- (Subjectively) faster instance launch times than other providers; and
- Sub-hour billing.
One brief usage note:
Kitchen-gce uses Fog to interface with GCE. Fog’s GCE provider code has been undergoing development, and until then next releases of Fog and kitchen-gce come out (greater than 1.18.0 and 0.0.1, respectively), I recommend using the development versions of each. For instance, in a Gemfile:
group :integration do gem 'test-kitchen' gem 'kitchen-gce', :git => 'https://github.com/anl/kitchen-gce.git' gem 'fog', :git => 'https://github.com/fog/fog.git', :ref => 'c5e6e2ae868b7fdec8e4fd8ef729fcab3b199b15' end
If you use Test Kitchen, please check out kitchen-gce. Feedback, issues and pull requests welcome.
Acknowledgements: Google has currently given me a free trial plan for GCE, and has, as of this writing, covered about $0.18 of compute time on GCE used in developing kitchen-gce. I spent about $0.55 of my own money before that – sub-hour billing really does make economic sense…
(See bottom of post for an update running similar tests on OpenDNS.)
Methods: I searched Google for keywords that I believed fell somewhere between obscure and common and collected the first ten hostnames printed on the screen. I then used local installations of dig to query a collection of DNS servers for the hostnames’ A records and collected the response times. The different resolvers used were:
- A local BIND installation (127.0.0.1, cache empty) with Comcast Internet connectivity;
- A Comcast DNS server (126.96.36.199) via Comcast Internet connectivity;
- My employer’s internal caching DNS;
- Google (188.8.131.52) via my employer’s Internet connectivity (mostly Level 3);
- Google (184.108.40.206) via Comcast; and
- Google (220.127.116.11) via an Amazon EC2 instance in us-east-1a.
Anticipating a bimodal distribution of results, I assumed high latency responses were cache misses, while low latency responses were cache hits, and categorized results correspondingly.