Puntos clave: Infrastructure as Code (IaC) automatiza la gestión de la infraestructura de TI a través del código, proporcionando entornos consistentes y reproducibles. Se integra con Pipelines CI/CD, mejorando la gestión de configuración y la escalabilidad.
- IaC reduce los procesos manuales, minimizando errores y acelerando los despliegues.
- Las herramientas más populares incluyen Terraform, Ansible y AWS CloudFormation, cada una adecuada para diferentes necesidades de gestión.
La infraestructura es uno de los principios fundamentales de un proceso de desarrollo de software: es directamente responsable del funcionamiento estable de una aplicación de software. Esta infraestructura puede ir desde servidores, balanceadores de carga, cortafuegos y bases de datos hasta complejos clústeres de contenedores. Las consideraciones de infraestructura son válidas más allá de los entornos de producción, ya que se extienden a lo largo de todo el proceso de desarrollo. Incluyen herramientas y plataformas como plataformas CI/CD, entornos de staging y herramientas de prueba. Estas consideraciones de infraestructura aumentan a medida que aumenta el nivel de complejidad del producto de software. Muy rápidamente, el enfoque tradicional de gestionar manualmente la infraestructura se convierte en una solución inescalable para satisfacer las demandas de los ciclos modernos de desarrollo rápido de software basados en DevOps. Y así es como Infraestructura como Código (IaC) se ha convertido en la solución de facto en desarrollo hoy en día. IaC te permite satisfacer las crecientes necesidades de cambios de infraestructura de manera escalable y rastreable.
¿Qué es infraestructura como código?
Infraestructura como Código o IaC están el proceso de aprovisionamiento y gestión de infraestructuras definidas mediante código, en lugar de hacerlo con un proceso manual. Como la infraestructura están define como código, permite a los usuarios editar y distribuir configuraciones fácilmente asegurando el estado deseado de la infraestructura. Esto significa que te puede Crea configuraciones de infraestructura reproducibles. Además, definir infraestructura como código también:
- Permite integrar fácilmente la infraestructura en los mecanismos de control de versiones para Crea cambios de infraestructura rastreables y auditables.
- Proporciona la capacidad de introducir una automatización extensa para la gestión de infraestructuras. Todo esto lleva a que IaC se integre en los Pipelines CI/CD como parte integral del SDLC.
- Elimina la necesidad de provisión y gestión manual de infraestructura. Así, permite a los usuarios gestionar fácilmente la inevitable desviación de configuración de la infraestructura y configuraciones subyacentes y mantener todos los entornos dentro de la configuración definida.
Infraestructura declarativa vs imperativa como código
Al tratar con herramientas IaC, son dos enfoques principales que diferencian la escritura de código. Estos dos enfoques son declarativos e imperativos. En pocas palabras:
- Un enfoque imperativo permite a los usuarios especificar los pasos exactos a seguir para un cambio, y el sistema no se desvía de los pasos especificados.
- Un enfoque declarativo significa esencialmente que los usuarios solo necesitan Define el requisito final, y la herramienta o plataforma específica gestiona los pasos a seguir para Lograr dicho requisito.
El enfoque declarativo están preferido en la mayoría de los casos de utiliza de gestión de infraestructura, ya que ofrece un mayor grado de flexibilidad al gestionar infraestructuras. Chef se considera una herramienta imperativa, mientras que Terraform, Pulumi, CloudFormation, ART y Puppet son todos declarativos. De forma única, Ansible está mayormente declarativo y soporta comandos imperativos.
IaC vs IaaS
Es importante destacar que IaC no están un derivado de infraestructura como servicio (IaaS). Son dos conceptos diferentes.
- La infraestructura como servicio está uno de los servicios en la nube centrales: los recursos informáticos virtualizados —servidores, infraestructura de red, almacenamiento, etc.— son proporcionados a través del servicio en la nube.
- Infraestructura como Código están una herramienta que puede usarse para provisiona y gestiona infraestructura. No están limitada solo a recursos basados en la nube. De hecho, te aplicar IaC a una amplia variedad de entornos, incluidos los locales.
Cuándo y cómo utilizar la infraestructura como código
La IaC puede parecer innecesaria para requisitos de infraestructura más simples y menos complejos, pero eso no es exacto. Cualquier pipeline de desarrollo de software moderno debería utilizar infraestructura como código para gestionar la infraestructura. Además, las ventajas de la IaC superan con creces cualquier carga de implementación y gestión.
Ventajas de IaC
Aquí son los principales beneficios de IaC:
- Reducir la tecnología en la sombra dentro de las organizaciones y permitir cambios de infraestructura oportunos y eficientes que son realizados en paralelo al desarrollo de aplicaciones.
- Integrando directamente con plataformas CI/CD.
- Habilitar cambios en la infraestructura y configuración controladas por versiones que llevan a configuraciones rastreables y auditables.
- Estandarizar fácilmente la infraestructura con configuraciones reproducibles.
- Gestionar eficazmente, configurar la deriva y mantener la infraestructura y configuraciones en el estado deseado.
- Tener la capacidad de escalar fácilmente la gestión de infraestructura sin aumentar CapEx o OpEx. Con IaC, te Reduce el gasto en CapEx y OpEx en general, ya que la automatización elimina la necesidad de interacciones manuales que consumen mucho tiempo y reduce configuraciones incorrectas.
Cuándo utilizar IaC
¿No sabes cuándo utiliza IaC? La respuesta más sencilla están siempre que te tener que gestiona cualquier tipo de infraestructura. Sin embargo, se vuelve más complejo con los requisitos y herramientas exactas. Algunas pueden requerir una gestión estricta de infraestructura, mientras que otras pueden requerir tanto infraestructura como configuración de la organización. Luego vienen preguntas específicas de la plataforma, como si la herramienta tiene el conjunto de funciones necesarias, implicaciones de seguridad, integraciones, etc. Además, entra en juego la curva de aprendizaje, ya que los usuarios prefieren una herramienta más sencilla y directa que una compleja. La tabla siguiente muestra una categorización de las herramientas mencionadas anteriormente según sus casos ideales utiliza.
| Caso de utiliza | Herramientas para utilizar |
|---|---|
| Gestión de infraestructuras | Terraform, Pulumi, AWS CloudFormation, Plantillas de Recursos Azure |
| Gestión de configuración con capacidades de gestión de infraestructura algo limitadas | Ansible, Chef, Puppet |
| Gestión de configuración | CFEngine |
Una sola herramienta puede no ser suficiente en la mayoría de los casos. Por ejemplo, Terraform puede ser excelente para gestionar infraestructura en múltiples entornos de nube, pero puede ser limitado cuando se requieren configuraciones son profundas. En ese tipo de situaciones, los usuarios pueden utilizar una herramienta como Ansible para realizar las configuraciones necesarias. Del mismo modo, los usuarios pueden combinar cualquier herramienta IaC y utilizarla en sus Pipelines CI/CD según los requisitos exactos. (Conoce cómo configurar tu propia tubería CI/CD.)
Herramientas y plataformas de Infraestructura como Código
Bajo el gran paraguas de IaC, son todo tipo de herramientas, desde herramientas dedicadas a la gestión de infraestructuras hasta la gestión de configuración, desde herramientas de código abierto hasta opciones IaC específicas para cada plataforma. Veamos algunas de las herramientas y plataformas de IaC más populares.
Terraform
Terraform están la herramienta líder en IaC para infraestructura multinube — y para los equipos que necesitan orquestar flujos de trabajo de Terraform con Control-M, la integración permite la provisión programada de infraestructura como un paso gobernado en las pipelines de despliegue en producción. Como herramienta independiente de la plataforma, Terraform puede usarse para facilitar cualquier provisión y gestión de infraestructura utiliza casos entre diferentes plataformas y proveedores, asegurando el estado deseado en todas las configuraciones.
Ansible
Ansible destaca en la gestión de configuración en entornos cloud y on-premise — y para equipos que necesitan programación y gobernanza a nivel empresarial, la orquestación de cargas de trabajo Control-M para Ansible coordina los trabajos AWX de Ansible dentro de flujos de trabajo más amplios de aplicaciones y pipelines de datos. (Descubre por qué la gente suele comparar Ansible y Control-M.)
Pulumi
Pulumi están una herramienta relativamente nueva que pretende ofrecer una experiencia IaC centrada en el desarrollador. A diferencia de otras herramientas que obligan a los usuarios a utilizar un lenguaje o formato específico, Pulumi ofrece libertad para utilizar cualquier lenguaje de programación compatible como deseen. Esta herramienta soporta Python, TypeScript, JavaScript, Go, C#, F#, y el estado se está gestionado por defecto mediante el servicio Pulumi.
Chef/Marioneta
Chef y Puppet son dos herramientas potentes de gestión de configuración. Ambas buscan proporcionar capacidades de gestión de configuración y automatización, junto con algunas capacidades de gestión de infraestructura a lo largo de la línea de desarrollo.
- Chef está desarrollado para integrarse fácilmente en las prácticas DevOps con mejores herramientas de colaboración.
- Puppet evolucionó dirigiéndose a la automatización de procesos puros. Hoy en día, Puppet cuenta con observadores automáticos integrados para identificar la deriva de configuración.
(Consulta el informe sobre el Estado del DevOps de Puppet.)
CFEngine
CFEngine está una de las herramientas más maduras centrada exclusivamente en la gestión de configuración. Aunque no están capaz de gestionar la infraestructura subyacente, CDEngine puede acomodar incluso los requisitos de configuración más complejos, cubriendo desde el endurecimiento de la seguridad hasta el cumplimiento normativo.
AWS CloudFormation
CloudFormation están la herramienta IaC propietaria específica de AWS para gestionar la infraestructura de AWS. CloudFormation tiene una integración profunda con todos los servicios de AWS y puede facilitar cualquier configuración de AWS como solución de primera parte.
Azure Resource Templates
Microsoft Azure utiliza plantillas de recursos de Azure basadas en JSON para facilitar las prácticas de IaC dentro de la plataforma Azure. Estas plantillas de recursos garantizan la coherencia de la infraestructura y pueden utilizarse para cualquier tipo de configuración de recursos. Además de lo anterior, son herramientas especializadas dirigidas a tareas específicas de gestión de infraestructura y configuración como:
- Packer, EC2 Image Builder y Azure Image Builder Crean imágenes personalizadas de sistema operativo desplegables.
- Cloud-Init es la herramienta estándar de la industria para la inicialización de instancias en la nube multiplataforma. Permite a los usuarios ejecutar el script al aprovisionar recursos (servidores).
- (R)?ex está un marco completo de automatización de infraestructuras
(Obtén familiaridad con Azure DevOps.)
Ejemplos de infraestructura como código
Vamos a considerar un escenario sencillo de aprovisionamiento de una Instancia AWS EC2. En el siguiente ejemplo, podemos Ve cómo se son utilizados los códigos Terraform, Ansible y AWS CloudFormation para este requisito.
Terraform
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.27"
}
}
}
provider "aws" {
access_key = "aws_access_key"
secret_key = "aws_secret_key"
// shared_credentials_file = "/Users/.aws/creds"
region = "us-west-1"
}
resource "aws_instance" "web_server" {
ami = "ami-0123456"
instance_type = "t3.small"
subnet_id = "subnet-a000111x"
vpc_security_group_ids = "sg-dfdd00011"
key_name = "web_server_test_key"
tags = {
Name = "Web_Server"
}
}
Ansible
- hosts: localhost
gather_facts: False
vars_files:
- credentials.yml
tasks:
- name: Provision EC2 Instance
ec2:
aws_access_key: "{{aws_access_key}}"
aws_secret_key: "{{aws_secret_key}}"
key_name: web_server_test_key
group: test
instance_type: t3.small
image: "ami-0123456"
wait: true
count: 1
region: us-west-1
instance_tags:
Name: Web_Server
register: ec2
AWS CloudFormation
AWSTemplateFormatVersion: "2010-09-09"
Resources:
WebInstance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t3.small
ImageId: ami-0123456
KeyName: web_server_test_key
SecurityGroupIds:
- sg-dfdd00011
SubnetId: subnet-a000111x
Tags:
-
Key: Name
Value: Web_Server
Un ejemplo real: IaC para DevOps
En el contexto del desarrollo de software, una limitación fundamental están la necesidad de que el entorno donde se está probado el código de software desarrollado refleje exactamente el entorno en vivo al que se desplegará dicho código. Esta es la única forma de asegurar que el nuevo código no colisione con las definiciones existentes: generando errores o conflictos que puedan comprometer todo el sistema. En el pasado, la entrega de software seguía este tipo de patrón:
- Un administrador de sistemas configuraba un servidor físico e instalaba el sistema operativo con todos los paquetes de servicio y ajustes necesarios para reflejar el estado de la máquina operativa principal que soporta el entorno de producción.
- Luego, un administrador de bases de datos pasaría por el mismo proceso para la base de datos de soporte, y la máquina se entregaba a un equipo de pruebas.
- El desarrollador entregaba el código/programa copiándolo a la máquina de pruebas, y el equipo de pruebas realizaba varias pruebas operativas y de cumplimiento.
- Una vez que el nuevo código ha completado todo el proceso, te puede desplegarlo en el entorno operativo en vivo. En muchos casos, el nuevo código no funcionará correctamente, por lo que son necesaria una solución adicional de problemas y retrabajos.
(Entiende las diferencias entre desplegar y lanzar software.) La recreación manual de un entorno en vivo deja abiertas puertas a multitud de errores humanos probablemente menores pero potencialmente bastante importantes, en lo que respecta:
- Versión del sistema operativo
- Nivel de parche
- Huso horario
- Etcétera.
Un clon de entorno en vivo, creado usando exactamente el mismo IaC que el entorno en vivo, tiene la garantía absoluta de que si funciona en el entorno clonado, funcionará en vivo. Imagina un proceso de entrega de software que involucre entornos separados para DEV, UAT y Producción. Aparentemente hay poco valor en tener un entorno DEV y UAT que no sea un reflejo exacto del entorno de producción, dado que esos primeros entornos son críticos para medir la calidad y la preparación para producción de una versión de compilación de software. La introducción de la virtualización permitió agilizar este proceso, especialmente en la fase de creación y actualización de un servidor de pruebas que reflejara el entorno en vivo. Sin embargo, el proceso era manual, lo que significaba que un humano tenía que Crea y actualizar la máquina en consecuencia y de forma oportuna. Con la introducción de DevOps, estos procesos se volvieron aún más "ágiles". Añadir automatización a las fases de virtualización y pruebas de servidores reemplaza la intervención humana, mejorando la productividad y la eficiencia. En resumen: en el pasado, se requerían varias horas de trabajo y recursos humanos para completar el ciclo de despliegue del software (desarrolladores, administradores de sistemas, administradores de bases de datos, probadores de operaciones). Ahora, es posible que el desarrollador complete todas las tareas por sí solo:
- El desarrollador escribe el código de la aplicación y las instrucciones relacionadas con la gestión de configuración que desencadenarán acciones desde el entorno de virtualización y otros entornos como la base de datos, los aparatos, las herramientas de prueba, las herramientas de entrega y más.
- Al entregar nuevo código, las instrucciones de gestión de configuración Crea automáticamente un nuevo entorno de prueba virtual con un servidor de aplicaciones más una instancia de base de datos que refleja exactamente la estructura del entorno operativo en vivo, tanto en términos de paquetes de servicio y versionado como en datos en vivo que están transferidos a dicho entorno virtual de prueba. (Esto está la Infraestructura como Código parte del proceso.)
- Después, un conjunto de herramientas realizará las pruebas de cumplimiento necesarias e identificará y resolver errores. El nuevo código están entonces listo para su despliegue en el entorno de TI en vivo.
Cambios rápidos y rastreables en la infraestructura
La infraestructura como código se ha convertido en una parte vital de las canalizaciones modernas de desarrollo y despliegue de aplicaciones. Se están logrados facilitando cambios rápidos y rastreables en la infraestructura que se integran directamente en las plataformas CI/CD. La infraestructura como código está crucial para ambos:
- Facilitar la gestión escalable de infraestructuras
- Gestionar eficientemente la deriva de configuración en todos los entornos
Empezar con Infraestructura como Código puede parecer abrumador con muchas herramientas y plataformas diferentes dirigidas a distintos utiliza casos. Sin embargo, si superas este obstáculo, te tendrás un potente mecanismo de gestión de infraestructura al alcance de tu mano.
Lecturas relacionadas
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.