Cuando sea posible, no debería iniciar sesión manualmente en un servidor y hacer cambios. No es necesario instalar el software haciendo clic en los botones de una GUI. Además, no es necesario realizar las actualizaciones en los archivos de configuración de un editor de texto. Estas acciones manuales crean una oportunidad para que se produzcan errores, lo que puede tener como resultado configuraciones erróneas y errores de aplicación. Si desea replicar la configuración de un servidor, ¿puede recordar todos los pasos necesarios para poner en marcha el servidor existente? ¿Qué ocurre si debe hacerlo nuevamente en seis meses?
En una entradas anteriores, nos referimos a una forma de comprobar y aplicar automáticamente las actualizaciones a los servidores. Esto se realizó con el uso de Azure Automation. En este capítulo, examinamos cómo puede crear, ejecutar y editar runbooks, además de usar Desired State Configuration de PowerShell para instalar aplicaciones y configurar servidores automáticamente.

¿Qué es Azure Automation?
Una cuenta de Azure Automation reúne muchos elementos, tal como se muestra en la figura. Una característica principal es la de crear y ejecutar scripts a petición o en un programa definido. Puede crear scripts en PowerShell o Python, y dejar que la plataforma Azure manipule la programación y ejecución de esos runbooks. Puede compartir credenciales y objetos de conexión, y aplicar e informar automáticamente las configuraciones de servidores deseadas. Update Management, mantiene sus servidores seguros y actualizados con los parches y las actualizaciones de host más recientes a lo largo del ciclo de vida del entorno de su aplicación.

Para simplificar la administración en múltiples runbooks o configuraciones de estado deseado en una cuenta de Automation, puede compartir los siguientes recursos:
– Los programas le permiten definir un conjunto de tiempos y recurrencias que se puede aplicar a cada runbook o tarea de Update Management. Si posteriormente desea realizar el cambio a una aparición habitual, puede cambiar uno de los programas compartidos en lugar de cambiar cada runbook o tarea de Update Management individual que la use.
– Los módulos amplían la funcionalidad principal al almacenar módulos de PowerShell adicionales. Los módulos básicos Windows PowerShell y Azure ya están disponibles, pero los módulos adicionales, como aquellos para la administración de Linux, se pueden agregar y usar en runbooks.
– Las credenciales para las diferentes cuentas que tienen permisos para ejecutar varios runbooks se almacenan como activos, no se definen en cada runbook. Este enfoque le permite actualizar y restablecer las credenciales según sea necesario, y cada runbook que las usa se actualiza automáticamente. Por lo tanto, las credenciales no se almacenan como texto sin formato en runbooks, lo que aumenta la seguridad de los runbooks.
– Las conexiones definen las propiedades de autenticación para las entidades del servicio Azure AD. Este es un tipo especial de cuenta de usuario que permite a los runbooks tener acceso a sus recursos de Azure. Estas conexiones normalmente usan certificados digitales, no usan nombres de usuario y contraseñas, para proporcionar un nivel de seguridad adicional.
– Los certificados a menudo se integran con activos de conexión para proporcionar una forma segura de verificar la identidad de una entidad del servicio. Al igual que con las credenciales básicas, puede actualizar habitualmente estos certificados en una ubicación central, y cada runbook que los usa puede tener acceso de manera automática a los certificados nuevos. Puede crear y almacenar sus propios certificados para uso con runbooks o las definiciones de configuración de estado deseado.
– Las variables proporcionan un lugar central para el almacenamiento de valores de tiempo de ejecución como nombres, cadenas de ubicación y enteros. Cuando se ejecutan los runbooks, se inyectan estas variables. Este enfoque limita la cantidad de recursos codificados en cada runbook.

Trabajar más inteligente, no más duro
En el capítulo 16, nos referimos a cómo los servicios de administración de Azure funcionan en conjunto para supervisar e informar sobre los servidores en Azure, en entornos locales o en otros proveedores de nube. Los agentes requeridos se instalan y configuran en servidores remotos y luego proporcionan una forma de volver a conectarse a la infraestructura de Azure.
Azure Automation también puede funcionar a través de plataformas e infraestructuras. Por ejemplo, el trabajador de runbook híbrido puede ejecutar runbooks de Automation en servidores que se encuentran fuera de Azure. Usted continúa usando los activos compartidos de Automation que definen credenciales, conexiones y certificados, solo que esta vez esos activos se pueden usar para definir los componentes de autenticación para las diferentes plataformas. También puede usar las configuraciones de estado deseado en VM que no son de Azure, tanto para Windows como para Linux.
En todos los casos, se instala un componente de gateway en el entorno remoto que actuar como proxy de los comandos de Automation cuando se envían a los destinos designados. Este enfoque de proxy de gateway proporciona un punto de conexión único para Automation en los entornos remotos y minimiza las inquietudes de seguridad, ya que de otro modo no existe acceso directo a los servidores remotos.
Es posible que los runbooks y las definiciones de configuración de estado deseado deban editarse ligeramente para ejecutarse en servidores físicos locales en comparación con las VM de Azure. Al igual que con Azure Backup, Site Recovery o Update Management, la ventaja de Azure Automation es que proporciona un plano de administración único y un conjunto de herramientas para ofrecer automatización en todas sus diferentes infraestructuras y servidores.

Creación de una cuenta de Azure Automation
Vamos a dar el salto para crear una cuenta de Azure Automation y observaremos los runbooks predeterminados que se incluyen. Los runbooks de demostración ofrecen un marco excelente de creación de sus propios runbooks, además de contar con un editor gráfico que puede usar para arrastrar y soltar bloques de construcción que generan scripts de automatización.

Pruébelo ahora
Para crear una cuenta de Azure Automation y runbooks de ejemplo, complete los pasos siguientes:
1 En Azure Portal, seleccione Crear un recurso en la esquina superior izquierda.
2 Busque y seleccione Automatización y, a continuación, seleccione Crear.
La opción Automatización y control también crea un espacio de trabajo de Operations Management Suite (OMS) y configura Automation Hybrid Worker para administrar recursos fuera de Azure. OMS está en cierto modo en vías de extinción, reemplazado por los servicios básicos de Azure que vimos en capítulos anteriores. Por ahora, elija crear solo el recurso de automatización.
3 Escriba un nombre, como azuremol, y luego cree un nuevo grupo de recursos, como azuremolchapter18.
4 Seleccione la región de Azure más apropiada y cercana a usted, y acepte la opción Crear cuenta de ejecución de Azure.
La opción Crear ejecución como cuenta crea cuentas adicionales en Azure AD. También se crean certificados de seguridad que permiten la autenticación automática de las cuentas, sin necesidad de mensajes de usuario o de guardar una contraseña. Podría crear y especificar credenciales de cuentas normales adicionales, las que se definen como activo de Automation, para proporcionar un control más detallado de las cuentas que se usan para ejecutar ciertos runbooks.
Al combinarse con RBAC, que analizamos en el capítulo 6, es posible crear cuentas de ejecución para runbooks que ofrecen un conjunto limitado de permisos necesarios para lograr las tareas que requiere cada runbook o conjunto de runbooks. Desde una perspectiva de seguridad, este enfoque le permite auditar y controlar la forma y el momento en los que se usan estas cuentas. Evite la tentación de crear una sola cuenta de ejecución que proporcione permisos similares a los de administrador, ya que este enfoque no ofrece mucha protección contra el mal uso.

Activos y runbooks de Azure Automation
La cuenta de Azure Automation que creó en la sección anterior incluye algunos runbooks de ejemplo. Hay disponibles ejemplos de PowerShell y Python. Los activos y certificados de conexión también se agregan a la cuenta de Automation para las cuentas de ejecución que se crearon. Exploremos esos activos de conexión compartida.

Pruébelo ahora
Para ver los activos configurados y los runbooks de ejemplo, complete los pasos siguientes:
1 En Azure Portal, seleccione Grupos de recursos a la izquierda; elija su grupo, como azuremolchapter18; y seleccione su cuenta de Azure Automation, como azuremol.
2 En Recursos compartidos que se encuentra en el menú a la izquierda, seleccione Conexiones.
3 Seleccione AzureRunAsConnection, como se muestra en la figura.

4 Seleccione Certificados en el menú principal de la cuenta de Automation en Recursos compartidos y, a continuación, elija AzureRunAsCertificate. Tal como se muestra en la figura, la huella digital coincide con RunAsConnection del paso anterior.

5 Ahora que entiende los activos para las conexiones y los certificados, observemos uno de los runbooks de ejemplo. Elija Runbooks en el menú que se encuentra a la izquierda en la cuenta de Automation. Hay disponibles algunos runbooks de ejemplo.
6 Elija el runbook de PowerShell llamado AzureAutomationTutorialScript.
7 En la parte superior del runbook de ejemplo hay opciones para iniciar, ver y editar el runbook. Estas opciones no requieren mayor explicación.
También tiene la opción de programar, que le permite crear o seleccionar un recurso compartido que define un programa para ejecutar el runbook en un momento determinado, y una opción para webhooks, que le permite crear una URL de webhook para ejecutar el runbook de algún otro script o acción. Elija Ver.

Azure Automation y control de origen con GitHub
Los runbooks se pueden integrar con un sistema de control de origen, como GitHub. Uno de los grandes beneficios de un sistema de control de origen para los runbooks es que proporciona una forma de documentar la administración de cambios y revertir a versiones anteriores de los runbooks en caso de un problema.
Cada vez que guarda un runbook de Azure Automation, se compromete una nueva versión para el control de origen. No es necesario que salga del editor de runbook, ya que la plataforma Azure y el sistema de control de origen configurado están configurados para avanzar y retroceder. Si tiene un problema con el nuevo runbook, puede extraer una versión anterior del control de origen que permita continuar con la ejecución de los trabajos sin retraso y luego solucionar el problema que tenga la versión actualizada.
El uso del control de origen también proporciona un registro de los cambios realizados y el momento en el que se hicieron. Si necesita auditar sus runbooks o entender cómo se desarrollaron con el tiempo, los sistemas de control de origen ofrecen una forma excelente de ver las diferencias con cada revisión.

Runbook de ejemplo de Azure Automation
Examinemos cómo el runbook de PowerShell de ejemplo, AzureAutomationTutorialScript, se conecta a Azure y reúne información sobre sus recursos. Puede seguir con el runbook de ejemplo de Python si lo prefiere; el diseño es similar. PowerShell y Python son los únicos lenguajes compatibles actualmente con los runbooks de Azure Automation. En la siguiente lista se configuran las credenciales de conexión en el runbook.

El código comienza con la creación de un objeto para $connectionName. En el ejercicio “Pruébelo ahora”, vio que se creó un activo de conexión predeterminado para AzureRunAsConnection. A medida que cree sus propios runbooks, es posible que desee crear cuentas de ejecución adicionales y activos de conexión para separar los runbooks y las credenciales que usan. Las partes de conexión y el control de excepciones que veremos a continuación deben ser comunes en todos los runbooks. Según sea necesario, puede cambiar el activo de conexión de ejecución a usar.
A continuación, se usa una instrucción try para realizar la solicitud de conexión. Se crea un objeto de entidad de servicio llamado $servicePrincipalConnection, basado en $connectionName. Luego, el runbook inicia sesión en Azure con Add-AzureRmAccount y usa el objeto $servicePrincipalConnection para obtener TenantId, ApplicationId y Certificate-Thumbprint. Analizamos estos parámetros anteriormente, como parte del activo de conexión. El activo de certificado que coincide con la huella digital de $servicePrincipalConnection se usa para completar el inicio de sesión en Azure.
La siguiente lista muestra que, si la conexión falla, el runbook detecta el error y detiene la ejecución.

La instrucción catch manipula cualquier error como parte del intento de inicio de sesión. Si no se puede encontrar una conexión de entidad de servicio, se genera un error. Este error generalmente significa que no se puede encontrar el recurso de conexión que especificó. Compruebe el nombre y la ortografía de la conexión.
De lo contrario, se encontró el objeto de conexión y se utilizó la entidad de servicio para iniciar sesión, pero el proceso de autenticación no se realizó correctamente. Este error podría provenir de un certificado que ya no es válido o de una cuenta de ejecución que ya no está habilitada. Esta funcionalidad muestra cómo puede revocar una cuenta en Azure AD y garantizar que cualquier runbook que use las credenciales ya no pueda ejecutarse.
Ahora el runbook obtiene una lista de todos los recursos de Azure.

La parte final del runbook es donde iría su código de runbook. Se crea un objeto para $ResourceGroups que obtiene una lista de todos los grupos de recursos de Azure disponibles. Luego, un bucle foreach recorre los grupos de recursos, encuentra una lista de recursos y escribe una lista de los nombres y tipos de recursos.
En este ejemplo básico se muestra cómo puede interactuar con Azure cuando el runbook se ha autenticado con la suscripción. Si implementa RBAC en la cuenta de ejecución, solo se devuelven los grupos de recursos que la cuenta tiene permisos para ver. Este enfoque de RBAC destaca por qué es un buen principio de seguridad crear y usar cuentas de ejecución con un alcance para limitar el acceso de los runbooks a los recursos en su entorno de Azure. Siempre trate de proporcionar la menor cantidad de privilegios necesarios.
Si todo esto de PowerShell o Python es nuevo para usted, no se preocupe. Ambos proporcionan un excelente lenguaje de script básico, pero también pueden usarse para desarrollar aplicaciones complejas y potentes. Como desarrollador, cualquiera de los dos lenguajes debiera ser relativamente fácil de aprender y usar. Si usted es un profesional de TI, las tareas de automatización le ayudan a tener tiempo libre para realizar todos los demás trabajos acumulados, y tanto PowerShell como Python son buenos lugares para comenzar. Manning Publications también posee otros grandes libros que le serán de ayuda.

Ejecución y visualización de la salida de un runbook de ejemplo
Ahora que ha visto lo que contiene el script de runbook de ejemplo y cómo se usan los activos de conexión y certificado, ejecutemos el runbook y observemos el resultado.

Pruébelo ahora
Para ver el runbook en acción, complete los pasos siguientes:
1 Cierre la ventana que muestra el contenido del runbook y vuelva a la descripción general de AzureAutomationScriptTutorial.
2 Seleccione Iniciar en la parte superior de la ventana del runbook.
3 Confirme que desea iniciar el runbook y espere unos segundos para que comience a ejecutarse.
4 Seleccione Salida, tal como se muestra en la figura, y luego observe la ventana de la consola a medida que el runbook inicia sesión en Azure, obtiene una lista de grupos de recursos, pasa reiteradamente y muestra la lista de recursos en cada uno.

No es necesario que los runbooks de automatización existan de forma aislada. Un runbook puede ejecutar otro runbook. Esta capacidad le permite crear una automatización compleja y de varios pasos, y minimizar la duplicación de código. A medida que diseña y crea runbooks, intente dividirlos en pequeños bloques de código discretos. Las funciones comunes que puede reutilizar, como iniciar sesión en Azure y generar una lista de recursos o una lista de VM, deben crearse como pequeños runbooks que se pueden incluir en los runbooks más grandes. Cuando se lanzan nuevos cmdlets de PowerShell o se cambian los parámetros, puede actualizar rápidamente un solo runbook compartido que incluya esos cmdlets en lugar de tener que actualizar múltiples runbooks diferentes. Al principio, puede parecer que no vale la pena hacer un poco de trabajo extra con runbooks más pequeños y reutilizables, pero a medida que su entorno y el uso de la Automatización crezcan, me lo agradecerá. Gran parte de lo que ha hecho en este libro ha sido en implementaciones más pequeñas, pero comience a pensar en cómo implementar y administrar aplicaciones a escala.

Desired State Configuration (DSC) de PowerShell
En el capítulo 12 se introdujo el concepto de extensiones de VM. Una extensión es un pequeño componente de software que se instala en una VM para realizar una tarea determinada. La extensión de diagnóstico de VM se instaló en una VM para permitir que las métricas de rendimiento y los registros de diagnóstico se informen a la plataforma Azure desde la VM. Eso es genial, pero también hablamos un poco sobre cómo puede instalar software automáticamente.
Una forma de instalar software y configurar un servidor es usar la Desired State Configuration (DSC) de PowerShell. Con DSC, usted define cómo desea que se configure un servidor: el estado deseado. Puede definir los paquetes que se instalarán, las funciones que se configurarán o los archivos que se crearán, por ejemplo. Lo bueno de la DSC es que va más allá de la primera acción de instalación y configuración. Con el tiempo, los servidores a menudo se someten a eventos de mantenimiento o solución de problemas donde las configuraciones y paquetes se cambian manualmente. Luego, el servidor se desviará del estado deseado que usted definió inicialmente. En la figura se muestra cómo Azure Automation puede
actuar como un servidor central que almacena las definiciones de DSC, permitiendo a los servidores de destino recibir sus configuraciones e informar sobre su cumplimiento.
El administrador de configuración local (LCM) en cada servidor de destino controla el proceso para conectarse al servidor de extracción de Azure Automation, recibir y analizar la definición de DSC, y aplicar e informar sobre el cumplimiento. El motor LCM puede funcionar sin un servidor de extracción, se llama localmente al proceso

para leer y aplicar una definición de DSC. En este modo, donde usted configura manualmente el motor LCM, pierde muchos de los controles e informes centrales que a menudo se necesitan cuando administra muchos servidores.
También hay flexibilidad en la forma en la que los servidores de destino procesan las definiciones de DSC recibidas del servidor de extracción de Azure Automation.
Puede configurar la DSC para que funcione en uno de los tres modos de configuración:
– Solo aplicar: su estado deseado se envía y se aplica al servidor de destino, eso es todo. Esto es como el comportamiento de Azure Custom Script Extension en el sentido de que cualquier configuración o instalación se aplica cuando se implementa por primera vez, pero no hay procesos establecidos para detener esas configuraciones que cambian manualmente durante el ciclo de vida del servidor.
– Aplicar y monitorear: después de que el servidor tiene aplicado el estado deseado, la DSC continúa monitoreando cualquier cambio que haga que el servidor se desvíe de esa configuración inicial. Se puede usar un informe central para ver los servidores que ya no cumplen con el estado deseado. Esta configuración es un buen acuerdo entre la necesidad de mantener un servidor que cumpla con el estado deseado y proporcionar un elemento de interacción humana para tomar decisiones relacionadas con las opciones de corrección.
– Aplicar y autocorregir: se aplica la configuración más automatizada y autónoma al estado deseado y luego se supervisa cualquier desviación y se corrige automáticamente el servidor en caso de que se produzcan cambios para garantizar que sigue siendo compatible. Existe el peligro de que los cambios manuales legítimos se sobrescriban y, en cambio, se vuelva al estado deseado configurado, pero este modo de configuración garantiza que las configuraciones que asigne siempre tengan prioridad.
La DSC de PowerShell se puede usar en VM que se ejecutan en otros proveedores de nube, así como en VM locales y servidores virtuales. Gracias a .NET Core, la DSC de PowerShell también se puede usar en servidores Linux, por lo que no es una solución exclusiva para Windows. Esta compatibilidad con múltiples SO y proveedores hace de PowerShell una opción poderosa para configurar y administrar servidores a escala.
Puede crear y mantener su propio servidor de extracción de DSC, pero las características integradas de Azure Automation ofrecen algunos beneficios adicionales:
– Las credenciales se administran de forma centralizada y los certificados se generan automáticamente.
– La comunicación entre el servidor de extracción de DSC y los servidores de destino está cifrada.
– Se proporcionan informes incorporados para el cumplimiento de DSC, y existe una integración con Log Analytics para generar informes y alertas más detallados.
Esta sección es un curso intensivo en DSC de PowerShell, un componente que es poderoso por sí mismo y ha estado ampliamente disponible desde hace algunos años. Cuando se combina con Azure Automation, la DSC es una excelente opción para automatizar la instalación y configuración del software. Piense en los capítulos anteriores sobre conjuntos de escala de máquinas virtuales, por ejemplo. Puede aplicar una configuración de DSC al conjunto de escalas con Azure Automation, y luego,
a medida que se crea cada VM en el conjunto de escalas, se configurará automáticamente con los componentes y archivos de aplicación necesarios.

Definición y uso de DSC de PowerShell y un servidor de extracción de Azure Automation
¡Espero que este arrollador recorrido por la DSC de PowerShell le haya dado una idea de lo que es posible! Vamos a usar la DSC de PowerShell para automatizar el ejemplo de instalación de un servidor web básico en una VM.

Pruébelo ahora
Complete los siguientes pasos para ver PowerShell DSC en acción:
1 Cree una VM de Windows Server 2019 Datacenter y abra el puerto TCP 80 para el tráfico HTTP. ¡Puede hacerlo solo, estamos en el capítulo 18! Puede crear la VM en Cloud Shell o en Azure Portal, usted decide. Use el grupo de recursos que creó en los ejercicios anteriores, como azuremolchapter18. Puede continuar con los siguientes pasos a medida que se implementa la VM.
2 En su equipo local, cree un archivo llamado webserver. ps1; escriba el siguiente código; y guarde y cierre el archivo cuando haya terminado:
configuration WebServer {
Node localhost {
WindowsFeature WebServer {
Ensure = «Present»
Name = «Web-Server»
}
}
}
3 En Azure Portal, seleccione su grupo de recursos y luego elija su cuenta de Automation.
4 A la izquierda, elija State Configuration (DSC); Seleccione la pestaña Configuraciones; y en la parte superior de la ventana, elija Agregar una configuración.
5 Busque y seleccione su archivo webserver.ps1. El nombre de la configuración debe coincidir con el nombre del archivo, así que acepte el nombre predeterminado del servidor web y luego elija Aceptar.
La configuración tardará unos momentos en cargarse y crearse.
6 Cuando esté listo, seleccione la configuración de la lista y luego elija Compilar.

La DSC en segundo plano
Hagamos una pausa para hablar sobre lo que sucede cuando compila la configuración, tal como se muestra en la figura en esta barra lateral. Para distribuir las definiciones de DSC, sus archivos de PowerShell se convierten en un archivo de Formato de objeto administrado (MOF). Este tipo de archivo se usa para más que solo DSC de PowerShell y permite cambios de configuración en los componentes de Windows de una manera central y bien conocida. Cualquier definición de DSC, no solo en Azure Automation, debe compilarse antes de que pueda aplicarse a un servidor de destino. El motor LCM solo acepta y procesa archivos de MOF.

Debido a que el archivo de MOF define el estado completo de sus servidores, debe proteger su contenido. Si un atacante conociera todos los componentes de la aplicación instalados y la ubicación de varios archivos de configuración y código personalizado, aumenta la posibilidad de que sus servidores se vean comprometidos. Las versiones recientes de PowerShell cifran todo el archivo de MOF. Azure Automation genera automáticamente las claves y los certificados digitales requeridos cuando un servidor de destino está configurado para DSC, lo que le permite usar sin problemas los archivos de MOF cifrados. La automatización también cifra el tráfico entre el servidor de extracción de DSC y los nodos de destino, no solo el archivo de MOF.
El proceso de compilación en Azure Automation convierte la definición de DSC que proporciona en un archivo de MOF y cifra el archivo de MOF con los certificados y claves digitales. El proceso de compilación de su definición de DSC tarda unos segundos, pero asegura en gran medida su entorno, otro ejemplo de cómo Azure protege sus recursos de forma predeterminada.

7 Para aplicar la configuración a su VM, seleccione la pestaña de nodos en las ventanas State Configuration (DSC); seleccione Agregar; y elija la VM que creó en los pasos anteriores.
8 Elija Conectar.
9 En el menú desplegable Nombre de configuración del nodo, elija webserver.local-
host.
10 Establezca el modo de configuración en ApplyAndMonitor y seleccione Aceptar.
Puede demorar uno o dos minutos en habilitar la VM para usar el servidor de extracción de DSC de Azure PowerShell y aplicar el estado inicial deseado.
11 Cuando Azure Portal informa que la configuración está aplicada, seleccione su grupo de recursos; a continuación, seleccione la VM que creó en los pasos anteriores.
12 ¿Abrió el puerto TCP 80 para la VM cuando la creó? Si no es así, cree una regla de grupo de seguridad de red para permitir el tráfico y luego abra la IP pública de la VM en un navegador web. El proceso de DSC instala el servidor web IIS y la página web predeterminada se carga, tal como se muestra en la figura.

Este ejemplo básico de DSC de PowerShell solo instala la característica de servidor web. Puede usar la DSC de PowerShell para configurar el servidor web de IIS o copiar el código de su aplicación a la VM y ejecutar el sitio. Se pueden usar definiciones de DSC complejas para preparar la VM para servir el tráfico a los clientes de su pizzería sin interacción manual. Nuevamente, recuerde cómo debe diseñar sus aplicaciones para que se amplíen automáticamente: ¡la VM no puede esperar a que alguien inicie sesión, instale y configure todo manualmente!

Laboratorio: Uso de DSC con Linux
Solo para demostrar que DSC de PowerShell funciona en servidores Linux, creemos una VM de Ubuntu, instalemos los requisitos previos necesarios y luego instalemos un servidor web básico de NGINX con DSC. En producción, podría usar una imagen de VM personalizada que ya tuviera instalados los componentes de administración y luego aplicar las definiciones de DSC de PowerShell de la forma habitual:

1 DSC de PowerShell para Linux tiene algunas limitaciones en las distribuciones de Linux que admite sin configuración adicional, así que para mantener este ejercicio de laboratorio de fin de capítulo tan simple como sea posible, cree una VM CentOS 7.7 o posterior, y abra el puerto 80.
2 En la cuenta de Azure Automation, elija Módulos en el menú que se encuentra a la izquierda.
3 Seleccione Explorar galería y luego busque, seleccione e importe el módulo nx para administrar los recursos de DSC de Linux.
4 En su equipo local, cree un archivo llamado httpd.ps1 y escriba el siguiente código:
configuration httpd {
Import-DSCResource -Module nx
Node localhost {
nxPackage httpd {
Name = «httpd»
Ensure = «Present»
PackageManager = «yum»
}
nxService httpd {
Name = «httpd»
State = «running»
Enabled = $true
Controller = «systemd»
}
}
}
5 Agregue una configuración DSC a la cuenta de Azure Automation, suba el archivo httpd.ps1 fil y compile la configuración.
6 Agregue un nodo de DSC a su cuenta de Azure Automation, seleccione su VM CentOS, y luego elija su nombre de configuración de nodo httpd.localhost.
Nuevamente, la VM tarda uno o dos minutos en aplicar la configuración deseada. Puede ver la lista de VM conectadas y su estado de cumplimiento en la ventana de nodos de DSC. La VM informa de que cumple cuando el LCM ha aceptado y aplicado el archivo MOF, pero los comandos para instalar y configurar los paquetes httpd necesarios dentro de la VM pueden tardar uno o dos minutos más.
7 Seleccione su VM CentOS en Azure Portal, obtenga su dirección IP pública e introduzca la dirección IP de su VM en un navegador web para ver el servidor web instalado por DSC. Si el sitio web no se carga, espere uno o dos minutos para que finalice el proceso de instalación y luego actualice la página.
Si desea experimentar verdaderamente el nuevo mundo de Microsoft y Linux, puede instalar PowerShell en su VM de Linux. Complete los pasos de configuración rápida en http://mng.bz/VgyP para entender cómo pueden ser ahora los scripts multiplataforma de PowerShell.

Asi terminamos la entrada de hoy, gracias y hasta la proxima