Infraestructura como código y GitOps en España

Servicios DevOps · España

Infraestructura como código y GitOps en España para equipos que quieren dejar de configurar servidores a mano. Definimos tu infraestructura con Terraform u OpenTofu, la configuración con Ansible, y el despliegue de aplicaciones con GitOps mediante ArgoCD o Flux, de forma que el estado deseado vive en git, revisado por pull request, y la recuperación ante un desastre es reconstruir desde código, no restaurar una imagen antigua.

  • Todo en git, revisado por pull request antes de aplicar
  • Detección de desviación (drift) entre lo declarado y lo real
  • Recuperación ante desastres reconstruyendo desde código
Habla con un ingenieroVer abonamientos
  • VPS 1–8 h/mes; dedicados 5-10 h/mes según el plan; GPU 10 h/mes
    Horas incluidas
  • Frankfurt, en la UE
    Datacenters
  • baja latencia desde Fráncfort
    Latencia
  • en EUR, con IVA del 21 % desglosado en factura
    Facturación

Qué automatizamos con Terraform y Ansible

Terraform (u OpenTofu) declara qué infraestructura debe existir: servidores, redes, balanceadores, registros DNS. Ansible se encarga de la configuración dentro de esos servidores: paquetes instalados, usuarios, servicios en marcha. La combinación de ambos permite reconstruir un entorno completo desde cero solo con el código del repositorio, sin depender de que alguien recuerde los pasos manuales que se hicieron hace meses.

  • Terraform/OpenTofu para la infraestructura: servidores, redes, DNS
  • Ansible para la configuración dentro de cada servidor
  • Estado bloqueado durante los cambios, para evitar aplicaciones simultáneas

Buenas prácticas que aplicamos

La infraestructura como código pierde su valor en cuanto alguien hace un cambio manual «solo por esta vez» directamente en producción, porque a partir de ahí el código deja de reflejar la realidad. Aplicamos una disciplina que evita ese desvío desde el primer despliegue, y somos honestos en que la parte difícil suele ser el hábito del equipo, no la herramienta.

  • Todo en git, revisado por pull request antes de aplicar
  • Infraestructura inmutable: se reemplaza, no se modifica a mano
  • Ningún cambio manual en producción, ni siquiera de emergencia sin registrar
  • Simulacros periódicos de recuperación ante desastres
  • Paridad real entre entornos de desarrollo, staging y producción

GitOps para el despliegue de aplicaciones

GitOps aplica la misma idea a las aplicaciones que corren sobre esa infraestructura: el estado deseado del clúster vive en un repositorio git, y una herramienta como ArgoCD o Flux se encarga de que lo que corre en producción coincida siempre con lo que hay declarado en ese repositorio, revirtiendo automáticamente cualquier cambio manual que se haga fuera del proceso. Esto incluye detección de desviación (drift): si algo cambia por fuera de git, lo detectamos y lo corregimos.

  • El estado deseado vive en git, no en la memoria de nadie
  • ArgoCD o Flux corrigen automáticamente cualquier desviación
  • Detección de drift entre lo declarado y lo que corre realmente

Cómo usas las horas incluidas

Las horas DevOps forman parte del abonamiento: entre 1 y 8 horas al mes en VPS, entre 5 y 10 horas al mes en dedicados según el plan y 10 horas al mes en GPU. Se solicitan desde el panel de cliente, en Servicios DevOps. Se usan habitualmente para escribir el código Terraform inicial de una infraestructura existente que se creó a mano, montar el pipeline GitOps, o realizar un simulacro de recuperación ante desastres. Lo que supera la cuota mensual se acepta y se factura por separado.

Cada suscripción incluye horas mensuales de DevOps, CyberSecurity y Programación: 1 h desde el plan cPanel Advanced, 1–8 h en VPS, entre 5 y 10 h en servidores dedicados según el plan y 10 h en servidores GPU. Las horas se solicitan desde el panel de cliente, no se acumulan al mes siguiente, y lo que supera la cuota se acepta y se factura por separado.

Cómo trabajamos

  1. Solicitas el trabajo desde el panel

    Describes tu infraestructura actual, si ya está en código o se configuró manualmente, y qué nivel de automatización buscas.

  2. Acordamos alcance y plazo

    Definimos qué se declara en Terraform, qué en Ansible, si añadimos GitOps para el despliegue, y cuántas horas cubre el trabajo.

  3. Escribimos el código y validamos sin romper nada

    Importamos la infraestructura existente al código cuando aplica, validamos los cambios en un entorno de prueba y aplicamos con revisión por pull request.

  4. Entrega con documentación

    Recibes el repositorio con la infraestructura declarada, la documentación del proceso de despliegue y el procedimiento de recuperación ante desastres.

Casos de uso

Empresa creciendo desde infraestructura manual

Una empresa de Madrid que configuró sus primeros servidores a mano y ya no recuerda con precisión qué se hizo en cada uno migra a Terraform y Ansible, recuperando la capacidad de reconstruir cualquier entorno desde código.

SaaS con varios entornos que divergen

Un equipo de producto descubre que su entorno de staging lleva meses sin coincidir con producción, causando bugs que solo aparecen al desplegar: GitOps con paridad real entre entornos elimina esa divergencia.

Empresa con requisito de recuperación ante desastres

Una empresa con obligaciones contractuales de continuidad de negocio necesita demostrar que puede reconstruir su infraestructura completa desde cero: lo verificamos con un simulacro real, no solo con un documento.

Tecnologías

  • Terraform
  • OpenTofu
  • Ansible
  • ArgoCD
  • Flux
  • SOPS
  • Vault

Preguntas frecuentes

  • ¿Terraform o Ansible?

    No son alternativas entre sí, sino complementarios: Terraform declara qué infraestructura debe existir (servidores, redes, DNS), Ansible configura lo que corre dentro de esos servidores (paquetes, usuarios, servicios). En la mayoría de proyectos usamos ambos, cada uno para lo que hace mejor.

  • ¿Qué es la infraestructura como código?

    Es la práctica de declarar tu infraestructura (servidores, redes, configuración) en archivos de texto versionados en git, en lugar de crearla manualmente desde un panel o por SSH. Esto permite revisar los cambios antes de aplicarlos, reconstruir el entorno completo desde cero si hace falta, y saber exactamente qué existe y por qué.

  • ¿Qué es GitOps?

    Es aplicar el mismo principio de infraestructura como código al despliegue de aplicaciones: el estado deseado de lo que corre en tu clúster vive en un repositorio git, y una herramienta como ArgoCD o Flux se asegura de que la realidad coincida siempre con lo declarado, corrigiendo automáticamente cualquier cambio manual no autorizado.

  • ¿Cuándo conviene usar infraestructura como código?

    Prácticamente siempre que tengas más de un servidor o esperes crecer, porque el coste de no tenerla aparece más tarde: cuando necesitas reconstruir algo rápido tras un fallo, o cuando nadie recuerda ya cómo se configuró un servidor concreto. Cuanto antes se adopta, menos infraestructura manual hay que migrar después.

  • ¿OpenTofu o Terraform?

    OpenTofu es el fork de código abierto de Terraform, compatible con la misma sintaxis y la mayoría de los módulos existentes, surgido tras el cambio de licencia de Terraform. Funcionalmente son muy similares hoy; la elección suele depender de tu postura respecto a la licencia más que de una diferencia técnica relevante.

  • ¿Cómo evitar cambios manuales en producción?

    Restringiendo el acceso directo de escritura a los servidores de producción y exigiendo que todo cambio pase por un pull request revisado y aplicado por el pipeline, nunca por SSH directo. Complementado con detección de drift, que avisa si algo cambia por fuera de ese proceso, incluso por accidente.

¿Tu infraestructura se creó a mano y nadie recuerda cómo?

Cuéntanos tu situación actual: te decimos por dónde empezar con Terraform, Ansible y GitOps, con las horas incluidas en tu abonamiento.

Habla con un ingenieroVer abonamientos

Guías para empresas en España