Cambios en el comportamiento de la configuración de invitados en PowerShell Desired State Configuration
Antes de comenzar, es una buena idea leer la información general de la configuración de invitado.
Hay disponible un tutorial de vídeo de este documento.
La configuración de invitado usa la versión 3 de Desired State Configuration (DSC) para auditar y configurar máquinas. La configuración de DSC define el estado en que debe encontrarse la máquina. Hay muchas diferencias importantes en el modo de implementación de DSC en la configuración de invitado.
La configuración de invitado usa PowerShell 7 multiplataforma
La configuración de invitado está diseñada para que la experiencia de administración de Windows y Linux pueda ser coherente. En ambos entornos de sistema operativo, alguien con conocimientos de DSC de PowerShell puede crear y publicar configuraciones mediante aptitudes de scripting.
La configuración de invitado solo usa la versión 3 de DSC de PowerShell y no se basa en la implementación anterior de DSC para Linux ni en los proveedores de "nx" incluidos en ese repositorio.
La configuración de invitado funciona en PowerShell 7.1.3 para Windows y PowerShell 7.2, versión preliminar 6, para Linux. A partir de la versión 7.2, el módulo PSDesiredStateConfiguration ha dejado de formar parte de la instalación de PowerShell y, en su lugar, se ha instalado como un módulo de la Galería de PowerShell.
Varias configuraciones
La configuración de invitado admite la asignación de varias configuraciones en la misma máquina. No se requieren pasos especiales en el sistema operativo de la extensión de configuración de invitado. No es necesario establecer configuraciones parciales.
Las dependencias se administran por configuración
Cuando una configuración se empaqueta con las herramientas disponibles, las dependencias necesarias para la configuración se incluyen en un archivo ZIP.
Las máquinas extraen el contenido a una carpeta única para cada configuración.
El agente entregado por la extensión de configuración de invitado crea una sesión de PowerShell dedicada para cada configuración, mediante un $Env:PSModulePath que limita la carga automática de módulos solo a la ruta de acceso en la que se extrajo el paquete.
Este cambio tiene varias ventajas.
- Es posible usar versiones de módulos distintas para cada configuración, en la misma máquina.
- Cuando ya no se elimina una configuración en una máquina, el agente elimina de forma segura toda la carpeta donde se extrajo sin necesidad de administrar las dependencias compartidas entre las configuraciones.
- No es necesario administrar varias versiones de ningún módulo en un servicio central.
Los artefactos se administran como paquetes
La característica State Configuration de Azure Automation incluye la administración de artefactos para scripts de configuración y módulos. Una vez que ambos se publican en el servicio, el script se puede compilar en formato MOF. Del mismo modo, el servidor de extracción de Windows también requería la administración de configuraciones y módulos en la instancia del servicio web. Por el contrario, la extensión DSC tiene un modelo simplificado en el que todos los artefactos se empaquetan y almacenan en una ubicación accesible desde la máquina de destino mediante una solicitud HTTPS (la opción más popular es Azure Blob Storage).
La configuración de invitado solo usa el modelo simplificado en el que todos los artefactos se empaquetan juntos y se accede a ellos desde la máquina de destino a través de HTTPS. No es necesario publicar módulos, scripts ni compilar en el servicio. Un cambio es que el paquete siempre debe incluir un MOF compilado. No es posible incluir un archivo de script en el paquete y compilarlo en la máquina de destino.
Tamaño máximo del paquete de configuración personalizado
En la configuración del estado de Azure Automation, las configuraciones de DSC tenían un tamaño limitado. La configuración de invitado admite un tamaño de paquete total de 100 MB (antes de la compresión). No hay ningún límite específico en el tamaño del archivo MOF dentro del paquete.
El modo de configuración se establece en el artefacto del paquete
Al crear el paquete de configuración, el modo se establece mediante las siguientes opciones:
- Audit: comprueba el cumplimiento de una máquina. No se realiza ningún cambio.
- AuditandSet: comprueba y corrige el estado de cumplimiento de la máquina. Se realizan cambios si la máquina no es compatible.
El modo se establece en el paquete en lugar de establecerse en el servicio Configuration Manager local ya que puede ser diferente según la configuración cuando se asignan varias configuraciones.
Compatibilidad con parámetros a través de Azure Resource Manager
Los parámetros establecidos por la matriz de propiedades configurationParameter en las asignaciones de configuración de invitado sobrescriben el texto estático en un archivo MOF de configuración cuando el archivo se almacena en una máquina. Los parámetros permiten que un operador de la API de servicio controle la personalización y los cambios sin necesidad de ejecutar comandos en la máquina.
Los parámetros de Azure Policy que pasan valores a las asignaciones de configuración de invitado deben ser de tipo cadena. No es posible pasar matrices mediante parámetros, aunque el recurso de DSC admita matrices.
Conjunto de desencadenadores ajeno a la máquina
En las versiones anteriores de DSC, un desafío era corregir el desfase a gran escala sin una gran cantidad de código personalizado y la dependencia de conexiones remotas de WinRM. La configuración de invitado soluciona este problema. Los usuarios de la configuración de invitado controlan la corrección de desfase a través de la corrección a petición.
La secuencia incluye el método Get
Cuando la configuración de invitado audita o configura una máquina, se usa la misma secuencia de eventos para Windows y Linux. El cambio de comportamiento importante es que el servicio llama al método Get para devolver detalles sobre el estado de la máquina.
- El agente primero ejecuta
Testpara determinar si la configuración se encuentra en el estado correcto. - Si el paquete se establece en
Audit, el valor booleano devuelto por la función determina si el estado de Azure Resource Manager para Asignación de invitado debe ser Compatible o No compatible. - Si el paquete se establece en
AuditandSet, el valor booleano determina si se debe corregir la máquina aplicando la configuración mediante el métodoSet. Si el métodoTestdevuelve False, se ejecutaSet. SiTestdevuelve True, no se ejecutaSet. - Por último, el proveedor ejecuta
Getpara devolver el estado actual de cada configuración, de modo que haya detalles disponibles tanto sobre el motivo por el que una máquina no es compatible como para confirmar que el estado actual es compatible.
Requisitos especiales para Get
El método de función Get tiene requisitos especiales para la configuración de invitado de Azure Policy, que no eran necesarios para Windows PowerShell Desired State Configuration.
- La tabla hash que se devuelve debe incluir una propiedad denominada Reasons.
- La propiedad Reasons debe ser una matriz.
- Cada elemento de la matriz debe ser una tabla hash con claves denominadas Code y Phrase.
- No se debe devolver valor alguno más que la tabla hash.
El servicio utiliza la propiedad Reasons para estandarizar el modo en que se presenta la información sobre el cumplimiento. Puede pensar en cada elemento de Reasons como un "motivo" por el que el recurso es o no es compatible. La propiedad es una matriz porque un recurso podría no cumplir los requisitos por más de un motivo.
El servicio espera las propiedades Code y Phrase. Al crear un recurso personalizado, establezca el texto (normalmente stdout) que le gustaría mostrar como el motivo por el que el recurso no es compatible como el valor de Phrase. Code tiene requisitos de formato específicos, por lo que los informes pueden mostrar claramente información sobre el recurso usado para realizar la auditoría. Con esta solución, la configuración de invitado es extensible. Se podría ejecutar cualquier comando, siempre que la salida se pueda devolver como un valor de cadena para la propiedad Phrase.
- Code (cadena): el nombre del recurso, repetido, y luego un nombre corto sin espacios como identificador del motivo. Estos tres valores deben estar delimitados por signos de dos puntos sin espacios.
- Un ejemplo sería
registry:registry:keynotpresent
- Un ejemplo sería
- Phrase (cadena): texto legible para explicar el motivo por el que la configuración no es compatible.
- Un ejemplo sería
The registry key $key isn't present on the machine.
- Un ejemplo sería
$reasons = @()
$reasons += @{
Code = 'Name:Name:ReasonIdentifer'
Phrase = 'Explain why the setting is not compliant'
}
return @{
reasons = $reasons
}
Al usar herramientas de línea de comandos para obtener información que se devuelva en Get, es posible que la herramienta devuelva una salida no esperada. Aunque capture la salida en PowerShell, también podría haberse escrito en un error estándar. Para evitar este problema, considere la posibilidad de redirigir la salida a null.
Clase incrustada de la propiedad Reasons
En los recursos basados en scripts (solo Windows), la clase Reasons se incluye en el archivo MOF del esquema como se muestra a continuación.
[ClassVersion("1.0.0.0")]
class Reason
{
[Read] String Phrase;
[Read] String Code;
};
[ClassVersion("1.0.0.0"), FriendlyName("ResourceName")]
class ResourceName : OMI_BaseResource
{
[Key, Description("Example description")] String Example;
[Read, EmbeddedInstance("Reason")] String Reasons[];
};
En los recursos basados en clases (Windows y Linux), la clase Reason se incluye en el módulo de PowerShell como se muestra a continuación. Linux distingue mayúsculas de minúsculas, por lo que la "C" de Código y la "P" de Phrase deben estar en mayúsculas.
enum ensure {
Absent
Present
}
class Reason {
[DscProperty()]
[string] $Code
[DscProperty()]
[string] $Phrase
}
[DscResource()]
class Example {
[DscProperty(Key)]
[ensure] $ensure
[DscProperty()]
[Reason[]] $Reasons
[Example] Get() {
# return current current state
}
[void] Set() {
# set the state
}
[bool] Test() {
# check whether state is correct
}
}
Si el recurso tiene las propiedades necesarias, Get debe devolver esas propiedades en paralelo con la clase Reason. Si no se incluye Reason, el servicio incluye un comportamiento "comodín" que compara los valores de entrada con Get y los valores devueltos por Get y proporciona una comparación detallada como Reason.
Nombres de la configuración
El nombre de la configuración personalizada debe ser coherente en todas partes. El nombre del archivo .zip para el paquete de contenido, el nombre de la configuración en el archivo MOF y el nombre de la asignación de invitado en la plantilla de Azure Resource Manager deben ser el mismo.
Características comunes de DSC no disponibles durante la versión preliminar pública de la configuración de invitado
Durante la versión preliminar pública, la configuración de invitado no admite la especificación de dependencias entre máquinas mediante recursos "WaitFor*". No es posible que una máquina supervise otra máquina y espere a que esta alcance un estado antes de progresar.
El control del reinicio no está disponible en la versión preliminar pública de la configuración de invitado; $global:DSCMachineStatus tampoco está disponible. Las configuraciones no pueden reiniciar un nodo durante la configuración ni cuando esta finaliza.
Problemas conocidos de compatibilidad con los módulos admitidos
El módulo PsDscResources de la Galería de PowerShell y el módulo PSDesiredStateConfiguration que se suministra con Windows son compatibles con Microsoft y han sido un conjunto de recursos de uso frecuente para DSC. Hasta que el módulo PSDscResources se actualice para DSCv3, tenga en cuenta los siguientes problemas de compatibilidad conocidos.
- No use recursos del módulo
PSDesiredStateConfigurationque se incluye con Windows. En su lugar, cambie aPSDscResources. - No use los recursos
WindowsFeatureyWindowsFeatureSetenPsDscResources. En su lugar, cambie a los recursosWindowsOptionalFeatureyWindowsOptionalFeatureSet.
Los recursos "nx" de Linux incluidos en el repositorio de DSC para Linux se han escrito en una combinación de los lenguajes C y Python. Dado que el método de DSC en Linux es usar PowerShell, los recursos "nx" existentes no son compatibles con DSCv3. Hasta que haya disponible un nuevo módulo que contenga recursos admitidos para Linux es necesario crear recursos personalizados.
Coexistencia con la versión 3 y anteriores de DSC
La versión 3 de DSC de la configuración de invitado puede coexistir con versiones anteriores instaladas en Windows y Linux. Las implementaciones son independientes. Sin embargo, no hay ninguna detección de conflictos en las versiones de DSC, por lo que no intente administrar la misma configuración.
Pasos siguientes
- Lea la introducción a la configuración de invitado.
- Configure un entorno de desarrollo personalizado de paquetes de configuración de invitado.
- Cree un artefacto de paquete para la configuración de invitado.
- Pruebe el artefacto de paquete desde el entorno de desarrollo.
- Use el módulo
GuestConfigurationa fin de crear una definición de Azure Policy para la administración a gran escala del entorno. - Asigne la definición de directiva personalizada mediante Azure Portal.
- Obtenga información sobre cómo ver los detalles de cumplimiento para las asignaciones de directivas de configuración de invitado.