labadmin/proyectosacc-mirror
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
proyectosacc-mirror/docs/11-checklist-primer-deploy.md
T
Evert Daniel Romero Garrido 85297b12a2 Initial commit: Terraform infrastructure, pipelines, docs and scripts
2026-04-14 14:53:05 -06:00

6.7 KiB
Raw Permalink Blame History

11 - Checklist: Primer Deploy

Lista de verificación de todo lo que debe estar listo antes de hacer el primer despliegue de proyectosacc.

1. Infraestructura AWS

  1. La instancia EC2 T3.small con Ubuntu 22.04 está creada y encendida.
  2. La EC2 tiene un Security Group que permite:
    • Puerto 22 (SSH) desde IPs confiables.
    • Puerto 80 (HTTP) desde cualquier lugar (solo para la API).
    • Puerto 443 (HTTPS) desde cualquier lugar (solo para la API).
  3. La RDS MariaDB (db.t3.micro) está creada y accesible desde la VPC.
  4. El bucket S3 para artefactos de la API está creado y la EC2 tiene permisos para leer/escribir en él.
  5. El bucket S3 para el frontend React está creado con Static Website Hosting habilitado.
  6. El bucket S3 del frontend tiene versionamiento de objetos habilitado.
  7. La distribución CloudFront está creada, apunta al bucket S3 del frontend, tiene HTTPS y un behavior /api/* que apunta a la EC2.
  8. El registro Route 53 sacc.ccsoft.mx apunta a CloudFront (no a la IP de la EC2).
  9. El certificado ACM para sacc.ccsoft.mx está emitido, válido y adjunto a CloudFront.
  10. El bucket S3 del frontend tiene un bucket policy que permite leer objetos solo a CloudFront (OAI/OAC).

2. Servidor EC2 (configuración interna)

  1. El usuario ubuntu puede conectarse por SSH.
  2. El usuario thoth está creado con su directorio /home/thoth.
  3. El usuario osiris está creado con su directorio /home/osiris.
  4. Los directorios de despliegue existen: 
    /home/thoth/deploy/artifacts/backup
/home/thoth/deploy/artifacts/current
/home/thoth/deploy/artifacts/logs
/home/thoth/deploy/artifacts/pids
  5. Nginx está instalado, configurado como proxy inverso solo para la API (/api → localhost:8080) y corriendo.
  6. Java (openjdk-21-jdk) está instalado.
  7. AWS CLI está instalado y configurado.
  8. Los permisos de carpetas están correctos (thoth y osiris pueden acceder donde deben).

3. Llaves SSH

  1. Se generó el par de llaves SSH dedicado para proyectosacc (no se reutilizan llaves de otros proyectos).
  2. La llave privada está codificada en base64 y guardada en Bitbucket Repository Variables (PROYECTOSACC_SSH_KEY).
  3. La llave pública está en /home/thoth/.ssh/authorized_keys (inyectada vía Terraform user_data).
  4. Se generó el par de llaves SSH para que thoth clone repositorios desde Bitbucket.
  5. Las Access Keys correspondientes están configuradas en los repositorios de Bitbucket (ci-cd-commons, ci-cd-saac4).
  6. Se probó la conexión SSH desde el pipeline (o manualmente) y funciona.

4. Base de datos

  1. La base de datos RDS está accesible desde la EC2.
  2. Se creó el esquema o las tablas necesarias para la aplicación.
  3. La aplicación tiene configurada la URL de conexión a la base de datos.
  4. Las credenciales de la base de datos están guardadas de forma segura (no en el código fuente).

5. Pipeline de Bitbucket

  1. El archivo bitbucket-pipelines.yml está en la raíz del repositorio.
  2. Los 7 pasos del pipeline están configurados correctamente:
    • Paso 4 compila tanto el frontend React (npm run build) como la API backend.
    • Paso 5 sube el frontend a S3 y el .jar de la API a S3.
    • Paso 7 invalida la caché de CloudFront y reinicia la API.
  3. Las variables de entorno están creadas en Bitbucket:
    • PROYECTOSACC_SSH_KEY
    • PROYECTOSACC_SERVER_IP
    • PROYECTOSACC_SSH_PORT
    • PROYECTOSACC_SERVER_USER
    • PROYECTOSACC_TELEGRAM_BOT_TOKEN
    • PROYECTOSACC_TELEGRAM_CHAT_ID
    • AWS_ACCESS_KEY_ID
    • AWS_SECRET_ACCESS_KEY
    • CLOUDFRONT_DISTRIBUTION_ID
    • S3_FRONTEND_BUCKET
  4. Todas las variables sensibles están marcadas como Secured 🔒.
  5. El pipeline puede clonar los repositorios necesarios (ci-cd-commons, ci-cd-saac4, etc.).

6. Scripts de despliegue

  1. El script deploy-frontend-s3.sh existe y puede subir archivos a S3 + invalidar CloudFront.
  2. El script setup/deploy.sh existe en el servidor y tiene permisos de ejecución (solo para la API).
  3. El script health-check.sh existe y funciona correctamente.
  4. El script rollback.sh existe y tiene al menos un backup de prueba de la API.
  5. El script notify-telegram.sh envía mensajes de prueba exitosamente.

7. Aplicación SACC

  1. El código fuente del frontend React compila sin errores (npm run build).
  2. El código fuente de la API backend compila sin errores localmente.
  3. El pipeline puede generar el artefacto final del frontend (build/) y de la API (.jar).
  4. El artefacto de la API se puede ejecutar manualmente en la EC2.
  5. La API responde en http://localhost:8080/actuator/health cuando corre localmente en la EC2.

8. Dominio y SSL

  1. El dominio sacc.ccsoft.mx resuelve a CloudFront (verifica con dig o nslookup).
  2. CloudFront sirve el frontend React por HTTPS sin errores de certificado.
  3. Nginx en la EC2 redirige las peticiones de la API correctamente (/api → localhost:8080).
  4. El endpoint https://sacc.ccsoft.mx/api/actuator/health responde correctamente.
  5. Al entrar a https://sacc.ccsoft.mx se ve la interfaz de SACC (o al menos una página de prueba del frontend).

9. Seguridad

  1. El archivo .env (si existe) está en .gitignore.
  2. No hay contraseñas, tokens ni llaves privadas en el código del repositorio.
  3. No se usa sshpass ni acceso SSH por contraseña.
  4. El puerto SSH (22) del Security Group no está abierto a 0.0.0.0/0.
  5. La base de datos RDS no es pública (solo accesible desde la VPC).
  6. El bucket S3 del frontend NO es público directamente; solo CloudFront accede a él (OAI/OAC).
  7. Los logs sensibles no se imprimen en los archivos de configuración del pipeline.

10. Comunicación y documentación

  1. El equipo de desarrollo sabe que el primer deploy se va a realizar.
  2. Hay un canal de comunicación activo (Telegram, Slack, etc.) para alertas.
  3. Este checklist ha sido revisado por al menos una persona más.
  4. Se tiene planificado un horario de bajo tráfico para el primer deploy.

¿Listo?

Si marcaste todas las 60 casillas, estás listo para hacer el primer deploy. 🚀

Si te falta alguna, resuélvela antes de continuar. Es mejor tardar un poco más y hacerlo bien, que apurarse y dejar el servicio caído.

Anterior: 10-runbook-rollback.md

Reference in New Issue View Git Blame Copy Permalink