Infraestructura como código: el fundamento de la plataforma
L'Infraestructura como código (IaC) y el principio por el cual surge la infraestructura definido, versionado y administrado a través de código declarativo o imperativo, en lugar de a través de Configuraciones manuales. En el contexto de la ingeniería de plataformas, IaC no es solo una mejor práctica: y un requisito fundamental para construir un IDP que sea repetible, escalable y auditable.
En este artículo compararemos los dos enfoques dominantes: Terraformar (declarativo) mi Pulumi (imperativo con lenguajes de propósito general) - y exploraremos cómo implementar Política como código con OPA y Sentinel para garantizar el cumplimiento y la seguridad automatizada.
lo que aprenderás
- Paradigmi IaC: dichiarativo (Terraform/HCL) vs imperativo (Pulumi/TypeScript)
- Gestión de estados: estado remoto, bloqueo, recuperación ante desastres
- Moduli Terraform riutilizzabili e composizione
- Pulumi: IaC con TypeScript, Python y Go
- Política como código: OPA/Rego para cumplimiento y Sentinel para Terraform Cloud
- Estrategias de migración hacia IaC para infraestructura existente
Terraform: El Enfoque Declarativo
Terraformar de HashiCorp y el fabricante de IaC más popular del mundo. Usa uno lenguaje declarativo llamado HCL (lenguaje de configuración de HashiCorp) párrafo describir el estado defectuoso de la infraestructura. Terraform compara el estado abierto con el estado actual y calcular un plan de ejecución para alcanzar la configuración objetivo.
Los puntos fuertes de Terraform son:
- Provider ecosystem: supporta centinaia di provider cloud e SaaS (AWS, Azure, GCP, Kubernetes, GitHub, Datadog...)
- Planifique antes de aplicar: Muestra los cambios antes de ejecutarlos, reduciendo el riesgo de errores
- Gestión patrimonial: Realice un seguimiento del estado real de su infraestructura para gestionar actualizaciones incrementales
- Formularios: Componentes reutilizables que encapsulan configuraciones complejas
# Terraform: modulo riutilizzabile per microservice infrastructure
# modules/microservice-infra/main.tf
variable "service_name" {
type = string
description = "Nome del microservizio"
}
variable "environment" {
type = string
description = "Environment (dev, staging, production)"
}
variable "cpu_limit" {
type = string
default = "500m"
}
variable "memory_limit" {
type = string
default = "512Mi"
}
# Kubernetes namespace con labels standard
resource "kubernetes_namespace" "service" {
metadata {
name = "${var.service_name}-${var.environment}"
labels = {
"app.kubernetes.io/name" = var.service_name
"app.kubernetes.io/env" = var.environment
"platform.company.io/managed" = "true"
}
}
}
# Database PostgreSQL (RDS)
resource "aws_db_instance" "database" {
identifier = "${var.service_name}-${var.environment}"
engine = "postgres"
engine_version = "15.4"
instance_class = var.environment == "production" ? "db.r6g.large" : "db.t3.micro"
allocated_storage = 20
max_allocated_storage = var.environment == "production" ? 100 : 50
storage_encrypted = true
db_name = replace(var.service_name, "-", "_")
username = "app_user"
password = random_password.db_password.result
backup_retention_period = var.environment == "production" ? 30 : 7
deletion_protection = var.environment == "production"
tags = {
Service = var.service_name
Environment = var.environment
ManagedBy = "terraform"
}
}
# Redis cache (ElastiCache)
resource "aws_elasticache_cluster" "cache" {
cluster_id = "${var.service_name}-${var.environment}"
engine = "redis"
node_type = var.environment == "production" ? "cache.r6g.large" : "cache.t3.micro"
num_cache_nodes = 1
parameter_group_name = "default.redis7"
port = 6379
}
output "namespace" {
value = kubernetes_namespace.service.metadata[0].name
}
output "database_endpoint" {
value = aws_db_instance.database.endpoint
}
output "cache_endpoint" {
value = aws_elasticache_cluster.cache.cache_nodes[0].address
}
Pulumi: IaC con Lenguajes de Propósito General
Pulumi adopta un enfoque diferente: en lugar de un lenguaje dedicado (como HCL), le permite definir la infraestructura utilizando lenguajes de programación estándar como TypeScript, Python, Go, C# y Java. Esto significa tener acceso a construcciones. como bucles, condicionales, funciones, clases y todo el ecosistema de bibliotecas del idioma elegido.
Las ventajas de Pulumi son:
- Modismos familiares: no es necesario aprender un nuevo idioma; Utilice lo que el equipo sabe.
- pruebas nativas: planes unitarios y planes de integración de infraestructura con marcas de plan estándar
- Abstracciones poderosas: Clases, interfaces y composición para crear componentes IaC complejos
- IDE support: autocomplete, type checking e refactoring con i tool del linguaggio
// Pulumi: componente riutilizzabile in TypeScript
// microservice-infra.ts
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as k8s from "@pulumi/kubernetes";
interface MicroserviceInfraArgs {
serviceName: string;
environment: string;
cpuLimit?: string;
memoryLimit?: string;
enableDatabase?: boolean;
enableCache?: boolean;
}
export class MicroserviceInfra extends pulumi.ComponentResource {
public readonly namespace: k8s.core.v1.Namespace;
public readonly databaseEndpoint?: pulumi.Output<string>;
public readonly cacheEndpoint?: pulumi.Output<string>;
constructor(
name: string,
args: MicroserviceInfraArgs,
opts?: pulumi.ComponentResourceOptions
) {
super("company:platform:MicroserviceInfra", name, {}, opts);
const isProd = args.environment === "production";
// Kubernetes namespace
this.namespace = new k8s.core.v1.Namespace(
`${args.serviceName}-ns`,
{
metadata: {
name: `${args.serviceName}-${args.environment}`,
labels: {
"app.kubernetes.io/name": args.serviceName,
"app.kubernetes.io/env": args.environment,
"platform.company.io/managed": "true",
},
},
},
{ parent: this }
);
// Database condizionale
if (args.enableDatabase !== false) {
const db = new aws.rds.Instance(
`${args.serviceName}-db`,
{
identifier: `${args.serviceName}-${args.environment}`,
engine: "postgres",
engineVersion: "15.4",
instanceClass: isProd ? "db.r6g.large" : "db.t3.micro",
allocatedStorage: 20,
storageEncrypted: true,
deletionProtection: isProd,
},
{ parent: this }
);
this.databaseEndpoint = db.endpoint;
}
this.registerOutputs({
namespaceName: this.namespace.metadata.name,
});
}
}
State Management
La gestión de permanecerá y uno de los aspectos más críticos de IaC. El expediente de verano Contiene el mapa entre los cursos definidos en el código y los cursos reales en la nube. una gestion Los errores de verano pueden provocar interrupciones, conflictos e incluso pérdidas de rentabilidad.
- Estado remoto: El estado debe guardarse en un backend remoto (S3, GCS, Azure Blob, Terraform Cloud) para compartirlo entre los miembros del equipo.
- estas bloqueando: mecanismo de bloqueo (DynamoDB para AWS, GCS para GCP) para evitar cambios simultáneos
- Cifrado de estado: El estado contiene información confidencial y debe cifrarse en reposo y en tránsito.
- Recuperación ante desastres: Copias de seguridad de estado regulares con control de versiones habilitado en el depósito
Regla Fundamental
Nunca envíe el archivo de estado al repositorio de Git. El estado contiene información. sensible (contraseñas, cadenas de conexión, claves) y debe administrarse exclusivamente a través del backend remoto con encriptación adecuada y control de acceso.
La política como código con OPA y Sentinel
Política como código y el principio de definir las políticas organizacionales como código versionado, comprobable y ejecutable automáticamente. En el contexto de IaC, las políticas verifican que la infraestructura definida cumpla primero con los requisitos de seguridad, cumplimiento y costos del despliegue.
- OPA (Agente de Política Abierta): motor de políticas de propósito general con lenguaje Rego. Puede validar planes Terraform, manifiestos de Kubernetes y solicitudes de API.
- Centinela: Marco de políticas de HashiCorp integrado en Terraform Cloud/Enterprise. Utilice un lenguaje dedicado optimizado para políticas de infraestructura
- Kyverno: motor de políticas nativo de Kubernetes que utiliza YAML para definir políticas (más simple que OPA para casos de uso específicos de K8)
# OPA/Rego: policy per validare Terraform plans
# policy/terraform/mandatory_tags.rego
package terraform.mandatory_tags
import rego.v1
# Tutti i resource devono avere i tag obbligatori
mandatory_tags := ["Environment", "Service", "ManagedBy", "Team"]
# Trova risorse senza tag obbligatori
deny contains msg if {
resource := input.planned_values.root_module.resources[_]
tags := object.get(resource.values, "tags", {})
required_tag := mandatory_tags[_]
not tags[required_tag]
msg := sprintf(
"Resource '%s' manca il tag obbligatorio '%s'",
[resource.address, required_tag]
)
}
# Database in produzione deve avere encryption abilitata
deny contains msg if {
resource := input.planned_values.root_module.resources[_]
resource.type == "aws_db_instance"
resource.values.storage_encrypted != true
msg := sprintf(
"Database '%s' deve avere storage_encrypted = true",
[resource.address]
)
}
# Nessuna risorsa pubblica senza approvazione
deny contains msg if {
resource := input.planned_values.root_module.resources[_]
resource.type == "aws_s3_bucket"
acl := object.get(resource.values, "acl", "private")
acl == "public-read"
msg := sprintf(
"S3 bucket '%s' non può essere pubblico senza approvazione",
[resource.address]
)
}
GitOps y PR-Based Workflows
La integración de IaC con el flujo de trabajo GitOps y esencial para un derrame interno duro. El mecenas más eficaz es aquel Flujo de trabajo basado en relaciones públicas.: Cualquier cambio en la infraestructura. Se produce mediante una solicitud de extracción que es válida automáticamente antes de la fusión.
- Atlántida: herramienta que automatiza el flujo de trabajo de Terraform en Pull Request (plan automático, aplicar después de la aprobación)
- Transporte espacial: Plataforma SaaS para gestión de IaC con políticas, detección de derivas y registro de módulos
- Env0: piattaforma che aggiunge governance, costi e TTL agli ambienti IaC
El flujo de negocios basado en las relaciones públicas es el trazabilidad completo: cada cambio a la infraestructura y documentado en un PR con revisiones, comentarios y aprobación. Esta satisfacción Requerimientos auditivos y cumplimiento de la forma natural.
Estrategias de Migración
Migrar una infraestructura existente (creada manualmente o con scripts ad-hoc) a IaC Es un proceso que requiere planificación y gradualidad:
- Fase 1 - Importación: Importe recursos existentes al estado Terraform sin modificaciones
- Paso 2 - Codificar: Escriba el código IaC que describe los recursos importados, verificando que el plan no muestre cambios
- Fase 3: estandarizar: refactorización progresiva de módulos compartidos y convenciones de nomenclatura
- Paso 4: automatizar: integración con CI/CD para aplicación automática y cumplimiento de políticas
Consejos sobre migración
No intente migrar toda su infraestructura de una sola vez. Comience con los componentes más simples. y de bajo riesgo (depósito S3, registros DNS, políticas de IAM), gane experiencia y confianza, luego proceda con los recursos más críticos (base de datos, clúster de Kubernetes, redes).