Esta página documenta el despliegue de BuenOrigen Backend en una máquina virtual de Oracle Cloud, incluyendo el acceso al servidor, la ejecución de la aplicación, la configuración de red y las comprobaciones realizadas para verificar su disponibilidad.

La construcción de imágenes y la ejecución de contenedores se describen en Docker.

Despliegue operativo y acceso a Swagger verificado.

Se dispone de una máquina virtual Ubuntu en Oracle Cloud donde se ejecuta BuenOrigen Backend mediante contenedores Docker.

Durante las pruebas se verificó que:

• El repositorio puede actualizarse desde GitHub.
• La imagen Docker de QA puede construirse en la VM.
• El contenedor de QA inicia correctamente.
• Swagger responde con HTTP 200 OK desde la propia VM.
• Swagger es accesible desde un navegador después de habilitar el puerto correspondiente en las reglas de ingreso de Oracle Cloud.

Estas comprobaciones validan el inicio y la disponibilidad de la documentación de la API. Las pruebas funcionales completas de los endpoints y sus reglas de negocio deben documentarse por separado.

La dirección IP pública y los datos de acceso deben consultarse en la configuración vigente de Oracle Cloud. No se incluyen credenciales ni claves privadas en esta documentación.

Durante las pruebas se identificaron los siguientes contenedores:

La versión de QA se construyó desde la rama qa, sincronizada con origin/qa. La revisión utilizada incorporaba los archivos Dockerfile y .dockerignore.

Los contenedores anteriores se mantuvieron en ejecución durante las pruebas de QA.

Importante: la etiqueta de una imagen no identifica por sí sola el commit exacto del código. Para una entrega reproducible se recomienda registrar el SHA del commit desplegado y asociarlo a la imagen correspondiente.

La conexión a la máquina virtual se realiza mediante SSH utilizando la dirección y la clave configuradas en Oracle Cloud.

Una vez conectado, se utiliza el usuario autorizado para administrar los contenedores de la aplicación.

Para acceder al directorio del proyecto:

cd ~/proyectos/grupo-2-backend

Para revisar la rama activa:

git branch --show-current

Para comprobar el estado del repositorio:

git status

Antes de actualizar el código, se debe comprobar que no existan modificaciones locales que puedan perderse.

Para obtener las referencias más recientes de GitHub:

git fetch origin

Para comprobar las ramas disponibles:

git branch -a

Durante las pruebas, la rama qa se actualizó mediante:

git switch qa
git pull origin qa

Se verificó que la rama local quedara sincronizada con origin/qa y que el árbol de trabajo estuviera limpio.

Estos comandos describen el procedimiento utilizado para probar QA. La actualización de la versión estable debe seguir el flujo de ramas y aprobaciones establecido por el equipo en Flujo de Git.

Para consultar los contenedores en ejecución:

docker ps

Para incluir también los contenedores detenidos:

docker ps -a

Para consultar los registros de un contenedor:

docker logs buenorigen-qa

Para comprobar la disponibilidad de Swagger desde el propio servidor:

curl -i http://localhost:3003/api

Resultado observado: HTTP/1.1 200 OK.

La respuesta contenía el HTML de Swagger UI, confirmando que la aplicación atendía la solicitud HTTP desde la VM.

Durante la validación de QA se utilizó la siguiente dirección:

http://159.112.150.143:3003/api

El acceso externo funcionó después de habilitar el puerto 3003 en las reglas de ingreso de Oracle Cloud.

La dirección IP corresponde al entorno de prueba utilizado durante la validación. Debe verificarse en Oracle Cloud antes de reutilizarla.

La configuración de red permite alcanzar el servicio, pero no sustituye las pruebas funcionales de los endpoints documentados en Endpoints.

La VM utiliza reglas de ingreso de Oracle Cloud para controlar las conexiones externas.

Durante las pruebas se habilitaron los puertos utilizados por los contenedores:

• 3001: servicio existente.
• 3002: contenedor de prueba anterior.
• 3003: contenedor de QA.

Los puertos del host se redirigen al puerto 3000 de cada contenedor.

Antes de mantener un puerto accesible públicamente, se debe evaluar si corresponde restringir las direcciones de origen y verificar los controles de autenticación y autorización de la API.

No se deben publicar contraseñas, tokens, claves privadas ni archivos .env en la Wiki.

El acceso a Swagger por HTTP confirma su disponibilidad, pero no acredita que la comunicación esté cifrada mediante HTTPS.

Si la aplicación no responde, se recomienda comprobar en este orden:

1. Estado del contenedor mediante docker ps -a.
2. Logs mediante docker logs <nombre-del-contenedor>.
3. Respuesta HTTP desde la VM mediante curl.
4. Publicación del puerto en el contenedor.
5. Reglas de ingreso de Oracle Cloud.

Si Swagger responde desde la VM pero no desde el navegador externo, se debe revisar la configuración de red antes de reconstruir o reiniciar la aplicación.

Los contenedores existentes deben conservarse hasta comprobar que la versión sustituta funciona correctamente.

Para completar la documentación del despliegue se debe:

• Probar los endpoints y las operaciones de negocio relevantes.
• Confirmar las variables de entorno requeridas y cómo se inyectan en el contenedor.
• Registrar el SHA del commit correspondiente a cada versión desplegada.
• Documentar el procedimiento de actualización y reversión de la versión estable.
• Confirmar la estrategia de acceso seguro y transporte HTTPS, si corresponde.
• Verificar que el procedimiento sea reproducible desde una versión limpia del repositorio.

El despliegue podrá considerarse completamente documentado cuando exista un procedimiento reproducible, se identifique la versión desplegada, se hayan registrado las verificaciones funcionales necesarias y se describan los mecanismos de configuración y recuperación efectivamente disponibles.

El cierre debe quedar asociado al issue y al PR correspondientes, conforme a Flujo de Git.

• Instalación y Configuración Local
• Docker
• Flujo de Git
• Endpoints
• OpenAPI y Swagger