Auf welcher Seite befinden Sie sich: Push and Pull in der gewünschten Statuskonfiguration

Wir haben bereits beschrieben, wie die Konfiguration in DSC (Desired State Configuration) beschrieben wird, und den integrierten LCM-Agenten (Local Configuration Manager) zerlegt, um die Konfiguration auf den Server anzuwenden. Im ersten Teil des Artikels haben wir Schritt für Schritt die Hauptfunktionen des Tools zusammen mit Evgeny Parfenov von DataLine erläutert .

Hier gehen wir auf die Einstellungen und Funktionen in den Push- und Pull-Modi ein.



Was wir erzählen werden:


  1. Unterschiede zwischen Push- und Pull-Modus
  2. Push-Modus im Detail
  3. Pull-Modus im Detail

Unterschiede zwischen Push- und Pull-Modus


Im Push-Modus starten wir manuell oder per Skript den Prozess des Überbringens von Änderungen auf den Server (lokal oder remote). Local Configuration Manager (LCM) wendet die Konfiguration interaktiv an.

Im Pull-Modus vergleicht der geplante LCM-Agent auf dem Server seine Konfiguration mit der im freigegebenen Konfigurationsrepository veröffentlichten Konfiguration. Bei Änderungen wird die Konfiguration lokal kopiert und angewendet.

Die Vor- und Nachteile beider Betriebsarten liegen auf der Hand.
drückenziehen
+
  1. Kosten. Es ist nicht erforderlich, zusätzliche Server zu installieren.
  2. Einfache Architektur. Alle Konfigurationen werden lokal in dem für den Administrator geeigneten Formular gespeichert.
  3. Zum Testen geeignet. Dsc
  4. DevOps Way. Bei der Bereitstellung von Servern ist die Automatisierung sehr einfach und passt in die Philosophie der Infrastruktur als Code.
  5. run-once .
  1. . .
  2. . DSC .
  3. Azure Automation State Configuration, Windows Server 2012R2+
  1. On-Premise c . , .
  1. , .
  2. On-Premise GPO, .
  3. — , .
Das Einstellen von Ressourcen unterscheidet sich auch geringfügig für verschiedene Modi. Wie wir uns erinnern, müssen Sie eine Ressource lokal und auf dem Server installieren, um sie verwenden zu können.

Bei Verwendung des Push-Modus muss der Administrator zunächst alle erforderlichen Ressourcen auf dem verwalteten Server und auf dem PC installieren, von wo aus die Konfiguration übermittelt wird.

Im Pull-Modus kann der DSC-Agent auf dem verwalteten Server alle erforderlichen Ressourcen unabhängig vom Pull-Server installieren. Der Administrator hat die Aufgabe, sie auf dem Pull-Server zu platzieren. Wir berücksichtigen jedoch, dass es unmöglich ist, die Anwendung der Konfiguration im Pull-Modus vorherzusagen, da das Gruppenrichtlinienobjekt keine garantierte Übermittlung von Einstellungen darstellt.

Push-Modus im Detail






Der Prozess des Schreibens und Anwendens von DSC-Konfigurationen auf oberster Ebene kann wie folgt dargestellt werden: In der ersten Phase ( Authoring ) beschreiben wir die Konfiguration mit einer für uns geeigneten IDE (Editor, PowerShell ISE, Visual Studio Code und andere). Nach Abschluss kompilieren wir die mof-Konfigurationsdateien (der Kompilierungsprozess ist in unserem vorherigen Artikel beschrieben ).

In der zweiten Phase ( Staging / Compilation ) beginnen wir mit der Anwendung der Konfiguration aus der kompilierten mof-Datei mithilfe des Cmdlets Start-DSCConfiguration . Dabei überträgt der Verwaltungsserver die .mof-Datei des LCM-Servers, die die Konfiguration anwenden soll.
In diesem Fall ist es besser, den Schalter -Verbose zu verwenden . Für die vollständige Kontrolle des Konfigurationsprozesses:

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

Es ist ersichtlich, dass die Engine das Vorhandensein der Variablen überprüft, sie nicht gefunden und eine neue gemäß der angegebenen Konfiguration erstellt hat:



In der dritten Phase ( Ausführung ) betritt der DSC-Agent LCM das Spiel. Es empfängt eine Mof-Datei, überprüft sie, legt sie in einem Ordner ab $env:systemRoot/system32/configurationund startet einen Workflow zum Anwenden der Konfigurationsdatei:

  1. LCM empfängt, wendet die Konfigurationsdatei an. Die Datei wird in pending.mof umbenannt und in abgelegt$env:systemRoot/system32/configuration
    • Wenn die Anwendung der Konfigurationsdatei fehlschlägt, bleibt die Datei pending.mof erhalten, und LCM versucht, sie im nächsten Zyklus anzuwenden.
  2. Befindet sich die Datei current.mof bereits im Ordner, wird sie in previous.mof umbenannt
  3. Wenn die Anwendung der Konfigurationsdatei erfolgreich abgeschlossen wurde, benennt LCM sie in current.mof um
  4. Die Datei current.mof wird in die Datei backup.mof kopiert

Der Workflow kann grafisch wie folgt dargestellt werden:



Um verschiedene Konfigurationsdateien zu verwalten, gibt es das Cmdlet Remove-DSCConfigurationDocument, mit dem Sie bestimmte Dokumente löschen können, wenn dies aus irgendeinem Grund erforderlich ist. Nichts hindert uns jedoch daran, sie manuell zu entfernen.

Pull-Modus im Detail


Der Pull-Modus ist schwieriger bereitzustellen und zu konfigurieren, vereinfacht jedoch die Verwaltung der damit verbundenen Server erheblich.

Das allgemeine Schema sieht ungefähr so ​​aus: Der



Pull-Modus erfordert die Bereitstellung eines Pull-Servers. Tatsächlich handelt es sich um einen regulären Webserver, der Clients Mof-Dateien und Ressourcen zur Verfügung stellen kann, die möglicherweise beim Anwenden von Konfigurationen aus Mof-Dateien erforderlich sind. Letzteres vereinfacht die Verwaltung und Konfiguration von Servern erheblich, da die Aufgabe der Bereitstellung der erforderlichen Ressourcen beim Client liegt. Der Pull-Server fungiert gleichzeitig als Repository \ Ressourcen-Repository.

Der Pull-Server kann über zwei Protokolle auf Ressourcen und Konfigurationsdateien zugreifen:

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

Die Installation des Pull-Servers kann über die regulären Ressourcen erfolgen, die das DSC-Entwicklungsteam anbietet. Weitere Details finden Sie hier . Oder verwenden Sie Community-gesteuerte Lösungen: hier oder hier .

Der Workflow für die weitere Arbeit mit dem Pull-Server lautet wie folgt:

  1. Wir konfigurieren Clients (LCM) für die Arbeit mit einem Pull-Server.
  2. Wir laden Ressourcendateien auf den Pull-Server hoch.
  3. Wir bereiten Client-Konfigurationsdateien (Schreiben und Kompilieren) und Dateien mit Prüfsummen vor.
  4. Genieße das Ergebnis.

Konfigurieren von Clients (LCM) für die Arbeit mit einem Pull-Server

Um dies zu tun, verwenden Sie die folgenden LocalConfigurationManager (v5) Einstellungen : Einstellungen

Block :

  • CertificateID - Gibt den Fingerabdruck des Zertifikats zum Schutz der in der Konfiguration übertragenen Anmeldungen / Kennwörter an.
  • Konfigurations-ID - enthält die Client-GUID. Auf den Client werden nur die Konfigurationen angewendet, deren GUID im Namen der Konfigurationsdatei enthalten ist. Die Einstellung bleibt aus Gründen der Kompatibilität mit älteren Versionen des Pull-Servers erhalten. Es ist besser, die RegistrationKey-Einstellung zu verwenden.
  • RefreshMode - Um mit Pull-Servern zu arbeiten, geben Sie in dieser Einstellung Pull an.

Block ConfigurationRepositoryWeb:

  • AllowUnsecureConnection - Erlaube \ erlaube keine Verbindung ohne Authentifizierung.
  • CertificateID - Gibt den Fingerabdruck des Zertifikats auf dem Client an, der bei der gegenseitigen Authentifizierung mit dem Server verwendet wird.
  • Konfigurationsnamen - Ein Array von Konfigurationsnamen, die auf den Client angewendet werden.
  • RegistrationKey - Ein auf dem Server generiertes Geheimnis, das vom Client zur Registrierung auf dem Server verwendet wird.
  • ServerURL - URL des Pull-Servers mit Konfigurationen.

ResourceRepositoryWeb- Block :

  • AllowUnsecureConnection - Erlaube \ erlaube keine Verbindung ohne Authentifizierung.
  • CertificateID - Gibt den Fingerabdruck des Zertifikats auf dem Client an, der bei der gegenseitigen Authentifizierung mit dem Server verwendet wird.
  • RegistrationKey - Ein auf dem Server generiertes Geheimnis, das vom Client zur Registrierung auf dem Server verwendet wird.
  • ServerURL - URL des Pull-Servers mit Ressourcen.

ReportServerWeb- Block :

  • AllowUnsecureConnection - Erlaube \ erlaube keine Verbindung ohne Authentifizierung.
  • CertificateID - Gibt den Fingerabdruck des Zertifikats auf dem Client an, der bei der gegenseitigen Authentifizierung mit dem Server verwendet wird.
  • RegistrationKey - Ein auf dem Server generiertes Geheimnis, das vom Client zur Registrierung auf dem Server verwendet wird.
  • ServerURL - URL des Pull-Servers mit Berichten.

Hochladen von Ressourcendateien auf den Pull-Server

Nachdem Sie die neuen Einstellungen auf LCM angewendet haben, die ihm die Verwendung des Pull-Servers beibringen, können Sie Ressourcendateien auf den Server hochladen . Ressourcen werden in Form von Zip-Dateien auf den Server hochgeladen (der Ordner mit der Ressource ist in Zip gepackt). Regel für die Benennung einer solchen Datei:

{ModuleName}_{Version}.zip

Der Standardspeicherort der Datei $env:PROGRAMFILES\WindowsPowerShell\DscService\Modules. Bei der Installation des Pull-Servers kann dieser Ordner neu definiert werden. Zusätzlich zu der Datei mit dem in zip gepackten Ressourcenordner müssen Sie die Datei mit der Prüfsumme dieser gepackten Ressource an derselben Stelle ablegen. Zum Beispiel so:

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

Platzieren von Client-Konfigurationsdateien auf dem Pull-Server

Hierbei ist zu beachten, dass wir in diesem Fall zwei Client-Betriebsmodi verwenden können (tatsächlich zweieinhalb): Der Client vom Server erhält die Konfiguration mit ConfigurationID , oder der Client verwendet den Konfigurationsnamen - ConfigurationName . Wenn mehrere Konfigurationen angewendet werden müssen, können alle im Konfigurationsnamen angegeben werden. Sie müssen LCM jedoch so konfigurieren, dass es mit Teilkonfigurationen funktioniert.

Bei Verwendung von ConfigurationID muss betont werden, dass die auf den Client angewendete mof-Konfigurationsdatei eine GUID enthält (sie ist in der ConfigurationID enthalten). Bei Verwendung von ConfigurationName enthält die mof-Datei den Konfigurationsnamen, den wir in ConfigurationName angeben. In beiden Fällen wird neben der mof-Datei auch die Konfigurationsprüfsummendatei dort abgelegt:

New-DscChecksum -Path '.\' -Force

Abschließend


Wir haben uns zwei Möglichkeiten angesehen, um Änderungen im Push- und Pull-Modus auf den Server anzuwenden. Wir gingen die Verwendungsfunktionen durch und versuchten, alle Nuancen zu erklären, die bei der Arbeit mit diesen Modi in DSC auftreten können. Wenn Sie noch Fragen haben - lassen Sie uns in den Kommentaren diskutieren. Wenn Sie nicht genügend Sichtbarkeit hatten, besuchen Sie unser Online-Meeting am 28. Mai: Wir analysieren die Systeme für Unified Communications und Kommunikationsfunktionen (Einrichten des Hochladens von Exchange-Protokollen in Elastic, Microsoft Endpoint Manager für die Verwaltung von iOS, Android und Windows 10) und sprechen ausführlicher über die Grenzen der Anwendbarkeit PowerShell-Konfiguration für den gewünschten Status. Sie müssen sich nur registrieren .

All Articles