Writing Chef providers requires interfacing with the underlying OS as well as other software packages. On Windows, this often means being able to call into COM or .NET. While there are a number of ruby gems wrapping different APIs (e.g. rubywmi), there is not a consistent solution that will provide access to any resource a provider may need.
PowerShell is a more natural environment for writing automation scripts on Windows. It also interfaces easily with .NET which allows the implementation of Chef providers to live in .NET assemblies should their implementation be too complex for a simple PowerShell script.
All the PowerShell scripts defining a Chef provider should be contained in a folder under the cookbook
powershell_providers directory. For example, creating an IIS Chef provider exposing a start web site and a stop web site action in PowerShell would involve creating the following file hierarchy (highlighted are directories specific to the PowerShell Chef provider):
`--iis_cookbook |-- metadata.json |-- metadata.rb |-- powershell_providers | `-- iis | |-- _init.ps1 | |-- _load_current_resource.ps1 | |-- start.ps1 | |-- stop.ps1 | `-- _term.ps1 |-- recipes | |-- default.rb | |-- install.rb | |-- restart.rb | |-- start.rb | `-- stop.rb `-- resources `-- iis.rb
In this example, the
restart.rb recipes would use the start and/or stop actions implemented by the corresponding PowerShell scripts.
_term.ps1 are optional scripts that can contain initialization and cleanup code respectively. These two scripts are called once during a single Chef converge and can be used e.g. to load required .NET assemblies in the PowerShell environment used to run the action scripts.
_load_current_resource.ps1 script is also optional. Chef calls this script right before executing an action if it exists. The script should load any state from the system that the provider needs in order to run its actions (in this example this script could check whether the website is currently running so that the start and stop scripts would know whether any action is required on their part).
Note that there should be a lightweight resource defined for each PowerShell provider (in this example
resources\iis.rb). By default, the resource name should match the name of the provider (that is the name of the folder containing the PowerShell scripts). A lightweight resource can specify a different name for its corresponding provider though. See the corresponding Opscode wiki page. So another way to look at PowerShell Chef providers is as a replacement of lightweight Chef providers for Windows.
Be sure to check out our public repository for some working examples of PowerShell scripts: http://github.com/rightscale/cookboo...ter/cookbooks/
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.