88 lines
3.5 KiB
Markdown
88 lines
3.5 KiB
Markdown
# Dudas sobre despliegue de webfetch en VPS2
|
|
|
|
**Proyecto:** Workspace de tools IA para empresas
|
|
**Modulo:** RAG
|
|
**Contexto:** Preparacion del despliegue de `RAG` en `VPS2` dentro de EasyPanel
|
|
**Objetivo:** Aclarar exactamente como fue montado `webfetch` para reutilizar el patron correcto en `ia_servicios`
|
|
|
|
---
|
|
|
|
## Instruccion
|
|
|
|
Este documento esta pensado para que otro agente o compañero rellene la informacion faltante sobre el despliegue real de `webfetch` en `VPS2`.
|
|
|
|
La idea es reducir incertidumbre antes de montar `RAG` en EasyPanel siguiendo el mismo patron operativo.
|
|
|
|
---
|
|
|
|
## Preguntas a responder
|
|
|
|
1. `webfetch` se creo desde imagen ya construida o desde codigo fuente con build en EasyPanel?
|
|
|
|
Respuesta: Se construyo como imagen local en el VPS. EasyPanel no genero la imagen.
|
|
|
|
2. Si se uso imagen ya construida, donde esta alojada?
|
|
|
|
Respuesta: La imagen quedo alojada localmente en Docker del VPS con la etiqueta `webfetch:latest`.
|
|
|
|
3. Si se hizo build en EasyPanel, desde donde se obtuvo el codigo?
|
|
- repositorio git
|
|
- zip
|
|
- subida manual
|
|
- otra via
|
|
|
|
Respuesta: No se hizo build en EasyPanel. Se copiaron archivos al VPS y se construyo alli manualmente.
|
|
|
|
4. Existe algun `Dockerfile` o configuracion especial usada para `webfetch`?
|
|
|
|
Respuesta: Si. Se uso un `Dockerfile` simple basado en `node:22-alpine`, copiando `package.json`, `package-lock.json`, `server.js` y `synonym-provider.js`, exponiendo el puerto `80` y arrancando con `npm start`.
|
|
|
|
5. Se uso algun dominio o ruta especial en EasyPanel aparte del dominio generado automaticamente?
|
|
|
|
Respuesta:
|
|
|
|
6. `webfetch` depende de algun servicio interno del proyecto `ia_servicios` o funciona completamente aislado?
|
|
|
|
Respuesta:
|
|
|
|
7. Hay variables de entorno importantes aparte de `WEBFETCH_API_KEY` y `PORT`?
|
|
|
|
Respuesta: Tambien aparecen metadatos de despliegue como `DEPLOY_TIMESTAMP` y `GIT_SHA`, pero la variable funcional importante recuperada fue `WEBFETCH_API_KEY`.
|
|
|
|
8. Hay algun volumen, bind mount o ruta persistente asociada a `webfetch` aunque no aparezca claramente en la inspeccion inicial?
|
|
|
|
Respuesta: En la inspeccion realizada no aparece volumen persistente visible para `webfetch`.
|
|
|
|
9. El servicio tiene alguna configuracion especial de EasyPanel respecto a:
|
|
- healthcheck
|
|
- restart policy
|
|
- resources
|
|
- command
|
|
- entrypoint
|
|
- publish settings
|
|
|
|
Respuesta: Se observo `restart policy` on-failure y despliegue Swarm simple en las redes `easypanel` y `easypanel-ia_servicios`. No se confirmo healthcheck personalizado ni recursos especiales.
|
|
|
|
10. Hay alguna razon por la que `webfetch` se monto asi y no de otra manera?
|
|
|
|
Respuesta: La razon practica fue rapidez y control local del build. Como contrapartida, EasyPanel no puede redeplegar correctamente si intenta hacer pull de una imagen que solo existe en el VPS.
|
|
|
|
11. Si hoy hubiera que redeplegar `webfetch` desde cero en `VPS2`, cuales serian los pasos exactos?
|
|
|
|
Respuesta:
|
|
1. Preparar un directorio temporal en el VPS.
|
|
2. Copiar los archivos necesarios del servicio.
|
|
3. Ejecutar `docker build -t webfetch:latest .`.
|
|
4. Ejecutar `docker service update --force ia_servicios_webfetch`.
|
|
5. Ajustar variables si hace falta, por ejemplo `docker service update --env-add WEBFETCH_API_KEY=... ia_servicios_webfetch`.
|
|
|
|
12. Que aspectos de ese despliegue deberian reutilizarse tal cual para `RAG` y cuales no?
|
|
|
|
Respuesta:
|
|
Reutilizar:
|
|
- build local en VPS como via rapida inicial
|
|
- redes del proyecto `ia_servicios`
|
|
- variables por entorno
|
|
|
|
No reutilizar necesariamente como solucion final:
|
|
- depender de imagen solo local si se quiere redeploy limpio desde EasyPanel
|