Todas las organizaciones quieren reducir el esfuerzo manual y los errores en sus actividades, y la automatización desempeña un papel importante a la hora de conseguir previsibilidad, estandarización y coherencia tanto en la creación de un producto como en las operaciones. La automatización ha sido el objetivo de casi todos los directores informáticos (CIO) y responsables digitales para garantizar que sus sistemas tengan una alta disponibilidad, además de ser escalables, fiables y capaces de satisfacer las necesidades de sus clientes.
La automatización se hizo más importante con la llegada del cloud ya que se pueden aprovisionar nuevos recursos sobre la marcha sin la adquisición de recursos de hardware. Por lo tanto, las empresas de cloud desean aplicar la automatización en casi todas sus actividades para reducir el uso indebido, los errores, la gestión, el mantenimiento y la administración.
En este capítulo, vamos a evaluar Azure Automation como un servicio principal que
proporciona capacidades de automatización, junto con sus capacidades diferenciadas
en comparación con otros servicios con un aspecto aparentemente similar. En este
capítulo, abordaremos los siguientes temas:

• El panorama de Azure Automation
• El servicio Azure Automation
• Recursos para los servicios de Azure Automation
• Escribir runbooks para Azure Automation
• Webhooks
• Hybrid Workers

Empecemos con Azure Automation, un servicio en el cloud para la automatización de procesos.

Automatización
La automatización es necesaria para el aprovisionamiento, las operaciones, la administración
y el desaprovisionamiento de recursos de TI dentro de una organización. En la Figura 4.1
se analiza con más detalle lo que representa cada uno de estos casos prácticos:

Antes de la llegada del cloud, los recursos de TI eran principalmente on-premises y a menudo
se utilizaban procesos manuales para estas actividades. Sin embargo, desde que aumentó la
adopción del cloud, se ha puesto un mayor énfasis y atención en la automatización. La razón
principal es que la agilidad y flexibilidad de la tecnología de cloud brindan la oportunidad de
aprovisionar, desaprovisionar y administrar estos recursos sobre la marcha en una pequeña
fracción del tiempo que solía requerir. Esta flexibilidad y agilidad vienen acompañadas con
los requisitos de ser más predecible y coherente con el cloud porque resulta más fácil para
las organizaciones la creación de recursos.

Microsoft tiene una excelente herramienta para la automatización de TI conocida como
System Center Orchestrator. Es una herramienta estupenda de automatización para
entornos on-premises y en el cloud, pero se trata de un producto y no de un servicio.
Debe tener licencia e implementarse en servidores y, a continuación, los runbooks
se pueden ejecutar para aplicar cambios en los entornos en el cloud y on-premises.
Microsoft se dio cuenta de que era necesaria una solución de automatización que pudiera
proporcionarse a los clientes como servicio en lugar de comprarse e implementarse como
un producto. Y aquí aparece Azure Automation.

Azure Automation
Azure proporciona un servicio denominado Azure Automation, que es un servicio
esencial para la automatización de procesos, actividades y tareas no solo en Azure, sino
también on-premises. Con Azure Automation, las organizaciones pueden automatizar
sus procesos y tareas relacionados con el procesamiento, el desmantelado, las operaciones
y la administración de sus recursos en el cloud, entornos de TI, plataformas y lenguajes.
En la Figura 4.2, podemos ver algunas características de Azure Automation:

Arquitectura de Azure Automation
Azure Automation consta de varios componentes y cada uno de estos está completamente
desacoplado del resto. La mayor parte de la integración se produce en el nivel del almacén
de datos y ningún componente se conecta directamente entre sí.
Cuando se crea una cuenta de Automation en Azure, la administra un servicio
de administración. El servicio de administración es un único punto de contacto para
todas las actividades dentro de Azure Automation. Todas las solicitudes del portal,
incluidos el almacenamiento, la publicación y la creación de runbooks para ejecutar,
detener, suspender, iniciar y probar se envían al servicio de administración de
automatización y el servicio escribe los datos de solicitud en su almacén de datos.
También crea un registro de trabajo en el almacén de datos y, en función del estado
de los trabajos de runbook, lo asigna a un trabajo.

El trabajo sigue sondeando la base de datos en busca de nuevos trabajos asignados. Una vez
que encuentra una asignación de trabajo, recupera la información del trabajo y comienza a
ejecutarlo mediante su motor de ejecución. Los resultados se escriben de nuevo en la base
de datos, los lee el servicio de administración y se muestran de nuevo en Azure Portal.
Los Hybrid Workers que trataremos más adelante en este capítulo también son trabajos
de runbook, aunque no se muestran en la Figura 4.3.
El primer paso para empezar a usar Azure Automation es crear una nueva cuenta. Una vez
creada la cuenta, el resto de artefactos se crean dentro de la cuenta.
La cuenta actúa como el recurso principal de nivel superior que se puede administrar
mediante grupos de recursos de Azure y su propio plano de control.
La cuenta se debe crear dentro de una región y toda la automatización de esta cuenta
se ejecuta en los servidores de esa región.
Es importante elegir la región de forma inteligente, preferiblemente cerca de otros recursos
de Azure que la cuenta de Automation integra o administra, para reducir el tráfico de red
y la latencia entre las regiones.
La cuenta de Automation también admite un par de cuentas de ejecución que se pueden
crear desde la cuenta de Automation. Como estas cuentas de ejecución son análogas a
una cuenta de servicio, las creamos principalmente para ejecutar acciones. Aunque de
forma general hablamos de cuenta de ejecución, hay dos tipos de cuenta de ejecución:
una se denomina cuenta de ejecución clásica de Azure y la otra es simplemente la cuenta
de ejecución, y las dos se utilizan para conectarse a suscripciones de Azure. La cuenta de
ejecución clásica de Azure se utiliza para conectarse a Azure mediante la API de Azure
Service Management y la cuenta de ejecución se utiliza para conectarse a Azure mediante
la API de Azure Resource Management (ARM).
Ambas cuentas utilizan certificados para autenticarse con Azure. Estas cuentas se pueden
crear al crear la cuenta de Automation, o puedes optar por crearlas en una etapa posterior
desde Azure Portal.

Se recomienda crear estas cuentas de ejecución más adelante en lugar de crearlas
durante la creación de la cuenta de Automation, porque si se crean al configurar la cuenta
de Automation, Automation generará los certificados y las entidades de servicio en segundo
plano con la configuración predeterminada. Si se necesita más control y configuración
personalizada para estas cuentas de ejecución, como usar un certificado o entidad de servicio
existentes, las cuentas de ejecución deben crearse después de la cuenta de Automation.
Una vez creada la cuenta de Automation, esta proporciona un panel a través del cual
se pueden habilitar varios escenarios de automatización.
Algunos de los escenarios importantes que se pueden habilitar mediante una cuenta
de Automation están relacionados con:

• Automatización de procesos
• Administración de la configuración
• Administración de actualizaciones

La automatización consiste en escribir scripts que sean reutilizables y genéricos para que
puedan reutilizarse en varios escenarios. Por ejemplo, un script de automatización debe
ser lo bastante genérico como para iniciar y detener cualquier MV en cualquier grupo
de recursos en cualquier suscripción y grupo de administración. La programación de la
información del servidor de MV, junto con los nombres de grupos de recursos, suscripciones
y grupos de administración, dará lugar a la creación de varios scripts similares, y cualquier
cambio en uno provocará sin duda el cambio de todos los scripts. Es mejor crear un script
único para esta finalidad mediante el uso de parámetros y variables de scripting, y debes
asegurarte de que el ejecutor suministre los valores para estos artefactos.
Examinemos con más detenimiento cada uno de los escenarios mencionados.

Automatización de procesos
La automatización de procesos hace referencia al desarrollo de scripts que reflejan
procesos del mundo real. La automatización de procesos consta de varias actividades,
donde cada actividad realiza una tarea específica. En conjunto, estas actividades forman
un proceso completo. Las actividades pueden ejecutarse en función de si la actividad
anterior se ejecutó correctamente o no.

Hay algunos requisitos que cualquier automatización de procesos requiere
de la infraestructura en la que se ejecuta. Algunos de ellos son los siguientes:

• La capacidad de crear flujos de trabajo
• La capacidad de ejecutar durante un periodo prolongado
• La capacidad de guardar el estado de ejecución cuando el flujo de trabajo no esté
  completo, lo que también se conoce como creación de puntos de control e hidratación
• La capacidad de reanudar desde el último estado guardado en lugar de empezar desde
  el principio

El siguiente escenario que vamos a explorar es la administración de la configuración.
Administración de la configuración
La administración de la configuración hace referencia al proceso de administrar
la configuración del sistema a lo largo de su ciclo de vida. Azure Automation State
Configuration es el servicio de administración de la configuración de Azure que permite
a los usuarios escribir, administrar y compilar la configuración de PowerShell DSC para
nodos en el cloud y centros de datos on-premises.
Azure Automation State Configuration nos permite administrar MV de Azure, MV
clásicas de Azure y las máquinas físicas o MV (Windows/Linux) on-premises, además
de proporcionar compatibilidad con MV en otros proveedores de cloud.
Una de las mayores ventajas de Azure Automation State Configuration es que proporciona
escalabilidad. Podemos administrar miles de máquinas desde una única interfaz de
administración central. Podemos asignar configuraciones a las máquinas con facilidad
y verificar si son compatibles con la configuración deseada.
Otra ventaja es que Azure Automation se puede utilizar como repositorio para almacenar
las configuraciones de Desired State Configuration (DSC) para utilizarse cuando sean
necesarias.
En la siguiente sección, hablaremos sobre la administración de actualizaciones.

Administración de actualizaciones
Como ya sabes, es responsabilidad del cliente administrar las actualizaciones y las revisiones
cuando se trata de IaaS. La característica Update Management de Azure Automation se puede
utilizar para automatizar o administrar las actualizaciones y revisiones de tus MV de Azure. Hay
varios métodos mediante los cuales puedes habilitar Update Management en tu MV de Azure:

• Desde tu cuenta de Automation
• A través de Azure Portal
• Desde un runbook
• Desde una MV de Azure

La habilitación desde una MV de Azure es el método más sencillo. Sin embargo, si tienes
un gran número de MV y necesitas habilitar Update Management, debes plantearte una
solución escalable, como un runbook, o hacerlo desde una cuenta de Automation.
Ahora que tienes claros los escenarios, vamos a explorar los conceptos relacionados
con Azure Automation.
Conceptos relacionados con Azure Automation
Ahora ya sabes que Azure Automation requiere una cuenta, que se denomina cuenta de
Azure Automation. Antes de profundizar más, vamos a examinar los conceptos relacionados
con Azure Automation. Comprender el significado de cada uno de estos términos es muy
importante, ya que vamos a utilizarlos a lo largo de este capítulo. Empecemos con runbook.
Runbook
Un runbook de Azure Automation es una colección de instrucciones de scripting que
representan un solo paso en la automatización de procesos o una automatización de procesos
completa. Es posible invocar otros runbooks desde un runbook principal y estos runbooks
pueden crearse en varios lenguajes de scripting. Los lenguajes que admiten la creación
de runbooks son los siguientes:

• PowerShell
• Python 2 (en el momento de escribir este artículo)
• Flujos de trabajo de PowerShell
• PowerShell gráfico
• Flujos de trabajo gráficos de PowerShell

Crear una cuenta de Automation es muy fácil y se puede realizar desde Azure Portal. En la
hoja Todos los servicios, encontrarás Cuenta de Automation o puedes buscarla en Azure
Portal. Como se ha mencionado anteriormente, durante la creación tendrás la opción de
crear una cuenta de ejecución. En la Figura 4.4 se muestran las entradas necesarias para
crear una cuenta de Automation:

Cuentas de ejecución
De forma predeterminada, las cuentas de Azure Automation no tienen acceso a ningún
recurso incluido en ninguna suscripción de Azure, incluida la suscripción en la que están
hospedadas. Una cuenta necesita acceso a una suscripción de Azure y sus recursos para
poder administrarlos. Una cuenta de ejecución es una forma de proporcionar acceso a las
suscripciones y a los recursos que contienen.
Esta práctica es opcional. Puede haber como máximo una cuenta de ejecución para cada
suscripción clásica y basada en el administrador de recursos; sin embargo, una cuenta de
Automation podría necesitar conectarse a numerosas suscripciones. En estos casos, se
recomienda crear recursos compartidos para cada una de las suscripciones y utilizarlos
en runbooks.

Después de crear la cuenta de Automation, ve a la vista Cuentas de ejecución en el portal y
verás que se pueden crear dos tipos de cuentas. En la Figura 4.5, puedes ver que la opción
para crear una cuenta de ejecución de Azure y una cuenta de ejecución clásica de Azure
están disponibles en la hoja Cuentas de ejecución:

Estas cuentas de ejecución se pueden crear mediante Azure Portal, PowerShell y la CLI.
Para obtener información sobre cómo crear estas cuentas con PowerShell, visita https://
docs.microsoft.com/azure/automation/manage-runas-account.
En el caso de la cuenta de ejecución de ARM, este script crea una nueva entidad de servicio
de Azure AD y un nuevo certificado, y proporciona permisos de RBAC de colaborador a la
entidad de servicio recién creada en la suscripción.
Trabajos
El envío de una solicitud de trabajo no se vincula directamente a la ejecución de la solicitud
de trabajo debido a la arquitectura desacoplada de Azure Automation. El enlace entre
ellas es indirecto mediante el uso de un almacén de datos. Cuando Automation recibe una
solicitud para ejecutar un runbook, crea un nuevo registro en su base de datos con toda
la información relevante. Hay otro servicio que se ejecuta en varios servidores, conocido
como Hybrid Runbook Worker, dentro de Azure, que busca las nuevas entradas agregadas
a la base de datos para la ejecución de un runbook. Una vez que ve un nuevo registro, lo
bloquea para que ningún otro servicio pueda leerlo y, a continuación, ejecuta el runbook.

Activos
Los activos de Azure Automation hacen referencia a artefactos compartidos que se pueden
usar en los runbooks. Se muestran en la Figura 4.6:

Credenciales
Las credenciales hacen referencia a los secretos, como la combinación de nombre de
usuario y contraseña, que se pueden usar para conectarse a otros servicios de integración
que necesitan autenticación. Estas credenciales se pueden utilizar en runbooks mediante
el cmdlet de PowerShell Get-AutomationPSCredential junto con su nombre asociado:
$myCredential = Get-AutomationPSCredential -Name ‘MyCredential’
La sintaxis de Python requiere importar el módulo automationassets y utilizar la función
get_automation_credential junto con el nombre de las credenciales asociado:
import automationassets
cred = automationassets.get_automation_credential(«credtest»)

Certificados
Los certificados hacen referencia al certificado X.509 que se puede adquirir de las
autoridades de certificación o puede ser autofirmado. Los certificados se utilizan con
fines de identificación en Azure Automation. Todos los certificados tienen un par de claves
conocidas como claves privadas/públicas. La clave privada se utiliza para crear un activo
de certificado en Azure Automation y la clave pública debe estar disponible en el servicio
de destino. Mediante la clave privada, la cuenta de Automation puede crear una firma digital
y anexarla a la solicitud antes de enviarla al servicio de destino. El servicio de destino puede
recuperar los detalles (el hash) de la firma digital mediante la clave pública ya disponible
y determinar la identidad del remitente de la solicitud.
Los activos de certificado almacenan la información y las claves de los certificados en Azure
Automation. Estos certificados se pueden utilizar directamente en runbooks y también los
utilizan los activos de la conexión. En la siguiente sección se muestra la forma de consumir
certificados en un activo de conexión. El activo de conexión de la entidad de servicio de
Azure utiliza una huella digital de certificado para identificar el certificado que desea usar,
mientras que otros tipos de conexión utilizan el nombre del activo de certificado para
acceder al certificado.
Se puede crear un activo de certificado al proporcionar un nombre y cargar un certificado.
Es posible cargar certificados públicos (archivos .cer) así como certificados privados
(archivos .pfx). La parte privada del certificado también tiene una contraseña que se
debe usar antes de acceder al certificado.

La creación de un certificado implica proporcionar un nombre y una descripción, cargar el
certificado, proporcionar una contraseña (en el caso de archivos .pfx) e informar al usuario
de si el certificado se puede exportar o no.
Debe haber un certificado disponible antes de poder crear este activo de certificado. Los
certificados se pueden adquirir de las autoridades de certificación o se pueden generar. Los
certificados generados se conocen como certificados autofirmados. Siempre es una buena
práctica utilizar certificados de autoridades de certificación para entornos importantes
como los entornos de producción. No hay problema en utilizar certificados autofirmados
con fines de desarrollo.
Para generar un certificado autofirmado mediante PowerShell, utiliza este comando:
$cert = New-SelfSignedCertificate -CertStoreLocation «Cert:\CurrentUser\my»
-KeySpec KeyExchange -Subject «cn=azureforarchitects»
Esto creará un nuevo certificado en el almacén de certificados de usuario actual en tu carpeta
personal. Dado que este certificado también debe cargarse en el activo de certificado de Azure
Automation, debe exportarse al sistema de archivos local, como se muestra en la Figura 4.8:

Al exportar el certificado, la clave privada también debe exportarse, por lo que se debe
seleccionar Exportar la clave privada.
Selecciona la opción Intercambio de información personal y el resto de valores deben
conservar sus valores predeterminados.

Proporciona una contraseña y el nombre de archivo C:\azureforarchitects.pfx
y la exportación debe realizarse correctamente.
La conexión a Azure puede realizarse de varias maneras. Sin embargo, el método más seguro
es a través de un certificado. Se crea una entidad de servicio en Azure mediante el certificado.
La entidad de servicio se puede autenticar mediante el uso del certificado. La clave privada
del certificado está con el usuario y la parte pública está con Azure. En la siguiente sección,
se creará una entidad de servicio mediante el certificado creado en esta sección.
Crear una entidad de servicio mediante credenciales de certificado
Se puede crear una entidad de servicio mediante Azure Portal, la CLI de Azure o Azure
PowerShell. El script para crear una entidad de servicio con Azure PowerShell está
disponible en esta sección.
Después de iniciar sesión en Azure, el certificado creado en la sección anterior se convierte
en codificación base64. Se crea una nueva entidad de servicio, azureforarchitects y las
credenciales de certificado se asocian a la entidad de servicio recién creada. Por último,
se proporcionan a la nueva entidad de servicio permisos de control de acceso basados
en roles de colaborador en la suscripción:

Login-AzAccount
$certKey = [system.Convert]::ToBase64String($cert.GetRawCertData())
$sp = New-AzADServicePrincipal -DisplayName «azureforarchitects»
New-AzADSpCredential -ObjectId $sp.Id -CertValue $certKey -StartDate
$cert.NotBefore -EndDate $cert.NotAfter
New-AzRoleAssignment -RoleDefinitionName contributor -ServicePrincipalName
$sp.ApplicationId
Get-AzADServicePrincipal -ObjectId $sp.Id
$cert.Thumbprint
Get-AzSubscription

Para crear un activo de conexión, se puede obtener el id. de aplicación mediante el cmdlet
Get-AzADServicePrincipal y el resultado se muestra en la Figura 4.9:

La huella digital del certificado se puede obtener mediante la referencia del certificado
junto con SubscriptionId, que se puede obtener mediante el cmdlet Get-AzSubscription.
Conexiones
Los activos de conexión se utilizan para crear información de conexión a servicios externos.
En este sentido, incluso Azure se considera un servicio externo. Los activos de conexión
poseen toda la información necesaria para conectarse correctamente a un servicio. Azure
Automation proporciona tres tipos de conexión «out of the box»:

• Azure
• Certificado clásico de Azure
• Entidad de servicio de Azure

Es una buena práctica utilizar la entidad de servicio de Azure para conectarse a recursos de
Azure Resource Manager y utilizar el certificado clásico de Azure para los recursos clásicos
de Azure. Es importante tener en cuenta que Azure Automation no proporciona ningún tipo
de conexión para conectarse a Azure utilizando credenciales, como un nombre de usuario
y una contraseña.
Los certificados clásicos de Azure y los certificados de Azure tienen una naturaleza similar.
Ambos nos ayudan a conectarnos a los recursos basados en API de administración de
servicios de Azure. De hecho, Azure Automation crea una conexión de certificado clásico
de Azure al crear una cuenta de ejecución clásica.
Las cuentas de ejecución utilizan de manera interna la entidad de servicio de Azure para
conectarse a recursos basados en Azure Resource Manager.

En la Figura 4.10 se muestra un nuevo activo de conexión del tipo AzureServicePrincipal.
Necesita:

• El nombre de la conexión. Es obligatorio proporcionar un nombre.
• Una descripción de la conexión. Este valor es opcional.
• Selecciona un tipo adecuado. Es obligatorio seleccionar una opción;
  AzureServicePrincipal está seleccionado para crear un activo de conexión
  para todos los propósitos de este capítulo.
• ApplicationId, también conocido como clientid, es el id. de aplicación generado
  durante la creación de una entidad de servicio. En la sección siguiente se muestra
  el proceso de creación de una entidad de servicio mediante Azure PowerShell.
  Es obligatorio proporcionar un id. de aplicación.
• TenantId es el identificador único del inquilino. Esta información está disponible
  en Azure Portal o mediante el uso del cmdlet Get-AzSubscription. Es obligatorio
  proporcionar un identificador de inquilino.
• CertificateThumbprint es el identificador de certificado. Este certificado ya debe
  estar cargado en Azure Automation mediante el activo de certificado. Es obligatorio
  proporcionar una huella digital de certificado.
• SubscriptionId es el identificador de la suscripción. Es obligatorio proporcionar un id.
  de suscripción.
  Puedes agregar una nueva conexión mediante la hoja Conexiones de la cuenta
  de Automation, como se muestra en la Figura 4.10:

Creación y ejecución de runbooks
Azure Automation permite la creación de scripts de automatización conocidos como runbooks.
Se pueden crear varios runbooks mediante Azure Portal o PowerShell ISE. También se pueden
importar desde la galería de runbooks. En la galería se puede buscar una funcionalidad
específica y se muestra todo el código contenido en el runbook.
Un runbook puede aceptar valores de parámetros como un script de PowerShell normal.
En el ejemplo siguiente se toma un único parámetro denominado connectionName del tipo
string. Es obligatorio proporcionar un valor para este parámetro al ejecutar este runbook:
param(
[parameter(mandatory=$true)]
[string] $connectionName
)
$connection = Get-AutomationConnection -name $connectionName
$subscriptionid = $connection.subscriptionid
$tenantid = $connection.tenantid
$applicationid = $connection.applicationid
$cretThumbprint = $connection.CertificateThumbprint
Login-AzureRMAccount -CertificateThumbprint $cretThumbprint
-ApplicationId $applicationid -ServicePrincipal -Tenant $tenantid
Get-AzureRMVM
El runbook utiliza el cmdlet Get-AutomationConnection para hacer referencia al activo de
conexión compartido. El nombre del activo está incluido en el valor del parámetro. Una
vez realizada la referencia al activo de conexión, los valores de la referencia de conexión
se rellenan en la variable $connection y, posteriormente, se asignan a otras variables.
El cmdlet Login-AzureRMAccount se autentica en Azure y proporciona los valores obtenidos
del objeto de conexión. Utiliza la entidad de servicio creada anteriormente en este capítulo
para la autenticación.
Por último, el runbook invoca el cmdlet Get-AzureRMVm para enumerar todas las MV
de la suscripción.

De forma predeterminada, Azure Automation sigue proporcionando módulos AzureRM para
trabajar con Azure. De forma predeterminada, no instala módulos Az. Posteriormente,
instalaremos un módulo Az manualmente en la cuenta de Azure Automation y usaremos
cmdlets en runbooks.
Runbooks principales y secundarios
Los runbooks tienen un ciclo de vida, desde su creación hasta su ejecución. Estos ciclos
de vida se pueden dividir en estado de creación y estado de ejecución.
El ciclo de vida de creación se muestra en la Figura 4.11.
Cuando se crea un nuevo runbook, tiene el estado Nuevo y, a medida que se edita y
se guarda varias veces, adopta el estado En edición para, finalmente, cuando se publica,
cambiar su estado a Publicado. También es posible editar un runbook publicado y, en
ese caso, vuelve al estado En edición.

A continuación se describe el ciclo de vida de ejecución.
El ciclo de vida empieza con el comienzo de una solicitud de ejecución de runbook.
Un runbook se puede ejecutar de varias maneras:

• Manualmente desde Azure Portal
• Mediante el uso de un runbook principal como runbook secundario
• Mediante un webhook

No importa cómo se inicie un runbook; el ciclo de vida sigue siendo el mismo. El motor de
Automation recibe una solicitud para ejecutar el runbook. El motor de Automation crea un
trabajo y lo asigna a un proceso de runbook. Actualmente, el runbook tiene un estado En cola.
Hay varios trabajos de runbook y el elegido recoge la solicitud de trabajo y cambia el estado
a Inicio en curso. En esta etapa, si hay algún problema de scripting y análisis en el script,
el estado cambia a Fallido y la ejecución se detiene.
Una vez que el trabajo inicia la ejecución del runbook, el estado cambia a En ejecución.
El runbook puede tener varios estados diferentes una vez que se está ejecutando.
El runbook cambiará su estado a Completado si la ejecución se produce sin ninguna
excepción de terminación y no controlada.

El usuario también puede suspender y reanudar la ejecución del runbook.
Crear un runbook
Se puede crear un runbook desde Azure Portal en el elemento de menú Runbook del
panel de navegación izquierdo. Un runbook tiene un nombre y un tipo. El tipo determina
el lenguaje de scripting utilizado para crear el runbook. Ya hemos hablado de los posibles
lenguajes y, en este capítulo, se usará principalmente PowerShell para todos los ejemplos.
La creación de un runbook de PowerShell es exactamente igual que crear un script de
PowerShell. Puede declarar y aceptar varios parámetros: los parámetros pueden tener
atributos, como tipos de datos, que son obligatorios (al igual que cualquier atributo de
parámetro de PowerShell). Puede invocar cmdlets de PowerShell cuyos módulos estén
disponibles y ya estén cargados y declarados, y puede invocar funciones y devolver resultados.
Un runbook también puede invocar otro runbook. Puede invocar un runbook secundario
en línea dentro del proceso y contexto originales o en un proceso y contexto distintos.
Invocar un runbook en línea es similar a invocar un script de PowerShell. En el siguiente
ejemplo se invoca un runbook secundario mediante el enfoque en línea:
.\ConnectAzure.ps1 -connectionName «azureforarchitectsconnection»
Get-AzSqlServer

En el código anterior, hemos visto cómo el runbook ConnectAzure acepta un parámetro
denominado connectionName y se le proporciona un valor adecuado. Este runbook crea
una conexión a Azure después de autenticarse con ella mediante una entidad de servicio.
Examina la sintaxis para invocar el runbook secundario. Es muy parecida a invocar un script
general de PowerShell junto con parámetros.
La siguiente línea de código, Get-AzVm, recupera la información relevante de Azure y
enumera los detalles de la MV. Observarás que aunque la autenticación se produce dentro
de un runbook secundario, el cmdlet Get-AzVm se ejecuta correctamente y enumera todas
las MV de la suscripción porque el runbook secundario se ejecuta en el mismo trabajo que
el runbook principal y comparten el contexto.
Como alternativa, se puede invocar un runbook secundario mediante el cmdlet Start-
AzurermAutomationRunbook proporcionado por Azure Automation. Este cmdlet acepta
el nombre de la cuenta de Automation, el nombre del grupo de recursos y el nombre
del runbook junto con los parámetros, como se indica a continuación:

$params = @{«connectionName»=»azureforarchitectsconnection»}
$job = Start-AzurermAutomationRunbook ‘
–AutomationAccountName ‘bookaccount’ ‘
–Name ‘ConnectAzure’ ‘
-ResourceGroupName ‘automationrg’ -parameters $params
if($job -ne $null) {
Start-Sleep -s 100
$job = Get-AzureAutomationJob -Id $job.Id -AutomationAccountName
‘bookaccount’
if ($job.Status -match «Completed») {
$jobout = Get-AzureAutomationJobOutput ‘
-Id $job.Id ‘
-AutomationAccountName ‘bookaccount’ ‘
-Stream Output
if ($jobout) {Write-Output $jobout.Text}
}
}

El uso de este enfoque crea un nuevo trabajo que es diferente del trabajo principal y cada
uno se ejecuta en contextos diferentes.

Usar módulos Az
Hasta ahora, todos los ejemplos han utilizado módulos AzureRM. Los runbooks mostrados
anteriormente se volverán a escribir para usar cmdlets del módulo Az.
Como se ha mencionado anteriormente, los módulos Az no se instalan de forma
predeterminada. Se pueden instalar mediante el elemento de menú Galería de módulos
(Modules gallery) de Azure Automation.
Busca Az en la galería y los resultados mostrarán varios módulos relacionados. Si se selecciona
e instala el módulo Az para importarlo e instalarlo, aparecerá un error que dice que sus
módulos dependientes no están instalados y que deben instalarse antes de instalar el módulo
actual. El módulo se puede encontrar en la hoja Galería de módulos (Modules gallery)
al buscar Az, como se muestra en la Figura 4.13:

En lugar de seleccionar el módulo Az, selecciona Az.Accounts e importa el módulo según las
indicaciones del asistente, como se muestra en la Figura 4.14:

Tras instalar Az.Accounts, se puede importar el módulo Az.Resources. Los cmdlets
relacionados con la máquina virtual de Azure están disponibles en el módulo Az.Compute
y también se puede importar con el mismo método que hemos utilizado para importar
Az.Accounts.
Una vez importados estos módulos, los runbooks pueden usar los cmdlets proporcionados
por estos módulos. El runbook ConnectAzure mostrado anteriormente se ha modificado para
utilizar el módulo Az:

param(
[parameter(mandatory=$true)]
[string] $connectionName
)
$connection = Get-AutomationConnection -name $connectionName
$subscriptionid = $connection.subscriptionid
$tenantid = $connection.tenantid
$applicationid = $connection.applicationid
$cretThumbprint = $connection.CertificateThumbprint
Login-AzAccount -CertificateThumbprint $cretThumbprint
-ApplicationId $applicationid -ServicePrincipal
-Tenant $tenantid -SubscriptionId $subscriptionid
Get-AzVm

Las dos últimas líneas del código son importantes. Utilizan cmdlets de Az en lugar de
cmdlets de AzureRM.

Al ejecutar este runbook, se mostrarán resultados similares a los siguientes:

En la siguiente sección, trabajaremos con webhooks.

Webhooks
Los webhooks se hicieron famosos después de la llegada de los puntos de conexión REST
y las cargas de datos JSON. Los webhooks son un concepto importante y una decisión
arquitectónica en la capacidad de ampliación de cualquier aplicación. Los webhooks son
marcadores que se han dejado en áreas especiales de una aplicación para que el usuario
de la aplicación pueda rellenar esos marcadores con direcciones URL de punto de conexión
que contengan lógica personalizada. La aplicación invocará la dirección URL del punto de
conexión, aprobará automáticamente los parámetros necesarios y, a continuación, ejecutará
el inicio de sesión disponible en el mismo.
Los runbooks de Azure Automation se pueden invocar manualmente desde Azure Portal.
También se pueden invocar mediante cmdlets de PowerShell y la CLI de Azure. Hay SDK
disponibles en varios lenguajes que pueden invocar runbooks.
Los webhooks son una de las formas más eficaces de invocar un runbook. Es importante
tener en cuenta que los runbooks que contienen la lógica principal nunca deben exponerse
directamente como un webhook. Se debe llamar a ellos mediante un runbook principal y el
runbook principal debe exponerse como un webhook. El runbook principal debe asegurarse
de que se realicen las comprobaciones apropiadas antes de invocar el runbook secundario
principal.
El primer paso para crear un webhook es crear un runbook normalmente, como se ha hecho
anteriormente. Una vez creado un runbook, se expondrá como un webhook.
Se crea un nuevo runbook basado en PowerShell denominado exposedrunbook. Este runbook
toma un único parámetro, $WebhookData del tipo objeto. Se le debe asignar el nombre verbatim.
El entorno de ejecución de Azure Automation crea este objeto y se suministra al runbook.
El entorno de ejecución de Azure Automation crea este objeto después de obtener los valores
de encabezado y el contenido del cuerpo de la solicitud HTTP y rellena las propiedades
RequestHeader y RequestBody de este objeto:

param(
[parameter(mandatory=$true)]
[object] $WebhookData
)
$webhookname = $WebhookData.WebhookName
$headers = $WebhookData.RequestHeader
$body = $WebhookData.RequestBody
Write-output «webhook header data»
Write-Output $webhookname
Write-output $headers.message
Write-output $headers.subject
$connectionname = (ConvertFrom-Json -InputObject $body)
./connectAzure.ps1 -connectionName $connectionname[0].name

Las tres propiedades importantes de este objeto son WebhookName, RequestHeader y
RequestBody. El runbook recupera los valores de estas propiedades y los envía al flujo de salida.
El contenido del encabezado y del cuerpo puede ser cualquier cosa que el usuario
proporciona al invocar el webhook. Estos valores se rellenan en las propiedades respectivas
y están disponibles en el runbook. En el ejemplo anterior, hay dos encabezados establecidos
por el autor de la llamada, es decir, los encabezados message y status. El autor de la llamada
también suministrará el nombre de la conexión compartida que se usará como parte del
contenido del cuerpo.
Después de crear el runbook, debe publicarse antes de que se pueda crear un webhook. Después
de publicar el runbook, al hacer clic en el menú Webhook de la parte superior, se inicia el
proceso de creación de un nuevo webhook para el runbook, como se muestra en la Figura 4.16:

Se debe proporcionar un nombre para el webhook. Este valor está disponible en el runbook
mediante el parámetro WebhookData con el nombre de propiedad WebhookName.

El webhook puede tener el estado enabled o disabled y puede caducar en una fecha y hora
determinadas. También genera una dirección URL única para este webhook y runbook. Esta
URL debe proporcionarse a cualquier persona que desee invocar el webhook.

Invocar un webhook
Los Webhooks se invocan como solicitudes HTTP mediante el método POST. Cuando se
invoca un webhook, la solicitud HTTP llega a Azure Automation para iniciar un runbook.
Crea el objeto WebHookData, lo rellena con los datos de cuerpo y encabezado HTTP entrantes
y crea un trabajo que un proceso de runbook debe recoger. Esta llamada utiliza la URL de
webhook generada en el paso anterior.
El webhook se puede invocar mediante Postman, mediante cualquier código que tenga
la capacidad de llamar a un punto de conexión REST con el método POST. En el siguiente
ejemplo, se usará PowerShell para invocar el webhook:

$uri = «https://s16events.azure-automation.net/
webhooks?token=rp0w93L60fAPYZQ4vryxl%2baN%2bS1Hz4F3qVdUaKUDzgM%3d»
$connection = @(
@{ name=»azureforarchitectsconnection»}
)
$body = ConvertTo-Json -InputObject $ connection
$header = @{ subject=»VMS specific to Ritesh»;message=»Get all virtual
machine details»}
$response = Invoke-WebRequest -Method Post -Uri $uri -Body $body -Headers
$header
$jobid = (ConvertFrom-Json ($response.Content)).jobids[0]

El código de PowerShell declara la dirección URL del webhook y construye el cuerpo en
formato JSON, con name establecido en azureforarchitectsconnection y un encabezado
con dos pares de nombre-valor de encabezado subject y message. Los datos de cuerpo
y encabezado se pueden recuperar en el runbook mediante el parámetro WebhookData.
El cmdlet invoke-webrequest genera la solicitud en el punto de conexión mencionado
anteriormente mediante el método POST, lo que proporciona tanto el encabezado como
el cuerpo.

La solicitud es asincrónica por naturaleza y, en lugar de la salida real del runbook,
el identificador de trabajo se devuelve como una respuesta HTTP. También está
disponible en el contenido de la respuesta. El trabajo se muestra en la Figura 4.17:

Al hacer clic en WEBHOOKDATA, se muestran los valores que llegaron al servicio
de automatización de runbooks en la solicitud HTTP:

Al hacer clic en el menú de salida, se muestra la lista de MV y SQL Server de la suscripción.
Los siguientes conceptos importantes en Azure Automation son Azure Monitor e Hybrid
Workers, y en las siguientes secciones se explicarán en detalle.

Invocar un runbook desde Azure Monitor
Los runbooks de Azure Automation se pueden invocar como respuestas a las alertas
generadas en Azure. Azure Monitor es el servicio central que administra registros y métricas
en los recursos y grupos de recursos de una suscripción. Puedes utilizar Azure Monitor
para crear nuevas reglas y definiciones de alertas que, cuando se desencadenen, puedan
ejecutar runbooks de Azure Automation. Pueden invocar un runbook de Azure Automation
en su formato predeterminado o un webhook que, a su vez, puede ejecutar el runbook
asociado. Esta integración entre Azure Monitor y la capacidad de invocar runbooks ofrece
numerosas oportunidades de automatización para corregir automáticamente el entorno,
aumentar y reducir los recursos de computación o adoptar medidas correctivas sin ninguna
intervención manual.
Las alertas de Azure se pueden crear y configurar en recursos y niveles de recursos
individuales, pero siempre es una buena práctica centralizar las definiciones de alertas
para facilitar y mejorar el mantenimiento y la administración.
Vamos a explicar el proceso de asociación de un runbook a una alerta y de invocarlo como
parte de la alerta que se genera.
El primer paso es crear una alerta nueva, como se muestra en la Figura 4.19:

Selecciona un recurso que se deba supervisar y evaluar para la generación de alertas.
Se ha seleccionado un grupo de recursos de la lista y esto habilita automáticamente todos
los recursos dentro del grupo de recursos. Es posible eliminar las selecciones de recursos
del grupo de recursos:

Configura la condición y las reglas que deben evaluarse. Selecciona el nombre de la
señal Apagar máquina virtual (Power Off Virtual Machine) tras seleccionar Registro
de actividades como Tipo de señal (Signal type):

La ventana resultante te permitirá configurar la lógica/condición de la alerta. Selecciona
crítico en Nivel del evento y establece Estado en Correcto:

Después de determinar la condición de la alerta, hay que realizar la configuración más
importante, que configura la respuesta a la alerta mediante la invocación de un runbook.
Podemos utilizar grupos de acciones para configurar la respuesta a una alerta. Proporciona
numerosas opciones para invocar una función de Azure, webhook o runbook de Azure
Automation, así como para enviar correos electrónicos y SMS.
Para crear un grupo de acciones, proporciona un nombre, un nombre corto, una suscripción
de hosting, un grupo de recursos y un nombre de acción. En relación con el nombre
de la acción, selecciona la opción Runbook de Automation (Automation Runbook) como
Tipo de acción:

La selección de un runbook de Automation abrirá otra hoja para seleccionar una cuenta y un
runbook adecuados de Azure Automation. Hay varios runbooks disponibles «out of the box»
y aquí se ha utilizado uno de ellos:

Por último, proporciona un nombre y un grupo de recursos de hosting para crear una
nueva alerta.
Si la MV se desasigna manualmente, se cumple la condición de la alerta y se generará una alerta:
Figura

Si compruebas los detalles de la MV después de unos segundos, deberías ver que se está
borrando:

Hybrid Workers
Hasta ahora, toda la ejecución de runbooks se ha realizado principalmente en la infraestructura
proporcionada por Azure. Los trabajos de runbook son recursos de computación de Azure
aprovisionados por Azure con los módulos y activos adecuados implementados en ellos.
Cualquier ejecución de runbooks se produce en este procesamiento. Sin embargo, es
posible que los usuarios aporten su propio procesamiento y ejecuten el runbook en este
procesamiento proporcionado por el usuario en lugar de en el predeterminado de Azure.
Esto tiene varias ventajas. La primera y más importante es que toda la ejecución y sus registros
son propiedad del usuario y Azure no tiene ninguna visibilidad de ellos. En segundo lugar,
el procesamiento proporcionado por el usuario puede realizarse en cualquier cloud, así
como on-premises.

La adición de un Hybrid Worker implica varios pasos.

• En primer lugar, es necesario instalar un agente en el procesamiento proporcionado
  por el usuario. Microsoft proporciona un script que puede descargar y configurar
  el agente automáticamente. Este script está disponible en https://www.
  powershellgallery.com/packages/New-OnPremiseHybridWorker/1.6.
  El script también se puede ejecutar desde PowerShell ISE como administrador desde
  el servidor que debe formar parte del Hybrid Worker mediante el siguiente comando:
  Install-Script -Name New-OnPremiseHybridWorker -verbose
• Después de instalar el script, se puede ejecutar junto con los parámetros relacionados
  con los detalles de la cuenta de Azure Automation. También se proporciona un
  nombre para el Hybrid Worker. Si el nombre aún no existe, se creará; si existe, el
  servidor se agregará al Hybrid Worker existente. Es posible tener varios servidores
  dentro de un solo Hybrid Worker y también es posible tener varios Hybrid Workers:

New-OnPremiseHybridWorker.ps1 -AutomationAccountName bookaccount
-AAResourceGroupName automationrg ‘
-HybridGroupName «localrunbookexecutionengine» ‘
-SubscriptionID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

• Cuando termine la ejecución, si vuelves al portal, se mostrará una entrada de Hybrid
  Worker, como se muestra en la Figura 4.27:

• Si, en este momento, se ejecuta un runbook de Azure que tiene una dependencia en
  el módulo Az y un certificado personalizado cargado en el activo de certificado, este
  fallará con errores relacionados con el módulo Az y por no encontrarse el certificado:

Instala el módulo Az utilizando el siguiente comando en el servidor:

Install-module -name Az -AllowClobber -verbose

También es importante tener el certificado .pfx disponible en este servidor.
El certificado exportado anteriormente debe copiarse en el servidor e instalarse
manualmente.

• Después de instalar el módulo Az y el certificado, la nueva ejecución del runbook en Hybrid
  Worker se muestra en la Figura 4.29 y debe mostrar la lista de MV de la suscripción:

Cuando hemos explicado los diferentes escenarios, hemos hablado de la administración
de la configuración. En la siguiente sección, trataremos con más detalle la administración
de la configuración con Azure Automation.
Configuración de estado de Azure Automation
Azure Automation proporciona un servidor de extracción Desired State Configuration
(DSC) junto con cada cuenta de Azure Automation. El servidor de extracción puede
contener scripts de configuración que pueden extraer los servidores a través de clouds
y on-premises. Esto significa que Azure Automation se puede utilizar para configurar
cualquier servidor hospedado en cualquier parte del mundo.
El DSC necesita un agente local en estos servidores, también conocido como administrador
de configuración local (LCM). Debe configurarse con el servidor de extracción DSC
de Azure Automation para que pueda descargar la configuración necesaria y configurar
automáticamente el servidor.
La configuración automática puede programarse de forma periódica (de forma
predeterminada es media hora) y si el agente encuentra cualquier desviación en
la configuración del servidor en comparación con la disponible en el script de DSC,
se corregirá automáticamente y devolverá el servidor al estado deseado y esperado.

En esta sección, configuraremos un servidor hospedado en Azure y el proceso seguirá
siendo el mismo, independientemente de si el servidor está en un cloud u on-premises.
El primer paso es crear una configuración de DSC. Aquí se muestra una configuración
de ejemplo y se pueden crear configuraciones complejas de forma similar:

configuration ensureiis {
import-dscresource -modulename psdesiredstateconfiguration
node localhost {
WindowsFeature iis {
Name = «web-server»
Ensure = «Present»
}
}
}

La configuración es bastante sencilla. Importa el módulo DSC base
PSDesiredStateConfiguration y declara una configuración de nodo único.
Esta configuración no está asociada a ningún nodo específico y se puede utilizar
para configurar cualquier servidor. La configuración debe configurar un servidor
web IIS y asegurarse de que esté presente en cualquier servidor al que se aplique.
Esta configuración aún no está disponible en el servidor de extracción DSC de Azure
Automation, por lo que el primer paso es importar la configuración en el servidor de
extracción. Esto se puede hacer mediante el cmdlet Import-AzAutomationDscConfiguration
de la cuenta de Automation, como se muestra a continuación:
Import-AzAutomationDscConfiguration -SourcePath «C:\Ritesh\ensureiis.ps1»
-AutomationAccountName bookaccount -ResourceGroupName automationrg -Force
-Published
Aquí hay varios factores importantes que tener en cuenta. El nombre de la configuración
debe coincidir con el nombre de archivo y solo debe contener caracteres alfanuméricos
y guiones bajos. Una buena convención de nomenclatura es usar combinaciones de verbo/
nombre. Los cmdlets necesitan la ruta de acceso del archivo de configuración y los detalles
de la cuenta de Azure Automation para importar el script de configuración.

En esta etapa, la configuración es visible en el portal:

Una vez importado el script de configuración, se compila y almacena en el servidor
de extracción DSC mediante el cmdlet Start-AzAutomationDscCompilationJob, como
se muestra a continuación:
Start-AzAutomationDscCompilationJob -ConfigurationName ‘ensureiis’
-ResourceGroupName ‘automationrg’ -AutomationAccountName ‘bookaccount’
El nombre de la configuración debe coincidir con el que se ha cargado recientemente
y la configuración compilada debe estar disponible ahora en la pestaña Configuraciones
compiladas (Compiled configurations), como se muestra en la Figura 4.31:

Es importante tener en cuenta que el recuento de nodos de la Figura 4.31 es 0. Esto significa
que existe una configuración de nodo denominada ensureiss.localhost, pero no está
asignada a ningún nodo. El siguiente paso es asignar la configuración al nodo.
Por ahora, tenemos una configuración DSC compilada disponible en el servidor
de extracción DSC, pero no hay nodos que administrar. El siguiente paso es incorporar
las MV y asociarlas al servidor de extracción DSC. Esto se hace mediante el cmdlet
Register-AzAutomationDscNode:
Register-AzAutomationDscNode -ResourceGroupName ‘automationrg’
-AutomationAccountName ‘bookaccount’ -AzureVMLocation «west
Europe» -AzureVMResourceGroup ‘spark’ -AzureVMName ‘spark’
-ConfigurationModeFrequencyMins 30 -ConfigurationMode ‘ApplyAndAutoCorrect’
Este cmdlet toma el nombre del grupo de recursos para la MV y la cuenta de
Azure Automation. También configura el modo de configuración y la propiedad
configurationModeFrequencyMins del administrador de configuración local de la MV.
Esta configuración comprobará y corregirá automáticamente cualquier desviación
con respecto a la configuración aplicada cada 30 minutos.
Si no se especifica VMresourcegroup, el cmdlet intenta encontrar la MV en el mismo
grupo de recursos que la cuenta de Azure Automation y, si no se proporciona el valor
de ubicación de la MV, intenta encontrar la MV en la región de Azure Automation.
Siempre es mejor proporcionar los valores correspondientes. Ten en cuenta que este
comando solo se puede utilizar para las máquinas virtuales de Azure, ya que solicita
AzureVMname explícitamente. Para servidores en otros clouds y on-premises, utiliza
el cmdlet Get-AzAutomationDscOnboardingMetaconfig.
Ahora, también se puede encontrar una nueva entrada de configuración de nodo en
el portal, como se muestra en la Figura 4.32:

La información del nodo se puede obtener de la siguiente manera:
$node = Get-AzAutomationDscNode -ResourceGroupName ‘automationrg’
-AutomationAccountName ‘bookaccount’ -Name ‘spark’
Y se puede asignar una configuración al nodo:
Set-AzAutomationDscNode -ResourceGroupName ‘automationrg’
-AutomationAccountName ‘bookaccount’ -NodeConfigurationName ‘ensureiis.
localhost’ -NodeId $node.Id
Una vez completada la compilación, se puede asignar a los nodos. El estado inicial
es Pendiente, como se muestra en la Figura 4.33:

Después de unos minutos, la configuración se aplica al nodo, el nodo se vuelve Conforme
y el estado pasa a ser Completado:

Más adelante, inicia sesión en el servidor y comprueba si el servidor web (IIS) está instalado
para confirmar que así es, como puedes ver en la Figura 4.35:

En la siguiente sección, se explicarán los precios de Azure Automation.
Precios de Azure Automation
Azure Automation no tiene ningún coste si no se ejecutan runbooks en él. El coste de Azure
Automation se cobra por minuto para la ejecución de trabajos de runbook. Esto significa
que si el número total de minutos de ejecución del runbook es de 10 000, el coste de
Azure Automation será 0,002 USD por minuto multiplicado por 9500, ya que los primeros
500 minutos son gratuitos.
Hay otros costes relacionados con Azure Automation en función de las características que
se consuman. Por ejemplo, un servidor de extracción DSC no cuesta nada dentro de Azure
Automation como tampoco la incorporación de MV de Azure en el servidor de extracción.
Sin embargo, si se incorporan servidores que no son de Azure, normalmente de otros clouds
u on-premises, los primeros cinco servidores son gratuitos y cualquiera adicional tiene
un coste de 6 USD por servidor al mes en la región Oeste de EE. UU.
Los precios pueden variar de una región a otra y siempre es una buena práctica verificar
el precio en la página de precios oficial: https://azure.microsoft.com/pricing/details/
automation.
Puede que te preguntes: ¿por qué necesitamos una cuenta de Automation para poder
implementar aplicaciones sin servidor a través de Azure Functions? En la siguiente
sección, exploraremos las principales diferencias entre Azure Automation y la
automatización sin servidor.
Comparación con la automatización sin servidor
Azure Automation y las tecnologías sin servidor de Azure, especialmente Azure Functions,
son bastante similares y se superponen en términos de funcionalidad. Sin embargo, se trata
de servicios separados con diferentes capacidades y precios.
Es importante comprender que Azure Automation es un conjunto completo para la
automatización de procesos y la administración de la configuración, mientras que
Azure Functions está diseñado para implementar la funcionalidad empresarial.

Azure Automation se utiliza para automatizar los procesos de aprovisionamiento,
desaprovisionamiento, administración y operaciones de administración de la infraestructura
y la configuración posterior. Por otro lado, Azure Functions se ha diseñado para la creación
de servicios, que implementan funcionalidades que pueden formar parte de microservicios
y otras API.
Azure Automation no se ha diseñado para una escala ilimitada y se espera que la carga
sea moderada, mientras que Azure Functions puede gestionar tráfico ilimitado y escalar
automáticamente.
Hay un gran número de activos compartidos, como conexiones, variables y módulos, que
se pueden reutilizar en los runbooks de Azure Automation; sin embargo, no hay ningún
concepto compartido «out of the box» en Azure Functions.
Azure Automation puede administrar el estado intermedio mediante puntos de control
y continuar desde el último estado guardado, mientras que Azure Functions generalmente
no tiene estado y no mantiene ningún estado.
Resumen
Azure Automation es un servicio importante dentro de Azure y el único servicio para
la automatización de procesos y la administración de la configuración. En este capítulo,
se han abordado muchos conceptos importantes relacionados con Azure Automation
y la automatización de procesos, incluidos los activos compartidos como la conexión,
los certificados y los módulos.
Se ha descrito la creación de runbooks, incluida la invocación de runbooks de diferentes
maneras, como relaciones principal-secundario, webhooks y uso del portal. En el capítulo
también se ha hablado de la arquitectura y del ciclo de vida de los runbooks.
También hemos examinado el uso de Hybrid Workers y, hacia el final del capítulo, hemos
explorado la administración de la configuración mediante un servidor de extracción DSC
y un administrador de configuración local. Por último, hemos realizado comparaciones
con otras tecnologías, como Azure Functions.
En el siguiente capítulo, exploraremos el diseño de políticas, bloqueos y etiquetas para las
implementaciones de Azure.