Last week, I hosted a webinar on Puppet and Puppet Enterprise on Windows. During the half-hour-long demo, I covered a number of items, including how to use Puppet Enterprise to manage Windows machines, and how to manage fundamental resources on Windows (in contrast with the same resources on Linux). I also dove deeper into Windows-specific resources, such as the Windows registry module. Attendees asked a lot of questions that I couldn’t get to, so today I’d like to share the following questions and answers with you. Hopefully you find this helpful. If you have any additional questions on Puppet and Windows, please feel to drop them in the comments below.
Please note: This is part I of a two-part series on Puppet and Windows. There’s more to come in the next couple of days.
Q: As a developer, I see the potential of Puppet, but I struggle at times to communicate it to management. One of the questions I often get is: How is Puppet better than SCCM and/or GPO?
A: System Center Configuration Manager (SCCM) brings to the table a Windows-native tool that is well-integrated with its target software and OS, capable of managing configuration from the provisioning step on up. Puppet is limited to the configuration layer only and does not descend as low as provisioning, and it doesn’t come with a Windows-native GUI for setting up policies. What Puppet does differently than SCCM is offer true infrastructure-as-code configuration management.
Puppet doesn’t depend on a database for any part of the configuration management process (a database for storing and searching reports is optional), and everything it consumes and produces can be reduced to flat files. This makes Puppet easily portable, deployable, simple, and node-disposable. For organizations with a hybrid IT infrastructure, Puppet offers a cross-platform management tool that can capture a complete, lightweight, versioned, automation-executable description of all nodes in human-readable plaintext; not just Windows nodes, not just Linux nodes, all of them.
In terms of technical ability, Puppet core types and providers give a solid spread of out-of-the-box functionality that can be built on per typical Puppet practice to fashion larger abstractions either within the Puppet language or in Ruby. Puppet is explicitly designed to be a highly extensible framework, therefore additional resource types are easy to write, distribute, or find on the Puppet Forge.
All of this, combined with the significantly lower per-node price, make Puppet Enterprise a compelling choice for hybrid Windows/Unix/Linux IT environments, an agile alternative to SCCM, and a tool complementary to Group Policy.
Q: Can the puppet master role be installed on a Windows machine?
A: Puppet Enterprise officially supports Windows Server 2008 R2 and Windows 7, but for the agent role only. The puppet master role must reside on a Linux-based system such as Debian or RedHat.
It’s worth noting that while support is provided only for Server 2008 R2 and Windows 7, the Puppet agent has been demonstrated to run in an unsupported capacity on most Windows releases from Server 2003 up (including 2003, 2003R2, 2008, Vista, and Windows 8).
Q: Does MCollective extend to Puppet on Windows?
A: The MCollective product works on Windows, but MCollective is not included in the Puppet Enterprise 2.7.0 installer for Windows. This is one of the last major bridges in terms of Puppet Enterprise Windows feature-parity with the Linux platforms, so it’s definitely a release we’re working towards.
Q: What plans do you have to help increase availability of Windows-capable modules on Puppet Forge?
A: I pinged Ryan Coleman, Product Owner of the Puppet Forge, for an answer on this question. Below was his response:
“There are two primary drivers of Windows-focused content on the Puppet Forge right now: Puppet Labs development and community contributions.
Modules such as puppetlabs/registry and puppetlabs/dism are examples of the kinds of content we build to enable Windows users with Puppet. Because we have limited resources to devote to these kinds of projects, most of our contributions come from the community. Thankfully, the community has been steadily contributing Windows content to the Puppet Forge. The following search produces 15 results, each a useful module for working with Windows and Puppet: http://forge.puppetlabs.com/modules?q=windows
My responsibility as Product Owner of Puppet Forge is to continue to enable the community to succeed and contribute great content. To that end, I do a number of things to help. I speak at conferences, write blog posts on how to more easily write great modules, and directly mentor community members on their modules when asked. In addition, I’m always on the lookout for work community members have done, and help them get that content onto the Puppet Forge. We also have the module bounty contest which asks the community to provide content we feel is lacking and awards the best contributors. If you have specific needs that aren’t being met, please email ryan@puppetlabs.com with what you’re looking for and I’ll do my best to get a solution onto Puppet Forge.”
Q: Are there any limitations on deploying Puppet modules on Windows?
A: There are no architectural limitations with regards to deploying modules for Windows nodes. Platform support varies between individual published modules depending on the effort invested by the relevant author and contributors, but there are no big-picture concerns specific in any way to modules and Windows.
Q: What techniques do you recommend to avoid having to put paths to particular MSI/EXE installers for particular versions in Puppet modules for Windows?
A: Puppet is about managing the configuration state on a system and leveraging whatever utilities are available in the environment to perform the actual work. On the Linux side, Puppet leverages Yum or Apt repositories to perform the install media retrieval. On the Windows side, there currently isn’t a ubiquitous abstraction that we can leverage in a package provider so much of the logic of schlepping around media that Puppet can use to install software has to be specified as part of the configuration. There are a variety of approaches that can be used. I’ll mention two of them here.
In an environment with Windows file shares available a “depot” can be set up containing the installation media for all managed software. Puppet can be used to connect to this software depot and use it for package sources. The following pseudo-code demonstrates the pattern.
Because I’m not currently aware of a native type/provider for mounting windows shares, an exec resource is used as a stand-in directive to ensure that the depot location is mounted and available. The exec could relatively easily be replaced with a full native “net_use” type and provider written along the same lines as the simondean/net_share module from Puppet Forge.
# The depot share path and connection information. Could be stored
# in hiera instead
$username = 'domain\puppet'
$password = 'passw0rd'
$share = '\\depot\packages'
$safeshare = regsubst($share, '[\\$]', '.', 'G')
# The `net use` command for the depot_mount exec resource
$netuse = 'C:\Windows\system32\cmd.exe /c net use'
# An exec resource that makes sure the depot is connected. If it's
# already connected, do nothing. If it isn't connected, connect
# to it.
exec { 'depot_mount':
command => "$netuse $share /USER:$username $password",
unless => "$netuse | FindStr /R \"^OK.*$safeshare\"",
}
# A package resource. Note specifically that it lists the
# depot_mount exec as a requirement.
package { 'Orca':
ensure => installed,
source => "$share\\orca\\orca-3.0.3790.msi",
install_options => { 'INSTALLDIR' => 'C:\orca' },
require => Exec['depot_mount'],
} |
When the depot pattern doesn’t work or isn’t ideal for a particular environment, another alternative is to use Puppet to ensure that a local copy of the installation media is available before ensuring the package. One way is to ship the files directly from the puppet master node, using it as a fileserver. Another option is to use Puppet Forge modules for alternative file sources, e.g. branan/s3file.
Any of these approaches can be wrapped in a defined type that will use logic or active mechanisms to locate an appropriate package source.
Click here for more information on the type/provider abstraction and how it can be used to build alternative means of ensuring that packages are installed if there is a native utility or repository software that you would like to use with Puppet for retrieving and installing packages.
More to Come
As I mentioned above, there were a number of questions asked at the webinar. Stay tuned for part II of the Puppet Enterprise and Windows blog series, or check out the resources below.
Learn More
