Solo otra herramienta: conocer la configuración del servicio con la Configuración de estado deseada 

La configuración de estado deseada (DSC) es una herramienta de administración de configuración del servidor. Con él, puede configurar el servidor (realizar cambios en el registro, copiar archivos, instalar y eliminar componentes), controlar el estado actual de la configuración y volver rápidamente a la configuración básica.

DSC es interesante para aquellos que siguen el enfoque de DevOps. Esta herramienta encaja bien con el paradigma Infraestructura como código: los desarrolladores pueden agregar sus requisitos a la configuración e incluirlos en el sistema de control de versiones, y los equipos pueden implementar el código sin usar procesos "manuales".

Junto con Stanislav Buldakov de RaiffeisenbankCombinamos nuestra experiencia con el motor DSC y la dividimos en 2 artículos. En el primero, analizaremos los principios básicos del trabajo y nos familiarizaremos con las características de uso en ejemplos prácticos:

  • “Desempaquete la caja” con el motor DSC, vea qué recursos están por defecto y muestre dónde obtener recursos adicionales;
  • Veamos cómo describir la configuración en DSC; 
  • Aprenderemos cómo el agente de configuración local Local Manager Manager aplica las configuraciones en el servidor, mostraremos cómo se configura usando metaconfiguraciones;
  • pasemos a casos de configuración más complejos: configuraciones parciales y configuraciones de código auxiliar.



DSC es un motor ligero y rápido. Por ejemplo, al usarlo, puede instalar .NET Framework 3.5 en máquinas virtuales mucho más rápido. Esto es lo que lo ayuda a acelerar el proceso de configuración del servicio:

  • « » Windows PowerShell. 
    DSC PowerShell Windows Management Framework. Linux . , PowerShell. 
  • , . 
    , , , . DSC. 
  • , .
    DSC , . .

Las configuraciones siempre se realizan de forma secuencial, sin condiciones ni ramificaciones. Por lo tanto, brevemente, el algoritmo de operación DSC se ve así:

  1. Configure el Administrador de configuración local (LCM) . Este es el agente integrado que se encarga de aplicar las configuraciones al servidor. Le decimos cómo deberían funcionar las configuraciones declaradas y en qué orden. 
  2. Si se necesitan recursos adicionales, instálelos y conéctelos con anticipación.
  3. En forma declarativa, escribimos el orden de configuración. 
  4. Emitimos la configuración en el formato del archivo MOF.
  5. Enviamos la configuración al servidor objetivo recién implementado o existente.
  6. LCM recibe la configuración (archivo MOF) más instrucciones para configurar el propio LCM.
  7. La configuración es aplicada inmediatamente por nuestro equipo.


Un diagrama simplificado de la arquitectura DSC.

Comenzaremos a conocer el motor estudiando los recursos predefinidos. A continuación, intente escribir la configuración.

Recursos de DSC 


Los recursos DSC son una especie de módulos analógicos a PowerShell. Cualquier servidor de Windows ya tiene un conjunto predefinido de recursos DSC; están en el mismo directorio que los módulos de PowerShell. La lista se puede obtener a través del cmdlet Get-DscResourse. Así es como se ve esta lista en Windows 10 1809:
 
PS C:\windows\system32> Get-DscResource | Sort-Object -Property Name | ft ImplementedAs, Name -a
 
ImplementedAs Name
------------- ----
   PowerShell Archive
   PowerShell Environment
       Binary File
   PowerShell Group
    Composite GroupSet
       Binary Log
   PowerShell Package
   PowerShell PackageManagement
   PowerShell PackageManagementSource
    Composite ProcessSet
   PowerShell Registry
   PowerShell Script
   PowerShell Service
    Composite ServiceSet
       Binary SignatureValidation
   PowerShell User
   PowerShell WaitForAll
   PowerShell WaitForAny
   PowerShell WaitForSome
   PowerShell WindowsFeature
    Composite WindowsFeatureSet
   PowerShell WindowsOptionalFeature
    Composite WindowsOptionalFeatureSet
   PowerShell WindowsPackageCab
   PowerShell WindowsProcess

Los nombres de los recursos dan una idea de con qué trabajan: 

  • Archivo - con embalaje y desembalaje de archivos;
  • Entorno: con variables de entorno;
  • Archivo - con archivos;
  • Grupo: con grupos de usuarios locales;
  • Registro - con registros;
  • Paquete —– con paquetes de software;
  • Registro —– con claves de registro y su estado;
  • Servicio - con servicios y su estado;
  • Usuario: con cuentas de usuario locales;
  • WindowsFeature — Windows Server;
  • WindowsProcess — Windows;
  • Script —  PowerShell- . 3 : SetScript — -, TestScript — , , GetScript — .

La mayoría de las veces, los recursos DSC listos para usar no son suficientes . En este caso, puede escribir sus propios scripts para todo lo que va más allá del módulo estándar. Para no reinventar la rueda, puede usar recursos DSC escritos por otros desarrolladores. Por ejemplo, desde aquí https://github.com/PowerShell/DscResources o desde PSGallery
 
Cómo instalar recursos adicionales . Usamos el cmdlet Install-Module . Instalar recursos es simplemente copiar archivos de recursos a lo largo de una de las rutas en la variable de entorno $ env: PSModulePath . Los recursos instalados no se conectan automáticamente durante la compilación, por lo que más adelante los conectaremos en la configuración misma.

Para usar un recurso, debe instalarlo localmente y en el servidor de destino. En las infraestructuras locales, una política de seguridad generalmente prohíbe el acceso a Internet para los servidores. En este caso, el servidor DSC no podrá cargar recursos adicionales de fuentes externas. Para publicar archivos con módulos, implementamos un repositorio NuGet local o un servidor web normal. Puede instalar recursos adicionales para el servidor web desempacando el módulo en el directorio C: \ Archivos de programa \ WindowsPowerShell \ Modules \.
Esto es exactamente lo que hace el cmdlet Install-Module.

En el segundo artículo, veremos más de cerca la diferencia entre la configuración de los modos Push y Pull. 

Análisis de configuración simple


La configuración es una descripción simple y consistente de lo que debe hacerse en el servidor. Así es como se ve una configuración DSC simple: 

Configuration EnvironmentVariable_Path
{
param ()
Import-DscResource -ModuleName 'PSDscResources'
Node localhost
    {
        Environment CreatePathEnvironmentVariable
        {
            Name = 'TestPathEnvironmentVariable'
            Value = 'TestValue'
            Ensure = 'Present'
            Path = $true
            Target = @('Process', 'Machine')
        }
    }
}
EnvironmentVariable_Path -OutputPath:"C:\EnvironmentVariable_Path"

Para su ejemplo, veamos en qué consiste la configuración.

El bloque de configuración es un tipo especial de función de PowerShell que describe lo que queremos obtener. 

Dentro del bloque contiene: 

  • PARAM bloque con los parámetros que se puede utilizar internamente; 
  • bloque con llamadas adicionales de PowerShell. Aquí, al comienzo de la configuración, siempre ejecutamos Import-Resource para conectar recursos adicionales;
  • bloques con configuraciones para servidores específicos de Node $ servername. 

Dentro del bloque Nodo , indicamos qué recursos configuraremos en un servidor en particular. En el ejemplo anterior, esto está creando una variable de entorno utilizando un recurso de entorno normal.

Veamos un poco más a fondo y veamos la sintaxis de un recurso específico a través del comando Get-DscResource -Name Environment -Syntax:
 

PS C:\windows\system32> Get-DscResource -Name Environment -Syntax
Environment [String] #ResourceName
{
    Name = [string]
    [DependsOn = [string[]]]
    [Ensure = [string]{ Absent | Present }]
    [Path = [bool]]
    [PsDscRunAsCredential = [PSCredential]]
    [Value = [string]]
}

En este ejemplo: 

  • Nombre : el nombre de la variable de entorno.
  • En DependsOn, especificamos la dependencia de otros recursos. Es importante recordar que la operación no se realizará hasta que se complete el recurso especificado aquí. 
  • En Asegurar, especificamos las condiciones de configuración. Si dicha variable está ausente, la crearemos; si está presente, este recurso no se configurará.
  • La ruta especifica si la variable de entorno contiene una ruta. 
  • En PsDscRunAsCredential credenciales especificadas.
  • Valor : el valor de la variable de entorno. 
  • El destino puede indicarse con respecto a quién se aplica la configuración.

Cómo comenzar la compilación . Simplemente llamamos a la configuración por su nombre con los parámetros necesarios. El resultado será un archivo mof, que el motor DSC también utiliza para configurar un servidor específico:
 
PS C:\windows\system32> EnvironmentVariable_Path -OutputPath:"C:\EnvironmentVariable_Path"
 
    Directory: C:\EnvironmentVariable_Path
 
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       25.02.2020     14:05           2172 localhost.mof

Configurar el administrador de configuración local


El administrador de configuración local es responsable de aplicar las configuraciones que compilamos en archivos mof. Es él quien supervisa la preservación del estado definido en la configuración. Si el sistema abandona este estado, LCM llama al código en los recursos para restaurar el estado especificado. 

Veamos la configuración del administrador de configuración local a través de Get-DscLocalConfigurationManager:
 
PS C:\windows\system32> Get-DscLocalConfigurationManager
 
ActionAfterReboot              : ContinueConfiguration
AgentId                        : 1FB3A2EE-57C9-11EA-A204-58A023EF3A48
AllowModuleOverWrite           : False
CertificateID                  :
ConfigurationDownloadManagers  : {}
ConfigurationID                :
ConfigurationMode              : ApplyAndMonitor
ConfigurationModeFrequencyMins : 15
Credential                     :
DebugMode                      : {NONE}
DownloadManagerCustomData      :
DownloadManagerName            :
LCMCompatibleVersions          : {1.0, 2.0}
LCMState                       : Idle
LCMStateDetail                 :
LCMVersion                     : 2.0
StatusRetentionTimeInDays      : 10
SignatureValidationPolicy      : NONE
SignatureValidations           : {}
MaximumDownloadSizeMB          : 500
PartialConfigurations          :
RebootNodeIfNeeded             : False
RefreshFrequencyMins           : 30
RefreshMode                    : PUSH
ReportManagers                 : {}
ResourceModuleManagers         : {}
PSComputerName                 :

  • RefreshMode contiene el modo operativo LCM: Push o Pull. Hablaremos más sobre modos en el segundo artículo.
  • ConfigurationMode muestra el modo de aplicación de configuración actual. En nuestro caso, es ApplyAndMonitor: aplica y realiza un seguimiento de los cambios. Los modos ApplyOnly también están disponibles (LCM no rastreará los cambios de configuración) y modos ApplyAndAutocorrect (LCM no solo rastreará los cambios, sino que también los revertirá a la configuración base).
  • RebootNodeIfNeeded : puede reiniciar el servidor una vez completada la configuración, si es necesario para aplicar la configuración. 
  • ConfigurationModeFrequencyMins : corrige la frecuencia con la que LCM verificará los cambios de configuración.

Cambiar la configuración de LCM en la metaconfiguración. Aquí está su ejemplo:
 

Configuration LCMConfiguration
{
   Node Localhost
   {
       LocalConfigurationManager
       {
           RebootNodeIfNeeeded = $True
       }
   }
}
LCMConfiguration

Lo mismo para la última versión de WMF con comentarios:


 
[DSCLocalConfigurationManager()]
Configuration LCMConfiguration
{
   param
   (
       [string[]]$Server = "localhost"
   )

 

#  LCM:
#  ,  
# : PUSH
#    30 
   Node $Server
   {
       Settings
       {
           RebootNodeIfNeeded = $True
           RefreshMode        = 'Push'
           RefreshFrequencyMins = 30
       }
   }
}


#   
LCMConfiguration -Server "localhost" -OutputPath "C:\DSC\MetaConfigurations\EnvironmentVariable_Path\"

Características de la metaconfiguración . Al escribir una metaconfiguración, usamos los mismos bloques que para una configuración DSC normal. La excepción es el bloque interno LocalConfigurationManager (v4) o el atributo DSCLocalConfigurationManager (v5) para un servidor específico. Describen todas las configuraciones necesarias. 

La metaconfiguración también se compila en un archivo mof, pero para usarla, se usa el cmdlet Set-DSCLocalConfigurationManager y no Start-DSCConfiguration.
 
PS C:\windows\system32> LCMConfiguration -OutputPath C:\EnvironmentVariable_Path\
 
    Directory: C:\EnvironmentVariable_Path
 
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       26.02.2020     20:05           1016 Localhost.meta.mof

 

PS C:\windows\system32> Set-DscLocalConfigurationManager -Path C:\EnvironmentVariable_Path\
PS C:\windows\system32> Get-DscLocalConfigurationManager
 
RebootNodeIfNeeded             : True

Teóricamente, nada nos impide combinar la configuración de LCM y recursos convencionales dentro de la misma configuración. Pero por simplicidad, se recomienda separar la ortografía y la aplicación de la configuración y la metaconfiguración.

Configuraciones parciales 


Configuraciones parciales: varias configuraciones que se ejecutan secuencialmente una tras otra. Son útiles cuando varios equipos trabajan en el servicio. Cada uno de los comandos indica la configuración de su parte del servicio, y la configuración parcial aplica todas las configuraciones secuencialmente. En la configuración de LCM, especificamos configuraciones parciales en PartialConfigurations

En configuraciones parciales, debemos considerar la lógica DSC directa. El motor no permite la ramificación, por lo que se necesitan recursos adicionales para cumplir diversas condiciones. Analizaremos esto con algunos ejemplos. 

Supongamos que queremos entregar la configuración al servidor y proceder de acuerdo con el siguiente algoritmo:

  1. Primero, verifique que los módulos necesarios estén instalados en el servidor.
  2. Realizamos la configuración, que llevará al servidor al estado deseado.

Así es como se ve una metaconfiguración con varias configuraciones consecutivas dentro:


#   
[DSCLocalConfigurationManager()]
configuration MetaPushConfig
{
param
   (
       [ValidateNotNullOrEmpty()]
       [string] $NodeName = 'localhost'
   )

 

   Node $NodeName
   {
 	
 #      LCM,    
       PartialConfiguration ModulesDownloadConfig
       {
               Description = 'Download and install modules'
               RefreshMode = 'Push'
       }

 

       #        
       PartialConfiguration ServerOSConfig
       {
               DependsOn = "[PartialConfiguration]ModulesDownloadConfig"
               Description = 'Configuration'
               RefreshMode = 'Push'
       }

 

       #   LCM
       Settings
       {
               RefreshMode        = 'Push'
               RefreshFrequencyMins = 30
               RebootNodeIfNeeded = $true
       }
   }
}

 
 

#  
MetaPushConfig -NodeName "NewServer.contoso.com" -OutputPath c:\DSC\MetaConfigurations

 

#      
$cred = (Get-Credential -UserName Administrator -Message "Enter admin credentials")

 

#  LCM   
Set-DscLocalConfigurationManager -ComputerName "NewServer.contoso.com" -Credential $cred -Path "c:\DSC\MetaConfigurations" -Verbose -Force

 

#  
Publish-DscConfiguration c:\DSC\Configurations\ModulesDownloadConfig -ComputerName "NewServer.contoso.com" -Credential $cred -Force
Publish-DscConfiguration c:\DSC\Configurations\ServerOSConfig -ComputerName "NewServer.contoso.com" -Credential $cred -Force

 

#    
Start-DscConfiguration -UseExisting -ComputerName "NewServer.contoso.com" -Credential $cred -Force -Verbose

La primera parte de la configuración dice Descargar e instalar módulos : descargue e instale los recursos necesarios. La segunda parte de ServerOSConfig lleva el servidor al estado deseado. ¿Cuáles son los matices con la sencillez DSC aquí: 

  1. Si la primera parte de la configuración inicialmente devolvió FALSO y se completó por completo, entonces LCM no pasará a la segunda configuración. Según la lógica DSC, primero debe llevar el servidor al primer estado descrito. 
    Cómo tratar: ejecute la configuración dos veces o automatice todo el proceso en un script.
  2. Si el servidor después de instalar algún componente requiere un reinicio, la configuración no irá más allá hasta que nosotros reiniciemos el servidor. Incluso si le decimos a LCM que RebootNodeIfNeeeded = $ True, el agente esperará nuestra solución durante la configuración.
    Cómo tratar: el recurso xPendingReboot viene al rescate , que controla la clave de registro al reiniciar. Este recurso reinicia el servidor por nosotros.

Aquí hay un ejemplo de configuración para descargar e instalar recursos en el escenario de "empresa sangrienta", cuando el servidor no tiene acceso a Internet. Asume la presencia de un servidor web, donde los recursos previamente descargados están disponibles para todos a través del protocolo http.


Configuration ModulesDownloadConfig
{
   param
   (
       [string[]]$Server
   )

 

   #   
   Import-DscResource -ModuleName "PSDesiredStateConfiguration"

 

   #  
   Node $Server
   {
       #  IE Security
       Registry DisableIEESC-Admin {
           Key = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}"
           ValueName = "IsInstalled"
           Ensure = "Present"
           ValueData = 0
           ValueType = "DWORD"
       }

 

       Registry DisableIEESC-User {
           Key = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}"
           ValueName = "IsInstalled"
           Ensure = "Present"
           ValueData = "0"
           ValueType = "DWORD"
       }

 

	
 #    ,    
       File CreateDistribDir {
           Ensure          = "present"
           DestinationPath = "C:\Install\PSModules"
           Type            = "Directory"
       }

 

	
 #   NetworkingDsc (<a href="https://www.powershellgallery.com/packages/NetworkingDsc/8.0.0-preview0004">https://www.powershellgallery.com/packages/NetworkingDsc/8.0.0-preview0004</a>),      
       Script NetworkingDscDownLoad {
           SetScript = { Invoke-WebRequest -Uri "http://repo.contoso.com/repo/modules/NetworkingDsc.zip" -OutFile "C:\Install\PSModules\NetworkingDsc.zip" }
           GetScript = { return @{ Result = Test-Path "C:\Install\PSModules\NetworkingDsc.zip"
               GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript
               }
           }
           TestScript = { Test-Path "C:\Program Files\WindowsPowerShell\Modules\NetworkingDsc" }
       }

 

 #   NetworkingDsc  C:\Program Files\WindowsPowerShell\Modules
       Archive UnpackNetworkingDsc {
           Ensure = "Present"
           DependsOn = "[Script]NetworkingDscDownLoad"
           Path = "C:\Install\PSModules\NetworkingDsc.zip"
           Destination = "C:\Program Files\WindowsPowerShell\Modules\"
       }

 

 #   ComputerManagementDsc (<a href="https://www.powershellgallery.com/packages/ComputerManagementDsc/8.2.1-preview0001">https://www.powershellgallery.com/packages/ComputerManagementDsc/8.2.1-preview0001</a>),      
       Script ComputerManagementDscDownLoad {
           SetScript = { Invoke-WebRequest -Uri "http://repo.contoso.com/repo/modules/ComputerManagementDsc.zip" -OutFile "C:\Install\PSModules\ComputerManagementDsc.zip" }
           GetScript = { return @{ Result = Test-Path "C:\Install\PSModules\ComputerManagementDsc.zip"
               GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript
               }
           }
           TestScript = { Test-Path "C:\Program Files\WindowsPowerShell\Modules\ComputerManagementDsc" }
       }

 

	
 #   ComputerManagementDsc  C:\Program Files\WindowsPowerShell\Modules
       Archive UnpackComputerManagementDsc {
           Ensure = "Present"
           DependsOn = "[Script]ComputerManagementDscDownLoad"
           Path = "C:\Install\PSModules\ComputerManagementDsc.zip"
           Destination = "C:\Program Files\WindowsPowerShell\Modules\"
       }

 

	
 #   xPendingReboot (<a href="https://www.powershellgallery.com/packages/xPendingReboot/0.4.0.0">https://www.powershellgallery.com/packages/xPendingReboot/0.4.0.0</a>),      
       Script xPendingRebootDownLoad {
           SetScript = { Invoke-WebRequest -Uri "http://repo.contoso.com/repo/modules/xPendingReboot.zip" -OutFile "C:\Install\PSModules\xPendingReboot.zip" }
           GetScript = { return @{ Result = Test-Path "C:\Install\PSModules\xPendingReboot.zip"
               GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript
               }
           }
           TestScript = { Test-Path "C:\Program Files\WindowsPowerShell\Modules\xPendingReboot" }
       }

 

	
 #   xPendingReboot  C:\Program Files\WindowsPowerShell\Modules
       Archive UnpackxPendingReboot {
           Ensure = "Present"
           DependsOn = "[Script]xPendingRebootDownLoad"
           Path = "C:\Install\PSModules\xPendingReboot.zip"
           Destination = "C:\Program Files\WindowsPowerShell\Modules\"
       }
   }
}

Acerca de la seguridad


La gran desventaja de DSC en el terreno es la falta de cuentas Run As. Este mecanismo almacena de forma segura las cuentas en forma de nombre de usuario + "sal de la contraseña" y las envía al servicio, que es responsable de la autenticación. Sin él, DSC no puede administrar cuentas en nombre de otro servicio. Y si necesitamos autenticarnos bajo una cuenta con privilegios especiales, el proceso de automatización es muy complicado. Por ejemplo, este será el caso al ingresar el servidor en el dominio.

Todo a nuestra disposición:

  • las credenciales se almacenan en texto sin formato,
  • Las credenciales cifradas solo funcionan en la PC donde se generaron.

En la práctica, hay varias soluciones. 


Los "apéndices" son buenos cuando se debe garantizar la previsibilidad del comportamiento del servidor.
Hacemos un "código auxiliar" después de la configuración del servidor en varios casos, si utilizamos:

  • reiniciar (recurso xPendingReboot) 
  • transferencia de credenciales 
  • otros recursos que pueden afectar el rendimiento del servidor con respecto a reinicios no planificados o seguridad.

Para hacer esto, cree y vuelva a publicar configuraciones SIN bloques que contengan el recurso xPendingReboot y configuraciones con credenciales.

Este enfoque se aplica solo al escenario Push, ya que Pull es bastante sencillo y no implica un cambio de configuración sobre la marcha. En el próximo artículo deBuldakovEcharemos un vistazo más de cerca a la configuración y las características de trabajar en los modos Push y Pull.

Y también vengan a discutir los matices de la tecnología DSC y los límites de su aplicación el 28 de mayo a las 18.00 en la primera reunión en línea de la comunidad de Comunicaciones DGTL de Raiffeisenbank. También en la reunión hablaremos sobre cómo hacer que ELK y Exchange sean amigos y qué puede hacer Microsoft Endpoint Manager en la administración de dispositivos. Aquí está el registro para el mitap .

All Articles