Blueprint 3.4 is out with two powerful additions: templating and rules.

Template functionality was included in release 3.3 and makes Blueprint a more complete configuration management system. Simple template use enables the substitution of system parameters such as the number of CPU cores, memory, domain names and IP addresses, in config files. More complex cases include iteration over output from a shell command.

Here's a quick example where we configure Unicorn to use four workers per CPU in /etc/unicorn.conf.rb.blueprint-template.mustache:

worker_processes {{`expr 4 \* $CORES`}}

Rules were part of 3.4 and are analagous to the blueprintignore concept. Power users will eventually want to pay specific attention to, instead of ignore, a set of resources. blueprint-rules solves that problem.

Check out what we include example.blueprint-rules:

:source:/usr/local
 /etc/init/example.conf
 /etc/nginx/sites-*/example
 :package:apt/libmysqlclient-dev
 :package:apt/mysql-client-5.1
 :package:apt/nginx-common
 :package:apt/nginx-light
 :package:apt/ruby-dev
 :package:apt/rubygems
 :package:rubygems/*
 :service:sysvinit/nginx
 :service:upstart/example

Now create the blueprint example using rules and it will only include those resources:

blueprint rules example.blueprint-rules

Lastly, we've revamped Blueprint's documentation and think you'll find it easier to get answers fast. We hope you enjoy this release and the progress we're making on the project. As always, we're here for any questions or suggestions. Enjoy!

Blueprint 3.2.0 is out and comes with two new commands and two new arguments.

First, hot on the heels of our announcement that blueprints work directly with AWS CloudFormation, we've added --cfn to blueprint-create and blueprint-show to generate a complete CloudFormation template from a blueprint.  The template contains all the necessary pieces to create a single EC2 instance running Amazon Linux that'll apply your blueprint at provision time.  From there you can of course add more resources to build out a larger infrastructure with CloudFormation.

Next is the --diff=subtrahend argument to blueprint-create, making it easier to create compact blueprints.  Observe:

blueprint create --diff=base custom

is roughly equivalent to

blueprint create dummy
blueprint diff dummy base custom
blueprint destroy dummy

but doesn't actually save dummy to disk.  The practice of creating base system blueprints and compact customizations on top of that is gaining traction and now it's a whole lot easier.

Last are two commands, blueprint-split and blueprint-prune, that make creating modular blueprints (like a base blueprint and a customization) possible without crazy blueprintignore(5) incantations.  blueprint-split interactively creates two blueprints from the resources contained in one source blueprint.  blueprint-prune works much the same way but creates one blueprint from a subset of the resources in a source blueprint.

As always, the full details are on GitHub: https://github.com/devstructure/blueprint/compare/v3.1.0...v3.2.0

If you're not yet using Blueprint, the installation instructions in the README will get you started.

Just last week, Amazon Web Services rolled out the first production release of the Amazon Linux AMI and with it some powerful new features for CloudFormation.  There’s a lot there (like updating stacks and IAM integration) but we at DevStructure are most excited about Application Bootstrapping.

The new Amazon Linux AMI comes with the aws-cfn-bootstrap package, which can unpack tarballs, place configuration files, install packages, and restart services at provision time.  Sound familiar?  That’s right, this new section of the CloudFormation template language uses the blueprint(5) file format!

Amazon’s PDF whitepaper, Bootstrapping Applications via AWS CloudFormation, walks through building a complete stack template by hand.  To summarize, you’ll need to create an IAM resource and declare your EC2 instances like this:

"Resources": {
  "DemoInstance": {
    "Metadata": {
      "AWS::CloudFormation::Init": {
        "config": THIS IS WHERE THE BLUEPRINT GOES!
      }
    },
    "Properties": {
            "ImageId": {"Fn::FindInMap": [
              "AWSRegionArch2AMI",
              {"Ref": "AWS::Region"},
              {"Fn::FindInMap": [
                "AWSInstanceType2Arch",
                {"Ref": "InstanceType"},
                "Arch"
              ]}
            ]},
      "InstanceType": {"Ref": "InstanceType"},
      "KeyName": {"Ref": "KeyName"},
      "SecurityGroups": [{"Ref": "DemoSecurityGroup"}],
      "UserData" : {"Fn::Base64" : {"Fn::Join" : ["", [
        "#!/bin/sh\n",
        "/opt/aws/bin/cfn-init",
        " -s '", {"Ref" : "AWS::StackName"}, "'",
        " -r 'DemoInstance'",
        " --region '", { "Ref" : "AWS::Region" }, "'",
        " --access-key '", {"Ref": "DemoKey"}, "'",
        " --secret-key '", {"Fn::GetAtt": ["DemoKey", "SecretAccessKey"]}, "'",
        "\n",
        "/opt/aws/bin/cfn-signal",
        " -e $?",
        " '", {"Ref" : "DemoWaitConditionHandle"}, "'",
        "\n"
      ]]}}
    },
    "Type": "AWS::EC2::Instance"
  }
}

The user-data calls cfn-init with the newly-generated IAM credentials to fetch and process the metadata, and cfn-signal to report success or failure via a WaitCondition.

Packages managed by Yum, Python’s easy_install, and RubyGems plus files and services all work natively within CloudFormation.  Source tarballs will work if you upload them someplace and provide the fully-qualified URL.

Going the other direction, the metadata from an existing CloudFormation template can be loaded into Blueprint by copying out the "config" document fragment and passing it on standard input to blueprint-create(1).

Our thanks to the Reto Kramer, Chris Whitaker, and Adam Thomas for making it even easier to deploy blueprints to Amazon EC2.

Today, we’re releasing Blueprint 3.1, which includes a number of fixes and improvements but most importantly, understands all of Amazon’s extensions to the blueprint(5) format, allowing seamless transition to and from AWS CloudFormation.  Get 3.1 from GitHub, DevStructure’s Debian archive, or from PyPI.

Just in time for the Node Knockout, I'm happy to announce preliminary support of Node and npm in the master branch of Blueprint.

For the uninitiated, installing Blueprint is easy:

git clone git://github.com/devstructure/blueprint.git
cd blueprint
make && sudo make install

Creating a blueprint of a server and generating shell code that can be used to configure the production server the same way is likewise easy:

blueprint create -S knockout
# Run knockout.sh in production.

If you're new, check out the Blueprint tutorial while you're getting started.

The details are on the blueprint-users mailing list post but the short version is to use Chris Lea's PPA (node.js or node.js-devel) to install Node itself and everything else will work out just fine.

Happy hacking!

Those of you that are fans of RedHat, CentOS, or Fedora are in for a
treat today: 3.0.8 is all about you.

This release closed only three bugs (one of which it caused along the
way!) but made 1000 additions and 173 deletions and made first run on
RPM-based systems on the order of 1000 times faster.

Compare: https://github.com/devstructure/blueprint/compare/v3.0.7...v3.0.8
Tree: https://github.com/devstructure/blueprint/tree/v3.0.8

Functionally, nothing much has changed, so keep on keeping on.

Big news, the 3.0.7 release of Blueprint now includes the blueprint-push and blueprint-pull commands, previously part of Blueprint I/O.  We decided to roll these commands into the main release for simplicity and exposure. Additionally, this release closed 13 issues and contains 42 commits.  

Highlights include:

• Commands for looking inside blueprints, with an eye towards scriptability: blueprint-show-sources(1), blueprint-show-files(1), blueprint-show-packages(1), blueprint-show-services(1), and blueprint-show-ignore(1).  These make it far easier to understand what's being included in blueprints without having to squint at raw JSON.
• A command for interacting directly with blueprints stored locally in Git: blueprint-git(1).
• Blueprint is now less aggressive about using sudo in blueprint-apply(1) in order to play nicely with non-interactive invocations.  Keep using sudo yourself if that's typically how you gain root access.

Updated packages are on packages.devstructure.com and PyPI.  Let us know if you have any questions. Enjoy!

Cross-posted from the blueprint-users and blueprint-dev mailing lists.

We’re back with Blueprint 3.0.6, featuring 87 commits to master and 13 issues closed since 3.0.5.  Many of those commits are behind-the-scenes, refactoring to lay the groundwork for a more maintainable future.  That doesn’t mean there aren’t some cool features, though.

First up is the much improved support for the various ways people use sudo to gain temporary root access and root shells through -i.  I expect most if not all strange GitError exceptions talking about lack of permissions to be a thing of the past.

Next, ever-smarter defaults for ignoring files to keep your blueprints free of noise: Blueprint won’t bother you about things you didn’t change in /etc/pam.d, about Debian's CD-ROM, or backup files.

blueprint-create, blueprint-show, and blueprint-apply all now support the --relaxed option that generates code without strict version numbers so any version of a package will suffice.  This is particularly helpful (and recommended) for users that don’t mirror their distro’s package archive.

And finally: service resources.  Now Blueprint will track down services that are running plus the files and packages that influence them.  These translate directly to service resources in the generated Puppet and Chef code.  In the generated shell code, changes to any file or package will cause the corresponding services to be restarted at the end.  Now you can use blueprints all by themselves to deploy your environment and application to production.

As always, Matt and I are listening for issues and feature requests, and would love to know how you’re using Blueprint.

• Source: https://github.com/devstructure/blueprint
• Changes: https://github.com/devstructure/blueprint/compare/v3.0.5...v3.0.6

I'm in the thick of moving and it's stressful. Two Men and a Truck makes it easier. True to their name, a couple guys show up, pack all of your stuff in a truck and move it to the new location. Building a server is stressful too. What packages do you need? How should you tweak configuration files? Is everything secure? Is the process documented? The list goes on. We want to make it less stressful for you and demonstrate the power of Blueprint. 

Introducing Two Men and a Server - tell us what you want, be as specific as possible, and we'll build a server for you. We'll package everything up in a Blueprint that you can easily reuse on a new or existing server. Ubuntu, Debian, Fedora or CentOS - your choice. AWS, Rackspace, Linode, Slicehost - anywhere you have root. Rethinking application design, moving providers or starting from scratch - not a problem. Just tell us what you need and we'll build it with Blueprint. Richard and I know servers and are happy to help - no strings attached. Get in touch and we'll get you a server.

Last week we rolled out Blueprint 3.0.4 to bring the speed and a rich new syntax for ignoring files and packages when creating blueprints. Not to rest on our laurels, we released Blueprint 3.0.5 this week which added the ability to tar up arbitrary directories along with your blueprint and a new blueprint-diff(1) command.

Now we're excited to announce something a little different: Blueprint I/O, a way to move your blueprints around.

Blueprint I/O comes with a default Blueprint I/O Server that we're making available free of charge which stores your blueprints in Amazon S3. Use blueprint-push(1) and blueprint-pull(1) to centralize your configuration management and bootstrap new servers painlessly.

Blueprint I/O is open-source and we're very interested in seeing where you take it.

Cross-posting once again from blueprint-users and blueprint-dev (have you joined the list yet?), I'm happy to announce Blueprint 3.0.3, our first release that includes support for RPM-based distros.

Packages managed by Yum/RPM are now first-class citizens just like Debian packages, Ruby gems, Python eggs, and PEAR/PECL packages. In addition, when Blueprint searches /etc for configuration files, it will check the RPM database and ignore files that haven't changed from their packaged version.

What are you waiting for? Install Blueprint from source, our Debian archive, or PyPI now!