Uso de la automatización para reducir el esfuerzo y los errores

Uso de la automatización para reducir el esfuerzo y los errores

  • 12 minutos

Administrar la infraestructura de cualquier tipo de carga de trabajo lleva parejas algunas tareas de configuración. Esta configuración se puede realizar de forma manual, pero los pasos manuales no escalan bien y, además, son laboriosos, propensos a errores e ineficaces. ¿Qué ocurre si nos asignan la dirección de un proyecto que requiere la implementación de cientos de sistemas en Azure? ¿Cómo podría crear y configurar estos recursos? ¿Cuánto tiempo tardaría? ¿Podría asegurar que todos los sistemas se han configurado correctamente, sin variaciones entre ellos?

Al usar la automatización en el diseño de la arquitectura, estos desafíos pueden quedar atrás. En esta unidad, veremos algunas de las formas de automatización en Azure.

Infraestructura como código

La infraestructura como código (IaC) es la administración de infraestructuras (como redes, máquinas virtuales, equilibra dores de carga y antropología de conexión) en un modelo descriptivo, con un sistema de control de versiones similar al que se usa con el código fuente. Al crear una aplicación, el mismo código fuente generará el mismo binario cada vez que se compile. De forma similar, un modelo de IaC genera el mismo entorno cada vez que se aplica. IaC es una práctica fundamental de DevOps y, a menudo, se usa junto con la entrega continua.

IaC ha evolucionado para resolver el problema de desfase del entorno. Sin IaC, los equipos deben mantener la configuración de los entornos de implementación individuales. Con el tiempo, cada entorno se convierte en un copo de nieve que cada vez es más único y que no se puede reproducir automáticamente. La administración y mantenimiento de la infraestructura de estos entornos de copo de nieve conllevan una serie de procesos manuales que son difíciles de seguir y que son propensos a errores. Además, las incoherencias resultantes entre estos entornos de copo de nieve conducen a problemas durante las implementaciones.

Al automatizar la implementación de los servicios y la infraestructura, podemos adoptar dos posturas diferentes: la imperativa y la declarativa.

  • En la postura imperativa, indicamos de forma explícita los comandos que se ejecutan para generar el resultado que estamos buscando,
  • mientras que en la declarativa especificamos el resultado que queremos, en lugar de especificar cómo realizarlo.

Ambas posturas son importantes, por lo que no hay una opción incorrecta. ¿Qué aspecto tienen estos enfoques en Azure y cómo se usan?

Automatización imperativa

Comencemos con la automatización imperativa. Con la automatización imperativa, se especifica cómo se van a realizar las cosas. Normalmente esto se realiza mediante programación a través de un lenguaje de scripting o SDK. Para los recursos de Azure, se podría usar la CLI de Azure o Azure PowerShell. Veamos un ejemplo en el que se usa la CLI de Azure para crear una cuenta de almacenamiento.CLI de AzureCopiar

az group create \
    --name storage-resource-group \
    --location eastus

az storage account create \
    --name mystorageaccount \
    --resource-group storage-resource-group \
    --kind BlobStorage \
    --access-tier hot

En este ejemplo especificaremos cómo crear estos recursos: ejecutaremos un comando para crear un grupo de recursos y, luego, ejecutaremos otro para crear una cuenta de almacenamiento. Indicaremos a Azure de forma explícita qué comandos deben ejecutarse para generar el resultado necesario.

Con este método, podremos automatizar la infraestructura completamente. Se pueden proporcionar áreas para la entrada y la salida, y garantizar que cada vez se ejecutan los mismos comandos. Al automatizar los recursos, estamos excluyendo del proceso los pasos manuales, lo que aumenta la eficacia operativa de la administración de los recursos.

Pero este método tiene algunos inconvenientes. Los scripts para crear recursos se pueden volver complejos con rapidez, a medida que aumenta la complejidad de la arquitectura. Es posible que sea necesario agregar control de errores y validación de entradas para garantizar la ejecución completa. Los comandos pueden cambiar, lo que requiere el mantenimiento continuado de los scripts.

Automatización declarativa

Con la automatización declarativa, especificamos qué resultado buscamos, dejando los detalles de cómo se consigue al sistema que estemos usando. En Azure, la automatización declarativa se realiza usando plantillas de Azure Resource Manager (ARM), que son archivos con estructura JSON que especifican lo que queremos que se genere. Las plantillas de ARM tienen cuatro secciones: parámetrosvariablesrecursos y salidas.

  • Los parámetros controlan la entrada que se va a usar dentro de la plantilla.
  • Las variables proporcionan una forma de almacenar los valores para su uso en la plantilla.
  • Los recursos son las “cosas” que se están creando.
  • Las salidas proporcionan detalles al usuario de lo que se ha creado.

En el siguiente ejemplo, indicamos a Azure que cree una cuenta de almacenamiento con los nombres y las propiedades que especificamos. Los pasos reales que se ejecutan en segundo plano para crear esta cuenta de almacenamiento se dejan a elección de Azure.JSONCopiar

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "name": {
            "type": "string"
        },
        "location": {
            "type": "string"
        },
        "accountType": {
            "type": "string",
            "defaultValue": "Standard_RAGRS"
        },
        "kind": {
            "type": "string"
        },
        "accessTier": {
            "type": "string"
        },
        "httpsTrafficOnlyEnabled": {
            "type": "bool",
            "defaultValue": true
        }
    },
    "variables": {
    },
    "resources": [
        {
            "apiVersion": "2018-02-01",
            "name": "[parameters('name')]",
            "location": "[parameters('location')]",
            "type": "Microsoft.Storage/storageAccounts",
            "sku": {
                "name": "[parameters('accountType')]"
            },
            "kind": "[parameters('kind')]",
            "properties": {
                "supportsHttpsTrafficOnly": "[parameters('httpsTrafficOnlyEnabled')]",
                "accessTier": "[parameters('accessTier')]",
                "encryption": {
                    "services": {
                        "blob": {
                            "enabled": true
                        },
                        "file": {
                            "enabled": true
                        }
                    },
                    "keySource": "Microsoft.Storage"
                }
            },
            "dependsOn": []
        }
    ],
    "outputs": {
        "storageAccountName": {
            "type": "string",
            "value": "[parameters('name')]"
        }
    }
}

Las plantillas de ARM se pueden usar para crear y manipular la mayoría de los servicios en Azure. Podemos almacenar nuestras plantillas en repositorios de código y heredar todas las ventajas de usar un sistema de control de código fuente, y podemos compartir esas plantillas entre entornos para asegurarnos de que la infraestructura que usamos en nuestro entorno de desarrollo coincide con el entorno de producción. Las plantillas de ARM son una manera excelente de automatizar las implementaciones, ayudan a garantizar la coherencia y a eliminar errores de configuración de la implementación y, asimismo, pueden aumentar la velocidad operativa.

Automatizar la implementación de la infraestructura constituye un primer paso excelente, pero cuando implementamos máquinas virtuales, nos queda más trabajo por hacer. Veamos un par de métodos para automatizar la configuración posterior a la implementación.

Diferencias entre las imágenes de máquinas virtuales y la configuración posterior a la implementación

En muchas implementaciones de máquina virtual, el trabajo no acaba cuando la máquina se pone en funcionamiento. Muchas veces, es bastante probable que tengamos que debamos ocuparnos de más configuraciones para que la máquina virtual cumpla realmente su propósito. Por ejemplo: es posible que sea necesario dar formato a más discos, unir la máquina virtual a un dominio, quizás instalar un agente para un paquete de software de administración… y es muy probable que la carga de trabajo también requiera instalación y configuración.

Hay dos estrategias comunes que podemos usar para la tarea de configuración, que a todos los efectos se considera parte del proceso de configuración de la propia máquina virtual. Cada una de estas estrategias tiene sus ventajas e inconvenientes.

  • Las imágenes personalizadas se generan a partir de la implementación de una máquina virtual y, después, de la configuración o instalación de software en esa instancia en ejecución. Si todo está configurado correctamente, podemos apagar la máquina virtual y crear una imagen de ella, que podremos usar como base para otras máquinas virtuales nuevas. Trabajar con imágenes personalizadas puede acelerar el tiempo total de implementación, ya que en cuanto implementemos la máquina virtual y esté en ejecución, no será necesario configurar nada más. Si la velocidad de implementación es un factor importante, sin duda merece la pena estudiar el uso de imágenes personalizadas.
  • El scripting posterior a la implementación suele hacer uso de una imagen base básica y, después, se basa en una plataforma de administración de configuración o scripting para realizar la configuración necesaria una vez implementada la máquina virtual. El scripting posterior a la implementación se podría realizar ejecutando un script en la máquina virtual con la extensión de script de Azure o usando una solución más sólida, como Desired State Configuration (DSC) de Azure Automation.

Cada uno de estos métodos tiene una serie de consideraciones particulares y otras comunes que debemos tener en cuenta.

  • Al usar imágenes, deberemos asegurarnos de que hay un proceso para controlar las actualizaciones de imagen, las revisiones de seguridad y la administración del inventario de las propias imágenes.
  • Con el scripting posterior a la implementación, se pueden ampliar los tiempos de compilación puesto que la máquina virtual no se puede agregar a cargas de trabajo dinámicas hasta que la compilación finalice. Es posible que esto no sea un aspecto importante en los sistemas independientes, pero cuando se usan servicios de escalado automático (por ejemplo, conjuntos de escalado de máquinas virtuales), este tiempo de compilación extendido puede afectar a la velocidad del escalado.
  • Con ambos métodos, nos conviene asegurarnos de solucionar el desfase de configuración; cuando se implemente la configuración nueva, tendremos que asegurarnos de que los sistemas existentes se actualizan en consecuencia.

La automatización de la implementación de recursos puede suponer un gran beneficio para el entorno. La cantidad de tiempo que se ahorra y el menor número de errores pueden llevar nuestras funcionalidades a otro nivel.

Automatización de las tareas operativas

Una vez que las soluciones estén en marcha, hay actividades operativas en curso que también se pueden automatizar. La automatización de estas tareas con Azure Automation reduce las cargas de trabajo manuales, permite administrar la configuración y actualización de los recursos de proceso, proporciona un marco para realizar cualquier tipo de tarea de Azure y centraliza la creación de recursos compartidos, como programaciones, credenciales y certificados.

Estos son algunos ejemplos de esta automatización:

  • La búsqueda periódica de discos huérfanos
  • La instalación de las revisiones de seguridad más recientes en las máquinas virtuales
  • La búsqueda y apagado de las máquinas virtuales en las horas de inactividad
  • La ejecución de informes diarios y la creación de un panel para informar a los directivos

Supongamos, por ejemplo, que queremos reducir los costos de proceso configurando una de las máquinas virtuales de desarrollo de forma que se ejecute solo durante el horario laboral de nuestra organización. Podemos escribir un script para que la máquina virtual se encienda por la mañana y se apague a última hora de la tarde, y configurar Azure Automation para ejecutar este script en los momentos definamos. En la siguiente ilustración se muestra el rol de Azure Automation en este proceso.

Ilustración que muestra el rol de Azure Automation en la administración de un proceso de negocio repetitivo.

Automatización de los entornos de desarrollo

En el otro extremo de la canalización de la infraestructura en la nube se encuentra un conjunto de equipos de desarrollo, que los desarrolladores usan para escribir las aplicaciones y los servicios que forman el núcleo de la empresa. Podemos usar Azure DevTest Labs para implementar máquinas virtuales con todos los repositorios y herramientas correctos que los desarrolladores necesitan. Los desarrolladores que trabajan en varios servicios pueden cambiar entre entornos de desarrollo sin tener que aprovisionar ellos mismos una máquina virtual nueva. Estos entornos de desarrollo se pueden apagar cuando no estén en uso y reiniciarse cuando vuelvan a ser necesarios.

Back to top