Skip to content

02 Building_DSC_Artefacts.md

Latest commit

 

History

History
99 lines (66 loc) · 4.98 KB

02 Building_DSC_Artefacts.md

File metadata and controls

99 lines (66 loc) · 4.98 KB

Infrastructure Pipeline

This part of the workshop tries to solve (or highlight) different problems usually found in production environments.

  1. The Release Pipeline Model

  2. The DSC Configuration Data Problem

  3. Composing Roles and Configurations, DRY (Don't repeat Yourself)

  4. Splatting DSC Resources

Composing Roles and Configurations

First Step

Make sure that git is in your path, your execution policy set to allow running powershell scripts, and you have an Internet connection.

# Setting up Machine level Path environment variable (for persistence)
C:\> [Environment]::SetEnvironmentVariable('Path',($Env:Path + ';' + 'C:\Program Files\Git\bin'),'Machine')
# Setting up Process level variable
C:\> [Environment]::SetEnvironmentVariable('Path',($Env:Path + ';' + 'C:\Program Files\Git\bin'),'Process')
C:\> Set-ExecutionPolicy -ExecutionPolicy Bypass

The first step to kick off a build of the DSC Artefacts is to run this command:

C:\> Build.ps1 -ResolveDependency

This will pull all the dependencies from the PowerShell Gallery and save them in your project (but not in the git repository).

This will take some time, but when working on your workstation you don't need to pull everytime (only when you change one of the PSDepend definition files).

You can compare this build to the latest from AppVeyor: https://ci.appveyor.com/project/AutomatedLab/dscworkshop/

Pulling Dependencies from PSGallery

Have a look at what is pulled from those files:

  • [Modules used during the Build process] (./DSC//PSDepend.build.psd1)
  • [Modules containing the DSC Configurations (DSC Composite Resource)] (./DSC/PSDepend.DscConfigurations.psd1)
  • [Modules containing the DSC Resources] (./DSC/PSDepend.DscResources.psd1)

Note that for this workshop, we have added to git some files directly under the DscConfigurations folder, but that's not a best practice. In this control repository, you only want to manage trusted artefacts (built in their own pipelines) instead of directly using module sources as we're doing for this demo.

If you are using the full AutomatedLab demo, you can change those PSD1s to use the private repository:

  • Register DSCPull01.contoso.com on port 8624 as a the Internal PSRepository on the Build Server
  • Edit the PSDepend files to add the Parameter block and set the Repository = 'internal' (within PSDepend options)

Building the Artefacts

The DSC Artefacts are built within the Output folder inside of your repository. This folder will be created once the build has been executed.

You will mainly be interested in the following folders:

  • DscModules: The Modules containing the resources, zipped for a DSC Pull server
  • MetaMOF
  • MOF

PowerShell 7 Compatibility

When building on PowerShell 7, Get-DscResource scans the Windows PowerShell module path (C:\Windows\system32\WindowsPowerShell\v1.0\Modules) and encounters Desktop-only modules such as Microsoft.PowerShell.Management. PS 7 automatically creates a WinPSCompatSession remoting session to load them, producing dozens of warnings during DSC compilation.

Simply removing the Windows system path from PSModulePath is not viable because built-in DSC resources (WindowsFeature, Service, Registry, etc.) reside only in PSDesiredStateConfiguration 1.1 at that location.

The NoWinPSCompatibility build task in .build/SuppressWinPSCompatWarning.ps1 solves this by setting Import-Module -SkipEditionCheck globally before DSC resource discovery. This tells PS 7 to load the modules directly in-process instead of creating a compatibility remoting session, which eliminates the warnings while keeping all DSC resources available.

Going further

Now that you've built the provided infrastructure, you can try to understand how it works. :)

Have a look at the links provided above for reference, ask questions, and try the following (in no particular order).

  • Create a New node based on an existing Role (& compile)
  • Create a new Role and assign a node to that role (& compile)
  • Make some changes to existing roles in the Data, (& commit + (& compile)
  • Make a diff of the RSOP (Resultant Set of Policy to see the difference between different commits for a given node)
  • Add a layer to your hierarchy (i.e. Environment), and create some Override for that layer
  • Create a custom Configuration (DSC Composite Resource), and add it to a few roles (use the 'splatting' technique)
  • Add credential or encrypted data to the configuration Data
  • Find out what a Datum Handler can do for you!

Feel free to look at the Datum documentation, and to submit issues and Pull requests.