Aprende a Montar un pipeline CI/CD simple para desplegar por SSH con rollback

Copiar archivos manualmente a un servidor puede funcionar al principio, pero no deja trazabilidad ni ofrece una ruta clara para volver a una versión estable si algo falla.

Esta guía propone un enfoque conservador para montar un pipeline CI/CD simple por SSH: cambios verificables, comandos claros, advertencias antes de acciones sensibles y una validación final que ayude a detectar errores antes de mover tráfico o afectar datos reales.

La idea es construir una base práctica que puedas adaptar a un Cloud Server de DonWeb Cloud, una instancia Linux propia o un entorno de laboratorio.

Qué vas a construir

Vas a preparar una implementación base para desplegar una aplicación en un servidor cloud usando SSH, Git y Docker Compose.

El resultado esperado es una configuración documentada, con comandos de prueba y recomendaciones para pasar de laboratorio a producción con más seguridad.

El flujo cubre:

• Etiquetado de versiones.
• Actualización del código en el servidor.
• Despliegue con Docker Compose.
• Validación mediante healthcheck.
• Revisión de logs.
• Criterios básicos de rollback.

Cuándo conviene usar este enfoque

Este enfoque es útil cuando necesitas una solución operativa y repetible, no solo una explicación conceptual.

También conviene cuando:

• El servicio va a vivir en un servidor cloud y necesita seguridad básica desde el primer despliegue.
• Necesitas dejar evidencia de configuración, pruebas y criterios de mantenimiento.
• Quieres reducir configuraciones manuales difíciles de auditar.
• Buscas una forma simple de desplegar sin incorporar todavía una plataforma CI/CD más compleja.

Requisitos previos

Antes de empezar, asegúrate de contar con:

• Cloud Server o servidor Ubuntu/Debian actualizado.
• Usuario con permisos sudo o rol equivalente.
• Acceso SSH o consola segura.
• Backup previo si el servidor ya tiene datos o tráfico real.
• Dominio o subdominio si vas a publicar un servicio web.
• Credenciales con mínimo privilegio si se usan comandos AWS.
• Ventana de mantenimiento para cambios de red, firewall, runtime, base de datos o credenciales.

Arquitectura del flujo de trabajo

El flujo recomendado es:

1. Preparar el entorno.
2. Versionar el estado que se va a desplegar.
3. Actualizar el código en el servidor.
4. Levantar o reconstruir los servicios.
5. Validar el estado de la aplicación.
6. Revisar logs.
7. Conservar una ruta de rollback.

Evita cambiar varias capas a la vez. Si algo falla, una modificación incremental es mucho más fácil de revertir.

Comandos principales

Estos son los comandos base del flujo:

git tag release-$(date +%Y%m%d)

ssh deploy@servidor 'cd /srv/app && git pull --ff-only'

ssh deploy@servidor 'docker compose up -d --build'

ssh deploy@servidor 'curl -f http://localhost/health'

ssh deploy@servidor 'docker compose logs --tail=80'

Configuración base recomendada

Rollback: conservar imagen anterior
Secretos: variables protegidas
Validacion: healthcheck antes de cambiar DNS

Esta configuración resume tres criterios importantes:

• Conservar una versión anterior para poder volver atrás.
• Proteger secretos y variables sensibles.
• Validar la aplicación antes de mover tráfico o cambiar DNS.

Paso 1: Preparar la versión del despliegue

Antes de ejecutar este paso, confirma que estás trabajando sobre el repositorio correcto y que el estado actual corresponde a la versión que quieres desplegar.

git tag release-$(date +%Y%m%d)

Este tag permite identificar una versión del código antes del despliegue. Si necesitas volver atrás, tener una referencia clara reduce el margen de error.

Verifica la salida antes de continuar. Si el cambio afecta infraestructura con tráfico real, conserva una ruta de rollback y asegúrate de tener un backup actualizado.

Paso 2: Actualizar el código en el servidor

Conéctate al servidor usando el usuario de despliegue y actualiza el código de la aplicación.

ssh deploy@servidor 'cd /srv/app && git pull --ff-only'

El parámetro --ff-only ayuda a evitar merges inesperados durante el despliegue. Si el servidor tiene cambios locales no previstos, el comando debería fallar en lugar de modificar el estado del repositorio de forma silenciosa.

Antes de repetir el comando con más privilegios, revisa permisos, rama activa y estado del repositorio.

Paso 3: Levantar o reconstruir los servicios

Una vez actualizado el código, reconstruye y levanta los servicios con Docker Compose.

ssh deploy@servidor 'docker compose up -d --build'

Este comando aplica los cambios y deja los servicios corriendo en segundo plano.

Si el servicio ya recibe tráfico, ejecútalo dentro de una ventana de mantenimiento. También conviene conservar la imagen anterior o el manifiesto previo para poder revertir si la nueva versión falla.

Paso 4: Validar que la aplicación responde

Después del despliegue, valida el estado de la aplicación desde el propio servidor.

ssh deploy@servidor 'curl -f http://localhost/health'

El endpoint /health debe responder correctamente antes de considerar exitoso el despliegue.

Si esta validación falla, no avances con cambios de DNS, balanceadores o tráfico externo. Primero revisa logs, variables de entorno, dependencias y conectividad interna.

Paso 5: Revisar logs y dejar evidencia

Consulta los logs recientes para confirmar que no haya errores visibles durante el arranque.

ssh deploy@servidor 'docker compose logs --tail=80'

Esta revisión ayuda a detectar problemas que no siempre aparecen en el healthcheck: fallos intermitentes, advertencias de configuración, problemas de conexión con base de datos o errores de permisos.

Deja documentado qué versión se desplegó, quién ejecutó el cambio, qué validaciones se realizaron y cuál es el procedimiento de rollback.

Rollback básico

Un rollback no debería improvisarse durante un incidente. Antes de desplegar, define cómo volver a la versión anterior.

Como mínimo, conserva:

• Tag o referencia de la versión previa.
• Imagen anterior si usas contenedores.
• Backup o snapshot si el cambio toca datos.
• Configuración anterior si modificas variables, firewall, runtime o manifiestos.

Si el despliegue falla, vuelve a la versión estable conocida y valida nuevamente el endpoint de salud antes de restaurar tráfico.

Problemas frecuentes

Permisos insuficientes

Revisa el usuario, el grupo, el rol IAM o el contexto de Kubernetes antes de repetir comandos con más privilegios.

Puerto ocupado o cerrado

Valida con ss -tulpn, reglas de firewall y security groups antes de asumir que la aplicación falló.

Variables de entorno ausentes

Confirma el archivo .env, los secretos del orquestador y que no se impriman credenciales en logs.

El servicio inicia pero no responde

Revisa healthchecks, logs, dependencias de base de datos y resolución DNS.

Rollback no definido

Conserva una versión anterior, snapshot, backup o manifiesto previo antes de aplicar cambios sensibles.

Buenas prácticas para producción

Para pasar este flujo a producción, aplica estas prácticas:

• Usa mínimo privilegio para usuarios, roles, contenedores y reglas de red.
• Versiona configuraciones sin incluir secretos.
• Prueba restauraciones de backup, no solo la creación del archivo.
• Activa logs y alertas antes de necesitar diagnosticar un incidente.
• Documenta quién puede ejecutar cambios y qué evidencia debe quedar.
• Revisa periódicamente dependencias, imágenes y paquetes del sistema.
• Evita modificar varias capas críticas en un mismo despliegue.

Advertencias de seguridad

No ejecutes estos pasos contra infraestructura de terceros ni contra producción sin autorización.

Los comandos y recomendaciones de seguridad están orientados a defensa, mitigación y auditoría autorizada. Si detectas credenciales expuestas, primero rótalas y luego investiga el alcance.

Cierre

Un pipeline CI/CD por SSH no reemplaza una plataforma de despliegue completa, pero puede ser una base sólida para ordenar operaciones pequeñas o medianas.

La clave está en que cada despliegue tenga una versión identificable, una validación clara, logs revisables y una ruta de rollback definida antes de tocar tráfico o datos reales.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting