¿Qué es la infraestructura como código?

10 minutos

Se le pide que evalúe si la infraestructura como código podría ser un enfoque valioso para el aprovisionamiento de recursos en su empresa. Está revisando las opciones disponibles para la implementación, entre las que se incluyen:

Azure Portal
Azure CLI
Azure PowerShell
Plantillas de Azure Resource Manager (JSON y Bicep)

Busca una opción repetible y debe decidir qué tecnología usar para implementar la infraestructura de Azure.

En esta unidad, aprenderá cómo y por qué la infraestructura como código puede ayudarle a implementar la infraestructura de Azure de forma automatizada y repetible.

Los comandos de la CLI de Azure se usan para ilustrar los conceptos. Obtenga más información sobre el uso de comandos para implementar recursos en otros módulos de la ruta de aprendizaje de Bicep.

Definición de la infraestructura como código

Su empresa diseña nuevos juguetes para su lanzamiento al mercado y la mayoría de los juguetes nuevos requieren algún tipo de ensamblado después de la compra. El equipo de diseño de la empresa crea manuales de instrucciones para incluirlos con cada juguete. Cada manual proporciona detalles sobre cómo ensamblar correctamente el juguete.

Para que se haga una idea, la infraestructura como código es como el manual de instrucciones de la infraestructura. El manual detalla la configuración final de los recursos y cómo alcanzar ese estado de configuración.

La infraestructura como código es el proceso de automatizar el aprovisionamiento de la infraestructura. Usa un lenguaje de codificación descriptivo y un sistema de control de versiones similar al que se utiliza para el código fuente. Al crear una aplicación, el código fuente genera el mismo resultado cada vez que se compila. De forma similar, las implementaciones de la infraestructura como código son automatizadas, coherentes y repetibles. La infraestructura como código puede automatizar las implementaciones de los recursos de infraestructura, como redes virtuales, máquinas virtuales, aplicaciones y almacenamiento.

Diagrama en el que se muestra la infraestructura como proceso de código mediante un repositorio de código fuente con una plantilla que implementa recursos de Azure.

Si recuerda el manual de instrucciones del nuevo juguete, verá que hay varias formas de escribir un manual de instrucciones. Una opción consiste en detallar cada paso del proceso de compilación. Otra opción es mostrar una vista desglosada de las piezas y partes necesarias para ensamblar el juguete. Más adelante en esta unidad, obtendrá información sobre las diferencias entre el código imperativo y declarativo y cómo se relacionan con los manuales de instrucciones de su empresa.

¿Por qué se debe utilizar la infraestructura como código?

La adopción de un enfoque de infraestructura como código ofrece muchas ventajas para el aprovisionamiento de recursos. Con la infraestructura como código, puede:

Aumentar la confianza en las implementaciones.
Administrar varios entornos.
Comprender mejor los recursos en la nube.

Aumento de la confianza

Una de las ventajas de usar la infraestructura como código es el nivel de confianza que obtiene en las implementaciones gracias a las mejoras en coherencia y seguridad.

Integración con los procesos actuales: Si su organización ya usa prácticas de desarrollo de software estándar, puede adoptar esos mismos procesos para las implementaciones de infraestructura. Por ejemplo, las revisiones del mismo nivel pueden ayudar a detectar problemas en configuraciones que podrían ser difíciles de detectar al realizar cambios manuales.
Coherencia: la adopción de un enfoque de infraestructura como código ayuda al equipo a seguir procesos bien establecidos para implementar la infraestructura. Al seguir estos procesos, la responsabilidad cambia de un pequeño grupo de individuos a su proceso de automatización y herramientas. La infraestructura como código ayuda a reducir los errores humanos en el aprovisionamiento de recursos y a garantizar implementaciones coherentes.
Examen automatizado: Puede examinar configuraciones de infraestructura como código con herramientas automatizadas que pueden comprobar si hay errores en el código. Las herramientas automatizadas también pueden revisar los cambios propuestos para asegurarse de que se sigan las prácticas de seguridad y rendimiento.
Administración de secretos: muchas soluciones requieren secretos, como cadenas de conexión, claves de cifrado, secretos de cliente y certificados. En Azure, Azure Key Vault es el servicio que se usa para almacenar estos secretos de forma segura. Muchas herramientas de infraestructura como código se pueden integrar con Key Vault para acceder a estos secretos de forma segura durante la implementación.
Control de acceso: con implementaciones de infraestructura como código, tiene la opción de usar identidades administradas o cuentas de servicio para automatizar el aprovisionamiento de recursos. Este proceso garantiza que solo estas identidades puedan modificar los recursos en la nube. También ayuda a evitar configuraciones incorrectas implementadas en producción. Si es necesario, puede invalidar este proceso mediante una cuenta de acceso de emergencia (a menudo denominada cuenta de emergencia) o mediante la característica Privileged Identity Management de Microsoft Entra ID.
Evitar el desfase de configuración: Idempotence es un término frecuentemente asociado a la infraestructura como código. Cuando una operación es idempotente, significa que proporciona el mismo resultado cada vez que se ejecuta. Si elige herramientas que usan operaciones idempotentes, puede evitar el desfase de configuración.

Como ejemplo de idempotencia, tenga en cuenta el siguiente comando de la CLI de Azure. El siguiente comando crea un grupo de recursos de Azure denominado storage-resource-group en la región Este de EE. UU.

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

Si ejecuta este comando una segunda vez, recibirá la misma salida porque este comando de la CLI de Azure se diseñó para ser idempotente. No recibirá un error ni un grupo de recursos duplicado.

Al usar la infraestructura como código, puede volver a implementar el entorno en cada versión de la solución. Estas versiones pueden incorporar pequeños cambios de configuración o incluso actualizaciones significativas. Este proceso ayuda a evitar el desfase de configuración. Si se realiza un cambio accidental en un recurso, se puede corregir mediante la reimplementación de la configuración. Al seguir este enfoque, está documentando el entorno mediante código.

Administración de varios entornos

Muchas organizaciones mantienen varios entornos de aplicación. Los desarrolladores de su empresa de juguetes pueden tener varias versiones del código de aplicación almacenadas en un repositorio para su lanzamiento en distintos entornos. Los entornos podrían incluir desarrollo, pruebas y producción. Algunas organizaciones mantienen varios entornos de producción para las aplicaciones que se distribuyen globalmente. Otras organizaciones, como los fabricantes de software independientes (ISV), mantienen entornos multiinquilino para sus clientes.

Estas son algunas de las formas clave en que la infraestructura como código puede ayudarle a administrar los entornos:

Aprovisionamiento de nuevos entornos: una de las principales ventajas de la informática en la nube es la capacidad de escalar. La infraestructura como código puede ayudarle a escalar a varias instancias de la aplicación. Estas instancias pueden ayudar en los momentos de mayor carga, o bien puede implementarlas para usuarios de otras áreas del mundo. Esta agilidad también puede ser beneficiosa al probar la aplicación, como durante las pruebas de penetración, las pruebas de carga y las pruebas de errores. Con una base de código bien definida, puede aprovisionar dinámicamente estos nuevos entornos de una manera coherente.
Entornos que no son de producción: Un problema común al que se enfrentan las organizaciones es la diferenciación entre los entornos de producción y los que no son de producción. Al aprovisionar recursos manualmente en entornos independientes, es posible que las configuraciones finales no coincidan. Un ejemplo es cuando se implementa una nueva característica en un entorno que no es de producción y que difiere de la del entorno de producción. Es posible que la nueva característica no funcione según lo previsto en el entorno de producción debido a las diferencias entre los dos entornos. El uso de la infraestructura como código puede ayudar a minimizar estos problemas. Puede usar los mismos archivos de configuración para cada entorno, pero proporcionar parámetros de entrada diferentes para crear una unidad.
Recuperación ante desastres: en algunas situaciones, la infraestructura como código se puede usar como parte del plan de recuperación ante desastres de una organización. Por ejemplo, es posible que tenga que volver a crear el entorno en otra región debido a una interrupción del servicio. Mediante el uso de la infraestructura como código, puede aprovisionar rápidamente una nueva instancia a la que conmutar por error en lugar de implementar y volver a configurar manualmente todo.

Comprensión mejorada de los recursos en la nube

La infraestructura como código también puede ayudarle a comprender mejor el estado de los recursos en la nube:

Pista de auditoría: los cambios en las configuraciones de infraestructura como código se controlan mediante versiones de la misma manera que el código fuente de la aplicación. Se realiza un seguimiento de estos cambios en las herramientas, como con el historial de versiones de Git. Esta pista de auditoría significa que puede revisar los detalles de cada cambio, quién realizó el cambio y cuándo se realizó.
Documentación: puede usar muchas configuraciones de la infraestructura como código para agregar metadatos, como comentarios, que describen la finalidad del código en la configuración. Si su organización ya sigue un proceso de documentación de código, considere la posibilidad de adoptar estos mismos procedimientos con el código de infraestructura.
Sistema unificado:muchas veces, cuando un desarrollador está trabajando en una nueva característica, debe realizar cambios en el código de la aplicación y en el código de la infraestructura. Al usar un sistema común, la organización puede comprender mejor la relación entre las aplicaciones y la infraestructura.
Mejor comprensión de la infraestructura en la nube: cuando se usa Azure Portal para aprovisionar recursos, muchos de los procesos se abstraen de la vista. La infraestructura como código puede ayudar a comprender mejor cómo funciona Azure y cómo solucionar problemas que puedan surgir. Por ejemplo, cuando se crea una máquina virtual mediante Azure Portal, algunos recursos creados se abstraen de la vista. Los discos administrados y las tarjetas de interfaz de red se implementan en segundo plano. Al implementar la misma máquina virtual mediante la infraestructura como código, tiene control total sobre todos los recursos que se crean.

Código imperativo y declarativo

Puede escribir un manual de instrucciones para el nuevo ensamblaje de juguetes de maneras diferentes. Al automatizar la implementación de los servicios y la infraestructura, puede adoptar dos enfoques: imperativo y declarativo.

Con el código imperativo, se ejecuta una secuencia de comandos, en un orden específico, para llegar a una configuración final. Este proceso define lo que debe lograr el código y cómo realizar la tarea. El enfoque imperativo es como un manual de instrucciones paso a paso.
Con el código declarativo, solo se especifica la configuración final. El código no define cómo realizar la tarea. El enfoque declarativo es como el manual de instrucciones de la vista desglosada.

Cuando elija entre usar un enfoque imperativo y un enfoque declarativo para el aprovisionamiento de recursos, tenga en cuenta las herramientas que podrían estar ya en uso en su organización. Tenga en cuenta también qué enfoque podría coincidir con sus propias aptitudes.

Código imperativo

En Azure, un enfoque de código imperativo se logra mediante programación con un lenguaje de scripting como Bash o Azure PowerShell. Los scripts ejecutan una serie de pasos para crear, modificar e incluso quitar los recursos.

En este ejemplo se muestran dos comandos de la CLI de Azure que crean un grupo de recursos y una cuenta de almacenamiento.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

El primer comando crea un grupo de recursos denominado storage-resource-group en la región Este de EE. UU. El segundo comando crea una cuenta de almacenamiento denominada mystorageaccount en el grupo de recursos storage-resource-group, que se ha creado en el primer comando. El segundo comando también configura algunas propiedades para la cuenta de almacenamiento, incluido el tipo de cuenta y su nivel de acceso.

Puede usar un enfoque imperativo para automatizar completamente el aprovisionamiento de recursos, pero el enfoque tiene algunas desventajas. A medida que la arquitectura madura, la administración de los scripts puede ser compleja. Los comandos pueden actualizarse o caer en desuso, lo que requiere revisiones de los scripts existentes.

Código declarativo

En Azure, se realiza un enfoque de código declarativo utilizando plantillas. Hay muchos tipos de plantillas disponibles para su uso, entre los que se incluyen:

JSON
Bicep
Ansible, por RedHat
Terraform, por HashiCorp

Nota:

Este módulo se centra en el uso de plantillas de Bicep.

Consulte el ejemplo siguiente de una plantilla de Bicep que configura una cuenta de almacenamiento. La configuración de la cuenta de almacenamiento coincide con el ejemplo de la CLI de Azure.

resource storageAccount 'Microsoft.Storage/storageAccounts@2203-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

La sección de recursos define la configuración de la cuenta de almacenamiento. Esta sección contiene el nombre, la ubicación y las propiedades de la cuenta de almacenamiento, incluida su SKU y el tipo de cuenta.

Es posible que observe que la plantilla de Bicep no especifica cómo implementar la cuenta de almacenamiento. La plantilla solo especifica el aspecto que debe tener la cuenta de almacenamiento. Los pasos reales que se ejecutan en segundo plano para crear esta cuenta de almacenamiento o para actualizarla para que coincida con la especificación se dejan a elección de Azure.