Infraestructura como código, GitOps y CI/CD para desplegar sin miedo
Que la infraestructura se pueda reconstruir desde el repositorio y que desplegar sea un merge, no un ritual de los viernes.
Herramientas habituales
- Gitea
- Laravel
- SonarQube
- Terraform
- Ansible
- Argo CD
- Flux
- GitLab
En resumen
La infraestructura como código consiste en describir servidores, redes, permisos y servicios en archivos versionados en lugar de configurarlos a mano. Pasamos vuestra infraestructura a Terraform y Ansible, desplegamos con GitOps desde el repositorio con Argo CD o Flux y montamos pipelines de CI/CD que construyen, prueban y despliegan. Cada cambio se revisa y se puede deshacer.
- Idiomas
- Español, catalán o inglés
- Respuesta
- El siguiente día hábil, en horario laboral
- Método
- En vuestra cuenta y vuestro repositorio, en código y documentado
Qué incluye
- Inventario de la infraestructura actual, incluida la creada a mano en la consola.
- Terraform por módulos, con el estado remoto protegido y bloqueado.
- Ansible para la configuración de los servidores que no son efímeros.
- GitOps con Argo CD o Flux: lo que hay en el clúster sale del repositorio.
- Pipelines de CI/CD en GitLab CI o GitHub Actions con pruebas y despliegue automático.
- Secretos fuera del código, con HashiCorp Vault o el gestor de vuestro proveedor.
- Procedimiento de vuelta atrás probado.
- README de cómo desplegar, cambiar y reconstruir cada entorno.
¿Qué problemas resuelve?
La infraestructura creada a mano funciona hasta que hay que repetirla, auditarla o arreglarla deprisa. Estos son los síntomas que solemos encontrar al llegar:
- Se despliega por SSH, con comandos que solo recuerda una persona.
- Producción y preproducción se parecen, pero nadie sabe en qué se diferencian.
- Hay recursos en la nube que nadie sabe para qué sirven ni si se pueden borrar.
- Las contraseñas viven en variables sueltas o en el propio repositorio.
- Volver a la versión anterior lleva horas, o directamente no se intenta.
¿Qué cambia antes y después?
El objetivo no es tener Terraform por tenerlo, sino que cada tarea habitual sea más rápida, más segura y quede registrada. Esta tabla resume el cambio en las tareas que más se repiten:
| Tarea | Antes | Después |
|---|---|---|
| Desplegar una versión | Comandos a mano por SSH | Merge en la rama principal y el pipeline despliega |
| Volver atrás | Recordar qué se cambió | Revertir el commit; GitOps restaura el estado anterior |
| Crear un entorno nuevo | Días copiando configuración | Un módulo de Terraform con otras variables |
| Saber qué hay en la nube | Revisar la consola servicio a servicio | Leer el repositorio y el estado |
| Rotar una credencial | Buscar dónde está escrita | Cambiarla en Vault; los servicios la recogen |
| Auditar un cambio | Preguntar a quien lo hizo | Historial de commits y revisiones |
¿Cómo lo hacemos sin parar nada?
Por capas y en paralelo a lo que ya funciona, para que el equipo siga desplegando mientras tanto:
Inventario
Listamos lo que hay en la cuenta, lo que se usa y lo que sobra, y lo compartimos antes de tocar nada.
Importar a Terraform
Red, permisos, bases de datos gestionadas y máquinas, módulo a módulo, hasta que el plan no propone cambios.
Pipeline
Construcción, pruebas, análisis de imágenes y despliegue automático a un entorno de pruebas.
GitOps
Argo CD o Flux toman el control del clúster; los cambios a mano dejan de ser posibles.
Secretos y traspaso
Credenciales a Vault, rotación de las expuestas y documentación de cada flujo.
¿Qué herramientas usamos?
Terraform para la infraestructura en AWS, Google Cloud, Azure, Hetzner o DigitalOcean; Ansible para servidores con estado; Helm para empaquetar servicios en Kubernetes; Argo CD o Flux para GitOps; GitLab CI o GitHub Actions para los pipelines; y HashiCorp Vault para los secretos. Si ya usáis otra herramienta que funciona, nos adaptamos a ella.
¿Qué experiencia tenemos?
Como DevOps en un SaaS B2B hemos mantenido los pipelines de CI/CD y los entornos multinube descritos en código, y como SRE en una fábrica alimentaria hemos trabajado con plataformas en las que una parada se nota en la producción. Desde la dirección técnica y de ingeniería hemos revisado y ordenado infraestructuras montadas a mano. Si después queréis que lo mantengamos nosotros, encaja con el SRE como servicio.
Preguntas frecuentes
¿Hay que parar el servicio para pasar a Terraform?
No. Importamos los recursos que ya existen en el estado de Terraform módulo a módulo y comprobamos que el plan no propone cambios antes de seguir. El servicio no se entera.
¿Argo CD o Flux?
Los dos funcionan bien. Argo CD tiene una interfaz que ayuda a los equipos que empiezan con GitOps; Flux es más ligero y encaja si todo se gestiona desde el repositorio. Lo decidimos según quién lo va a usar.
¿Trabajáis con nuestro GitHub o GitLab?
Sí. Trabajamos en vuestro repositorio, con vuestras reglas de revisión, y cada cambio va en una merge request o pull request. No usamos repositorios propios ni cuentas compartidas.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Revisado el