fix(swarm): add evo-flow, ClickHouse and RabbitMQ to the deploy stack - #163
Merged
Conversation
The Segments screen proxies /api/v1/segments through the CRM to evo-flow, but the swarm stack never declared the service — nor the four env vars the CRM client needs. Without AUTH_APIKEY_INTEGRATION_LOCAL the CRM raises EvoFlow::ConfigurationError while building the client, before any network call, so every segments endpoint answers 500. evo-flow cannot boot alone: it requires ClickHouse (STORAGE_MODE=clickhouse) and a broker (BrokerModule aborts when BROKER_TYPE is unset, even with QUEUE_MODE=direct), plus a dedicated Postgres database it creates on boot. EVO_FLOW_ALLOW_INSECURE is set because the stack runs RAILS_ENV=production over an internal http:// URL, which the client otherwise refuses. Secrets stay empty, following the template convention.
Reviewer's GuideAdds evo-flow and its required infrastructure (ClickHouse, RabbitMQ, env vars, volumes, and secrets) to the swarm stack so that /settings/segments works correctly in swarm deployments. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Consider pinning the service images (clickhouse/clickhouse-server:latest, rabbitmq:3-alpine, evoapicloud/evo-flow-community:develop) to explicit versions/tags to avoid unexpected behavior when base images are updated.
- The RABBITMQ_URL currently embeds the password as a literal placeholder string; it would be more robust to compose this from environment variables or secrets to avoid duplicating the password in multiple places and reduce the chance of configuration drift.
- The multi-line shell in evocrm_evoflow’s command (ClickHouse wait, DB create, migrations) is quite dense; consider extracting this bootstrapping logic into a script or entrypoint to make it easier to maintain and reason about failures.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider pinning the service images (clickhouse/clickhouse-server:latest, rabbitmq:3-alpine, evoapicloud/evo-flow-community:develop) to explicit versions/tags to avoid unexpected behavior when base images are updated.
- The RABBITMQ_URL currently embeds the password as a literal placeholder string; it would be more robust to compose this from environment variables or secrets to avoid duplicating the password in multiple places and reduce the chance of configuration drift.
- The multi-line shell in evocrm_evoflow’s command (ClickHouse wait, DB create, migrations) is quite dense; consider extracting this bootstrapping logic into a script or entrypoint to make it easier to maintain and reason about failures.
## Individual Comments
### Comment 1
<location path="docker-compose.swarm.yaml" line_range="614" />
<code_context>
+ - |
+ until node -e 'require("http").get("http://evocrm_clickhouse:8123/ping",r=>process.exit(r.statusCode===200?0:1)).on("error",()=>process.exit(1))'; do echo 'Waiting for clickhouse...'; sleep 5; done
+ node -e 'const{Client}=require("pg");const db=process.env.POSTGRES_DB_DATABASE;const c=new Client({host:process.env.POSTGRES_DB_HOST,port:+(process.env.POSTGRES_DB_PORT||5432),user:process.env.POSTGRES_DB_USERNAME,password:process.env.POSTGRES_DB_PASSWORD,database:"postgres"});c.connect().then(()=>c.query("CREATE DATABASE "+db)).then(()=>console.log("[init] created "+db)).catch(e=>console.log("[init] "+(e.code==="42P04"?"db already exists":e.message))).finally(()=>c.end());'
+ node_modules/.bin/typeorm migration:run -d dist/database/ormconfig.js || echo "[init] migration:run failed (continuing)"
+ exec node dist/main.js
+
</code_context>
<issue_to_address>
**issue (bug_risk):** Failing to run migrations should probably stop the container instead of being ignored
Letting `typeorm migration:run` fail but still starting the app means it can run against an outdated or partially applied schema, leading to subtle runtime errors. Consider making migration failure cause a non‑zero exit (or only calling `exec node dist/main.js` when migrations succeed) and rely on orchestration to restart the container.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| - | | ||
| until node -e 'require("http").get("http://evocrm_clickhouse:8123/ping",r=>process.exit(r.statusCode===200?0:1)).on("error",()=>process.exit(1))'; do echo 'Waiting for clickhouse...'; sleep 5; done | ||
| node -e 'const{Client}=require("pg");const db=process.env.POSTGRES_DB_DATABASE;const c=new Client({host:process.env.POSTGRES_DB_HOST,port:+(process.env.POSTGRES_DB_PORT||5432),user:process.env.POSTGRES_DB_USERNAME,password:process.env.POSTGRES_DB_PASSWORD,database:"postgres"});c.connect().then(()=>c.query("CREATE DATABASE "+db)).then(()=>console.log("[init] created "+db)).catch(e=>console.log("[init] "+(e.code==="42P04"?"db already exists":e.message))).finally(()=>c.end());' | ||
| node_modules/.bin/typeorm migration:run -d dist/database/ormconfig.js || echo "[init] migration:run failed (continuing)" |
There was a problem hiding this comment.
issue (bug_risk): Failing to run migrations should probably stop the container instead of being ignored
Letting typeorm migration:run fail but still starting the app means it can run against an outdated or partially applied schema, leading to subtle runtime errors. Consider making migration failure cause a non‑zero exit (or only calling exec node dist/main.js when migrations succeed) and rely on orchestration to restart the container.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problema
/settings/segmentsresponde 500 (INTERNAL_ERROR) em qualquer ambiente subido a partir deste stack.A tela é um proxy: o CRM recebe
GET /api/v1/segmentse repassa ao evo-flow viaEvoFlow::Client. Só que odocker-compose.swarm.yamlnunca declarou o serviço evo-flow, nem as variáveis que o client precisa. SemAUTH_APIKEY_INTEGRATION_LOCAL, o CRM levantaEvoFlow::ConfigurationErrorjá na construção do client (app/services/evo_flow/client.rb:99), antes de qualquer chamada de rede — o controller só fazrescue EvoFlow::HTTPError, então a exceção escapa e vira 500 opaco.Diagnosticado no staging (
evo_crm_test), onde nenhum dos três serviços existia:O que muda
3 serviços novos. O evo-flow não sobe sozinho:
evocrm_evoflow— porta 3334 (a porta do projeto, conforme o.env.exampledo evo-flow). Usa um Postgres dedicado (evo_campaign), criado no boot junto com as migrations; o banco do CRM não é tocado.evocrm_clickhouse— exigido porSTORAGE_MODE=clickhouse. O evo-flow cria database e tabelas sozinho.evocrm_rabbitmq— oBrokerModuleaborta o boot seBROKER_TYPEnão estiver setado, mesmo comQUEUE_MODE=direct. Usuário dedicado porque oguestdo RabbitMQ recusa conexão remota.4 envs em
evocrm_crmeevocrm_crm_sidekiq:EVO_FLOW_ALLOW_INSECUREnão é opcional aqui: o stack rodaRAILS_ENV=productionsobre uma URLhttp://interna, e sem a flag o client se recusa a mandar a chave em cleartext — ou seja, o 500 voltaria mesmo com todo o resto cabeado.Mais: 2 volumes (
evocrm_clickhouse_data,evocrm_rabbitmq_data) e o cabeçalho de segredos do arquivo atualizado com os 3 novos.Segredos ficam vazios, seguindo a convenção do template (
# Ex.: gere com "openssl rand -hex 32").Validação
Aplicado no staging (
evo_crm_test) antes de virar commit. Os 3 serviços subiram, o evo-flow criou oevo_campaignno Postgres, rodou as migrations e criou as 16 tabelas no ClickHouse. O caminho que estava 500 agora responde 200:Tela confirmada funcionando no browser.
Fora de escopo (ficam abertos)
EvoFlow::ConfigurationErrornão tratada noSegmentsController→ misconfig continua virando 500 opaco em vez de 503 legível. É outro repo (evo-ai-crm-community), PR separada.EvoFlow::Client::DEFAULT_API_URLe.env.example:275), divergindo do 3334 do evo-flow. Mesma PR do item acima.evo-flow-community:developestá congelada em 04/jul — o evo-flow não aparece em nenhum workflow de publish do umbrella (só norelease.yml, que roda em tag). Mesmo padrão do EVO-1998.localhost:9092, poisKAFKA_BROKERS_INTERNALnão está setada). Não afeta Segments (QUEUE_MODE=direct).Summary by Sourcery
Add EvoFlow and its required infrastructure services to the swarm stack so the CRM Segments feature works in swarm-based environments.
New Features:
Enhancements: