Bootstrapping and Secrets Management: solving the chef-vault chicken/egg problem with chef-metal

Intro

Automating server creation with Chef can be very satisfying when it works well. It saves time and avoids the need for tedious and repetitive tasks. Distribution of secrets to servers created this way has always been a hassle for me (or insecure, if laziness gets the best of me). Chef-vault does some fancy things with encrypted data bags and the public/private key system used by chef. When an item is updated in the vault, it encrypts the data for clients using their public keys from chef, allowing those clients to decrypt it with their private keys. The problem with this is, the client needs to exist before the vault is updated, but you also want the client to access things in the vault while it is running its initial run list. In this post I'll cover how I'm currently solving this problem with chef-metal and chef-vault. For those unfamiliar, chef-metal allows you to create machines, clusters, full stacks, or whatever, using the same type of code you are already familiar with in configuring machines.

Too long; not going to read

A single chef-metal recipe does the following

1. creates an instance with a role and empty run list
2. chef-vault is updated using said role
3. instance gets a new run list

Disclaimer

My knowledge of ruby is pretty limited, and this whole method seems a little convoluted. I'm hoping someone will come along and show me a better way.

Tutorial

First, to get chef-metal to interact with your virtualization provider of choice, you need to set a driver. This can be done in knife.rb as follows:

...
driver 'fog:AWS:example'
...

I'm using AWS, so I also have a file ~/.aws/config with profiles for different accounts. In this case, I've specified the 'example' profile

...
[profile example]
aws_access_key_id=ABC
aws_secret_access_key=123
region=us-west-2
availability_zone=us-west-2b

chef-vault also needs to know whether it should act in 'client' or 'solo' mode. Put something like this in your knife.rb as well (replacing values as needed)

...
knife[:vault_mode] = "client"
knife[:vault_admins] = [ "reese" ]
...

Now we need a recipe that bootstraps a machine, updates the vault, and then adds the application to the machine's run list once it can access items in the vault.

#secrets/recipes/metal.rb

%w{chef-metal chef-metal-fog fog}.each do |pkg|
    chef_gem "#{pkg}" do
        action :install
    end
end
require 'chef_metal_fog'
#require "cheffish"

#specify where the chef server is
with_chef_server 'https://chef.example.com',
    :client_name => 'reese',
    :signing_key_filename => '~/.chef/reese.pem'


#create a key pair for the default admin user (ec2-user in this case)
fog_key_pair "admin"

#put options in a variable for easier overriding for different environments
options = {
    :sudo => true,
    :ssh_username => 'ec2-user',
    :sudo => true,
    :bootstrap_options => {
        :key_name => 'admin',
        :availability_zone => 'us-west-2b',
        :security_group_ids => %w(sg-12345678), 
        :subnet_id => 'subnet-abcdef12', 
        :flavor_id => 't2.micro',
        :image_id => 'ami-d13845e1', #amazon linux ami, us-west t2.micro
        :virtualization_type => 'hvm' #required for t2.micro
    }
}

with_machine_options options

machine "lego-app-dev" do
    chef_environment "development"
    role 'keyholder-bootstrap'
    role 'lego-app-bootstrap'
    action [:converge]
end

def deep_clone(o)
    Marshal.load(Marshal.dump(o))
end

production_options = deep_clone(options) #someone good at ruby, tell me there's a better way
production_options[:bootstrap_options][:flavor_id] = "m3.medium"
production_options[:bootstrap_options][:image_id] = "ami-d13845e1"

machine "lego-app1" do
    machine_options production_options
    chef_environment "production"
    role 'lego-app-bootstrap'
    action [:converge]
end

include_recipe "secrets::update-vault"

machine "lego-app-dev" do
    role 'keyholder-bootstrap' #is this needed? or does it remain from before?
    role 'keyholder'
    role 'lego-app-bootstrap'
    role 'lego-app'
    converge true
end

machine "lego-app1" do
    role 'lego-app-bootstrap'
    role 'lego-app'
    converge true
end

Check out the documentation to see more driver/machine configuration options

I want to deliver sensitive data only to the clients which need it, so I have an empty 'bootstrap' role to go along with each role that accesses a set of secrets. These non-empty roles (e.g. 'keyholder') trivially run a single recipe with a name similar to the role. In this case, the role 'keyholder' lets emmet and wildstyle log in, while the role 'lego-app' runs the actual application.

The update-vault recipe takes care of making sure each client can access the items it should be able to. This code is probably cringeworthy (but it works, as far as I can tell).

#secrets/recipes/update-vault.rb
chef_gem "chef-vault" do
    action :install
end

secrets_path = "~/.chef/secrets"
vault_name = 'credentials'

#create or update the vault
def update_vault(vault, item, filePath, type, role)
    ruby_block "check_vault_#{vault}_#{item}" do
        block do
            #probably a terrible way to decide whether to create or update the vault
            Chef::Resource::RubyBlock.send(:include, Chef::Mixin::ShellOut)
            #see if item exists in vault
            command = 'knife vault show '+vault+' '+item
            command_out = shell_out(command)
            #check if command resulted in an error
            if command_out.stderr.to_s != ''
                puts "\ncreating vault and/or vault item\n"
                action = "create"
            else
                puts "\nvault exists\n"
                action = "update"
            end
            vault_command = "knife vault #{action} #{vault} #{item} --mode client --#{type} #{filePath} -A 'reese' -S 'role:#{role}' "
            vault_command_out = shell_out(vault_command)
            puts vault_command_out.stdout
        end
    end
end

#for each secret file, add an entry to the vault
secrets = {
    "emmet" => "emmet.pub",
    "wildstyle" => "wildstyle.pub"
}

secrets.each do |secret_name,filename|
    filePath = File.join(secrets_path, filename)
    type = "file"
    role = "keyholder-bootstrap"
    update_vault(vault_name, secret_name, filePath, type, role)
end

vault_name = 'config'

#for each json secrets set, add an entry to the vault
jsonSecrets = {
    "service_config" => "services.json"
}
jsonSecrets.each do |secret_name,filename|
    filePath = File.join(secrets_path, filename)
    type = "json"
    role = "lego-app-bootstrap"
    update_vault(vault_name, secret_name, filePath, type, role)
end

And here's an example services.json:

{
    "password":"spaceship",
    "username":"benny"
}

So since we run update-vault with chef-zero, it runs the knife commands using the local knife client.

The actual 'lego-app' and 'keyholders' recipes run as usual on the machines.

#secrets/recipes/keyholders.rb
#allow use of chef_vault_item resource
include_recipe "chef-vault"

users = %w(emmet wildstyle)
vault = "credentials"

users.each do |username|

    user username do
        action :create
    end

    dir = "/home/#{username}/.ssh"
    directory dir do
        owner username
        group username
        mode 0755
        action :create
    end

    private_key = chef_vault_item(vault, username)
    file File.join(dir,"authorized_keys") do
        content private_key['file-content']
        owner username
        group username
        mode "0600"
        action :create
    end
end

#secrets/recipes/lego-app.rb
include_recipe "chef-vault"

vault = "config"
secret_name = "service_config"
config = chef_vault_item(vault, secret_name)

#these attributes could be used in a template or something
node.set['service']['password'] = config['password']
node.set['service']['username'] = config['username']

#alternatively, do stuff directly with the secrets
username = config['username']
execute "configure_amazing_service" do
    command "echo username=#{username} > /usr/local/etc/service.conf"
end

To run the recipe, use chef-zero and run the following command

chef-client -z -o secrets::metal

The 'metal' recipe should create 2 servers with empty run lists, one micro for development and one medium for production. From there, it will update the vaults, allowing the two new machines to access items if they are in the right role. Finally, it will apply the roles with the run lists to create the users and install/configure the application.
Let me know if I missed anything important or can do things a better way.

Inspiration/Credits

The method used here was inspired by the orchestration scenario presented on this page and by this tweet conversation which I didn't fully understand.

Using the ServiceManager as an Inversion of Control Container (Part 2)

In Part 1, we learned how to inject a single, shared dependency into the controller using the ServiceManager as an inversion of control container, but what if you need multiple instances of a class? For example, what if you needed multiple Brick objects to build that Building? Here is the Brick class:

<?php
#module/Building/src/Building/Model/Brick.php
namespace Building\Model;

class Brick
{
    protected $_color;
    protected $_randomColors = array("red", "brown", "black", "yellow",
        "orange", "purple", "green");

    public function __construct($color)
    {
        $this->_color = ($color===null)?"default":$color;
    }

    public function setColor($color)
    {
        $this->_color = $color;
    }

    public function getColor()
    {
        return $this->_color;
    }

    public function getRandomColor()
    {
        return $this->_randomColors[array_rand($this->_randomColors)];
    }
}

Now the Building model needs to be able to get multiple unique instances of Brick. To accomplish this, we'll need a basic understanding closures and capturing state. If we follow the same pattern as before, and add Brick as a dependency in Building, we will only have access to a single instance of Brick. Additionally, we will be unable to provide any runtime dependencies, such as the $color parameter in Brick's construction.

<?php
#module/Building/src/Building/Model/Building.php (wrong)
namespace Building\Model;

class Building
{
    protected $_brick;

    public function __construct($brick)
    {
        $this->_brick = $brick;
    }

    public function getBrick()
    {
        return $this->_brick;
    }

In order to have multiple Bricks instantiated from within Building, we'll need to pass in the ability for Building to do so on its own. This can be done by passing in a BrickFactory. The factory is another closure, so we will have a closure within a closure. Notice that the runtime parameter $color is able to be passed in for the Brick construction

    #module/Building/Module.php excerpt
    public function getServiceConfig()
    {
        return array(
            'factories'=>array(
                'BrickFactory'=>function($sm)
                {
                    $factory = function ($color=null)
                    {
                        $brick = new Model\Brick($color);
                        return $brick;
                    };
                    return $factory;
                },
                //...

The $factory in this BrickFactory service doesn't need access to the ServiceManager in this example, but to imagine the Brick class having a BrickMapper dependency. If you are following along, don't copy this into your code.

    #module/Building/Module.php excerpt (aside)
    public function getServiceConfig()
    {
        return array(
            'factories'=>array(
                'BrickFactory'=>function($sm)
                {
                    $factory = function ($color=null) use ($sm)
                    {
                        $mapper = $sm->get('BrickMapper');
                        $brick = new Model\Brick($mapper, $color);
                        return $brick;
                    };
                    return $factory;
                },
                'BrickMapper'=>function($sm)
                {
                    $factory = $sm->get('BrickFactory');
                    $mapper = new Model\BrickMapper($factory);
                    return $mapper;
                },
                'Brick'=>function($sm)
                {
                    $factory = $sm->get('BrickFactory');
                    $model = $factory->__invoke();
                    return $model;
                },
                //...

Luckily, doing it this way does not create circular dependencies, even though the mapper uses the factory, and the factory uses the mapper. Notice also that if we needed a single Brick model in some other class, we can create a brick for the ServiceManager using the BrickFactory, albeit without runtime construction parameters.

The use keyword is what captures the ServiceManager for use later, when the factory is invoked. Without it, the factory would be unable to create the BrickMapper, because the scope of the closure is limited to itself.
Anyway, back to creating Bricks. We can now modify the Building class to use the BrickFactory to create new Bricks. The factory closure needs be called, or 'invoked'. This can be done with either $factory() or $factory->__invoke(). I prefer the latter, as it is slightly less mysterious what is going on. The parameters inside the parenthesis are passed to the $factory closure.

    #module/Building/src/Building/Model/Building.php excerpt

    public function __construct($brickFactory)
    {
        $this->_brickFactory = $brickFactory;
    }

    public function getNewBrick($color=null)
    {
        $factory = $this->_brickFactory;
        $brick = $factory->__invoke($color);
        return $brick;
    }

    public function addLayer($color=null)
    {
        $layer = array();
        for ($i=1; $i<=6; $i++)
        {
            $brick = $this->getNewBrick();
            if ($color === null)
            {
                //constructed with the default color and then initialized
                $brick = $this->getNewBrick();
                $brick->setColor($brick->getRandomColor());
            }
            else
            {
                //constructed fully initialized with runtime 
                //  parameter (usually preferred)
                $brick = $this->getNewBrick($color);
            }
            $layer[] = $brick;
        }
        $this->_bricks[]=$layer;
    }

What we've just done can be difficult to comprehend if closures are new to you. They are a tricky concept, but once understood, can be used to create such elegant code. Leave me a comment if this needs elaboration. For now, we are done with the conceptual stuff. Continue reading to get everything running.
Next, we need to configure and inject this dependency. While we're here, lets do the same thing for the ViewModel that the controller needs.

    #module/Building/Module.php excerpt
    public function getServiceConfig()
    {
        return array(
            'factories'=>array(
                //...
                'Building'=>function($sm)
                {
                    $factory = $sm->get('BrickFactory');
                    $building = new Model\Building($factory);
                    return $building;
                },
                'ViewFactory'=>function($sm)
                {
                    $factory = function($variables=null, $options=null)
                    {
                        $viewModel = new \Zend\View\Model\ViewModel($variables,
                            $options);
                        return $viewModel;
                    };
                    return $factory;
                },
                //...

And finally, add those dependencies to the constructors in their respective classes

    #module/Building/Module.php excerpt
    public function getControllerConfig()
    {
        return array('factories' => array(
            'Building\Controller\Building' => function ($sm)
            {
                $building = $sm->getServiceLocator()->get('Building');
                $viewFactory = $sm->getServiceLocator()->get('ViewFactory');
                $controller = new Controller\BuildingController(
                    $building, $viewFactory);
                return $controller;
            }
        ));
    }

    #module/Building/src/Building/Controller/BuildingController.php excerpt
    public function getViewModel($variables = null, $options = null)
    {
        return $this->_viewFactory->__invoke($variables, $options);
    }

    public function indexAction()
    {
        $building = $this->getBuilding();
        $building->addLayer('blue');
        $building->addLayer();
        $building2 = $this->getBuilding(); //gets same instance
        $building2->addLayer('green');
        $building2->addLayer();
        $viewModel = $this->getViewModel(array('building'=>$building));
        return $viewModel;
    }

<?php
#module/Building/src/Building/Model/Building.php
namespace Building\Model;

class Building
{
    protected $_brickFactory;
    protected $_bricks;

    public function __construct($brickFactory)
    {
        $this->_brickFactory = $brickFactory;
    }

    public function getNewBrick($color=null)
    {
        $factory = $this->_brickFactory;
        $brick = $factory->__invoke($color);
        return $brick;
    }

    public function addLayer($color=null)
    {
        $layer = array();
        for ($i=1; $i<=6; $i++)
        {
            $brick = $this->getNewBrick();
            if ($color === null)
            {
                $brick->setColor($brick->getRandomColor());
            }
            else
            {
                $brick->setColor($color);
            }
            $layer[] = $brick;
        }
        $this->_bricks[]=$layer;
    }

    public function getBricks()
    {
        return $this->_bricks;
    }

}

<?php #module/Building/view/building/building/index.pthml ?>
<table >
<?php
foreach ($this->building->getBricks() as $key=>$layer)
{
    echo '<tr>';
    foreach ($layer as $brick)
    {
        echo '<td style="text-align:center; border:1px solid black; '.
            'background-color:' . $brick->getColor() . '">';
        echo $brick->getColor();
        //echo spl_object_hash($brick);
        echo '</td>';
    }
    echo '</tr>';
}
?>

Now you can go to http://localhost/building to see that everything works as expected. You should see 4 layers: a green, a blue, and 2 with random colored bricks. Go to https://github.com/rwilson04/zf2-dependency-injection/tree/part2 for complete code.
For production, you might want to convert the closures in the 'factories' key to classes, as suggested in this article.
I'm still trying to figure out how to include initializers, and have them work on the objects created by the closures. If you have a solution, let me know.
Another thing to consider would be type-hinting. For anything that is swappable, you would define an interface and add that to the method definitions. For other types, I'm not sure yet whether including type-hinting is the right way to go.
Thanks for reading. I hope this helped. Leave me a comment, especially if there is something missing or something that needs clarification.

Using the ServiceManager as an Inversion of Control Container (Part 1)

Intro:

In Zend Framework 1, it was difficult to follow best practices when it came to writing testable code. Sure, you could make testable models, but once you need those models in a controller, what do you do? Zend Framework 2 makes it much easier. In this post, I'll cover the basics of injecting a model into a controller.

Motivation:

The main goal here is to be able to wire up and configure your application from the highest level possible. Constructor injection + inversion of control makes it easy to determine which classes are dependent on other classes, and swapping classes with mocks or stubs is a breeze.

Prerequisites:

• Basic understanding of what we are trying to accomplish, namely, dependency injection using the ServiceManager as an inversion of control container
• Looked through/tested ZF2's Skeleton Application and Getting Started guide.
• Cursory knowledge of closures/callbacks

Begin by creating a new Buildingmodule, with its directory structure, similar to creating the Album module in the Getting Started guide.

To create objects, first let's take a look at what we are trying to get away from.

    $building = new \Building\Model\Building();

This is bad. At least in a controller, or another model. No more new anything (except maybe Exceptions...), no more hard-coded class names. Dependencies don't belong at this level of the code. Zend Framework 2's ServiceManager allows you to programmatically configure your dependencies. You should already be at least vaguely familiar with higher level dependency configuration from the ZF2 Getting Started guide, as this is how the AlbumController is configured, though it does a lot of stuff behind the scenes.

    $sm = $this->getServiceLocator();
    $building  = $sm->get('Building');

This approach is better, but you still don't want to put this in the controller. You should avoid pulling in classes using the ServiceManager anywhere except factories. Put another way, in general, $sm->get() does not belong in a controller or model, but does belong in Module.php's factories array, which I'll demonstrate further down. A class full of objects created this way has a lot of "soft dependencies", which are difficult to document and keep track of. Instead, to 'inject' a dependency into a class, it should be a parameter in the construction. Let's start by creating the BuildingController with a Building model as a dependency, which we'll learn how to inject shortly. I usually store dependencies as instance variables during construction and access them when needed with 'getters'. In this example, we are still instantiating a new ViewModel from within the controller. We'll fix this in Part 2, where we learn how to use the ServiceManager to create objects with runtime dependencies (such as the $variables parameter in the ViewModel construction)

 
<?php
#module/Building/src/Building/Controller/BuildingController.php
namespace Building\Controller;

use Zend\Mvc\Controller\AbstractActionController;

class BuildingController extends AbstractActionController
{
    protected $_building;

    public function __construct($building)
    {
        $this->_building = $building;
    }

    protected function _getBuilding()
    {
        return $this->_building;
    }
    protected function _getViewModel($variables=null)
    {
        #we'll fix this later
        return new \Zend\View\Model\ViewModel($variables);
    }
    public function indexAction()
    {
        $building = $this->_getBuilding();
        $building->addLayer('blue');
        $building->addLayer('red');
        $viewModel = $this->_getViewModel(array('building'=>$building));
        return $viewModel;
    }
}

The Application's ServiceManager is responsible for creating services (the model and controller are both services). Internally, when tasked with creating a service with a particular name, Building\Controller\Building for example, it runs canCreate("Building\Controller\Building"), which checks all of your aggregated config arrays. One of the places it checks by default is the array returned by the method getControllerConfig() in Module.php, if it exists. This is where we can add the factory closure for the model that the controller needs access to.

    #module/Building/Module.php excerpt
    public function getControllerConfig()
    {
        return array('factories' => array(
            'Building\Controller\Building' => function ($sm)
            {
                $building = $sm->getServiceLocator()->get('Building');
                $controller = new Controller\BuildingController(
                    $building, $viewFactory);
                return $controller;
            }
        ));
    }

Creating controllers is actually handled by the ControllerManager, a (sub)subclass of the main ServiceManager, and $usePeeringServiceManagers is set to false, which is why we need $sm->getServiceLocator()->get() here instead of just $sm->get(); it needs to retrieve the main ServiceManager to have access to the rest of the application's services.

In this controller, the constructor triggers the instantiation of the Building model. The model isn't actually created until the controller's constructor runs, since it is not a model being passed in, but a factory. The factory is a closure, a function without a name which can be saved as a variable. The ServiceManager sets services as 'shared' by default, meaning that the first time it is referenced, it calls the closure creating the object, and every time after that it simply returns the already instantiated object.

It is important to note that if the name of controller configuration (in this case Building\Controller\Building) is listed here, it cannot be defined somewhere else as well. For example, if it is in the $config['controllers']['invokables'] section in your module.config.php, the ServiceManager will try to 'invoke' it, that is, construct it with no arguments, and will fail. If you are following along with your code, check if this is the case now, and fix it if necessary. I'll wait.

Let's create the Building model as a simple class with no dependencies for now.

 
<?php
#module/Building/src/Building/Model/Building.php
namespace Building\Model;

class Building
{
    protected $_bricks=array();

    public function addLayer($color)
    {
        $bricks = array($color, $color, $color);
        $this->_bricks[] = $bricks;
    }

    public function getBricks()
    {
        return $this->_bricks;
    }

}

Because there are no dependencies or other required constructor arguments, we can define Building\Model\Building as an invokable in Module.php. The getServiceConfig() method is one of the aggregated configs that the ServiceManager checks to see which services it can create, and you should recognize it from the Getting Started guide.

 
    #module/Building/Module.php excerpt
    public function getServiceConfig()
    {
        return array(
            'invokables'=>array(
                'Building'=>'Building\Model\Building',
            ),
        );
    }

ZF2 provides multiple ways of doing a lot of things. It is possible, for example, to separate the configuration into multiple files, which might be advisable once your wiring starts getting complicated. The factories can be their own classes which implement 'FactoryInterface' instead of closures defined in the config array.

But, we are done for now. Control has now been inverted. We are injecting a dependency (Building) into a controller using the ServiceManager, and all of our wiring and configuration is in one place, Module.php.

If you want to test it out now and get something running, read the rest of this post. Otherwise, check out Part 2 to learn how to inject a dependency where each instance needs to be distinct and have its own configuration, e.g. using a $model->findAll() or similar.

You'll need to create a view

 
<?php
#module/Buidling/view/building/building/index.phtml
?>
<table >
<?php
foreach ($this->building->getBricks() as $key=>$layer)
{
    echo '<tr>';
    foreach ($layer as $brick)
    {
        echo '<td style="text-align:center; border:1px solid black;'.
            ' background-color:' . $brick . ';">';
        echo $brick;
        echo '</td>';
    }
    echo '</tr>';
}
?>
</table>

And then be sure to set up a route to /building so it is accessible.

 
<?php
#module/Building/config/module.config.php

return array(
    'router' => array(
        'routes' => array(
            'building' => array(
                'type'    => 'segment',
                'options' => array(
                    'route'    => '/building[/:action]',
                    'constraints' => array(
                        'action' => '[a-zA-Z][a-zA-Z0-9_-]*',
                    ),
                    'defaults' => array(
                        'controller' => 'Building\Controller\Building',
                        'action'     => 'index',
                    ),
                ),
            ),
        ),
    ),
    'view_manager' => array(
        'template_path_stack' => array(
            'building' => __DIR__ . '/../view',
        ),
    ),
);

Don't forget the getConfig() and getAutoloaderConfig() methods in your Module.php.

    
    #module/Building/Module.php excerpt
    public function getAutoloaderConfig()
    {
        return array(
            'Zend\Loader\ClassMapAutoloader' => array(
                __DIR__ . '/autoload_classmap.php',
            ),
            'Zend\Loader\StandardAutoloader' => array(
                'namespaces' => array(
                    __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
                ),
            ),
        );
    }

    public function getConfig()
    {
        return include __DIR__ . '/config/module.config.php';
    }

Finally, just go to http://localhost/building, and you should see a simple empty page with the layers we added.
Check out https://github.com/rwilson04/zf2-dependency-injection/tree/part1 for the code.

Here's the link to Part 2 again.

Comments are welcome.

Custom Format for Date Validator

The Date validator, when created with no 'format' option, will default to 'yyyy-mm-dd', or as a PHP format string, 'Y-m-d'. If you want to use a custom date format, the Date validator doesn't seem to be quite adequate. It relies on PHP being able to create a valid date with

DateTime::createFromFormat($format, $value)

It will also blindly validate any pure integer inputs, assuming no error is thrown when attempting to create a date with that integer as a timestamp. So, if you want a date to be in the format (mm-dd-yyyy), you would use the format string 'm-d-Y', but there are a lot of invalid dates that will still pass. For example, if someone enters '12-12-99', it will validate. While it is easy for a human to look at that and know that they probably meant 1999, your date parser might not handle it well (what you do with the validated date is up to you). For proper input validation in a case like this, you really need a regex validator (the default format checks against a regex behind the scenes, but not for custom formats).

                'validators'=>array(
                    array(  
                        'name'=>'Date',
                        'break_chain_on_failure'=>true,
                        'options'=>array(
                            'format'=>'m-d-Y',
                            'messages'=>array(
                                'dateFalseFormat'=>'Invalid date format, must be mm-dd-yyy', 
                                'dateInvalidDate'=>'Invalid date, must be mm-dd-yyy'
                            ),
                        ),      
                    ),      
                    array(  
                        'name'=>'Regex',
                        'options'=>array(
                            'messages'=>array('regexNotMatch'=>'Invalid date format, must be mm-dd-yyy'),
                            'pattern'=>'/^\d{1,2}-\d{1,2}-\d{4}$/',
                        ),      
                    ),      
                ),   

This particular regex will work with 1 or 2 digit days and months, because when I parse the date while handling the posted form data, I accept that format as well.
Note that I set a few custom error messages. 'dateInvalidDate' should display when a date like 13-13-1999 is entered, while the other message should show up for anything that doesn't match the specified format. 'break_chain_on_failure' is needed to prevent duplicate errors from displaying when the format is invalid.

(outdated) Using the ServiceManager as an Inversion of Control Container (Part 2)

Note: This post has been superseded. Check out the Part 1 and Part 2. The post you are reading now is outdated, and there is a much better way of doing this, in my opinion. 

Note about superseded posts: The new Part 1's changes mostly involve coding style and use of design patterns. In the outdated Part 2, I attempted to instantiate multiple instances of objects using the AbstractPluginManager. This worked for simple things, but got complicated when one of the non-shared instantiated instances had dependencies. The best I could work out involved creating factory factories, which created the required factories, which then created the model I wanted. Even without dependencies, the AbstractPluginManager method still required creating those extra factory classes for the sole purpose of creating objects, which leads to a plethora of files in bigger applications. Another deficiency of the outdated version is that it still has hard-coded dependencies in the form of type-hinting.

In the Part 1, we learned how to inject a single, shared dependency into the controller using the ServiceManager as an inversion of control container, but what if you need multiple instances of a class? For example, what if you needed multiple Brick objects to build that Building?

<?php
namespace Building\Model;

class Brick
{
    protected $color;

    public function __construct($options = array())
    {
        if (!is_array($options))
        {    
            throw new \DomainException('$options must be an array');
        }    
        $this->color = (empty($options['color']))?"default":$options['color'];
    }

    public function setColor($color)
    {
        $this->color = $color;
    }

    public function getColor()
    {
        return $this->color;
    }
}
~    

That is where the AbstractPluginManager comes in. It extends ServiceManager, but its get() method allows an extra parameter, $options, which allows you to initialize each new instance with a unique configuration. Even though it is simplified and only needs one option, I set up the Brick class to match this pattern, allowing the $options array to be passed in to the constructor. I'll get to the implementation of the AbstractPluginManager after a little more setup.

Lets add a BrickFactory class as a dependency for our Building. Adding a little functionality for actually doing something with the Bricks, Building now looks like this:

<?php
namespace Building\Model;

class Building
{
    protected $brickFactory;
    protected $bricks;
    protected $colors = array("red", "brown", "black", "yellow", "orange", "purple", "green");

    public function __construct(BrickFactory $brickFactory)
    {
        $this->brickFactory = $brickFactory;
    }

    public function getNewBrick($color)
    {
        $factory = $this->brickFactory;
        $brick = $factory->get('Brick', array('color'=>$color));
        return $brick;
    }

    public function addLayer($color=null)
    {
        $layer = array();
        for ($i=0; $i<6; $i++)
        {    
            $newBrickColor = ($color === null)?$this->colors[array_rand($this->colors)]:$color;
            $brick = $this->getNewBrick($newBrickColor);
            $layer[] = $brick;
        }    
        $this->bricks[]=$layer;
    }

    public function getBricks()
    {
        return $this->bricks;
    }

}

With the new constructor, you can no longer instantiate a Building without a BrickFactory, so it can no longer be an invokable in the serviceConfig. We also need to specify how to create a BrickFactory. Update Module.php's getServiceConfig() method to look like this:

    public function getServiceConfig()
    {
        return array(
            'factories'=>array(
                'ViewFactory'=>function($sm)
                {    
                    $viewFactory = new Model\ViewFactory();
                    $viewFactory->setInvokableClass('ViewModel', 'Zend\View\Model\ViewModel');
                    return $viewFactory;
                },  
                'BrickFactory'=>function($sm)
                {    
                    $brickFactory = new Model\BrickFactory();
                    $brickFactory->setInvokableClass('Brick', 'Building\Model\Brick', false);
                   return $brickFactory;
                },  
                'Building'=>function($sm)
                {    
                    $pluginManager = $sm->get('BrickFactory');
                    $building = new Model\Building($pluginManager);
                    return $building;
                },  
            ),  
        );  
    }

Notice that we also added a ViewFactory so that the ViewModel is not a hard dependency in the controller. Isn't it convenient that the ViewModel fits into this pattern, as an invokable with an optional array constructor parameter?
The difference between these two factories is that ViewModel will be shared, meaning every time you call $factory->get('ViewModel') it will return the same instance, while Brick will return a brand new instance every time. The third parameter in the setInvokableClass function sets whether the class is shared, and defaults to true.
You might see examples in the ZF2 source where invokeableClasses is set directly in the class implementing abstractPluginManager, like the following:

$protected invokableClasses = array('db', 'firephp');

I'd recommend using the setter, as I did in Module.php, as it takes care of canonicalization of the name, and you can use the same name format that you use everywhere else (e.g. 'ViewModel' instead of 'viewmodel').

So what is this BrickFactory? It is simply a class to create new Bricks. The key to having it work is the fact that AbstractPluginManager extends ServiceManager, which means it can have its own invokable classes and factories.This means that when we ask it for a Brick, it sees it as an invokable class and instantiates it (since we specified it as invokable in the closure), including the $options array in the constructor if it was specified. The implementation is as simple as this:

<?php
namespace Building\Model;

use Zend\ServiceManager\AbstractPluginManager;

class BrickFactory extends AbstractPluginManager
{
    public function validatePlugin($plugin)
    {
        if ($plugin instanceof Brick)  
        {    
            return;
        }    
        throw new \DomainException('Invalid Brick Implementation');
    }

}

The only function we are required to implement is validatePlugin, which checks to see if it is the correct type, and any other checking you need to do.
The ViewFactory is nearly identical:

<?php
namespace Building\Model;

use Zend\ServiceManager\AbstractPluginManager;
use Zend\View\Model\ViewModel;

class ViewFactory extends AbstractPluginManager
{
    public function validatePlugin($plugin)
    { 
        if ($plugin instanceof ViewModel)
        { 
            return;
        } 
        throw new \DomainException('Invalid ViewModel Implementation');
    } 

}

Finally, here is the new BuildingController and the new index.phtml

<?php

namespace Building\Controller;

use Zend\Mvc\Controller\AbstractActionController;
use Building\Model\Building;
use Building\Model\ViewFactory;

class BuildingController extends AbstractActionController
{
    protected $building;
    protected $viewFactory;
 

    public function __construct(Building $building, ViewFactory $viewFactory)
    {
        $this->building = $building;
        $this->viewFactory = $viewFactory;
    }

    public function getBuilding()
    {
        return $this->building;
    }

    public function getViewFactory()
    {
        return $this->viewFactory;
    }

    public function indexAction()
    {
        $building = $this->getBuilding();
        $building->addLayer('blue');
        $building->addLayer();
        $building2 = $this->getBuilding(); //gets same instance
        $building2->addLayer('green');
        $building2->addLayer();
        $viewModel = $this->getViewFactory()->get('ViewModel', array('building'=>$building));
        return $viewModel;
    }
} 

<?php
foreach ($this->building->getBricks() as $key=>$layer)
{
    echo '<tr>';
    foreach ($layer as $brick)
    {
        echo '<td style="text-align:center; border:1px solid black">';
        echo $brick->getColor();
        echo '</td>';
    }
    echo '</tr>';
}
?>

And update the getControllerConfig method to accomodate the new constructor (adding the viewFactory)

    #Module.php
    public function getControllerConfig()
    {
        return array('factories' => array(
            'Building\Controller\Building' => function ($sm)
            {
                $building = $sm->getServiceLocator()->get('Building');
                $viewfactory = $sm->getServiceLocator()->get('ViewFactory');
                $controller = new Controller\BuildingController($building, $viewFactory);
                return $controller;
            }
        ));
    }

And we're done. Now you can go to http://localhost/building to see the building that you built. It should have 2 layers with random colors, and 2 layers with fixed colors. Try setting $shared to true in the BrickFactory closure and see what happens.

Hopefully this is enough to get you started writing your applications with injected dependencies using the ServiceManager as an inversion of control container, rather than a service locator. It will save you a lot of trouble in the long run.
You can get the source code used for this project at https://github.com/rwilson04/zf2-dependency-injection

Please leave me some comments, especially if you see something I did wrong, could do better, needs clarification, etc. For example, passing a model into the view? What was I thinking? 

(outdated) Using the ServiceManager as an Inversion of Control Container (Part 1)

Note: This post has been superseded. Check out the Part 1 and Part 2. The post you are reading now is outdated, and there is a much better way of doing this, in my opinion. 

Note about superseded posts: The new Part 1's changes mostly involve coding style and use of design patterns. In the outdated Part 2, I attempted to instantiate multiple instances of objects using the AbstractPluginManager. This worked for simple things, but got complicated when one of the non-shared instantiated instances had dependencies. The best I could work out involved creating factory factories, which created the required factories, which then created the model I wanted. Even without dependencies, the AbstractPluginManager method still required creating those extra factory classes for the sole purpose of creating objects, which leads to a plethora of files in bigger applications. Another deficiency of the outdated version is that it still has hard-coded dependencies in the form of type-hinting.

In Zend Framework 1, it was difficult to follow best practices when it came to writing testable code. Sure, you could make testable models, but once you need those models in a controller, what do you do? Zend Framework 2 makes it much easier. In this post, I'll cover the basics of injecting a model into a controller.

Motivation:

The main goal here is to be able to wire up and configure your application from the highest level possible. Constructor injection + inversion of control makes it easy to determine which classes are dependent on other classes. The Getting Started guide uses the ServiceManager in the Controller to pull in the model, which creates "soft dependencies", so you can't completely tell which classes depend on other ones unless you look at the code on the lower levels. For actual testable/maintainable code, avoid this as much as possible.

Prerequisites:

• Basic understanding of what we are trying to accomplish, namely, dependency injection using the ServiceManager as an inversion of control container
• Looked through/tested ZF2's Skeleton Application and Getting Started guide.
• Cursory knowledge of closures/callbacks

Begin by creating a new Building module, with a structure like the Album module in the Getting Started guide, and a route to /building so it is accessible. For the actual module code, let's start by adding the BuildingController with a Building model as a dependency, which we'll learn how to inject shortly.

<?php
#Building/src/Building/Controller/BuildingController.php
namespace Building\Controller;

use Building\Model\Building;

class BuildingController extends AbstractActionController
{
    protected $building;  

    public function __construct(Building $building)
    { 
        $this->building = $building;
    } 

    public function getBuilding()
    { 
        return $this->building;
    } 

    public function indexAction()
    { 
        $building = $this->getBuilding();
        $building->addLayer('red');
        $viewModel = $this->getViewModel(array('building'=>$building)); #we'll add this function later
        return $viewModel;
    } 
}

Zend Framework 2's ServiceManager allows you to programmatically configure your dependencies. You should already be at least vaguely familiar with this from the ZF2 Getting Started guide. The Application's ServiceManager is responsible for creating services. Internally, when tasked with creating a service with a particular name, "Building\Controller\Building" for example, it runs canCreate("Building\Controller\Building"), which checks all of your aggregated configs. So one of the places it checks by default is the array returned by the method getControllerConfig() in Module.php. This is where we can add the factory closure for the model that the controller needs access to.

    #Module.php
    public function getControllerConfig()
    { 
        return array('factories' => array(
            'Building\Controller\Building' => function ($sm)
            { 
                $building = $sm->getServiceLocator()->get('Building');
                $controller = new Controller\BuildingController($building);
                return $controller;
            } 
        ));
    }  

Creating controllers is actually handled by the ControllerManager, a (sub)subclass of the main ServiceManager, and $usePeeringServiceManagers is set to false, which is why here we need $sm->getServiceLocator()->get() instead of just $sm->get(); it needs to retrieve the main ServiceManager to have access to the rest of the application's services.

It is important to note that if the name of controller configuration (in this case Building\Controller\Building) is listed here, it cannot be defined somewhere else as well. For example, if it is in the $config['controllers']['invokables'] section in your module.config.php, the ServiceManager will try to 'invoke' it, that is, construct it with no arguments, and will fail. Check for this situation now.

Let's create the Building model as a simple class with no dependencies for now.

<?php
#Building/src/Building/Model/Building.php
namespace Building\Model;

class Building
{
    protected $colors = array("red", "brown", "black", "yellow", "orange", "purple", "green");

    public function addLayer($color=null)
    { 
        #add either a random color brick, or the color specified         $newBrickColor = ($color === null)?$this->colors[array_rand($this->colors)]:$color;
        echo "Added $newBrickColor brick";
    }
}

Since there are no dependencies or other required constructor arguments, we can define Building\Model\Building as an invokable in Module.php. The getServiceConfig() method is one of the aggregated configs that the ServiceManager checks to see which services it can create, and you should recognize it from the Getting Started guide.

    #Module.php
    public function getServiceConfig()
    { 
        return array(
            'invokables'=>array(
                'Building'=>'Building\Model\Building',
            ),
        );
    }  

That's it. Control has now been inverted. You are injecting a model into a controller using the ServiceManager, and all of your wiring and configuration is in one place. It is possible to separate the configuration into multiple files, which might be advisable once your wiring starts getting complicated. The factories can be their own classes which implement 'FactoryInterface' instead of closures defined in the config array.

If you want to try it out now, you'll need to replace the line in the controller

$viewModel = $this->getViewModel(array('building'=>$building));

with

$viewModel = new ViewModel(array('building'=>$building));

Then just go to http://localhost/building, and if you set your routing up, it will just be an empty page with the line echo'd in the indexAction. Hint: don't forget the getConfig() and getAutoloaderConfig() methods in your Module.php

Check out Part 2 to learn how to inject a dependency where each instance needs to be distinct and have its own configuration.

Please leave me some comments, especially if you see something I did wrong, could do better, needs clarification, etc.