41,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A learning guide to get you started with PowerShell DSC.
About This Book
- Create flexible and maintainable deployments using DSC configuration scripts that stand the test of time.
- Explore the core architecture, concepts, and practices in depth.
- Learning PowerShell DSC is a step-by-step guide that shows you how to start using and taking advantage of PowerShell DSC along with configuring and deploying applications.
Who This Book Is For
If you are a system administrator, developer, or engineer and are responsible for configuration management and automation, then this book is for you. IT professionals who wish to learn PowerShell Desired State Configuration for the efficient management, configuration, and deployment of systems will also find this book useful.
What You Will Learn
- Explore PowerShell Desired State Configuration and activities around it, including the need for configuration management and abstraction.
- Create reusable DSC configurations and debug/ troubleshoot configuration files.
- Learn about the PowerShell DSC architecture with the help of push-and-pull management and workflows.
- Define DSC configuration scripts and data files and push DSC configuration files remotely and locally.
- Validate DSC Pull Server install and register target nodes with a DSC Pull Server.
- Learn about DSC Cross Platform and install PowerShell on Linux and macOS along with real-life DSC uses and different types of deployment.
In Detail
The main goal of this book is to teach you to configure, deploy, and manage your system using the new features of PowerShell v5/v6 DSC.
This book begins with the basics of PowerShell Desired State Configuration, covering its architecture and components. It familiarizes you with the set of Windows PowerShell language extensions and new Windows PowerShell commands that make up DSC. Then it helps you create DSC custom resources and work with DSC configurations with the help of practical examples. Finally, it describes how to deploy configuration data using PowerShell DSC. Throughout this book, we will be focusing on concepts such as building configurations with parameters, the local configuration manager, and testing and restoring configurations using PowerShell DSC.
By the end of the book, you will be able to deploy a real-world application end-to-end and will be familiar enough with the powerful Desired State Configuration platform to achieve continuous delivery and efficiently and easily manage and deploy data for systems.
Style and approach
The purpose of this book is to introduce readers to the powerful PowerShell Desired State Configuration platform to achieve continuous delivery, efficient management, and the easy deployment of data for systems.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 361
Veröffentlichungsjahr: 2017
Ähnliche
Learning PowerShell DSC
Second Edition
BIRMINGHAM - MUMBAI
Learning PowerShell DSC
Second Edition
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: October 2015
Second edition: September 2017
Production reference: 1060917
ISBN 978-1-78728-724-2
www.packtpub.com
Credits
Author
James Pogran
Copy Editor
Stuti Shrivastava
Reviewers
Mark Andrews
Steve Parankewich
Project Coordinator
Virginia Dias
Commissioning Editor
Vijin Boricha
Proofreader
Safis Editing
Acquisition Editor
Prateek Bharadwaj
Indexer
Aishwarya Gangawane
Content Development Editor
Sharon Raj
Graphics
Kirk D'Penha
Technical Editor
Vishal Kamal Mewada
Production Coordinator
Aparna Bhagat
About the Author
James Pogran has been working with computers in one way or another for over 15 years. His first job involved systems administration for a large military installation. He then moved on to develop monitoring software and automating large-scale Windows environments for a major managed services provider. He is currently a senior software engineer at Puppet, Inc, where he helps make Windows automation even better with Puppet.
About the Reviewers
Mark Andrews's career in technology has been a varied one; over the last 20 years, he has held several different positions, ranging from customer service to quality assurance. Throughout all of these positions, the responsibility of configuration management and build management has always fallen either on Mark personally or on one of the groups that he managed; because of his “keeping a hand in” management style, he has been closely involved with the scripting and automation framework for this area. Creating scripted frameworks that intercommunicate across machine/operating system/domain boundaries is a passion for him.
PowerShell 3.0 Advanced Administration Handbook
Windows PowerShell 4.0 for .NET Developers
PowerShell for SQL Server Essentials
Microsoft Exchange Server PowerShell Essentials
Microsoft Exchange Server PowerShell Cookbook (Third Edition)
AWS Tools for PowerShell 6
Steve Parankewich is a professional systems analyst, architect, and engineer. With over 20 years of experience, Steve has always had a passion for automation. He is currently a PowerShell evangelist and leads the Boston PowerShell user group, organizing monthly meetups with fellow IT professionals. Steve currently focuses on implementation and migration to both Office 365 and Azure. You can reach him or read additional PowerShell based articles that he has written at powershellblogger.com.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com, and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review.
If you'd like to join our team of regular reviewers, you can email us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Errata
Piracy
Questions
Introducing PowerShell DSC
What is PowerShell DSC?
What is PowerShell?
On to PowerShell DSC
Why do we need configuration management?
What is DevOps?
DSC quick wins
DSC high-level overview
The authoring phase
The staging phase
The execution phase
Why all the abstraction?
How does DSC help?
The who
The what
The how
Idempotence
Isn't this Group Policy or SCCM?
DSC features
DSC requirements
DSC versions
PowerShell V4 DSC
V4 DSC language extensions
V4 DSC base resources
V4 DSC cmdlets
V4 DSC pull server
PowerShell V5 DSC
V5 DSC language extensions
V5 DSC base resources
V5 DSC cmdlets
V5 improvements
The PowerShell ISE
Partial configurations and dependencies
Class-based DSC resources
DSC built-in support for help
DSC run as credential support
DSC resource side-by-side installation
DSC resource script debugging
Separation of node and configuration IDs
DSC LCM MetaConfig updates
DSC LCM rich state information
DSC LCM RefreshMode values
DSC status from a central location
PowerShell V6 DSC
Summary
DSC Architecture
Overview
Push and pull modes
The push management model
The pull management model
The general workflow
Authoring
Syntax
Compilation
Staging
Execution
Push executions
Pull executions
The example workflow
Configuration data
Hardcoded data
Parameter-based data
Hashtable data
Local Configuration Manager
LCM settings
Configuration modes
ApplyOnly
ApplyAndMonitor
ApplyAndAutoCorrect
Refresh modes
The LCM configuration
An example LCM configuration
The DSC pull server
What is a DSC pull server?
What does the pull server do for us?
Automatic and continuous configuration
Repository
Reporting
Security
Setting up a DSC pull server
Pull server settings
Installing the DSC server
Adding MOF files to a pull server
Adding DSC resources to a pull server
Deployment considerations
General observations
LCM gotchas
Deployment mode differences
Summary
DSC Configuration Files
Defining a DSC configuration script file
Authoring DSC configuration files
DSC automatic variables
AllNodes
Node
ConfigurationData
DSC resource import declarations
Import-DSCResource
DSC configuration syntax
The configuration keyword
The Node keyword
DSC resource statements
DSC configuration script file example
Defining a DSC configuration data file
Authoring DSC configuration data files
Configuration data syntax
The variable syntax
The data file syntax
Allowable DSC configuration content
Creating reusable DSC configurations
Nested DSC configurations
Nested DSC configuration syntax
Nested DSC configuration limitations
DSC composite resources
Why use DSC composite resources?
The DSC composite resource syntax
The DSC composite resource folder structure
DSC composite resource drawbacks
Partial DSC configurations
Debugging and troubleshooting configuration script files
Status at a glance
Using DSC event logs
Enabling verbose logging
What do DSC event logs contain?
Gathering events from a single DSC operation
Event Viewer
PowerShell
Using the xDscDiagnostics module to analyze DSC logs
Get-xDSCOperation
Trace-xDSCOperation
Resetting the DSC engine cache
Enabling the debug mode
Fixing a stuck DSC run
Summary
DSC Resources
What are DSC resources?
What makes a good DSC resource
Idempotent
Do one thing well
Reuse code, but don't go overboard
Contribute back
Creating PowerShell MOF-based custom DSC resources
MOF-based DSC resource folder structure
MOF-based DSC resource syntax
The DSC resource definition file
Naming
Versioning
Parameters
Qualifiers
The DSC PowerShell module file
Get-TargetResource
Test-TargetResource
Set-TargetResource
Authoring custom DSC resources
Creating DSC resources manually
Creating DSC resources automatically
Creating PowerShell class-based custom DSC resources
PowerShell classes
Class-based DSC resources
The folder structure of class-based DSC resource
Class-based DSC resource syntax
Advantages of a class-based DSC resource
Disadvantages of a class-based DSC resource
Creating single-instance custom DSC resources
Creating PowerShell custom DSC resources in C#
Create the MOF schema
Create the Visual Studio project
Create the C# cmdlet code
Packaging the C# custom DSC resource
Testing custom DSC resources
Using xDscResourceDesigner
Pester
Microsoft recommendations
How do you find DSC resources?
Microsoft DSC resource Kits
Installing DSC resource Kits
Microsoft PowerShell DSC GitHub repository
Installing DSC resources from GitHub
Microsoft PowerShell Gallery
PackageManagement
Discover DSC resources in the PowerShell Gallery
Installing DSC resources in the PowerShell Gallery
Custom hosting options
Local SMB/network share
NuGet IIS
Third-party NuGet servers
Deploying DSC resources
Deploying DSC resources in a push DSC configuration deployment
Deploying DSC resources in a pull DSC configuration deployment
Summary
Pushing DSC Configurations
Tooling
Setting things up
Test environment
Locally pushing DSC configurations
Setting up the test environment locally
Compiling configurations for local target nodes
Executing configurations for local target nodes
Remotely pushing DSC configurations
Setting up the test environment remotely
Compiling configurations for remote target nodes
Executing configurations for remote target nodes
Things you must consider when pushing DSC configurations
Summary
Pulling DSC Configurations
Creating DSC pull servers
DSC pull server setup considerations
DSC pull server type
The Windows management framework version
Initial setup tasks
Installing required DSC resources
SSL certificates
SMB share creation
Preparing DSC resources for pull server distribution
Miscellaneous tasks
Creating an SMB DSC pull server
Creating an HTTPS DSC pull server
DSC pull server and registration keys
Validating a DSC pull server install
Testing using a web browser
Testing using the command line
Registering target nodes with a DSC pull server
Registering a target node using a configuration ID
Registering a target node using RegistrationKey
Pulling DSC configurations with a DSC pull server
Compiling DSC configurations using ConfigurationIDs
Compiling DSC configurations using RegistrationKeys
Deploying DSC Configurations to the DSC pull server
DSC pull server and target node status
Checking the current LCM configuration status
Triggering a DSC configuration to run on a target node
Triggering a WMF 4 target node
Triggering a WMF 5 target node
Using DSC logging to check on the status
Reporting on the target node status
Reporting on the target node status with the DSC pull server
WMF 5 pull server reporting
WMF 4 pull server reporting
Summary
DSC Cross Platform Support
DSC cross-platform support
Using DSC on Linux
Installing DSC on Linux
Pushing a DSC configuration to a Linux node
PowerShell Core
Installing PowerShell Core on Windows
Installing PowerShell Core on macOS
Homebrew
Manual
Installing PowerShell Core on Linux
Ubuntu
Summary
Example Scenarios
Real-life DSC usage
Setting up a common installation base
Installing software
Configuration management refresher
Complicated deployments
Handling change
Summary
Preface
Windows PowerShell, a scripting language specially designed for system administration, lets you manage computers from the command line. PowerShell DSC enables you to deploy and manage configuration data for software services and also manages the environment in which these services run.
What this book covers
Chapter 1, Introducing PowerShell DSC, helps you identify PowerShell DSC and configuration management concepts, covers the features included in DSC, and provides an overview the different DSC versions.
Chapter 2, DSC Architecture, offers in-depth explanations of the three phases of DSC, the two different DSC deployment models, and the considerations when deploying a pull server or using push deployment.
Chapter 3, DSC Configuration Files, covers authoring DSC configuration scripts and configuration data files and explains how to use them together effectively.
Chapter 4, DSC Resources, covers the DSC resource syntax and file structure in both PowerShell V4 and V5. It shows how to find DSC resources both on the local system as well as using community and Microsoft-provided online resources.
Chapter 5, Pushing DSC Configurations, offers step-by-step instructions on how to push DSC configurations to remote target nodes. It covers the extra steps the user must take in order to make push deployments work as well as the pros and cons of using push deployments.
Chapter 6, Pulling DSC Configurations, offers step-by-step instructions on how to set up both a DSC pull server and your environment to best utilize a pull-based deployment. It covers the pros and cons of using pull deployments in comparison to push deployments.
Chapter 7, DSC Cross Platform Support, instructs you on setting up DSC on Linux platforms, including software installation and configuration. It explores the future of PowerShell by showing how to install PowerShell Core.
Chapter 8, Example Scenarios, covers how to use DSC in the real world and how to integrate DSC into not only new environments but also with legacy deployments. It walks you through the processes of handling the changing requests and the requirements of different software deployments using DSC.
What you need for this book
Any of the following operating systems required for this book:
Windows 10
Windows 2012 R2
Windows 2016
Software: PowerShell V4, V5, V5.1
Who this book is for
This book is intended for system administrators, developers, and DevOps engineers who are responsible for configuration management and automation and wish to learn PowerShell DSC for the efficient management, configuration, and deployment of systems and applications.
You must have some basic knowledge of Windows PowerShell and should have experience of installing and configuring operating systems and Windows servers. You must also understand the basics and principles of configuration management and know how to apply them to deploying and managing systems and applications using PowerShell DSC.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply email [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files emailed directly to you. You can download the code files by following these steps:
Log in or register to our website using your email address and password.
Hover the mouse pointer on the
SUPPORT tab at the top.
Click on
Code Downloads & Errata.
Enter the name of the book in the
Search box.
Select the book for which you're looking to download the code files.
Choose from the drop-down menu where you purchased this book from.
Click on
Code Download.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR / 7-Zip for Windows
Zipeg / iZip / UnRarX for Mac
7-Zip / PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Learning-PowerShell-DSC-Second-Edition. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title. To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at [email protected] with a link to the suspected pirated material. We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Introducing PowerShell DSC
Welcome to PowerShell Desired State Configuration (DSC), the new configuration management platform from Microsoft. We begin with a quote from Alice in Wonderland. Besides pertinent advice from the author, it is apropos of what DSC is at its very core. DSC, by the very simplest definition, allows you to write down the beginning, the middle, and the end of your deployment story. The second quote we see is from The Hitchhiker's Guide to the Galaxy, and it is something to remember throughout this book. We will cover a lot of new concepts, some old concepts with new importance, and a lot of PowerShell. Don't panic; we'll get through fine.
This book will begin with the basics of PowerShell DSC, covering its architecture and many components. It will familiarize you with the set of Windows PowerShell language extensions and new Windows PowerShell commands that comprise DSC. Then, it will help you create custom DSC resources and work with DSC configurations with the help of practical examples. Finally, it will describe how to deploy a configuration data set using PowerShell DSC.
By the end of this book, you will be able to deploy a real-world application end to end.
In this chapter, we will cover the following topics:
What is PowerShell DSC?
Why do we need configuration management and what is DevOps?
How does DSC help?
A high-level overview of DSC
DSC requirements
DSC versions
What is PowerShell DSC?
Do you have some software that needs to be installed in a certain order? Software with special configuration steps? Software along with some security policies that must be applied to every server? How about ensuring that a set of services are never enabled to start? Have you ever written scripts to handle this kind of work but found them brittle because of changes in software from release to release? Needed to make these changes on dozens or hundreds of servers repeatedly on schedule? Ever had someone change something and have your script break because the state is not what you expected? These and many more scenarios are handled by DSC.
PowerShell DSC is a new management platform in Windows PowerShell that enables the deployment and management of configuration data for systems and software services and the management of the environment in which these services run. DSC allows you to define the current state of a machine and ensure that the machine is always in that state.
What we mean by state here is everything that is on that machine, including the operating system and software installed, all the configuration settings for the OS and software, and any files or process that need to be present or set with specific content; the list goes on. Whether you considered this earlier or not, all this makes up the configuration of your system. DSC is designed to help you deal with all this configuration data and execute it consistently and repeatedly.
What is PowerShell?
While we assume in this book that you have a basic understanding of PowerShell command-line use and scripting, before we go too much into DSC, it is helpful to describe what PowerShell is compared to PowerShell DSC.
First released in 2006, PowerShell is a scripting language and command-line shell built on the .NET framework. PowerShell provides complete access to COM, WMI, and .NET and also provides a large set of commands called cmdlets to perform administrative tasks on both local and remote systems.
PowerShell can execute PowerShell scripts, PowerShell cmdlets, and standalone executable programs or other language files. PowerShell also provides a hosting API that allows programs to run PowerShell natively inside their program, enabling scripting or automation scenarios. Being both a shell language and a scripting language allows it to be quick as well as terse on the command line, along with being verbose and consistent in scripts.
Over the years, PowerShell has become the de facto way to administer and automate Windows OS and software. As computing environments grow larger and engineering teams become smaller, it is paramount in automating processes and procedures that used to be done by hand. PowerShell provides a consistent command-line language to automate the administration of a large number of scenarios, which are growing every day and were previously not available on Windows. Because of PowerShell's hosting API, applications such as Microsoft Exchange have enabled a command line, first, GUI—second, mode of development, which enables quick deployment and management using automated tools.
PowerShell not only enables the automation at the single system level, but it also scales out to the multi-node environment. Being able to automate your system from the command line or script is fine, but if you have to manually run that script on every system in your environment by hand, then we still have a bottleneck on efficiency. Using an industry standard protocol, PowerShell provides PowerShell remoting as a way of running commands or scripts on any number of remote hosts in parallel. Thousands of computers can be managed at the same time, consistently, in a repeatable and automated manner.
Consistent repeatable automation is important, but PowerShell is also extensible, which is not only essential, but it also leads us into DSC. PowerShell is a both a typed and dynamic scripting language, which means that it supports both static typed objects (System.IO.FileInfo) and objects with methods and properties that are defined at runtime (PSCustomObject and Add-Member). This enables PowerShell to be extended to suit the needs of the user. You do this every day to an extent, by creating functions and scripts to wrap common operations into reusable components or modules. Taking this a step further, PowerShell can be extended to support specific scenarios that were not envisioned when the product was made. DSC is such an extension, as it builds on the existing PowerShell language and infrastructure to enable new uses of the program.
Why do we need configuration management?
Whether you manage a few servers or several thousands, the traditional methods of server and software installation and deployment are failing to address your current needs. These methods treat servers as special singular entities that have to be protected and taken care of, with special configurations that may or may not be documented, and if they go down, they take the business with them.
For a long while, this worked out. But as the number of servers and applications and configuration points grows, it becomes untenable to keep it all in your head or consistently documented by a set of people. New patches that are released, feature sets change, employee turnover, poorly documented software—all these reasons introduce variance and change into the system. If not accounted for and handled, these special servers become ticking time bombs that will explode the moment a detail is missed.
Written installation or configuration specifications that have to be performed by humans and be error-free time and time again on numerous servers are increasingly self-evident as brittle and error-prone affairs. To further complicate things, despite the obvious interdependence of software development and other IT-related departments, the software developers are often isolated from the realities faced by IT professionals during the deployment and maintenance of the software.
The answer to this is automation: defining a repeatable process that configures servers the right way every time. Servers move from being special snowflakes to being disposable numbers on a list that can be created and destroyed without requiring someone to remember the specific incantation to make it work. Instead of a golden image that has to be kept up to date with all the complexities of image storage and distribution, there is instead a set of steps to bring all servers to compliance regardless of whether they are a fresh installation or a number of years old.
What is being described is Configuration Management (CM). CM ensures that the current design and build state of a system is a known good state. It ensures trust by not relying on the knowledge of one person or a team of people; it's an objective truth that can be verified at any time. It provides a historical record of what was changed as well, which is useful not only for reporting purposes (such as for management), but also for troubleshooting purposes (this file used to be there, now it's not). CM detects variance between builds, so changes to the environment are both easily apparent and well known to all who work on the system.
This allows anyone to see what the given state of the system is at any time, at any granularity, whether on one system or over the span of thousands. If a target system fails, it's a matter of re-running the CM build on a fresh installation to bring the system back to a steady state.
CM is part of a set of ideas called Infrastructure as Code. It requires that every step in provisioning an environment be automated and written down in files that can be run any time to bring the environment to a known good state. While CM is infrastructure automation (replicating steps multiple times on any amount of target nodes), Infrastructure as Code takes things one step further and codifies every step required to get an entire environment running. It encompasses the knowledge of server provisioning, server configuration, and server deployment into a format that is readable by sysadmins, developers, and other technical staff. Like CM, Infrastructure as Code uses existing best practices from software development, such as source control, automated code testing, and continuous integration, to ensure a redundant and repeatable process.
The approaches being described are not that new and are part of a larger movement that has been slowly accepted among companies as the optimal way of managing servers and software, called DevOps.
What is DevOps?
The set of concepts we have been describing is collectively termed DevOps and is a part of a larger process called continuous delivery. DevOps is a shortened form of development operations and describes a close working relationship between the development of software and the deployment and operation use of that software. Continuous delivery is a set of practices that enables software to be developed and continuously deployed to production systems on a frequent basis, usually in an automatic fashion that happens multiple times a week or day.
Each year, a company called Puppet Labs surveys over 4,000 IT operations professionals and developers about their operations procedures. Of those surveyed, companies that have implemented DevOps practices have reported improved software deployment quality and more frequent software releases. Their report states that these companies shipped code 30 times faster and completed those deployments 8,000 times faster than their peers. They had 50% fewer failures and restored service 12 times faster than their peers.
Results such as the ones shown in the Puppet Labs survey show that organizations adopting DevOps are up to five times more likely to be high performing than those who have not. It's a cumulative effect; the longer you practice, the greater the results from adoption and the easier it is to continue doing that. How DevOps enables high performance is something that centers around deployment frequency.
To define and explain the entirety of DevOps and, since continuous delivery is out of the scope of this book, for the purposes here the goals can be summarized as follows: to improve the deployment frequency, lower the failure rate of new releases, and shorten the recovery time if a new release is faulty. Even though the term implies strict developer and operations roles as the only ones involved, the concept really applies to any person or department involved in the developing, deployment, and maintenance of the product and the servers it runs on.
These goals work toward one end: minimizing the risk of software deployment by making changes safe through automation. The root cause of poor quality is variation, whether that is in the system, software settings, or in the processes performing actions on the system or software. The solution to variation is repeatability. By figuring out how to perform an action repeatedly, you have removed the variation from the process and can continually make small changes to the process without causing unforeseen problems.
DSC quick wins
While there are many aspects to DSC that are beneficial, it is useful to pause here and list some quick wins that DSC brings us to inspire us to keep reading:
DSC configuration and supporting files are all written in the PowerShell syntax. Investments in knowledge about PowerShell are improved upon and expanded in using DSC.
DSC is designed to support continuous deployment, so it will react and adjust as your environment changes.
When DSC applies a configuration to a target node, DSC resources only change that which does not match the expected state (we will cover the terminology for this and how important this is in
Chapter 2
,
DSC Architecture
), ensuring a quick deployment.
DSC separates configuration logic from configuration data, reducing the rate of change in your configuration scripts and the variation in your deployments.
DSC operates on more platforms than just Windows. DSC has a set of DSC resources that know how to install, configure, and manage Linux target nodes and some network switches. In a heterogeneous environment, having one tool that can address many different platforms is a huge time and cost saver.
DSC high-level overview
We will look into the DSC architecture in much greater detail in the next chapter, but it is useful to show a quick overview of how all the concepts we just covered fit together. DSC has several steps that can be bucketed together into three large phases.
The authoring phase
You begin with DSC by writing a configuration script in PowerShell. The script itself doesn't actually do anything. You can run the script interactively all you want; it won't change a thing. Since the configuration script is the DSL we were talking about earlier, it's only a list of things to do, not the things that actually execute the list. Because there can only be one MOF per target host and each configuration script is translated to an MOF, this means there is usually only one configuration script you write, which handles all the variances in your environment. This sounds like it will get complicated and difficult to manage quickly, but there are DSC patterns to follow in order to manage this. We will cover these in Chapter 3, DSC Configuration Files.
The next step is to translate the configuration script to an MOF file. The translation, or compiling, happens only once—when you deploy the MOF file to the target node or to the DSC pull server. The configuration script is often kept in a version control system and only compiles and deploys the MOF file when the configuration script changes.
The staging phase
The next step is to get it over to the target computer. The deployment of the MOF happens in two ways: push and pull. A push method is when you execute the Start-DSCConfiguration cmdlet, which compiles the MOF and copies over to the target system. The pull method involves putting the MOF file on the DSC pull server, which handles distributing it to all the target hosts.
The execution phase
Whether an MOF file was pushed (using Start-DSCConfiguration) or pulled (using a DSC pull server), the next step is the actual execution of the MOF file. If pushed, the execution happens interactively or in a PowerShell job depending on how you called the cmdlet. If pulled, the Local Configuration Manager (LCM) schedules and executes the MOF file without user input or oversight.
LCM is part of the DSC system installed on the target node and is responsible for receiving, coordinating, and executing configurations on target nodes. LCM itself is configurable using DSC and is flexible enough to allow multiple types of deployments.
The phases described earlier will be covered in much more detail in the upcoming chapters, so do not worry if some of it does not make sense.
Why all the abstraction?
It seems like we are writing scripts just to have them turned into another format altogether, which in turn is converted into something else. Why all the indirection and abstraction? Why don't we write the final result ourselves the first time? The primary reasons are readability and flexibility.
DSC configuration files are written in the PowerShell syntax, which we already established as being consistent and readable. When the configuration is human-readable, it's understandable to the whole team and not just the implementer. It's written down in textual format, so it can be controlled in a source control system such as Git, Subversion (SVN), or Team Foundation Server. Deployment processes (sets of instructions on how to complete a task) are automatically saved and backed up by the source control system and made available to the entire team instead of one person's desktop.
Readability serves more than just the implementer and the team. Written configuration files codify the deployment process in a historical record. In that record, we can see the progression of the system by comparing the text files between releases, thereby monitoring drift and variation.
