Hola a todos!
Vamos a hablar de recursos en DSC.
Visión de conjunto:
Los recursos de configuración de estado deseado (DSC) proporcionan los componentes básicos para una configuración de DSC. Un recurso expone propiedades que se pueden configurar (esquema) y contiene las funciones de script de PowerShell que el Administrador de configuración local (LCM) llama para «hacer que así sea».
Un recurso puede modelar algo tan genérico como un archivo o tan específico como la configuración de un servidor IIS. Los grupos de recursos similares se combinan en un Módulo DSC, que organiza todos los archivos necesarios en una estructura que es portátil e incluye metadatos para identificar cómo se pretende utilizar los recursos.
Cada recurso tiene un *esquema que determina la sintaxis necesaria para usar el recurso en una configuración. El esquema de un recurso se puede definir de las siguientes maneras:
- Archivo Schema.Mof: la mayoría de los recursos definen su esquema en un archivo schema.mof, utilizando el formato de objeto administrado.
- Archivo .schema.psm1: los recursos compuestos definen su esquema en un archivo .schema.psm1 mediante un bloque de parámetros.
- Archivo .psm1: los recursos DSC basados en clases definen su esquema en la definición de clase. Los elementos de sintaxis se indican como propiedades de clase. Para obtener más información, consulte about_Classes.
Para recuperar la sintaxis de un recurso DSC, use el cmdlet Get-DSCResource con el parámetro Sintaxis. Este uso es similar al uso de Get-Command con el parámetro Syntax para obtener la sintaxis del cmdlet. El resultado que verá mostrará la plantilla utilizada para un bloque de recursos para el recurso que especifique.
Get-DscResource -Syntax Service
El resultado que ve debe ser similar al siguiente, aunque la sintaxis de este recurso podría cambiar en el futuro. Al igual que la sintaxis de cmdlet, las claves que se ven entre corchetes son opcionales. Los tipos especifican el tipo de datos que espera cada clave.
Service [String] #ResourceName
{
Name = [string]
[BuiltInAccount = [string]{ LocalService | LocalSystem | NetworkService }]
[Credential = [PSCredential]]
[Dependencies = [string[]]]
[DependsOn = [string[]]]
[Description = [string]]
[DisplayName = [string]]
[Ensure = [string]{ Absent | Present }]
[Path = [string]]
[PsDscRunAsCredential = [PSCredential]]
[StartupType = [string]{ Automatic | Disabled | Manual }]
[State = [string]{ Running | Stopped }]
}
Dentro de una configuración, un bloque de recursos de servicio podría tener este aspecto para garantizar que el servicio Spooler se esté ejecutando.
Configuration TestConfig
{
# It is best practice to always directly import resources, even if the
# resource is a built-in resource.
Import-DSCResource -Name Service
Node localhost
{
# The name of this resource block, can be anything you choose, as l
# ong as it is of type [String] as indicated by the schema.
Service «Spooler:Running»
{
Name = «Spooler»
State = «Running»
}
}
}
Las configuraciones pueden contener varias instancias del mismo tipo de recurso. Cada instancia debe tener un nombre exclusivo. En el siguiente ejemplo, se agrega un segundo bloque de recursos de servicio para configurar el servicio «DHCP».
Configuration TestConfig
{
# It is best practice to always directly import resources, even if the
# resource is a built-in resource.
Import-DSCResource -Name Service
Node localhost
{
# The name of this resource block, can be anything you choose, as
# long as it is of type [String] as indicated by the schema.
Service «Spooler:Running»
{
Name = «Spooler»
State = «Running»
}
# To configure a second service resource block, add another Service
# resource block and use a unique name.
Service "DHCP:Running"
{
Name = "DHCP"
State = "Running"
}
}}
Extraido de MS.
un saludo