Published on 14 June 2017 by

Puppet is excited to announce that the Puppet IIS module is now a Puppet Supported module, the latest addition to our ever-expanding collection of Puppet Supported and Approved modules for Windows.

Improvements

The Puppet IIS module was crafted with performance in mind. Instead of running PowerShell multiple times, we've taken advantage of performance improvements to the Puppet PowerShell module, applying them to the IIS module. We now open PowerShell just once per Puppet run instead of once per resource, vastly reducing the time taken and memory usage, compared to other approaches.

We've made API improvements that will make it easier to declare your configurations. Look for differences and improvements in managing things like web site bindings, and when associating IIS applications, application pools, and sites.

We created a type that manages IIS features, allowing you to bring a newly provisioned target node from zero to working, and without using additional modules.

We have also started work on integrating the new IIS module IISAdministration cmdlets into the Puppet IIS module. The plumbing code is present in this release, and future releases will have support for IISAdministration cmdlets as we add them. This lights up Windows 2016 and Nano, allowing us to manage those operating systems.

Community

Puppet is nothing without you, and we recognize that Puppet community members have already created some great IIS modules. Vox Pupuli and OpenTable have created just a couple of the many good modules out there. While we recognize the hard work done by the community (thank you!), we also want to help bring Windows automation forward and make things easier for everyone. We decided it would work well if we made a direct migration path from existing modules to our own, working with the community to create a Supported module. Vox Pupuli graciously agreed to transfer the puppet\iis module to Puppet, and we appreciate their collaboration.

Migration

If you are currently using puppet\iis, we have written a migration guide to make the process as painless as possible. We made every effort to make as few API changes as possible, but some instances were unavoidable, and we made the best decision as we could in choosing the right path forward. We used a few guidelines in our decision making process:

  • Be as explicit as possible in naming types. For example, favor iis_application_pool rather than 'iis_pool. While this makes for more typing, it keeps the intent clear and avoids name collisions for similar concepts.
  • Collate similar concepts into as few types as possible. For example, we moved parameters that were previously managed in catch-all classes into their relevant types. This makes types more verbose, but keeps your configurations more organized.
  • Be opinionated in implementation, but let the user decide what's best. For example, include the iis_feature type to ensure IIS is installed correctly, but allow the user to decide which features to install, instead of providing catch-all lists of features we think should be in a base IIS install.

Summary

If you want to talk to our Windows experts in person, we’d love to meet you at PuppetConf, where we’ll have a bunch of great Windows talks. Also, feel free to come talk to us in Slack: https://slack.puppet.com/

James Pogran is a software engineer at Puppet.

Learn more

Share via:
Posted in:

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.