In the
configuration management life cycle in DSC, configuration delivery plays a
major role. Once a configuration is authored, a delivery mode helps to enact
the configuration on the target systems. These modes dictate how the
configuration is enforced and corrected, as required. DSC supports two types of
delivery modes: Push and Pull.
PUSH mode
In the PUSH
configuration delivery mode, the configuration to be enacted gets pushed to the
node, whether it is local or remote. This is unidirectional and immediate. In a
unidirectional mode the configuration is pushed from a management system to a target node. In push mode, the user initiates configuration
processing via the Start-DscConfiguration
cmdlet. This command immediately applies the configuration to the target, which
can be specified by the -ComputerName
parameter of the Start-DscConfiguration
DSC cmdlet. By default, this cmdlet uses the files in the -Path folder to find the target node details and the configuration
pushed to the node is enacted immediately.
The PUSH
mode can be viewed as:
Note:
Whether the target node is local or remote, it’s important to have the WinRM service up and running with the
appropriate WinRM listeners.
Limitations of PUSH mode
The PUSH
mode is easy to configure and use as it does not require any infrastructure
services, such as a central shared location to host the configurations.
However, the Push mode is not scalable. Pushing configuration to hundreds or
thousands of systems would take quite long and can be limited, based on the
resources available on the system on which the Start-DscConfiguration cmdlet is being run.
To enact
configuration, we need all resource modules to be present on the target system.
This represents another limitation of the Push mode. For example, if you have
custom DSC resources used in a configuration script, the modules for these
resources must be copied to target systems prior to pushing the configuration
PULL mode
Unlike the
Push mode for configuration delivery, the Pull mode is bidirectional. This
means that the pull server and the client both communicate with each other to
manage the client configuration. In PULL mode the DSC Local Configuration
Manager (LCM) can periodically poll a server for new configurations and keep
the servers in compliance with the configuration and avoid drift. The Local
Configuration Manager (LCM) of target node periodically performs a compliance
check on the configuration of the node using a checksum on the MOF file. If the
checksum is the same then nothing happens. Otherwise the LCM requests the new
configuration and once it is transmitted to the client, the LCM executes it and
also ensures that any missing resources that are part of the configuration is
downloaded as well.
The PULL
mode can be viewed as with the pull server configured to use SMB (Server
Message Block)
To configure
an SMB based pull server, you can use the New-SmbShare
cmdlet to create a file share that can store the configuration and custom
modules.
New-SmbShare -Name
MySMBPullServer -Path E:\DSCShare -ReadAccess Everyone -Description "PULL
server SMB"
Configuring the PULL client based on
SMB
The download
manager for SMB based pull clients is DSCFileDownloadManager.
You can configure the LCM for SMB based pull clients by creating a
configuration like and executing on the local machine
Configuration LCMSMBConfig {
Node MyServer1 {
LocalConfigurationManager {
ConfigurationID = '9C3DE0FC-FCB2-491F-B5EF-22DE7A368DE6'
RefreshMode = "Pull"
DownloadManagerName = "DscFileDownloadManager"
DownloadManagerCustomData = @{SourcePath = "\\MyServer1\DSCResources"}
ConfigurationModeFrequencyMins = 60
RefreshFrequencyMins = 30
}
}
}
LCMSMBConfig
Set-DscLocalConfigurationManager -Path .\LCMSMBConfig
Later when
creating PULL configurations for the clients to react, you can use the GUID
mentioned in the ConfiguationID
property for the target machine as the Node value.
No comments:
Post a Comment