Skip to main content
Uma implantação autônoma do Fetcher são dois serviços e quatro dependências. Esta página cobre o que cada dependência faz, como dimensionar o Worker e o que interrompe um serviço na inicialização. Se você só precisa de extração dentro de uma aplicação Go, não implanta nada disso. Veja Embarcando o Engine.

​
O que você implanta

​
MongoDB

Os dois serviços conectam à mesma implantação de MongoDB. O Manager grava registros de conexão e de job, e o Worker atualiza o estado do job. Em modo multi-tenant, cada tenant recebe o próprio banco, resolvido a partir das claims do JWT na requisição. Esse caminho falha de forma fechada: uma requisição que carrega uma identidade de tenant sem banco de tenant retorna um erro em vez de tocar o banco compartilhado.

​
RabbitMQ

O Fetcher usa três exchanges e quatro filas. A stack local que acompanha o repositório os declara para você. No seu próprio ambiente, declare-os antes de os serviços subirem.

​
A dead-letter queue

A fila de trabalho carrega x-dead-letter-exchange: fetcher.dlx e a routing key fetcher.dlq.key. Uma mensagem que o Worker rejeita cai em fetcher.dlq. Essa fila guarda mensagens por 7 dias e limita em 10.000 mensagens na configuração que acompanha o repositório. Monitore a dead-letter queue. Uma mensagem ali é um job que o Worker não conseguiu processar.

​
Eventos de job

O Worker publica job.completed e job.failed para todo job terminal. As duas rotas são obrigatórias, então uma falha de entrega não é silenciosa. Consumidores ligam-se às duas filas acima, ou ligam as próprias.

​
Object storage

O Worker grava cada resultado armazenado em object storage compatível com S3, pelo protocolo S3 da AWS. AWS S3, MinIO e SeaweedFS funcionam. Alcance o SeaweedFS pelo gateway S3 dele, e não pela API nativa de filer. Duas configurações decidem a postura da conexão:
  • O esquema em OBJECT_STORAGE_ENDPOINT controla o TLS. Use https:// fora do desenvolvimento local.
  • OBJECT_STORAGE_USE_PATH_STYLE=true é o que MinIO e SeaweedFS esperam.

​
Retenção de resultados

Defina a retenção no bucket, com a política de ciclo de vida do próprio object storage. Uma regra de ciclo de vida S3 sobre OBJECT_STORAGE_KEY_PREFIX expira os resultados depois da janela que a sua política de retenção exige. Dê ao Fetcher um bucket próprio ou um prefixo próprio, para que a regra se aplique aos resultados de extração e a mais nada. O Fetcher criptografa todo resultado armazenado antes de ele chegar ao bucket. Veja Segurança.

​
Valkey ou Redis

O Manager usa Valkey ou Redis para duas coisas. Ele guarda em cache os esquemas de fonte de dados descobertos, e limita a taxa do teste de conexão. A variável SCHEMA_CACHE_TTL_SECONDS define a vida do cache, e o padrão dela é 5 minutos. O cache de esquema cai para a memória do processo quando o Redis está inacessível. O Manager continua atendendo. A sonda de prontidão dele reporta o estado do Redis em separado, então o fallback continua visível. O Worker não usa o cache de esquema.

​
Concorrência e autoescala do Worker

RABBITMQ_NUMBERS_OF_WORKERS define quantos jobs um processo Worker roda em paralelo. O padrão é 5. Dimensione contra as suas fontes de dados, e não contra o Worker. Cada job paralelo abre conexões com os bancos que lê. Todo pool de fonte de dados relacional limita em 25 conexões abertas e 10 ociosas, e o MongoDB limita em 100. Dentro de uma extração, o Engine roda no máximo 4 passos de fonte de dados por vez. Para escala horizontal, adicione réplicas do Worker e comande-as pela profundidade da fila de trabalho de extração. A stack local que acompanha o repositório roda o operador KEDA (2.16.0) contra essa fila, então o mesmo gatilho vale no Kubernetes. Toda extração também carrega limites fixos do Engine. Eles são 10 fontes de dados, 20 tabelas por fonte de dados e 50 campos por tabela. Uma execução também para em um tempo limite de 5 minutos ou em um resultado serializado de 256 MiB. Uma requisição pode baixar qualquer um deles, e nenhuma requisição pode elevá-los.

​
Modo de implantação e TLS

DEPLOYMENT_MODE declara o sabor da implantação: saas, byoc ou local. Ele etiqueta a resposta de /readyz e, em saas, exige TLS.
O modo SaaS exige TLS em toda dependência de plataforma. Defina DEPLOYMENT_MODE=saas e uma URL em texto claro de MongoDB, Redis, RabbitMQ, S3 ou Tenant Manager interrompe o serviço. A parada ocorre antes de qualquer conexão abrir, e o erro nomeia a regra. As fontes de dados dos seus próprios tenants ficam fora do escopo dessa checagem.
Deixe ALLOW_INSECURE_TLS sem definir em produção. Ela permite conexões em texto claro com MongoDB, Redis, PostgreSQL e RabbitMQ, e o ambiente local que acompanha o repositório é o único lugar para ela.

​
Checagens de inicialização

O Fetcher falha de forma fechada. Cada checagem abaixo interrompe o processo antes de ele atender tráfego.
Uma dependência fora do ar no boot não produz um pod quebrado em silêncio. O /health retorna 503 até a autossondagem de inicialização passar. O kubelet então reinicia o pod, em vez de mandar tráfego para ele.

​
Atualizações contínuas

Em SIGTERM, os dois serviços entram em drenagem. O /readyz responde 503 por READYZ_DRAIN_DELAY_SEC segundos, 12 por padrão, antes de as conexões serem derrubadas. O Kubernetes remove o pod dos endpoints do Service enquanto ele ainda atende o trabalho em voo. Defina o período de graça de término acima da janela de drenagem. Veja Observabilidade para o que as sondas reportam durante uma drenagem.

​
Próximos passos

Configuração

Cada variável de ambiente, por componente.

Segurança

Chaves, assinatura, criptografia em repouso e validação de host.

Observabilidade

Sondas, comportamento de drenagem, métricas e tracing.

Jobs de extração

Ciclo de vida do job, estados terminais e eventos.