Condividi tramite


Servizio pull della configurazione dello stato desiderato

Importante

Il server di pull ( funzionalità Windows DSC-Service) è un componente supportato di Windows Server, tuttavia non è prevista l'offerta di nuove funzionalità o funzionalità. Si desidera che si sappia che è ora disponibile a livello generale una versione più recente di DSC, gestita da una funzionalità di Criteri di Azure denominata configurazione guest. Il servizio di configurazione guest combina le funzionalità dell'estensione DSC, la configurazione dello stato di Automazione di Azure e le funzionalità più comunemente richieste dal feedback dei clienti. La configurazione guest include anche il supporto di macchine ibride tramite server abilitati per Arc.

Gestione configurazione locale può essere gestito centralmente da una soluzione di servizio pull. Quando si utilizza questo approccio, il nodo gestito viene registrato con un servizio e gli viene assegnata una configurazione nelle impostazioni di Gestione configurazione locale. La configurazione e tutte le risorse DSC necessarie come dipendenze per la configurazione vengono scaricate nel computer e utilizzate da Gestione configurazione locale per gestire la configurazione. Le informazioni sullo stato del computer gestito vengono caricate nel servizio per la creazione di report. Questo concetto viene definito "servizio pull".

Le opzioni correnti per il servizio pull includono:

  • Servizio di configurazione dello stato desiderato di Automazione di Azure
  • Un servizio pull in esecuzione su Windows Server
  • Soluzioni open source mantenute dalla community
  • Una condivisione SMB

La scala consigliata per ogni soluzione è la seguente:

Soluzione Nodi client
Windows Pull Server con database MDB/ESENT Fino a 500 nodi
Windows Pull Server con database SQL Fino a 3500 nodi
DSC di Automazione di Azure Ambienti sia piccoli che grandi

La soluzione consigliata e l'opzione con il maggior numero di funzionalità disponibili è Azure Automation DSC. Non è stato identificato un limite massimo per il numero di nodi per ogni account di automazione.

Il servizio Azure può gestire i nodi in locale in data center privati o in cloud pubblici, ad esempio Azure e AWS. Per gli ambienti privati in cui i server non possono connettersi direttamente a Internet, è consigliabile limitare il traffico in uscita solo all'intervallo IP di Azure pubblicato (vedere Intervalli IP di Azure e tag di servizio).

Le funzionalità del servizio online che non sono attualmente disponibili nel servizio pull in Windows Server includono:

  • Tutti i dati sono crittografati in transito e a riposo
  • I certificati client vengono creati e gestiti automaticamente
  • Archivio segreti per la gestione centralizzata di password/credenziali o variabili come nomi di server o stringhe di connessione
  • Gestione centralizzata della configurazione LCM dei nodi
  • Assegnazione centralizzata delle configurazioni ai nodi client
  • Rilasciare le modifiche alla configurazione in "gruppi canary" per il test prima di raggiungere la produzione
  • Reportistica grafica
    • Dettagli sullo stato a livello di granularità delle risorse DSC
    • Messaggi di errore dettagliati dai computer client per la risoluzione dei problemi
  • Integrazione con Azure Log Analytics per avvisi, attività automatizzate, app Android/iOS per reportistica e avvisi

Servizio pull DSC in Windows Server

È possibile configurare un servizio pull per l'esecuzione in Windows Server. Si noti che la soluzione del servizio pull inclusa in Windows Server include solo funzionalità di archiviazione di configurazioni e moduli per il download e l'acquisizione dei dati dei report in un database. Non include molte delle funzionalità offerte dal servizio in Azure e quindi non è uno strumento valido per valutare la modalità di utilizzo del servizio.

Il servizio di pull offerto in Windows Server è un servizio Web in IIS che usa un'interfaccia OData per rendere disponibili i file di configurazione DSC ai nodi di destinazione quando tali nodi li richiedono.

Requisiti per l'utilizzo di un server di pull:

  • Un server che esegue:
    • WMF/PowerShell 4.0 o versione successiva
    • Ruolo del server IIS
    • Servizio DSC
  • Idealmente, alcuni mezzi per generare un certificato, per proteggere le credenziali passate a Gestione configurazione locale (LCM) nei nodi di destinazione

Il modo migliore per configurare Windows Server per ospitare il servizio pull consiste nell'usare una configurazione DSC. Di seguito viene fornito uno script di esempio.

Sistemi di database supportati

A partire dalla versione 17090 di Windows Server, WMF 5.1 include il supporto per l'opzione SQL Server per il servizio Pull ( Windows Feature DSC-Service). In questo modo è disponibile una nuova opzione per il ridimensionamento di ambienti DSC di grandi dimensioni di cui non è stata eseguita la migrazione ad Azure Automation DSC.

Per configurare il server di pull per l'utilizzo di SQL Server, impostare SqlProvider su $true e SqlConnectionString su una stringa di connessione di SQL Server valida. Per altre informazioni, vedere Stringhe di connessione SqlClient. Per un esempio di configurazione di SQL Server con xDscWebService, leggere prima di tutto Uso della risorsa xDscWebService e quindi esaminare 2-xDscWebService_RegistrationUseSQLProvider_Config.ps1 in GitHub.

Utilizzo della risorsa xDscWebService

Il modo più semplice per configurare un server di pull Web consiste nell'utilizzare la risorsa xDscWebService , inclusa nel modulo xPSDesiredStateConfiguration . La procedura seguente illustra come utilizzare la risorsa in un Configuration servizio Web che configura.

  1. Chiamare il cmdlet Install-Module per installare il modulo xPSDesiredStateConfiguration .

  2. Ottenere un certificato SSL per il server di pull DSC da un'autorità di certificazione attendibile, all'interno dell'organizzazione o da un'autorità pubblica. Il certificato ricevuto dall'autorità è solitamente in formato PFX.

  3. Installare il certificato nel nodo che diventerà il server di pull DSC nel percorso predefinito, che deve essere CERT:\LocalMachine\My. Prendere nota dell'identificazione personale del certificato.

  4. Selezionare un GUID da utilizzare come chiave di registrazione. Per generarne uno utilizzando PowerShell, immettere quanto segue al prompt PS e premere invio: [guid]::newGuid() o New-Guid. Questa chiave verrà utilizzata dai nodi client come chiave condivisa per l'autenticazione durante la registrazione. Per ulteriori informazioni, vedere la sezione Chiave di registrazione riportata di seguito.

  5. Nell'ISE di PowerShell avviare (F5) lo script di configurazione seguente (incluso nella cartella del modulo xPSDesiredStateConfiguration come Sample_xDscWebServiceRegistration.ps1.

    Questo script configura il server di pull.

    configuration Sample_xDscWebServiceRegistration
    {
        param
        (
            [string[]]$NodeName = 'localhost',
    
            [ValidateNotNullOrEmpty()]
            [string] $certificateThumbPrint,
    
            [Parameter(HelpMessage='This should be a string with enough entropy (randomness)' +
                ' to protect the registration of clients to the pull server.  We will use new' +
                ' GUID by default.'
            )]
            [ValidateNotNullOrEmpty()]
            [string] $RegistrationKey   # A guid that clients use to initiate conversation with pull server
        )
    
        Import-DSCResource -ModuleName PSDesiredStateConfiguration
        Import-DSCResource -ModuleName xPSDesiredStateConfiguration
    
        Node $NodeName
        {
            WindowsFeature DSCServiceFeature
            {
                Ensure = "Present"
                Name   = "DSC-Service"
            }
    
            xDscWebService PSDSCPullServer
            {
                Ensure                  = "Present"
                EndpointName            = "PSDSCPullServer"
                Port                    = 8080
                PhysicalPath            = "$env:SystemDrive\inetpub\PSDSCPullServer"
                CertificateThumbPrint   = $certificateThumbPrint
                ModulePath              = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
                ConfigurationPath       = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"
                State                   = "Started"
                DependsOn               = "[WindowsFeature]DSCServiceFeature"
                RegistrationKeyPath     = "$env:PROGRAMFILES\WindowsPowerShell\DscService"
                AcceptSelfSignedCertificates = $true
                UseSecurityBestPractices     = $true
                Enable32BitAppOnWin64   = $false
            }
    
            File RegistrationKeyFile
            {
                Ensure          = 'Present'
                Type            = 'File'
                DestinationPath = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"
                Contents        = $RegistrationKey
            }
        }
    }
    
  6. Eseguire la configurazione, passando l'identificazione personale del certificato SSL come parametro certificateThumbPrint e una chiave di registrazione GUID come parametro RegistrationKey :

    # To find the Thumbprint for an installed SSL certificate for use with the pull server list all
    # certificates in your local store and then copy the thumbprint for the appropriate certificate
    # by     reviewing the certificate subjects
    
    dir Cert:\LocalMachine\my
    
    # Then include this thumbprint when running the configuration
    $sample_xDscWebServiceRegistrationSplat = @{
        certificateThumbprint = 'A7000024B753FA6FFF88E966FD6E19301FAE9CCC'
        RegistrationKey = '140a952b-b9d6-406b-b416-e0f759c9c0e4'
        OutputPath = 'C:\Configs\PullServer'
    }
    Sample_xDscWebServiceRegistration @sample_xDscWebServiceRegistrationSplat
    
    # Run the compiled configuration to make the target node a DSC Pull Server
    Start-DscConfiguration -Path c:\Configs\PullServer -Wait -Verbose
    

Chiave di registrazione

Per consentire ai nodi client di registrarsi con il server in modo che possano utilizzare i nomi di configurazione anziché un ID di configurazione, una chiave di registrazione creata dalla configurazione precedente viene salvata in un file denominato RegistrationKeys.txt in C:\Program Files\WindowsPowerShell\DscService. La chiave di registrazione funziona come un segreto condiviso utilizzato durante la registrazione iniziale dal client con il server di pull. Il client genererà un certificato autofirmato usato per eseguire l'autenticazione in modo univoco al server di pull una volta completata correttamente la registrazione. L'identificazione personale di questo certificato viene archiviata localmente e associata all'URL del server di pull.

Annotazioni

Le chiavi di registrazione non sono supportate in PowerShell 4.0.

Per configurare un nodo per l'autenticazione con il server di pull, la chiave di registrazione deve essere nella metaconfigurazione per qualsiasi nodo di destinazione che verrà registrato con questo server di pull. Si noti che la RegistrationKey nella metaconfigurazione seguente viene rimossa dopo che il computer di destinazione è stato registrato correttamente e che il valore deve corrispondere al valore archiviato nel RegistrationKeys.txt file sul server di pull ('140a952b-b9d6-406b-b416-e0f759c9c0e4' per questo esempio). Trattare sempre il valore della chiave di registrazione in modo sicuro, perché conoscerlo consente a qualsiasi computer di destinazione di registrarsi con il server di pull.

[DSCLocalConfigurationManager()]
configuration Sample_MetaConfigurationToRegisterWithLessSecurePullServer
{
    param
    (
        [ValidateNotNullOrEmpty()]
        [string] $NodeName = 'localhost',

        # the key used to set up pull server in previous configuration
        [ValidateNotNullOrEmpty()]
        [string] $RegistrationKey,

        # The name of the pull server, same as $NodeName used in previous configuration
        [ValidateNotNullOrEmpty()]
        [string] $ServerName = 'localhost'
    )

    Node $NodeName
    {
        Settings
        {
            RefreshMode        = 'Pull'
        }

        ConfigurationRepositoryWeb CONTOSO-PullSrv
        {
            ServerURL          = "https://$ServerName`:8080/PSDSCPullServer.svc"
            RegistrationKey    = $RegistrationKey
            ConfigurationNames = @('ClientConfig')
        }

        ReportServerWeb CONTOSO-PullSrv
        {
            ServerURL       = "https://$ServerName`:8080/PSDSCPullServer.svc"
            RegistrationKey = $RegistrationKey
        }
    }
}

$MetaConfigurationSplat = @{
    RegistrationKey = $RegistrationKey
    OutputPath = 'c:\Configs\TargetNodes'
}

Sample_MetaConfigurationToRegisterWithLessSecurePullServer @MetaConfigurationSplat

Annotazioni

La sezione ReportServerWeb consente l'invio dei dati di report al server di pull.

La mancanza della proprietà ConfigurationID nel file di metaconfigurazione indica in modo implicito che il server di pull supporta la versione V2 del protocollo del server di pull, pertanto è necessaria una registrazione iniziale. Al contrario, la presenza di un ConfigurationID significa che viene utilizzata la versione V1 del protocollo del server di pull e non vi è alcuna elaborazione di registrazione.

Annotazioni

In uno scenario PUSH, nella versione corrente è presente un bug che rende necessaria la definizione di una proprietà ConfigurationID nel file di metaconfigurazione per i nodi che non sono mai stati registrati con un server di pull. In questo modo verrà forzato il protocollo del server di pull V1 ed eviteranno messaggi di errore di registrazione.

Posizionamento di configurazioni e risorse

Al termine dell'installazione del server di pull, le cartelle definite dalle proprietà ConfigurationPath e ModulePath nella configurazione del server di pull sono la posizione in cui verranno inseriti i moduli e le configurazioni che saranno disponibili per il pull dei nodi di destinazione. Questi file devono essere in un formato specifico affinché il server di pull possa elaborarli correttamente.

Formato del pacchetto del modulo di risorse DSC

Ogni modulo di risorse deve essere compresso e denominato in base al seguente modello <Module Name>_<Module Version>.zip.

Ad esempio, un modulo denominato xWebAdminstration con una versione del modulo 3.1.2.0 verrebbe denominato xWebAdministration_3.1.2.0.zip. Ogni versione di un modulo deve essere contenuta in un singolo file zip. Poiché esiste una sola versione di una risorsa in ogni file zip, il formato del modulo aggiunto in WMF 5.0 con il supporto per più versioni del modulo in una singola directory non è supportato. Ciò significa che prima di creare il pacchetto dei moduli di risorse DSC per l'uso con il server di pull, sarà necessario apportare una piccola modifica alla struttura di directory. Il formato predefinito dei moduli contenenti la risorsa DSC in WMF 5.0 è <Module Folder>\<Module Version>\DscResources\<DSC Resource Folder>\. Prima di creare il pacchetto per il server di pull, rimuovere la <Module version> cartella in modo che il percorso diventi <Module Folder>\DscResources\<DSC Resource Folder>\. Con questa modifica, comprimi la cartella come descritto sopra e posiziona questi file zip nella cartella ModulePath .

Utilizzare New-DscChecksum <module zip file> per creare un file di checksum per il modulo appena aggiunto.

Configurazione formato MOF

Un file MOF di configurazione deve essere associato a un file di checksum in modo che un LCM in un nodo di destinazione possa convalidare la configurazione. Per creare un checksum, chiamare il cmdlet New-DscChecksum . Il cmdlet accetta un parametro Path che specifica la cartella in cui si trova il MOF di configurazione. Il cmdlet crea un file di checksum denominato ConfigurationMOFName.mof.checksum, dove ConfigurationMOFName è il nome del file mof di configurazione. Se nella cartella specificata sono presenti più file MOF di configurazione, viene creato un checksum per ogni configurazione nella cartella. Inserire i file MOF e i file di checksum associati nella cartella ConfigurationPath .

Annotazioni

Se si modifica il file MOF di configurazione in qualsiasi modo, è necessario ricreare anche il file di checksum.

Strumentazione

Per configurare, convalidare e gestire il server di pull, utilizzare gli strumenti seguenti inclusi come esempi nella versione più recente del modulo xPSDesiredStateConfiguration:

  1. Un modulo che consente di creare pacchetti di moduli di risorse DSC e file di configurazione da utilizzare nel server di pull. PublishModulesAndMofsToPullServer.psm1. Esempi di seguito:

    # Example 1 - Package all versions of given modules installed locally and
    # MOF files are in c:\LocalDepot
    $moduleList = @('xWebAdministration', 'xPhp')
    Publish-DSCModuleAndMof -Source C:\LocalDepot -ModuleNameList $moduleList
    
    # Example 2 - Package modules and mof documents from c:\LocalDepot
    Publish-DSCModuleAndMof -Source C:\LocalDepot -Force
    
  2. Uno script che convalida il server di pull è configurato correttamente. PullServerSetupTests.ps1.

Soluzioni della community per il servizio pull

La community DSC ha creato diverse soluzioni per implementare il protocollo del servizio pull. Per gli ambienti locali, questi offrono funzionalità del servizio pull e l'opportunità di contribuire alla community con miglioramenti incrementali.

Eseguire il pull della configurazione del client

Negli argomenti seguenti viene descritta in dettaglio la configurazione dei client pull:

Vedere anche