¿Qué es State Configuration de Azure Automation?
Puede usar State Configuration de Azure Automation para asegurarse de que las máquinas virtuales (VM) en un área de clúster se encuentran en un estado coherente con el mismo software instalado y las mismas configuraciones.
En esta unidad, obtendrá información sobre las características y funcionalidades de Azure Automation, revisará el modelo declarativo de Desired State Configuration (DSC) de PowerShell y explorará sus ventajas.
State Configuration de Azure Automation es un servicio de Azure basado en PowerShell. Le permite implementar de forma coherente, supervisar de manera confiable y actualizar automáticamente el estado deseado de todos los recursos. Azure Automation proporciona las herramientas para definir configuraciones y aplicarlas a máquinas reales y virtuales.
Razones para usar State Configuration de Azure Automation
El mantenimiento manual de una configuración correcta y coherente para los servidores que ejecutan los servicios puede ser difícil y propenso a errores. State Configuration de Azure Automation usa DSC de PowerShell para ayudar a resolver estos desafíos. Administra de forma centralizada los artefactos de DSC y el proceso de DSC.
State Configuration de Azure Automation tiene un servidor de extracción integrado. Puede seleccionar nodos como destino para que reciban automáticamente las configuraciones de este servidor de extracción, se ajusten al estado deseado y devuelvan la información de cumplimiento. Puede tener como destino máquinas físicas o virtuales Windows o Linux, en la nube o en un entorno local.
Puede usar los registros de Azure Monitor para revisar el cumplimiento de los nodos si configura State Configuration de Azure Automation para enviar estos datos.
¿Qué es DSC de PowerShell?
DSC de PowerShell es una plataforma de administración declarativa que usa State Configuration de Azure Automation para configurar, implementar y controlar sistemas. Un lenguaje de programación declarativo separa la intención (lo que se quiere hacer) de la ejecución (cómo se quiere hacer). Se especifica el estado deseado y se permite que DSC realice el trabajo para lograrlo. No tiene que saber cómo implementar una característica cuando un recurso de DSC está disponible. En su lugar, puede centrarse en la estructura de la implementación.
Si ya usa PowerShell, puede que se pregunte por qué necesita DSC. Considere el ejemplo siguiente.
Si quiere crear un recurso compartido en un servidor de Windows, puede usar este comando de PowerShell:
# Create a file share
New-SmbShare -Name MyFileShare -Path C:\Shared -FullAccess User1 -ReadAccess User2
Este script es sencillo y fácil de comprender. Pero si usa este script en producción, se encontrará varios problemas. Tenga en cuenta lo que podría ocurrir si el script se ejecuta varias veces o si User2 ya tiene acceso total en lugar de acceso de solo lectura.
Este enfoque no es idempotente. La idempotencia describe una operación que tiene el mismo efecto si se ejecuta una o 10 001 veces. Para lograr esta idempotencia en PowerShell, tiene que agregar lógica y control de errores. Si el recurso compartido no existe, créelo. Si el recurso compartido existe, no es necesario crearlo. Si User2 existe pero no tiene acceso de lectura, se agrega acceso de lectura.
El script de PowerShell tendría un aspecto similar al siguiente:
$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
Write-Verbose -Message "Share with name $Name exists"
$shareExists = $true
}
if ($shareExists -eq $false)
{
Write-Verbose "Creating share $Name to ensure it is Present"
New-SmbShare @psboundparameters
}
else
{
# Need to call either Set-SmbShare or *ShareAccess cmdlets
if ($psboundparameters.ContainsKey("ChangeAccess"))
{
#...etc., etc., etc
}
}
Otros casos especiales que no se han considerado podrían presentarse solo cuando surjan problemas. DSC controla automáticamente los casos inesperados. Con DSC, se describe el resultado en lugar del proceso para lograr el resultado.
En el siguiente fragmento de código de DSC se muestra un ejemplo:
Configuration Create_Share
{
Import-DscResource -Module xSmbShare
# A node describes the VM to be configured
Node $NodeName
{
# A node definition contains one or more resource blocks
# A resource block describes the resource to be configured on the node
xSmbShare MySMBShare
{
Ensure = "Present"
Name = "MyFileShare"
Path = "C:\Shared"
ReadAccess = "User1"
FullAccess = "User2"
Description = "This is an updated description for this share"
}
}
}
En el ejemplo anterior se usa el módulo xSmbShare que indica a DSC cómo comprobar el estado de un recurso compartido de archivos. El Kit de recursos de DSC tiene más de 100 módulos de recursos, incluido uno para la instalación de un sitio de IIS. Puede encontrar un vínculo al Kit de recursos de DSC en la unidad Resumen al final de este módulo.
Obtendrá más información sobre la estructura del código de DSC de PowerShell en la unidad siguiente.
¿Qué es el LCM?
El administrador de configuración local (LCM) es un componente de Windows Management Framework (WMF) de un sistema operativo Windows. El LCM es responsable de actualizar el estado de un nodo, como una máquina virtual, para que coincida con el estado deseado. Cada vez que se ejecuta el LCM, completa los pasos siguientes:
- Get: obtiene el estado actual del nodo.
- Test: compara el estado actual de un nodo con el estado deseado mediante un script de DSC compilado (archivo .mof).
- Set: actualiza el nodo para que coincida con el estado deseado que se describe en el archivo .mof.
Configurará el LCM al registrar una máquina virtual con Azure Automation.
Arquitecturas de inserción y extracción en DSC
El LCM de cada nodo puede funcionar de dos modos.
Modo de inserción: un administrador envía o inserta de forma manual las configuraciones en los nodos. El LCM se asegura de que el estado de cada nodo coincida con el que especifica la configuración.
Modo de extracción: un servidor de extracción contiene la información de configuración. El LCM de cada nodo sondea el servidor de extracción a intervalos regulares (de forma predeterminada, cada 15 minutos) para obtener los detalles de configuración más recientes. Estas solicitudes se indican como Paso 1 en el diagrama siguiente. En el Paso 2, el servidor de extracción devuelve los detalles de los cambios de la configuración a cada nodo.
En el modo de extracción, cada nodo tiene que estar registrado con el servicio de extracción.
Ambos modos tienen ventajas:
- El modo de inserción es fácil de configurar. No necesita su propia infraestructura dedicada y se puede ejecutar en un equipo portátil. El modo de inserción resulta útil para probar la funcionalidad de DSC. También puede usar el modo de inserción para hacer que una nueva imagen de máquina tenga el estado deseado de línea de base.
- El modo de extracción resulta útil en una implementación empresarial que abarca un gran número de máquinas. El LCM sondea regularmente el servidor de extracción y comprueba que los nodos se encuentran en el estado deseado. Si una herramienta o un equipo externos aplican revisiones que producen un desfase de configuración en máquinas individuales, esas máquinas vuelven a ponerse rápidamente en línea con la configuración que se haya establecido. Este proceso puede ayudarle a lograr un estado de cumplimiento continuo de las obligaciones normativas y de seguridad.
Plataformas y sistemas operativos compatibles
DSC de Azure Automation es compatible con Azure Cloud Services y otros proveedores de nube, la infraestructura local o una combinación híbrida de todos estos entornos.
DSC de Azure Automation es compatible con los sistemas operativos siguientes:
- Windows
- Server 2022
- Server 2019
- Server 2016
- Server 2012 R2
- Server 2012
- Server 2008 R2 SP1
- 11
- 10
- 8.1
- 7
- Linux
- La extensión DSC de Linux admite todas las distribuciones de Linux que se enumeran en la documentación de DSC de PowerShell.
DSC de PowerShell está instalado en todas las máquinas Linux compatibles con DSC de Azure Automation.
Requisitos de DSC para Windows
En las máquinas Windows, la extensión de máquina virtual Desired State Configuration (DSC) de Azure usa WMF para administrar las versiones de características de Windows como DSC de Windows PowerShell y Administración remota de Windows (WinRM). Azure DSC admite WMF 4.0 y versiones posteriores, por lo que las máquinas Windows deben ejecutar Windows Server 2008 R2 SP1, Windows 7 o versiones posteriores.
La primera vez que se llama a la extensión DSC de Azure, se instala una versión de WMF compatible con el sistema operativo en todas las versiones de Windows, excepto para Windows Server 2016 o versiones posteriores. En Windows Server 2016 y versiones posteriores ya está instalada la versión más reciente de WMF. Después de instalar WMF, es necesario reiniciar la máquina.
WinRM está habilitado en los nodos de máquina que ejecutan Windows Server 2012 o versiones posteriores, y Windows 7 o versiones posteriores.
La compatibilidad con proxy para el agente DSC está disponible en las compilaciones 1809 y posteriores de Windows. La compatibilidad con proxy no está disponible en DSC para versiones anteriores de Windows.
Otros requisitos de DSC
Si los nodos se encuentran en una red privada, se necesitan el puerto y las direcciones URL siguientes para que DSC se comunique con Azure Automation:
- Puerto: Solo se requiere el puerto TCP 443 para el acceso a Internet de salida
- Dirección URL global: *.azure-automation.net
- Direcciones URL globales de US Gov Virginia: *.azure-automation.us
- Servicio de agente: https://
<workspaceId>.agentsvc.azure-automation.net