Skip to main content
Un despliegue independiente de Fetcher son dos servicios y cuatro dependencias. Esta página cubre qué hace cada dependencia, cómo dimensionar el Worker y qué detiene un servicio al arrancar. Si solo necesitas extracción dentro de una aplicación Go, no despliegas nada de esto. Consulta Embeber el Engine.

​
Lo que despliegas

​
MongoDB

Los dos servicios se conectan al mismo despliegue de MongoDB. El Manager escribe registros de conexión y de job, y el Worker actualiza el estado de los jobs. En modo multi-tenant, cada tenant recibe su propia base de datos, resuelta a partir de los claims del JWT de la petición. Ese camino falla cerrado: una petición que lleva una identidad de tenant sin base de datos de tenant devuelve un error en lugar de tocar la base de datos compartida.

​
RabbitMQ

Fetcher usa tres exchanges y cuatro colas. El stack local incluido los declara por ti. En tu propio entorno, decláralos antes de que arranquen los servicios.

​
La cola de mensajes muertos

La cola de trabajo lleva x-dead-letter-exchange: fetcher.dlx y la routing key fetcher.dlq.key. Un mensaje que el Worker rechaza cae en fetcher.dlq. Esa cola retiene mensajes durante 7 días y tiene un tope de 10.000 mensajes en la configuración incluida. Vigila la cola de mensajes muertos. Un mensaje ahí es un job que el Worker no pudo procesar.

​
Eventos de job

El Worker publica job.completed y job.failed por cada job terminal. Las dos rutas son obligatorias, así que un fallo de entrega no pasa en silencio. Los consumidores se ligan a las dos colas de arriba, o ligan las suyas.

​
Almacenamiento de objetos

El Worker escribe cada resultado almacenado en almacenamiento de objetos compatible con S3, a través del protocolo de AWS S3. AWS S3, MinIO y SeaweedFS funcionan. Alcanza SeaweedFS por su gateway S3, no por su API nativa de filer. Dos ajustes deciden la postura de la conexión:
  • El esquema de OBJECT_STORAGE_ENDPOINT controla TLS. Usa https:// fuera del desarrollo local.
  • OBJECT_STORAGE_USE_PATH_STYLE=true es lo que esperan MinIO y SeaweedFS.

​
Retención de resultados

Define la retención en el bucket, con la política de ciclo de vida del propio almacén de objetos. Una regla de ciclo de vida de S3 sobre OBJECT_STORAGE_KEY_PREFIX expira los resultados después de la ventana que exige tu política de retención. Dale a Fetcher su propio bucket o su propio prefijo, para que la regla aplique a los resultados de extracción y a nada más. Fetcher cifra cada resultado almacenado antes de que llegue al bucket. Consulta Seguridad.

​
Valkey o Redis

El Manager usa Valkey o Redis para dos cosas. Cachea los esquemas de datasource descubiertos, y limita la tasa de la prueba de conexión. La variable SCHEMA_CACHE_TTL_SECONDS define la vida de la caché, y su valor por defecto son 5 minutos. La caché de esquemas cae a la memoria del proceso cuando Redis está inalcanzable. El Manager sigue sirviendo. Su sonda de readiness reporta el estado de Redis por separado, así que el respaldo queda visible. El Worker no usa la caché de esquemas.

​
Concurrencia del Worker y autoescalado

RABBITMQ_NUMBERS_OF_WORKERS define cuántos jobs corre en paralelo un proceso Worker. Su valor por defecto es 5. Dimensiónalo contra tus datasources, no contra el Worker. Cada job paralelo abre conexiones a las bases de datos que lee. Cada pool de datasource relacional tiene un tope de 25 conexiones abiertas y 10 inactivas, y MongoDB llega a 100. Dentro de una extracción, el engine corre como máximo 4 pasos de datasource a la vez. Para escalar horizontalmente, agrega réplicas del Worker y guíalas por la profundidad de la cola de trabajo de extracción. El stack local incluido corre el operador KEDA (2.16.0) contra esa cola, así que el mismo disparador se traslada a Kubernetes. Cada extracción lleva además límites fijos del engine. Son 10 datasources, 20 tablas por datasource y 50 campos por tabla. Una ejecución también se detiene ante un timeout de 5 minutos o un resultado serializado de 256 MiB. Una petición puede bajar cualquiera de ellos, y ninguna petición puede subirlos.

​
Modo de despliegue y TLS

DEPLOYMENT_MODE declara el sabor del despliegue: saas, byoc o local. Etiqueta la respuesta de /readyz, y en saas exige TLS.
El modo SaaS exige TLS en todas las dependencias de plataforma. Define DEPLOYMENT_MODE=saas y una URL en texto plano de MongoDB, Redis, RabbitMQ, S3 o Tenant Manager detiene el servicio. Se detiene antes de abrir cualquier conexión, y el error nombra la regla. Los datasources de tus propios tenants quedan fuera del alcance de esta verificación.
Deja ALLOW_INSECURE_TLS sin definir en producción. Permite conexiones en texto plano a MongoDB, Redis, PostgreSQL y RabbitMQ, y el entorno local incluido es el único lugar para ella.

​
Verificaciones de arranque

Fetcher falla cerrado. Cada verificación de abajo detiene el proceso antes de que sirva tráfico.
Una dependencia caída en el arranque no produce un pod roto en silencio. /health devuelve 503 hasta que la autosonda de arranque tiene éxito. El kubelet entonces reinicia el pod en lugar de enviarle tráfico.

​
Actualizaciones progresivas

Ante SIGTERM, los dos servicios entran en drenaje. /readyz responde 503 durante READYZ_DRAIN_DELAY_SEC segundos, con un valor por defecto de 12, antes de que se cierren las conexiones. Kubernetes saca el pod de los endpoints del Service mientras este todavía atiende el trabajo en vuelo. Define tu periodo de gracia de terminación por encima de la ventana de drenaje. Consulta Observabilidad para ver qué reportan las sondas durante un drenaje.

​
Próximos pasos

Configuración

Todas las variables de entorno, por componente.

Seguridad

Claves, firma, cifrado en reposo y validación de host.

Observabilidad

Sondas, comportamiento de drenaje, métricas y trazas.

Jobs de extracción

Ciclo de vida del job, estados terminales y eventos.