35,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Windows PowerShell is a task-based command-line shell and scripting language designed especially for system administration. PowerShell DSC is a new management platform that enables you to deploy and manage configuration data for software services and manage the environment in which these services run.
This book begins with an overview of the basics of PowerShell DSC by covering the architecture and components of the Desired Sate Configuration. It will then familiarize you with the set of PowerShell language extensions and new PowerShell commands. It will help you understand and create DSC configurations with the help of practical examples, and to create DSC custom resources for your custom applications. Finally, you will learn to deploy a real world application using PowerShell DSC. By the end of the book, you will have better knowledge about the powerful Desired State Configuration platform, which helps you to achieve continuous delivery, and efficient management and easy deployment of data for systems.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 348
Veröffentlichungsjahr: 2015
Ähnliche
Table of Contents
Learning PowerShell DSC
Learning PowerShell DSC
Copyright © 2015 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
Production reference: 1161015
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78398-070-3
www.packtpub.com
Credits
Author
James Pogran
Reviewers
Marcin Grzywa
Brian Scholer
Sergei Vorobev
Dave Wyatt
Acquisition Editor
Manish Nainani
Content Development Editor
Shali Deeraj
Technical Editor
Mrunmayee Patil
Copy Editor
Lauren Harkins
Project Coordinator
Kinjal Bari
Proofreader
Safis Editing
Indexer
Mariammal Chettiyar
Graphics
Disha Haria
Production Coordinator
Nilesh Mohite
Cover Work
Nilesh Mohite
About the Author
James Pogran has been working with computers in some form or fashion for over 15 years. His first job was systems administration for a large military installation. He then moved on to develop monitoring software and automate large scale Windows environments for a major managed services provider. He is currently a software engineer at Puppet Labs where he helps to make Windows automation even better with Puppet.
Writing a book is no easy task, a technical one about a technology as important and as fast changing as DSC is doubly so. That I was able to do so in a short time was through no small effort by many people. I would first like to thank the PowerShell product team for their awesome work and community outreach, which is truly unique in this industry. I would also like to thank the team at Packt Publishing who worked tirelessly to keep me on schedule and enabled me to be the best I could be. I am also indebted to the technical reviewers who poured over this book and made sure it was the best book possible. I would especially like to thank my wife, Jessica, my mother and father, and Cecil Morris; without their support, I would not have had the courage to write this book at all.
About the Reviewers
Marcin Grzywa is a senior software developer at Objectivity Bespoke Software Specialists. After getting an MSc in computer science degree in 2008, he spent the following years developing and architecting applications in various technologies, including Java EE, MS Business Intelligence, .NET, and JavaScript. Having always been interested in improving development processes, he then focused on using TeamCity and PowerShell in Continuous integration (CI) pipelines, which led him to Configuration as Code and PowerShell DSC.
He is also the author of open source projects PSCI (Powershell Continuous Integration) and PowerShell ISE Project Explorer.
Brian Scholer is a systems engineer with over 13 years of experience across server administration, virtualization, software development, web operations, networking, and more. He is the author of the xPfxImport DSC Resource (pending inclusion in Microsoft's xCertificate module). He blogs at http://www.briantist.com/.
Sergei Vorobev is a software developer at Microsoft. After working on the DSC Azure extension, he concentrate on PowerShell language for PowerShell v5. He is passionate about developer tools and developer experience. You can find him on Twitter at @xvorsx, where he rambles on about languages, frameworks, version control systems, workflows, scripts, and one-liners.
I would like to thank the DSC team development lead Narayanan Lakshmanan for his wise mentorship.
Dave Wyatt has been in the IT industry since 1999, working primarily as a systems administrator and engineer for the Windows Server environments. He has been heavily focused on the scripting and automation of Windows systems since that time, and he became a Microsoft MVP (PowerShell) in 2014.
Currently, he is an operations engineer for DevOpsGuys, focusing mainly on building continuous delivery pipelines for clients, which includes the configuration management of Windows servers using Windows PowerShell Desired State Configuration. He is also on the board of directors for PowerShell.org, a not-for-profit PowerShell community organization.
He is the author of The Big Book of PowerShell Error Handling, and the coauthor of Secrets of PowerShell Remoting, both free e-books available at PowerShell.org.
Thanks to my wife, Kiersten, and daughter, Moira, who bring sunshine into every day of my life (and graciously put up with all of the extra time I spend on these side projects!) Also, thanks to Don Jones, who first recognized my potential for community contributions and invited me to write blog posts for PowerShell.org.
www.PacktPub.com
Support files, eBooks, discount offers, and more
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://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Free access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view 9 entirely free books. Simply use your login credentials for immediate access.
Instant updates on new Packt books
Get notified! Find out when new books are published by following @PacktEnterprise on Twitter or the Packt Enterprise Facebook page.
To my mother Marianne Pogran, who gave me the world when she taught me how to fix my first computer.
Preface
Windows PowerShell was a transformative event for the Windows management ecosystem. It marked a shift from the GUI-based administration of "click next, next, finish" to a composable command line experience that can be scripted and automated. This methodology was not accepted immediately by the Windows community, but time has proven the approach viable and PowerShell is now an integral part of any systems administrator's toolkit.
Windows PowerShell Desired State Configuration (DSC) marks another shift in Windows administration, but this time, it is a move away from the run-once scripts that cannot detect the existing state to declarative and repeatable automation without side effects. While PowerShell enabled an automation paradigm that was previously unmatched on Windows systems, crafting truly dependable automation took many lines of boilerplate code of exception catching and state checking. DSC handles this boilerplate code and gives you a clean and readable way to declare the expected state of your systems without worrying about how those systems are configured.
Whether you manage a few servers or several thousands of them, the same problems occur repeatedly. How do you ensure that all the servers under your care are configured to the exact specifications? How do you write those specifications down so that not only you and your coworker but also the machine understands them? This seemingly conflicting set of requirements is the purpose of DSC. Using DSC, you can write the human-readable desired state of the system you expect, and DSC ensures that the state of the system is what you desired it to be.
In this book, we will introduce the configuration management concepts that DSC uses to accomplish these feats. We then cover the architecture of DSC, which allows us to specify the state of a target system without having to code the implementation details ourselves. From there, we will cover how to create files that can be read by both DSC and humans to ensure that the state of target systems is what we specify. We will then address how to customize DSC to administer our customized and unique environments, and then walk through the ways in which we can deploy these configurations to the target systems using the different deployment models of DSC. We will wrap up with a walkthrough of a typical deployment cycle of example software using real-world problems and solutions.
What this book covers
Chapter 1, Introduction to PowerShell DSC, introduces you to PowerShell DSC and configuration management concepts. It covers the features included in DSC and briefly introduces the different DSC versions.
Chapter 2, DSC Architecture, covers all three phases of DSC in depth, the two different DSC deployment models, and the considerations to be made when deploying a Pull Server or using a push deployment.
Chapter 3, DSC Configuration Files, covers authoring the DSC configuration scripts and configuration data files from end to end. It also covers 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 on the local system as well as using community and Microsoft-provided online resources.
Chapter 5, Pushing DSC Configurations, gives step-by-step instructions on how to push DSC configurations to remote target nodes. It also covers the extra steps the user must take to make push deployments work and discusses the pros and cons of using push deployments.
Chapter 6, Pulling DSC Configurations, gives step-by-step instructions on how to set up 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, Example Scenarios, covers the use of DSC in the real world and how to integrate DSC into not only new environments but also with legacy-style deployments. This chapter walks us through the thought processes of handling the changing requests and the requirements of different software deployments using DSC.
What you need for this book
You will need the following operating systems:
You will also need PowerShell v4 or v5 as the software.
Who this book is for
This book is intended for system administrators, developers, or DevOps engineers who are responsible for configuration management and automation and wish to learn PowerShell Desired State Configuration for efficient management, configuration, and deployment of systems and applications.
You are expected to have some basic knowledge of Windows PowerShell and should have experience in installing and configuring operating systems and Windows servers. You also need to understand the basics and principles of configuration management and to apply both to deploying and managing systems and applications using PowerShell DSC.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "DSC operates in a push scenario when configurations are manually pushed to target nodes using the Start-DscConfiguration Cmdlet."
Any command-line input or output is written as follows:
Important words are shown in bold and appear in the text like this: "These will typically fail with a generic Access Denied, which will most likely lead you down the wrong path when troubleshooting."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
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 e-mail <[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 from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
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.
Why do we need Configuration Management?
Whether you manage a few servers or several thousand, 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 it.
For a long while, this has worked out. But as the number of servers and applications grow, and the number of configuration points grows, it becomes untenable to keep it all in your head, or consistently documented by a set of people. New patches are released, feature sets changed, 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 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, software developers are often isolated from the realities faced by IT professionals during the deployment and maintenance of the software.
The answer to this isautomation: 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 also provides a historical record of what was changed, which is useful not only for reporting purposes (like 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. It 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 is 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 technology 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 of that software. Continuous delivery is a set of practices that enable 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 report 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 like the ones shown in the Puppet Labs survey show that organizations that adopt 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 so. How DevOps enables high performance centers around deployment frequency.
To define and explain the entirety of DevOps and continuous delivery is out of the scope of this book, but for the purposes of this book, the goals can be summarized as the following: to improve the deployment frequency, to lower the failure rate of new releases, and to 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 development, 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 be 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:
A high level overview of DSC
We will go into 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.
As we mentioned earlier, DSC can manage more platforms than just Windows, but for the purposes of this book, we will stick to Windows configurations. The DSC Resources for Linux and other platforms are in the early stages, so there will be significant changes as these implementations mature; it would be too hard to account for these changes in the space we have in this book.
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 a 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 be difficult to manage quickly, but there are DSC patterns to follow to manage this. We will cover these in Chapter 3, DSC Configuration Files.
The next step is to translate the configuration script into a 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.
