Инфраструктура как код ia c часть 3 желаемая конфигурация состояния dsc

On many popular forums, the question arose “is Desired State Configuration still alive”? If you look at the statistics on the PowerShell Gallery, many popular DSC Resources are still being updated frequently.

You might also not be aware, that the PowerShell team has released the alpha version of DSCv3, which is publicly available.

To come back to the question then, “is Desired State Configuration still alive”? Personally, I would say it is!

DSCv3 is wholly rewritten and became open-source. In this article, you will learn the differences compared to v2.

Desired State Configuration (DSC) is a management platform in PowerShell that enables you to manage your IT and development infrastructure with configuration as code.

It was first released in PowerShell version 4.0 and can be used to automate the configuration of Windows and Linux operating systems.

No Active Directory and GPOs are needed.

DSC runs within the Local Configuration Manager (LCM) engine which is a system module from Windows. The LCM runs on every target node and is responsible for parsing and enacting configurations that are sent to the node which should be configured.

For Linux the Open Management Infrastructure (OMI) stack acts as a similar counterpart to LCM on Windows systems and is designed for Linux and other Unix-like operating systems. OMI is often used in conjunction with configuration management tools like PowerShell DSC for cross-platform configuration management.

Converting Desired State Configuration (DSC) PowerShell scripts directly to JSON or YAML is not a straightforward automated process because DSC scripts and JSON/YAML serve different purposes. DSC scripts define the desired state of a system using a specific PowerShell syntax, while JSON and YAML are data serialization formats. However, you can manually create JSON or YAML representations of the configuration data defined within a DSC script. This process involves interpreting the configuration elements within the DSC script and representing them in JSON or YAML format.

For example-
First, you need a DSC configuration defined in a .ps1 file.

Configuration MyWebServer { Import-DscResource -ModuleName 'PSDesiredStateConfiguration' Node localhost { WindowsFeature IIS { Ensure = "Present" Name = "Web-Server" } }
}
Write-Host "MyWebServer configuration has been loaded."

Run the configuration script to generate a .mof file. This .mof file represents the desired state in a standardized format that DSC can understand.

To convert the DSC configuration to JSON, you need to extract the configuration data. However, DSC configurations do not natively support exporting directly to JSON or YAML. As a workaround, you could define the configuration data as a hashtable and export it to JSON.

Let’s assume we’ve modeled our DSC configuration data like so:

#ConfigurationData.ps1
$ConfigurationData = @{ AllNodes = @( @{ NodeName = 'localhost' PSDscAllowPlainTextPassword = $true PSDscAllowDomainUser = $true } ) WindowsFeature_IIS = @{ Ensure = 'Present' Name = 'Web-Server' }
}
#Convert the configuration data to JSON
$json = $ConfigurationData | ConvertTo-Json -Depth 5
#Save the JSON

Now, convert this hashtable to JSON using the ConvertTo-Json cmdlet in PowerShell. This will create a MyDscConfiguration.json file with your configuration data.

Now if you further want to convert this json to yaml then PowerShell does not have a built-in cmdlet to convert JSON to YAML, but you can install a third-party module called powershell-yaml to accomplish this.

After you’ve installed the powershell-yaml module, the next steps are to import the module, convert the JSON content to YAML, and save it. Run the below commands , just modify the path as per your own

# Import the powershell-yaml module
Import-Module powershell-yaml
# Path to the JSON file
$jsonFilePath = "C:\Users\arko\Downloads\MyDscConfiguration.json"
# Read the JSON file content
$jsonContent = Get-Content -Path $jsonFilePath -Raw
# Convert the JSON content to a PowerShell object
$object = ConvertFrom-Json -InputObject $jsonContent
# Convert the PowerShell object to YAML
$yaml = $object | ConvertTo-Yaml
# Path to the YAML file
$yamlFilePath = "C:\Users\arko\Downloads\MyDscConfiguration.yaml"
# Save the YAML content to a file
$yaml | Out-File -FilePath $yamlFilePath

you will end up with a MyDscConfiguration.yaml file in your directory wherever you have given the path.

Introduction

Desired State Configuration (DSC) is a feature of PowerShell where modules are structured in a specific way to simplify configuration management in Linux and Windows machines.

DSC is a declarative language, where the state of a machine is described using a format that should be clear to understand even if the reader is not a subject matter expert. DSC is unique compared to imperative PowerShell script format, because the definition of an application environment is separate from the script logic that implements how it is delivered.

There are two primary components:

• Configurations are declarative PowerShell scripts that define instances of resources. Typically configurations define what to automate. Example scenarios include requirements for an application environment or operational/security standards.
• Resources contain the script functions that define how to automate. Resources always contain three methods, “Get”, “Test”, and “Set”. Example scenarios include how to update the contents of a file, how to run a utility that changes the state of a machine, or how to configure settings of an application.

As of version 7.2, the module PSDesiredStateConfiguration containing the DSC feature and must be installed as an independent component after you install PowerShell. Separating DSC into an independent module reduces the size of the PowerShell release package, and allows DSC to be upgraded on machines without also planning an upgrade of the PowerShell 7 installation.

Versions

There are three versions of DSC available:

• DSC 1.1 is the legacy version of DSC that originally shipped in Windows PowerShell 5.1.
• DSC 2.0 is the version of DSC that shipped in PowerShell 7.
• DSC 3.0 is the new version of DSC. This version is a preview release that is still being developed. Users working with non-Windows environments can expect cross-platform features in DSC 3.0. DSC 3.0 is the version that is supported by the machine configuration feature of Azure Automanage.

The documentation for DSC has been moved to a new location so that we can manage the DSC version-specific information separate from the versions of PowerShell.

See the new documentation in Desired State Configuration 2.0.

Documentation

Desired State Configuration 2.0

DSCv3 leverages the PSDesiredStateConfiguration module to support compatibility with existing PowerShell based resources.

DSCv3 differs from PowerShell Desired State Configuration (PSDSC) in a few important ways:

• DSCv3 doesn’t depend on PowerShell. You can use DSCv3 without PowerShell installed and manage resources written in bash, python, C#, Go, or any other language.
• DSCv3 doesn’t include a local configuration manager. DSCv3 is invoked as a command. It doesn’t run as a service.
• Non-PowerShell resources define their schemas with JSON files, not MOF files.
• Configuration documents are defined in JSON or YAML files, not PowerShell script files.

Resources

A resource can model something as generic as a file or as specific as an IIS server setting. Groups of like resources are combined in to a DSC Module, which organizes all the required files in to a structure that is portable and includes metadata to identify how the resources are intended to be used.

Here you will see a list by using PowerShell version 7.3.4 on a Windows Server 2019.

Ensure=Present –> will ensure that a configuration will be applied if not already done.
Ensure=Absent –> will ensure that a configuration will be revoked if already applied

Local Configuration Manager (LCM)

• Determining refresh mode (push or pull).
• Specifying how often a node pulls and enacts configurations.
• Associating the node with pull service.
• Specifying partial configurations.

RefreshFrequencyMins
The time interval, in minutes, at which the LCM checks a pull service to get updated configurations and checks local configuration for drift. The configuration is applied regardless of whether an update was downloaded. This value is ignored if the LCM is not configured in pull mode. The default value is 30.

RefreshMode
Specifies how the LCM gets configurations. The possible values are “Disabled”, “Push”, and “Pull”.

Get started with Desired State Configuration (DSC) for Windows

• Ensure=Present –> will ensure that a configuration will be applied if not already done.
• Ensure=Absent –> will ensure that a configuration will be revoked if already applied.
• DependsOn=”[Ressourcentypename]RessourceName”
  Typically resources are applied in the order they are defined within the Configuration. As your Configuration grows larger and more complex, you can use the DependsOn key to change the applied order of your resources by specifying that a resource depends on another resource.

Creating a configuration MOF document

To declare our configuration for the system, we need to create a DSC document which has the file type .mof for Managed Object Format (MOF).

Below we will see a first example about how to create a DSC document and apply the configuration to a computer.

The Configuration will ensure a HelloWorld.txt file exists on your local machine. If you delete the file, DSC will recreate it the next time it updates.

In more advanced scenarios where multiple modules need to be imported so you can work with many DSC Resources in the same configuration, make sure to put each module in a separate line using Import-DscResource. This is easier to maintain in source control and required when working with DSC in Azure State Configuration.

Configuration HelloWorld { # Import the module that contains the File resource. Import-DscResource -ModuleName PsDesiredStateConfiguration Import-DscResource -ModuleName xWebAdministration

Configuration HelloWorld { # Import the module that contains the File resource. Import-DscResource -ModuleName PsDesiredStateConfiguration # The Node statement specifies which targets to compile MOF files for, when # this configuration is executed. Node localhost { # The File resource can ensure the state of files, or copy them from a # source to a destination with persistent updates. File HelloWorld { DestinationPath = "C:TempHelloWorld.txt" Ensure = "Present" Contents = "Hello World from DSC!" } }
}

Save the file as HelloWorld.ps1.

The configuration calls one resources, the File resource. Resources do the work of ensuring that the target node is in the state defined by the configuration.

Dot source your HelloWorld.ps1 script by typing in the path where you stored it, after the . (dot, space). You may then, run your configuration by calling it like a function.

You could also invoke the configuration function at the bottom of the script so that you don’t need to dot-source.

HelloWorld -Output .Output

So the complete DSC document will now looks like this.

Configuration HelloWorld { # Import the module that contains the File resource. Import-DscResource -ModuleName PsDesiredStateConfiguration # The Node statement specifies which targets to compile MOF files for, when # this configuration is executed. Node localhost { # The File resource can ensure the state of files, or copy them from a # source to a destination with persistent updates. File HelloWorld { DestinationPath = "C:TempHelloWorld.txt" Ensure = "Present" Contents = "Hello World from DSC!" } }
}
HelloWorld -Output .Output

Now that you have the compiled MOF, you can apply the configuration to the target node (in this case, the local computer) by calling the Start-DscConfiguration cmdlet.

The Start-DscConfiguration cmdlet tells the Local Configuration Manager (LCM), the engine of DSC, to apply the configuration. The LCM does the work of calling the DSC resources to apply the configuration.

Use the code below to execute the Start-DSCConfiguration cmdlet. Specify the directory path where your localhost.mof is stored to the Path parameter. The Start-DSCConfiguration cmdlet looks through the directory specified for any <computername>.mof files. The Start-DSCConfiguration cmdlet attempts to apply each .mof file it finds to the computername specified by the filename (“localhost”, “server01”, “dc-02”, etc.).

Start-DscConfiguration -Path C:ScriptsHelloWorld -Verbose -Wait

Once the Start-DSCConfiguration cmdlet is complete, you should see a HelloWorld.txt file in the location you specified.

Apply the configuration to the machine

To allow DSC to run, Windows needs to be configured to receive PowerShell remote commands even when you’re running a localhost configuration. To easily configure your environment correctly, just run Set-WsManQuickConfig -Force in an elevated PowerShell Terminal.

Installation and configuration for Windows Remote Management
https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management

You can apply Configuration documents (MOF files) to a machine with the Start-DscConfiguration cmdlet.

Start-DscConfiguration -Path ‘C:<path .mof files>’ -Wait -Verbose

Get the current state of the configuration

The Get-DscConfiguration cmdlet queries the current status of the machine and returns the current values for the configuration.

If a configuration is applied you will see something like this.

Install new PowerShell Version

Recommended way to install PowerShell on Windows clients is to use the winget command.

Search for the latest version of PowerShell
PS C:> winget search Microsoft.PowerShell

Install PowerShell or PowerShell Preview using the id parameter
PS C:> winget install –id Microsoft.Powershell –source winget
PS C:> winget install –id Microsoft.Powershell.Preview –source winget

Best choice for Windows Servers and enterprise deployment scenarios is the MSI package.

Determine PowerShell version

PS C:> $PSVersionTable

Install Desired State Configuration (DSC)

PowerShell includes several Out-of-the-box resources for Desired State Configuration (DSC). The PSDesiredStateConfiguration module contains all of the OOB DSC resources available on your specific instance of PowerShell.

Below you will find a list of the OOB resources included in PowerShell 4.0 and a description of the resource’s capabilities.

Install Additional DSC Resources
https://learn.microsoft.com/en-us/powershell/dsc/configurations/install-additional-dsc-resources?view=dsc-1.1

The OOB resources allow a good starting point for common operations. If the OOB resources do not meet your needs, you can write your own Custom Resource. Before you write a custom resource to solve your problem, you should look through the vast number of DSC resources that have already been created by both Microsoft and the PowerShell community.

You can find DSC Resources on both the PowerShell Gallery and GitHub. You can also install DSC Resources directly from the PowerShell console using PowerShellGet.

PowerShellGet is a module with commands for discovering, installing, updating and publishing PowerShell artifacts like Modules, DSC Resources, Role Capabilities, and Scripts.

If you’re running PowerShell 6.0 or later, you already have a newer version of PowerShellGet and PackageManagement installed. You can upgrade to a newer version if necessary or install the preview release. You should always install the latest stable release.

Get-Module PowerShellGet, PackageManagement -ListAvailable

Install-Module -Name xPSDesiredStateConfiguration

The xPSDesiredStateConfiguration module contains the same resources as the module PSDscResources but also includes bugfixes and new features, including additional resources. Some resources in this module use the prefix ‘x’ to not conflict with the older built-in resources in the Windows PowerShell PSDesiredStateConfiguration module and the PSDscResources module. The prefix ‘x’ has no other meaning and does not indicate that these are experimental resources.

This module is no longer comparable with the module PSDscResources as they are completely separate modules and they have a different lifecycle. The xPSDesiredStateConfiguration module surpasses the PSDscResources module in both features and bugfixes.

The module xPSDesiredStateConfiguration is supported by the DSC community who fixes bugs and adds features.

The module PSDscResources is supported by Microsoft and is meant to be 1:1 replacement for the built-in resources (in Windows PowerShell), with the exception for the File resource. For that reason new features are no longer being added to the PSDscResource module, and bugfixes must be approved (most likely through a Microsoft Support case) to be merged. If you require new features or missing bugfixes, please migrate to xPSDesiredStateConfiguration and request/add the features or bugfixes against this module.

After installing the xPSDesiredStateConfiguration module you will see a bunch of additional resources when executing the Get-DscResoure cmdlet like shown below.

Get-DscResource -Module <ModulePrefix* or full name>

e.g.
Get-DscResource -Module PSDscResources

Install PowerShell Packages for DSC

In order to extend the range of functions (various configuration items on a machine) you can install additional packages for DSC.

All packages with an x as prefix are experimental and there will be no support for.

Get-Module vs. Get-InstalledModule

Get-InstalledModule lists all modules that were installed by using the Install-Module cmdlet (installed by PowerShellGet).

Get-Module shows modules from all locations mentioned in $env:PsModulePath location. List the modules imported in the current session or that can be imported from the PSModulePath.

The Get-Module cmdlet lists the PowerShell modules that have been imported, or that can be imported, into a PowerShell session. Without parameters, Get-Module gets modules that have been imported into the current session. The ListAvailable parameter is used to list the modules that are available to be imported from the paths specified in the PSModulePath environment variable ($env:PSModulePath).

Remove a Desired State Configuration (DSC)

This cmdlet removes that configuration document (.mof file) from the Windows PowerShell Desired State Configuration (DSC) configuration store and does additional cleanup.

$Session = New-CimSession -ComputerName “Server01” -Credential ACCOUNTSPattiFuller
Remove-DscConfigurationDocument -Stage Current -CimSession $Session

A CIM session is a client-side object representing a connection to a local computer or a remote computer. The CIM session contains information about the connection, such as ComputerName, the protocol used, or various identifiers.

The second command removes the current configuration document for the computer specified in the CimSession stored in $Session.

In this case if no current configuration is applied to the target node, this folder on the target node will looks like this.

Now I will push a configuration from another node to the target node.

• Previous.mof
• Pending.mof

Remove-DscConfigurationDocument -Stage Current, Pending, Previous -Verbose

Desired State Configuration Pull Service

So far we just used the Push mode where we delivered the MOF file manually to the target node and its local LCM to enact it.

There is also a further and more complex method to deploy the MOF file automatically to the target nodes and is called Pull mode.

The Pull Server (Windows Feature DSC-Service) is a supported component of Windows Server however there are no plans to offer new features or capabilities.

It is recommended to begin transitioning managed clients to Azure Automation DSC (includes features beyond Pull Server on Windows Server) or one of the community solutions listed here.

Before you enable Automation State Configuration, we would like you to know that a newer version of DSC is now generally available, managed by a feature of Azure Policy named guest configuration. The guest configuration service combines features of DSC Extension, Azure Automation State Configuration, and the most commonly requested features from customer feedback. Guest configuration also includes hybrid machine support through Arc-enabled servers.

!!! Note !!!
Azure Policy Guest Configuration is now called Azure Automanage Machine Configuration.

Links

Windows Management Framework
https://learn.microsoft.com/en-us/powershell/scripting/windows-powershell/wmf/overview

DSC Resource Kit
https://github.com/powershell/dscresources

Configuring the Local Configuration Manager
https://learn.microsoft.com/en-us/powershell/dsc/managing-nodes/metaconfig

PowerShell Desired State Configuration overview
https://learn.microsoft.com/en-us/powershell/dsc/overview?view=dsc-3.0

Samples

Below we will see some samples of configuration scripts (DSC documents with the file extension *.ps), which will be used to generate a Managed Object Format (MOF) file we finally use to apply the configuration to the nodes.

Configurations are declarative PowerShell scripts

# Create the MOF file
.<Configuration DSC Document>.ps1
# Publish (Push) the MOF file
Start-DscConfiguration -Path .<Folder with .mof files> -Wait -Verbose -Force
# This example specifies the Verbose parameter. Therefore, the command sends messages to the console as it proceeds.
# The command includes the Wait parameter. Therefore, you cannot use the console until the command finishes all configuration tasks.

Crate a File

Configuration HelloWorld { # Import the module that contains the File resource. Import-DscResource -ModuleName PsDesiredStateConfiguration # The Node statement specifies which targets to compile MOF files for, when # this configuration is executed. Node localhost { # The File resource can ensure the state of files, or copy them from a # source to a destination with persistent updates. File HelloWorld { DestinationPath = "C:TempHelloWorld.txt" Ensure = "Present" Contents = "Hello World from DSC!" } }
}
HelloWorld -Output .Output

Create a Folder

Configuration CreateFolder { Import-DscResource -ModuleName PSDesiredStateConfiguration Node localhost { File CreateDataDir { DestinationPath = 'D:DSC TestingFolder1' Ensure = 'Present' Type = 'Directory' } }
}
CreateFolder -Output .Output

Create a Registry Entry

configuration CreateRegistryEntries
{
node localhost
{ Registry CreateFirstRegEntry { Ensure ="Present" Key ="HKEY_LOCAL_MACHINESOFTWAREblog.matrixpost.net" ValueName="FirstValueName" ValueData="123" } Registry CreateSecondRegEntry { Ensure ="Present" Key ="HKEY_LOCAL_MACHINESOFTWAREwww.matrixpost.net" ValueName="FirstValueName" ValueData="123" }
}
}
CreateRegistryEntries -Output .Output

Adding Windows Features (Telnet Client)

The WindowsFeature resource in Windows PowerShell Desired State Configuration (DSC) provides a mechanism to ensure that roles and features are added or removed on a target node.

To determine the correct Name property, use the Get-WindowsFeature cmdlet like shown below.

The WindowsFeature resource is also included in the main module PsDesiredStateConfiguration as you can see below when listing all resources installed on the source node from which you will push the configuration.

So the configuration DSC document will looks like this.

Configuration TelnetClient { # Import the module that contains the WindowsFeature resource. Import-DscResource -ModuleName PsDesiredStateConfiguration # The Node statement specifies which targets to compile MOF files for, when # this configuration is executed. Node SQL2019.braincourt.de { # The WindowsFeature resource in Windows PowerShell Desired State Configuration (DSC) provides a # mechanism to ensure that roles and features are added or removed on a target node. WindowsFeature TelnetClient {	Ensure = "Present"	# Alternatively, to ensure the feature is uninstalled, set Ensure to "Absent"	Name = "Telnet-Client" # Use the Name property from Get-WindowsFeature } }
}
TelnetClient -Output .Output

Pushing the configuration this time takes a little bit longer than for the previously samples which is obviously because installing a WindowsFeatures on the target node takes more time like creating a new file or registry entry.

Finally the Telnet Client feature is installed on the target node.

Adding Windows Roles (Network Policy and Access Services NPS)

To determine the correct Name property, we will use again the Get-WindowsFeature cmdlet like shown below.

The WindowsRole resource is include in the WindowsFeature resource which himself is included in the main module PsDesiredStateConfiguration as we previously saw.

The configuration DSC document will looks like this, up to the Name property its the same as previously for the Windows Feature, so here its not different to configure roles.

Configuration Nps { # Import the module that contains the WindowsFeature resource. Import-DscResource -ModuleName PsDesiredStateConfiguration # The Node statement specifies which targets to compile MOF files for, when # this configuration is executed. Node SQL2019.braincourt.de { # The WindowsFeature resource in Windows PowerShell Desired State Configuration (DSC) provides a # mechanism to ensure that roles and features are added or removed on a target node. WindowsFeature Nps {	Ensure = "Present"	# Alternatively, to ensure the feature is uninstalled, set Ensure to "Absent"	Name = "NPAS" # Use the Name property from Get-WindowsFeature } }
}
Nps -Output .Output

Finally the Network Policy and Access Services are installed on the target node.

Похожее:

Топ-3 модуля power shell Создание модуля power shell Скачать Все официальные темы Windows с сайта Microsoft 28.11.2019 Power shell и его возможности в уходящем году