Propiedad de la infraestructura e IaC

Opfield es responsable de la capa de servicios: nodos, Routes, certificados, cargas de trabajo, bases de datos, copias de seguridad, monitorización y permisos. Las capas inferiores (cuentas de proveedores, redes y sistema operativo del host) se crean a mano, con Terraform, OpenTofu o Ansible, o con el propio Opfield a través de una integración con un proveedor de hosting.

La regla es sencilla: un recurso, un responsable. Dos sistemas pueden observar el mismo recurso, pero no deberían reescribirlo ambos de forma continua.

Quién es responsable de cada capa

Capa	Responsable habitual	Ejemplos
Base del proveedor	Terraform, OpenTofu, consola de la nube o integraciones de hosting de Opfield	redes, máquinas virtuales, cortafuegos, zonas DNS, destinos de copias de seguridad
Configuración base del host	Ansible, pipeline de imágenes o equipo de hosts	sistema operativo, usuarios, política del kernel, instalación de Docker, discos, seguridad del endpoint
Capa de servicios	Opfield	nodos, Routes, certificados, cargas de trabajo, proyectos Compose, bases de datos y almacenamiento gestionados, vinculaciones, copias de seguridad, métricas, logs, alertas, permisos, historial operativo
Intención de versión de la aplicación	control de código fuente y Opfield	revisión del repositorio, build, artefacto, despliegue, reversión
Copias externas	almacenamiento fuera de la instalación	copias de seguridad externas; un SIEM cuando tus normas de cumplimiento exigen conservar la auditoría fuera de Opfield

Un equipo pequeño crea los hosts a mano o mediante una integración de hosting y deja que Opfield sea responsable de todo lo que está por encima del sistema operativo. Una organización más grande crea los hosts con Terraform y registra cada uno cuando supera sus comprobaciones de seguridad.

Decide la propiedad antes de importar

Antes de incorporar un recurso existente a Opfield, registra:

1. qué sistema puede cambiarlo;
2. qué sistema solo puede observarlo;
3. dónde está su fuente de verdad;
4. quién aprueba los cambios de emergencia;
5. cómo se concilia después un cambio de emergencia.

Por ejemplo, si Terraform es responsable de un registro DNS, no configures además Opfield para que reescriba continuamente ese mismo registro. O mantienes el DNS en Terraform y lo apuntas a una Route gestionada por Opfield, o transfieres deliberadamente el ciclo de vida de ese registro a Opfield y lo eliminas del estado de Terraform.

Evita la propiedad dividida

La propiedad dividida provoca deriva: una herramienta aplica un cambio válido y otra ve un valor inesperado y lo revierte. El resultado puede parecer aleatorio aunque ambos sistemas se comporten según su configuración.

Entre los conflictos habituales están:

• Terraform y Opfield gestionando a la vez un mismo registro DNS;
• Ansible y Opfield sustituyendo la misma configuración de nginx;
• un script del host que reinicia o elimina contenedores que pertenecen a un Deployment o a un Compose Project de Opfield;
• una herramienta de bases de datos externa que modifica usuarios creados para una vinculación gestionada por Opfield;
• un pipeline de CI que despliega la misma carga de trabajo que Opfield también construye y despliega.

Si dos sistemas tienen que tocar un mismo ámbito, divídelo con un límite explícito. Terraform puede ser responsable de la VM y del cortafuegos mientras Opfield lo es de las aplicaciones dentro de esa VM. Ansible puede encargarse de instalar Docker mientras Opfield gestiona los recursos de Docker. Un sistema de copias de seguridad externo puede leer una base de datos mientras Opfield es responsable de su ciclo de vida como servicio.

Cambios manuales de emergencia

Durante un incidente, un cambio directo en el host puede ser la acción más segura. Trátalo como una excepción temporal:

1. registra el recurso, el comando o ajuste, el operador, la hora y el motivo;
2. pausa la automatización que podría sobrescribir el cambio;
3. restablece el servicio al cliente y conserva las pruebas;
4. decide si Opfield o la fuente de verdad externa debe adoptar el nuevo estado;
5. concilia de forma deliberada y elimina la excepción temporal.

No dejes una corrección de emergencia que funcionó como una deriva permanente sin documentar. De lo contrario, el siguiente despliegue rutinario puede deshacerla.

Pasar a Opfield

Traslada una familia de recursos cada vez: tráfico entrante, cargas de trabajo, bases de datos, copias de seguridad, monitorización. Para cada una, transfiere la propiedad de forma explícita, elimínala de la herramienta anterior y demuestra que su restauración funciona antes de pasar a la siguiente. Lleva tu stack a Opfield indica el orden y la comprobación de cada paso.