RUN_MODE seleciona suas superfícies ativas: o gerenciador de API, o worker de relatórios, ou ambos. Você define essas variáveis no momento do deploy, por meio de valores do Helm, Docker Compose ou do ambiente do seu orquestrador. Variáveis marcadas como obrigatórias fazem o servidor falhar na inicialização se não forem definidas.
Para os blocos de configuração que todo produto Lerian compartilha (postura de TLS, OpenTelemetry, autenticação do Access Manager, multi-tenancy, service discovery e event streaming), veja a referência de configuração BYOC. Esta página foca no que é específico do Reporter.
Modo de execução e portas
RUN_MODE decide quais superfícies o processo atende. Rode a API e o worker como um único processo (all) para deploys pequenos, ou separe-os em deployables distintos (api e worker) para escalar a geração de relatórios de forma independente. Veja a referência de health e readiness para o contrato de probes.
Deploy e TLS
CORS e proxies
Paginação da API
Previews de template
Banco de dados (MongoDB)
Armazena metadados de relatórios, templates e histórico de execuções.Message broker (RabbitMQ)
Transporta a fila de comandos de geração de relatório entre a API e o worker.Armazenamento de objetos (compatível com S3)
Onde os relatórios renderizados são armazenados. Funciona com qualquer endpoint compatível com S3.Cache (Redis / Valkey)
Renderização de PDF (worker)
Datasources de relatório
Os relatórios leem de datasources PostgreSQL e MongoDB no registro persistido. Crie e gerencie entradas comuns pela API de data source. O bloco de ambiente abaixo é um caminho opcional de bootstrap single-tenant. Deploys multi-tenant criam datasources comuns por tenant pela API.DATASOURCE_{NAME}_CONFIG_NAME faz um bloco de seed de ambiente existir. O Reporter varre chaves que correspondem a DATASOURCE_*_CONFIG_NAME. O prefixo conta tanto quanto o sufixo, então uma chave que apenas termina em _CONFIG_NAME não declara nada. Na inicialização do Manager, um bloco completo semeia seu configName apenas quando nenhuma entrada no registro, incluindo uma com soft delete, já usa esse nome. O valor é o nome que seus templates usam para endereçar a fonte.
Dentro de um bloco, as variáveis marcadas como obrigatórias são as que o Reporter precisa antes de ler o bloco.
Um bloco completo de seed por datasource segue abaixo. Defina o
DATASOURCE_CRED_ENC_KEY global separadamente, como descrito acima. Recomendamos usar o mesmo nome para CONFIG_NAME e {NAME}, com o segmento da variável de ambiente em maiúsculas (por exemplo, ONBOARDING para CONFIG_NAME=onboarding). Isso mantém a chave de schema intuitiva, porque SCHEMAS usa o valor de CONFIG_NAME como chave, enquanto todo o resto dos campos usa {NAME}:
{{ onboarding.accounts }}. Use a API para adicionar ou atualizar uma datasource comum. No modo single-tenant, um bloco de ambiente apenas semeia uma entrada previamente ausente. Ele nunca sobrescreve uma entrada gerenciada pela API nem restaura uma com soft delete.
Datasource CRM reservada
plugin_crm é a datasource CRM reservada, gerenciada por ambiente. Não a crie nem faça PATCH nela pela API comum de data source: o Reporter rejeita esse caminho com RPT-0073. Um template de CRM deve usar exatamente o nome de config plugin_crm e um bloco MongoDB completo:
DATASOURCE_CRM_PASSWORD, CRYPTO_HASH_SECRET_KEY_CRM e CRYPTO_ENCRYPT_SECRET_KEY_CRM no seu secret store. Os valores de criptografia do CRM devem ser as mesmas chaves já usadas pelo CRM; não gere chaves substitutas para o Reporter. Mantenha DATASOURCE_CRED_ENC_KEY estável também: alterá-la impede que o Reporter descriptografe as credenciais de datasource armazenadas.
Em um deploy single-tenant, o Manager usa esse bloco na inicialização para semear plugin_crm e preencher um metadata.midazOrganizationId ausente ou vazio. Um ID de organização persistido e não vazio prevalece e não é sobrescrito pelo ambiente. Se estiver errado, não use a API comum para alterá-lo: pare e use o caminho de recuperação de engenharia aprovado. Em um deploy multi-tenant, o Manager pula esse seed de ambiente, então esse bloco não é um mecanismo de provisionamento multi-tenant.
Para o posicionamento no Helm e um exemplo completo de values, veja Reporter via Helm. Para templates que usam plugin_crm, valide o caminho completo: importe ou salve o template, gere um relatório, confirme que os campos de CRM descriptografam e confirme que os registros ficam com escopo restrito à organização Midaz pretendida.
Backbone de configuração compartilhado
Os blocos a seguir são idênticos entre os produtos Lerian. A referência de configuração BYOC os documenta por completo. Ficam desabilitados por padrão.- Autenticação do Access Manager:
PLUGIN_AUTH_ENABLED,PLUGIN_AUTH_ADDRESS. Habilite em produção. - Multi-tenancy:
MULTI_TENANT_*, além deRABBITMQ_MULTI_TENANT_SYNC_INTERVALeRABBITMQ_MULTI_TENANT_DISCOVERY_TIMEOUT. Desabilitado por padrão. - Service discovery:
SD_*(Consul, e o Reporter também aceita os aliases legadosSD_ADVERTISE_*/CONSUL_ADDR). Desabilitado por padrão. - Event streaming:
STREAMING_ENABLED,STREAMING_BROKERS,STREAMING_CLOUDEVENTS_SOURCE, além deRABBITMQ_REPORT_EVENTS_EXCHANGEpara a exchange de eventos. Desabilitado por padrão. - OpenTelemetry:
ENABLE_TELEMETRY,OTEL_*,OTEL_INSECURE_EXPORTER. A telemetria é OTLP push.

