Get best of the week

您在哪一边：推入和拉入所需状态配置

我们已经描述了如何在所需状态配置（DSC）中描述配置，并拆解了内置的本地配置管理器（LCM）代理以将配置应用于服务器。在文章的第一部分，我们走一步上沿工具的主要功能一步叶夫根Parfenov从的DataLine。

在这里，我们深入了解“推”和“推”模式下的设置和功能。



我们将说：


  1. 推和拉模式之间的差异
  2. 推送模式详细
  3. 拉模式详细

推和拉模式之间的差异


在“推送”模式下，我们手动或通过脚本启动将更改应用于服务器（本地或远程）的过程。本地配置管理器（LCM）以交互方式应用配置。

在拉模式下，服务器上计划的LCM代理将其配置与共享配置存储库中发布的配置进行比较。如果有更改，则将配置复制到本地并应用。

两种操作模式的优缺点都非常明显。
推拉
+
  1. 成本。它不需要安装其他服务器。
  2. 简单的架构。所有配置都以便于管理员使用的形式存储在本地。
  3. 适合测试。Dsc
  4. DevOps方式。部署服务器时，非常容易实现自动化，并且符合基础架构即代码的理念。
  5. run-once .
  1. . .
  2. . DSC .
  3. Azure Automation State Configuration, Windows Server 2012R2+
–
  1. On-Premise c . , .
  1. , .
  2. On-Premise GPO, .
  3. — , .
对于不同的模式，设置资源也略有不同。我们记得，要使用资源，您需要在本地和服务器上安装资源。

在使用“推送”模式的情况下，管理员必须首先在所有要提交配置的受管服务器和PC上安装所有必需的资源。

在拉模式下，受管服务器上的DSC代理可以独立地从拉服务器安装所有必需的资源；管理员的任务是将它们放置在拉服务器上。但是，请记住，由于GPO不能保证交付设置，因此无法预测在Pull模式下配置的应用。

推送模式详细


编写和应用DSC配置



的顶层过程可以表示如下：在第一阶段（创作），我们使用对我们方便的任何IDE（记事本，PowerShell ISE，Visual Studio Code等）描述配置。完成后，我们将编译mof配置文件（编译过程已在上一篇文章中进行了描述）。

在第二阶段（登台/编译）中，我们开始使用Start-DSCConfiguration cmdlet从编译的mof文件中应用配置。在此过程中，管理服务器将传输LCM服务器.mof文件，以应用配置。
在这种情况下，最好使用-Verbose开关。 为了完全控制配置过程：

PS C:\windows\system32> Start-DscConfiguration -Path C:\EnvironmentVariable_Path\ -Wait -Verbose

# C 
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer COMPUTER with user sid
S-1-5-21-SID.

#  
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]
VERBOSE: [COMPUTER]: LCM:  [ Start  Resource ]  [[Environment]CreatePathEnvironmentVariable]

#       (test)
VERBOSE: [COMPUTER]: LCM:  [ Start  Test     ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' does not exist.
VERBOSE: [COMPUTER]: LCM:  [ End    Test     ]  [[Environment]CreatePathEnvironmentVariable]  in 0.1320 seconds.
#      “Environment variable 'TestPathEnvironmentVariable' does not exist”

#       
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' created with value 'TestValue'.
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]  [[Environment]CreatePathEnvironmentVariable]  in 0.0690 seconds.
VERBOSE: [COMPUTER]: LCM:  [ End    Resource ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]    in  2.1900 seconds.
#  

#  
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 2.749 seconds

可以看出，引擎根据指定的配置检查了变量的存在，没有找到它并创建了一个新变量：



在第三阶段（执行），DSC代理LCM进入游戏。它接收一个mof文件，对其进行检查，将其放置在文件夹中，$env:systemRoot/system32/configuration并启动应用该配置文件的工作流程：

  1. LCM接收并应用配置文件。该文件被重命名为pending.mof，并放置在$env:systemRoot/system32/configuration
    • 如果配置文件的应用程序失败，则pending.mof文件将保留，LCM将尝试在下一个周期中应用它。
  2. 如果当前.mof文件已在文件夹中，则将其重命名为previous.mof
  3. 如果配置文件的应用程序成功完成，则LCM会将其重命名为current.mof
  4. 将当前.mof文件复制到backup.mof文件

图形化地，工作流可以表示为：



为了管理不同的配置文件，有一个Remove-DSCConfigurationDocument cmdlet，如果由于某些原因需要删除特定的文档，该cmdlet允许您删除它。但是，没有什么阻止我们手动删除它们。

拉模式详细


拉模式更难以部署和配置，但是它大大简化了管理与其连接的服务器的过程。

一般方案如下所示：



拉模式需要部署拉服务器。实际上，它是一个常规的Web服务器，可以为客户端提供mof文件和从mof文件应用配置时可能需要的资源。后者大大简化了管理和配置服务器的过程，因为交付必要资源的任务在于客户端。 Pull服务器同时充当存储库\资源存储库。

Pull服务器可以通过两种协议提供对资源和配置文件的访问：

  1. SMB. . DFS-R. , , . SMB , Kerberos.
  2. Http\https. . IIS.

提取服务器的安装可以通过DSC开发团队提供的常规资源来完成。可以在此处找到更多详细信息。或使用社区驱动的解决方案：此处或此处。

拉取服务器的进一步工作流程如下：

  1. 我们将客户端（LCM）配置为与拉取服务器一起使用。
  2. 我们将资源文件上传到拉取服务器。
  3. 我们准备客户端配置文件（编写和编译）以及带有校验和的文件。
  4. 享受结果。

配置客户端（LCM）与拉取服务器一起使用

为此，请使用以下LocalConfigurationManager（v5）设置：设置

块：

  • CertificateID-表示证书的指纹，以保护配置中传输的登录名/密码。
  • ConfigurationID-包含客户端GUID。只有那些在配置文件名中包含其GUID的配置才会应用于客户端。保留该设置是为了与拉取服务器的旧版本兼容。最好使用RegistrationKey设置。
  • RefreshMode-要使用Pull服务器，请在此设置中指定Pull。

块配置存储库Web：

  • AllowUnsecureConnection-允许\不允许未经身份验证的连接。
  • CertificateID-表示客户端上证书的指纹，将在与服务器的相互身份验证过程中使用。
  • ConfigurationNames-将应用于客户端的配置名称数组。
  • RegistrationKey-在服务器上生成的秘密，客户端使用它在服务器上进行注册。
  • ServerURL-具有配置的Pull服务器的URL。

ResourceRepositoryWeb 块：

  • AllowUnsecureConnection-允许\不允许未经身份验证的连接。
  • CertificateID-表示客户端上证书的指纹，将在与服务器的相互身份验证过程中使用。
  • RegistrationKey-在服务器上生成的秘密，客户端使用它在服务器上进行注册。
  • ServerURL-具有资源的Pull服务器的URL。

ReportServerWeb 块：

  • AllowUnsecureConnection-允许\不允许未经身份验证的连接。
  • CertificateID-表示客户端上证书的指纹，将在与服务器的相互身份验证过程中使用。
  • RegistrationKey-在服务器上生成的秘密，客户端使用它在服务器上进行注册。
  • ServerURL-具有报告的Pull服务器的URL。

将资源文件上传到Pull服务器

在LCM上应用了新设置后，它将教他如何使用Pull服务器，您可以将资源文件上传到该服务器。资源以zip文件的形式上载到服务器（带有资源的文件夹打包在zip中）。命名此类文件的规则：

{ModuleName}_{Version}.zip

默认文件位置$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules。安装Pull服务器时，可以重新定义此文件夹。除了将资源文件夹打包为zip的文件之外，还必须将带有此打包资源的校验和的文件放在同一位置。例如，像这样：

New-DscChecksum -Path .\xPSDesiredStateConfiguration_8.4.4.0.zip

将客户端配置文件放置在Pull服务器上

这里要特别注意的是，在这种情况下，我们可以使用两种客户端操作模式（实际上是两种半）：来自服务器的客户端将使用ConfigurationID接收配置，或者客户端将使用配置名称-ConfigurationName。如果有必要应用多个配置，则可以在ConfigurationName中指定所有配置，但是必须配置LCM才能使用部分配置。

使用ConfigurationID时，必须强调将应用于客户端的mof配置文件将包含一个GUID（包含在ConfigurationID中）。在使用ConfigurationName的情况下，mof文件将包含我们将在ConfigurationName中指定的配置名称。在这两种情况下，除了mof文件之外，配置校验和文件也将放置在此处：

New-DscChecksum -Path '.\' -Force

结论


我们研究了两种在推和拉模式下将更改应用于服务器的方法。我们介绍了使用功能，并试图解释在DSC中使用这些模式时可能出现的所有细微差别。如果您还有问题，请在评论中进行讨论。如果您没有足够的可视性，请参加5月28日的在线会议：我们将分析统一通信和通信设施的系统（在Elastic，iOS，Android和Windows 10的Microsoft Endpoint Manager中设置上传Exchange日志），并详细讨论适用性的限制PowerShell所需状态配置。您只需要注册。

More articles:


All Articles