"As an architect you design for the present, with an awareness of the past for a future which is essentially unknown." | ||
| --Herman Foster | ||
In the last chapter, we covered what PowerShell DSC is and how it fits into a continuous delivery and DevOps process. DSC uses PowerShell language extensions to define configuration files that express the expected state of a target node. We know that DSC uses DSC Resources to determine whether or not the current state of the target node matches the expected state and that these resources know how to change the current state to the expected state.
In this chapter, we will cover the following topics:
- Push and pull management
- General workflow
- Local Configuration Manager
- DSC Pull Server
- Deployment considerations
We are in a precarious position in writing about DSC. In order to explain any one concept, we tend to have to explain a couple more before we get to it. We are going to start out here with some terms and examples of configuration files, DSC settings, and workflow models, but for the most part, the words and actions used will not be clear at first. They are explained in the chapters ahead in greater detail. Remember the previous chapter? Don't panic! If you find yourself getting confused about why something is important, it may become clear as we move from the explanation to putting it into practice. So, for now, look at them and get a feel for the flow of operations, and then come back to them as we touch each step in the operations process in later chapters.
DSC enables you to ensure that the components of your server environment have the correct state and configuration. It enables declarative, autonomous, and idempotent deployment, as well as configuration and conformance of standards-based managed elements.
By its simplest definition, DSC is a Windows service, a set of configuration files, and a set of PowerShell modules and scripts. Of course, there is more to it than that; there's push and pull modes, MOF compilation, and module packaging, but this is really all you need to describe DSC architecture at a high level.
At a lower level, DSC is much more complex. It has to be complex to handle all the different variations of operations you can throw at it. Something so flexible has to have some complicated inner workings. The beauty of DSC is that these complex inner workings are abstracted away from you most of the time, so you can focus on getting the job done. If you need to, you can also access the complex inner workings and tune them to your needs.
To ensure that we are all on the same page about the concepts we are going to cover, let's cover some terms that we have seen over the course of the last chapter, since we will be seeing them in this chapter as well. This won't be an exhaustive list, but it will be enough to get us started.