Managing PowerShell DSC with Puppet

1. Managing PowerShell DSC with Puppet Ethan Brown Technical Lead, Windows Engineering James Pogran Software Engineer, Author of Learning PowerShell DSC

2. Agenda • How Puppet Enterprise works • Why Puppet and DSC • Demo • Puppet Labs Windows support • Resources • Q&A

3. Our software automates the provisioning, configuration & ongoing management of your machines & the applications, services & software running on them.

4. Puppet Deployment Ubuntu Server PUPPET MASTER Windows Server Cisco Switch

5. How Puppet Enterprise Works

6. Why Puppet and DSC • Use the skills you have to do more • DSC and Puppet: Best of both worlds • Tracking and reporting on change

7. Use the skills you have to do more • Migrate a DSC Configuration script to a Puppet manifest with a few text edits • Puppet DSL is similar to PowerShell DSC syntax • Less code when used together

8. Converting DSC Configuration to Puppet Manifest

9. DSC and Puppet: Best of Both Worlds • 200+ DSC Resources made by Microsoft and the community • 4000+ modules made by Puppet and the community • Interoperable with multiple platforms

10. Best of Both Worlds: Immediate Value • Solving problems using the strengths of Puppet and DSC

11. DEMO

12. Best of Both Worlds: Advanced Scenario • Let’s deploy an ASP.NET 4.5.2 website – Puppet reduces the number of steps to get IIS installed – DSC IIS module has more features – Also posted here: https://puppetlabs.com/blog/dsc-deep-dive- installing-and-configuring-iis-using-puppet-and-powershell-dsc

13. DEMO

14. Tracking and Reporting on Change • Reporting is a must for have any company that has to do any kind of compliance auditing • Track changes across your environment to ensure the correct state • Knowing when something broke is just as important as knowing what broke

15. Tracking Change in DSC

16. Tracking Change in DSC with Puppet

17. Error Investigation in DSC • Get-xDscOperation • Trace-xDscOperation

18. Error Investigation in DSC with Puppet

19. Summary • Use the skills you have to do more • DSC and Puppet: Best of both worlds • Tracking and reporting on change

20. Puppet Labs Windows Support • 32- & 64-bit Support – Native MSI packages for x64 as of Puppet Enterprise 3.7 • Broad Platform Support - Windows 2008, 2012, 7, 8, 10 • Windows Provisioning - Provision Windows OSes with Razor • Puppet Supported & Approved Modules for Windows – Including Windows Module Pack, Supported SQL Sever & DSC modules • Azure Integration – Microsoft Azure extension handler for bootstrapping Puppet installs. Supported Azure module.

21. Puppet Supported Modules • SQL Server – Installs & manages MS SQL Server 2012 & 2014 on Windows systems • WSUS Client – Configure clients to point to update servers; schedule updates • DSC – Manages PowerShell DSC resources • Azure – Provision and manage Azure VMs • ACL – manage permissions with Windows ACLs • Registry – manage Registry keys and values • PowerShell – execute PowerShell commands with Puppet • Reboot – Automatically reboot after install

22. Puppet Approved Modules • IIS – install and manage IIS • Chocolatey – package manager • windows_env – manage Windows environment variables • Windows Java – Install and manage Oracle Java on Windows • pget – PowerShell alternative to wget or curl

23. Windows Webinar Series Register for upcoming webinars at: http://info.puppetlabs.com/1885- Windows-Series-Main_LP-Registration.html • Patch Management on Windows with Puppet • Setting up Windows for System and Application Monitoring • Getting Up and Running with the Windows Module Pack • Get Started on Azure with Puppet

24. Questions & Answers

25. Resources PuppetConf 2015 Windows Track • Chocolatey and Puppet - Rob Reynolds • Azure for the Non-Microsoft Person - Rob Reynolds & Scott Hanselman, MSFT • Better Together: Managing Windows with Puppet and DSC - Ethan Brown & Bruce Payette, MSFT Blog • Chocolatey blog series • PowerShell DSC blog series Docs • Managing Windows Configurations Books • Learning PowerShell DSC by James Pogran Education • Learning VM • Puppet Essentials for Windows – Instructor-led • Puppet Essentials for Windows - Virtual

Editor's Notes

My name is James Pogran. I've been working on automating systems on the Windows platform for over 14 years. Now I'm a developer at Puppet Labs working to make automation in Windows even better. I used PowerShell DSC at my last job to deploy a large client/server application in production. There was no documentation at the time, so I wrote my own book called Learning PowerShell DSC, to help others who were struggling with DSC. While you can use DSC on it's own, it's so much better with Puppet. Today I will be talking about using Puppet and PowerShell DSC together, what the benefits are, and provide some real world use cases.
Our software helps you automate the configuration and ongoing management of your machines and the software running on them, so you spend less time fighting fires and more time deploying great software. We help you make rapid, repeatable changes and automatically enforce the consistency of systems and devices–across physical and virtual machines, on prem or in the cloud.
Thanks for that great introduction to Puppet. We have covered why Puppet is important tool to have and how it works, but why should you use Puppet and PowerShell DSC? Whether you are new to Puppet or have been using it for years, there are lots of reasons for using Puppet and DSC together. Today we are going to talk about three reasons Puppet and DSC can work together to enable you to do more. I will go over each reason in more detail as we proceed, but I’ll quickly summarize the points right now. Puppet enables you to use the skills you already have to do more The Puppet DSL is similar to DSC syntax, so you can get up and running quickly You can migrate a DSC Configuration script to a Puppet manifest with just a few text edits Overall there is less code when you use them together With DSC and Puppet you get all of the advantages of both worlds There are thousands of resources made by Puppet, Microsoft and the community that you can use right away You immediately become able to handle multiple platforms that cover your entire environment Puppet provides rich management capabilities that you can layer on top of DSC, including node classification, status of nodes, role based access control, and more Tracking and reporting on change becomes easier Knowing when something broke is just as important as knowing when something succeeded Reporting is a must have for have any company that has to do any kind of compliance auditing Now that was a quick run through. Lets go through these one by one
First off, doing more with less sounds like a cliché, but it's a fact of life for any sysadmin or developer. Time and resource constraints necessitate flexibility and resourcefulness. You will get productive fast with Puppet and DSC. Converting an existing PowerShell DSC Configuration script to a Puppet manifest is just a few text edits. With Puppet you can take your existing PowerShell DSC skills and knowledge and apply them directly to fixing the problem at hand without having to learn everything upfront. As you do more, you can delve deeper, but you can get going quickly. Oftentimes a Puppet manifest has less code to write than a PowerShell DSC configuration script. We’ll see more of how this works later in our demos. Let’s get started
On the left is a PowerShell DSC configuration script, on the right is a Puppet manifest. It is a direct port from the DSC script. In it we are compressing a log directory and ensuring that a file is present on the file system with specific text inside it. If you're new to Puppet but PowerShell is familiar, you'll be right at home using the Puppet DSC module. Even if you are not familiar, its so human readable that you can see what’s going on right away. DSC works a lot like Puppet in many ways: it's declarative, uses a similar syntax, and similar terminology. Right away, you can see that there are only a few syntactical differences you need to account for when migrating to a Puppet manifest. You have to add a ‘dsc_’ prefix to all resource declarations and to all parameters. Your equal signs turn into hash rockets Commas are added at the end of each value These are simple, short changes that make sense. The syntax is so similar, there isn't any cognitive dissonance. Switching from a PowerShell DSC Resource to a Puppet module declaration is really just a few text edits and then you’re done. You’ll start to notice that there is less to write using Puppet. No configuration blocks to add, no DSC Resource module import declarations to keep track of, just the individual components you need. All PowerShell DSC types are supported, including base types like integers and Booleans, complex types like PSCredentials and any custom type bindings that you may use. Now that we have covered how to transition to a Puppet manifest using DSC, we’ll talk about what you can DO with Puppet and DSC
A key part of any sysadmin or developers life is re-using good tools and code. If there is something good out there, use it. If someone else has already solved the problem, use their solution. We stand on shoulders of giants when we work together. That’s why the Puppet DSC module enables you to use the 200+ PowerShell DSC Resources that have already been released and tested by the PowerShell community. Some of these resources cover scenarios not yet addressed by Puppet, providing immediate value. Like Lego pieces, you can mix and match the DSC Resources and Puppet modules to address any situation you encounter. And when you come to something that DSC can’t do yet or a platform that it doesn’t yet support, you can look toward the existing 4,000+ Puppet modules to have your back. Puppet supports almost all OS and platforms under the sun: Windows, Linux, Network devices, storage arrays, etc, allowing you to cover your entire environment using first class modules and best practices. Let’s look at a real world example showing how you can mix and match DSC and Puppet to get the job done
DSC is a powerful platform, but it’s a new technology. Like many new products, it needs to choose which features to implement first. Like Jeffey Snover says, to ship is to choose. This is not a bad thing, its focusing on delivering value first and getting it right. Then fill in the edges as time goes on. This does result in some waiting, but as we will see in a moment we can address that now. In this slide we see a PowerShell community member asking for the ability to restart a service when it’s configuration file has changed. Dave Wyatt, one of the maintainers of Pester, replies that it’s a big wishlist item for him, and that he currently works around it by using a Script DSC Resource. It’s a good workaround, but you have to do all the work to ensure the Script DSC Resource is idempotent, i.e. that it only changes the state of the system if it is not in the desired state. It’s extra work for you, and something that isn’t portable. You will have to modify it for every individual service. While we wait for the shipping cycle for PowerShell DSC, we can use Puppet WITH DSC to solve this problem right now.
Here we are installing the awesome Foo Product software on our target node using Puppet and PowerShell DSC. Foo Product has a configuration file it uses which allows users to change certain behavior in the program. We need to update the configuration file after the product is installed, which requires us to restart the service. We model this by declaring a PowerShell DSC Package resource that will handle installing the MSI for us. We then use a Puppet File module to ensure the file is present on the target node, and contains the exact text we want. Lastly we set the Puppet Service module to ensure the service is running. Notice the line in the File declaration where it says it will notify the Service module. This means that if the File module changes anything, it will send a notification to Puppet to tell the Service module to perform a refresh. The Service module doesn’t know anything about the config file, or when it changes, it just receives the notification from Puppet that it needs to refresh, or restart. These change notifications, along with many other features make Puppet a really powerful way to model and control change in your environment. Lets run this example now. This was a nice simple example, but doesn’t really show anything too fancy. Let’s move onto something more complicated.
We just showcased how you can use Puppet and DSC together in a simple example. Now lets show something more complicated by deploying an ASP.NET Website. This is more complicated because there are several software requirements needed for a ASP.NET website to run (IIS, .NET 4.5.2, etc) as well as some configuration settings (ApplicationPool, directories, files) that need to be set correctly. We’re using DSC along with Puppet because the IIS DSC Resource has some pretty nice features in it that we’ll use here to get a website up and running quickly. We won’t go into too much detail of setting up an ASP.NET website because I’ve written a blog post walking you through the steps on the Puppet Blog in our DSC Deep Dive series. If you want more information on the example, go there and read all about it! Lets get started
I’m going to run this demo while I talk, so that we aren’t all watching a screen scroll quietly by. In this demo we ported an existing PowerShell DSC Configuration script to a Puppet manifest. When we move to the Puppet manifest, we immediately see a reduction in code ceremony that results in less code written and less to think about. The immediate benefits we see are: No DSC Resource module imports and DSC Configuration function declaration are required We can describe the dependencies between resources using a simpler dependency symbol, which results in less to write as well as making it easier to move sections around or add new sections without remember to keep array statements in sync Global resource defaults to parameters reduces the amount of repetitive code you have to write. You get all the benefits from the maturity of the Puppet DSL and the reach of the DSC Resources in the same manifest
We have gone over how Puppet and DSC together enables you to do more with your existing skill sets and provides a large toolset to accomplish any task. The last thing we are going to cover today is how to see the results of everything we’ve done so far. Change reporting is a must have for any company that has to comply with any kind of auditing. Being able to pinpoint when something was successfully changed is a huge step towards getting control over your environment, never mind proving it to auditors or your coworkers. Seeing the changes across your environment presented in an easily accessible way reduces the amount of time spent verifying change. You don’t have to manually go out and check the state, it’s already collected for you. Historical reporting is important because knowing when something broke is just as important as knowing what broke. If you are able to find out the time a change happened, correlation to other events becomes easier and reduces the amount of time spent troubleshooting. Lets delve a little deeper into what is available built into PowerShell DSC and how Puppet expands on that by showing changes across your environment over time.
While PowerShell DSC does not keep historical data on changes performed, it does provide some ways for you to find out what changed manually. PowerShell shows status of the whole operation if queried, not on resource by resource. This provides a good indication of the state of the last run, but you can’t find out how that changed over time as these results are not kept. In PowerShell v4 this is accomplished by using the EventLogs and searching for the last run result. In PowerShell v5 you can use Get-DscConfigurationStatus cmdlet as show here to get the same information. PowerShell results are only available on target node, unless a DSC Pull Server is setup. A Pull Server can store the last result for all target nodes configured to point to it, but it still requires a manual HTTP call to get the information. You can script these calls to generate reports, but this is not built-in Now that we have seen what is built in to DSC, lets see how we can extend that using Puppet
Puppet can extend DSC by providing historical change tracking and reporting. Configuration results and history are available on the target node as well as in the Puppet Server Web UI. The Web UI provides a single pane of glass interface that shows the status of your environment as a whole all the way down to individual servers. It even shows resource by resource change. As we see in the slide, the result of each DSC Resource execution is shown. A log is provided of the execution as well. Puppet Server keeps track of changes by keeping all of these reports. This allows you to investigate over time how things change in your environment. For instance it could alert you to a target node that is continually being changed outside of specification, so that you can ensure compliance. Seeing the results of DSC and Puppet is great, but what about when things go wrong? How do you find out what’s going on? Let’s look at how you do this in DSC and then with Puppet
Finding any errors that are occuring during a DSC Configuration run is an exercise in searching the Eventlog. This can either be done manually with EventViewer or using the xDscDiagnostics module cmdlets: Get-xDscOperation and Trace-xDscOperation. They can be run either locally or remotely. Get-xDscOperation lists statuses of the last few run DSC operations. It returns an object that has information about the time that run was created, whether the run was successful or not, all the events generated by that run, and the unique job identifier for that run. You use this cmdlet to find the specific DSC Job that created the error condition you want to investigate. Trace-xDscOperation takes the JobId or SequenceId from the Get-xDscOperation cmdlet as parameters and gives you a readable list of events generated by their respective DSC operation. By default, Trace-xDscOperation will list all the events generated by the most recent run. This cmdlet returns an object that contains properties such as event type, event message, and time of event creation. The results of this cmdlet are what you use to figure out which part of the DSC Configuration is failing, and what the root cause is.
We just saw how investigating errors when applying configurations in DSC requires looking at EventLogs on the target node, either using EventViewer or the DscDiagnostics module the PowerShell team created. In Puppet errors are surfaced up front and are easy to diagnose compared to searching through dozens of events. These are the same messages you would see from DSC in the EventLog or on the PowerShell console, viewable inside the Puppet Server UI. Puppet automatically logs the results of all actions taken, either by Puppet or DSC, so you can review exactly what happened without having to ‘go to the target node’ or run commands manually yourself. This is a huge time saver, when you’re on the line to figure out why something is going wrong. It’s just a few clicks compared to several minutes running commands and searching through events.
We have come along way in our discussion about Puppet and DSC. We’ve shown how we can use the skills you have to do more, how the syntax is similar and that migrating to Puppet manifests requires little extra effort. We’ve seen how the thousands of Puppet modules and hundreds of DSC resources can enable you to cover any scenario you are faced with, on any platform you support Finally we’ve covered how you can track these changes in your environment and report on them for compliance. I hope that this has been informative and useful. I'm going to pass off to Ethan to talk more about Puppet
First, we think it’s critical to adopt automation technology that helps you model and enforce the desired state of the services you deliver. Second, we think that you should automate those processes (among others) from your core infrastructure up through your applications, all in one place for full enforcement, traceability and auditability. Third, we think you should automate across the entire lifecycle, from initial provisioning of infrastructure through decommissioning. Finally, you should do this across everything. If it has an IP address, you should automate the management of it. Let’s dig into each of these.
First, we think it’s critical to adopt automation technology that helps you model and enforce the desired state of the services you deliver. Second, we think that you should automate those processes (among others) from your core infrastructure up through your applications, all in one place for full enforcement, traceability and auditability. Third, we think you should automate across the entire lifecycle, from initial provisioning of infrastructure through decommissioning. Finally, you should do this across everything. If it has an IP address, you should automate the management of it. Let’s dig into each of these.
First, we think it’s critical to adopt automation technology that helps you model and enforce the desired state of the services you deliver. Second, we think that you should automate those processes (among others) from your core infrastructure up through your applications, all in one place for full enforcement, traceability and auditability. Third, we think you should automate across the entire lifecycle, from initial provisioning of infrastructure through decommissioning. Finally, you should do this across everything. If it has an IP address, you should automate the management of it. Let’s dig into each of these.

Managing PowerShell DSC with Puppet

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (17)

Similar to Managing PowerShell DSC with Puppet

Similar to Managing PowerShell DSC with Puppet (20)

More from Puppet

More from Puppet (20)

Recently uploaded

Recently uploaded (20)

Managing PowerShell DSC with Puppet

Editor's Notes