History

blitzem was created at the end of 2011 following a couple of years' experience with using various cloud providers for development and production infrastructure. We generally controlled our infrastructure via the cloud providers' web consoles or simple API scripting, but wanted a way to reduce the administrative overhead.

blitzem is open source, and released under a BSD Licence (see LICENCE.txt)

Design philosophy

• To allow cloud servers to be managed in an automated, repeatable way, rather than being created ad-hoc via a web console.
• To allow environments to be defined in a simple, declarative configuration file, allowing version control, visibility and shared ownership across teams.
• To allow environments to be managed as a whole, allowing rapid setup/teardown of complete replicas of production for development, testing and experimentation.

Suggested use cases

• If production infrastructure is cloud-based, refer to or copy the same blitzem configuration file for each different environment (prod, pre-prod, test, etc). This allows confidence that the pre-production environments match production. A different cloud account would be used for each tier to provide isolation and avoid naming conflicts.
• When diagnosing a production fault, use blitzem to quickly spin up a replica of production infrastructure.
• Use blitzem to manage continuous integration servers, allowing tear down at the end of each working day, and clean recreation the next morning.
• Tag certain nodes as 'peak' or 'offpeak', and use blitzem on a scheduled job to spin them up/down around busy periods.
• Use dynamic scripting within the blitzem environment file to provide fine-tuning over scaling; e.g. detect load average across a tier and instantiate enough servers to handle the load.
• Keep the blitzem environment file in source control and allow each developer to have their own mini-replica of production. Use dynamic scripting within the environment file to add the developer's username as a prefix to each node/load balancer's name, and to select smaller/fewer nodes.

It is suggested that blitzem always be used in conjunction with a package configuration management tool (e.g. Puppet, Chef, CFEngine) to install packages and detailed configuration files on provisioned nodes.

A load-balanced server environment

1. See examples/load_balanced/environment.groovy. Hover over the '?' symbols for an explanation of each element:

   import org.blitzem.model.*
   import org.blitzem.model.thirdparty.*
   import static org.blitzem.model.Size.*
   
   /* After raising the load balancer and nodes, requests to the load 
    * balancer on port 80 should be randomly distributed across web1 
    * and web2, and the returned index.html page should be the node hostname.
    *
    * To verify, run `blitzem up` and put the public IP address of the
    * load balancer into a web browser.
    */
   
   Defaults.DEFAULTS["osVersion"] = "11.04"
   Defaults.DEFAULTS["provisioning"] = [new ScriptExecution("apt-get update; apt-get install dtach; mkdir web; cd web; hostname > index.html; dtach -n /tmp/simple_http.worker python -m SimpleHTTPServer 8080")]      // ?
   
   
   new LoadBalancer([                      // ?
       name:"web-lb1",
       tags:["web"],                       // ?
       appliesToTag: "web",                // ?
       protocol: "http",
       port: 80,
       nodePort: 8080
       ])
   
   new Node([                              // ?
       name:"web1",
       tags:["web", "peak"],               // ?
       size:ram(512)                       // ?
       ])
   
   new Node([
       name:"web2",
       tags:["web", "peak"],
       size:ram(256)
       ])
   

2. In this environment, we have two server nodes and a single load balancer configured to share load between them. A simple script execution performed after node creation is used to create a basic web server on each node
3. While in the examples/load_balanced folder, execute the command blitzem up
4. blitzem brings up both server nodes followed by the load balancer:
5. Afterwards it displays a summary of the currently active devices:
6. If you visit the load balancer's public IP address and refresh the page, you should see that the traffic has been spread across both server nodes.

Command line syntax

Credentials file syntax

blitzem requires your cloud provider credentials to be stored separately from your environment configuration file. This can be used to enable sensitive credentials to be distributed appropriately, whilst still enabling visibility and reuse of environment configuration across teams. For blitzem to operate, you need to ensure that a file similar to the following is placed at ~/.blitzem/config.properties:

# config.properties template (created for blitzem version 0.3)

# Valid values: cloudservers-uk, aws-ec2
compute-provider=
compute-accesskeyid=
compute-secretkey=

# Valid values: cloudloadbalancers-uk, aws-ec2
loadbalancer-provider=
loadbalancer-accesskeyid=
loadbalancer-secretkey=

# Valid values: rackspace-uk, aws
provider=rackspace-uk

Environment file syntax

The blitzem environment file should be named environment.groovy. It should either be present in the working directory where blitzem is run from, or should be referred to using a command line option: blitzem --source=/some/other/dir/environment.groovy up.

new Os([
  family:  'UBUNTU',
  version: '11.04',
  os64Bit: true
])

blitzem project

Visit the blitzem project on Github or email rich.north+blitzem@gmail.com with any questions or comments.

About the author

The author, Richard North, is an IT Consultant based in London, UK.