Conflict Between Multiple Instances of wppconnect-server in Docker Swarm or Docker Container standalone #2056
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
[en] Description
I'm experiencing an issue running multiple instances of the
wppconnect-serverin a Docker Swarm setup. When attempting to launch a new stack (e.g.,homologacao) alongside the production stack, Puppeteer/Chromium fails to initialize properly, causing a direct conflict between instances, which seem to interfere with each other despite being isolated. This behavior occurs only within container environments.The problem was identified while debugging an attachment upload limit (restricted to 60MB). This issue remains unresolved and will be reported separately.
[pt-br] Descrição
Estou enfrentando um problema ao executar múltiplas instâncias do
wppconnect-serverem uma configuração de Docker Swarm. Quando tento subir uma nova stack (por exemplo,homologacao) além da stack de produção, o Puppeteer/Chromium não consegue inicializar corretamente, causando um conflito direto entre as instâncias que, apesar de isoladas, parecem interferir uma com a outra. Esse comportamento é específico para containers e não ocorre fora desse ambiente.O problema foi identificado durante a tentativa de debugar uma limitação no envio de anexos, que está restrito a 60MB. Este problema ainda não foi resolvido, mas será reportado separadamente.
[en] Environment
[pt-br] Ambiente
{ "secretKey": "my_key", "host": "http://localhost", "port": "21465", "deviceName": "WppConnect", "poweredBy": "WPPConnect-Server", "startAllSession": true, "tokenStoreType": "file", "maxListeners": 15, "customUserDataDir": "./userDataDir/", "webhook": { "url": null, "autoDownload": true, "uploadS3": false, "readMessage": false, "allUnreadOnStart": false, "listenAcks": true, "onPresenceChanged": false, "onParticipantsChanged": false, "onReactionMessage": true, "onPollResponse": false, "onRevokedMessage": false, "onLabelUpdated": false, "onSelfMessage": false, "ignore": ["status@broadcast"] }, "websocket": { "autoDownload": false, "uploadS3": false }, "chatwoot": { "sendQrCode": true, "sendStatus": true }, "archive": { "enable": false, "waitTime": 10, "daysToArchive": 45 }, "log": { "level": "silly", "logger": ["console", "file"] }, "createOptions": { "browserArgs": [ "--disable-web-security", "--no-sandbox", "--disable-web-security", "--aggressive-cache-discard", "--disable-cache", "--disable-application-cache", "--disable-offline-load-stale-cache", "--disk-cache-size=0", "--disable-background-networking", "--disable-default-apps", "--disable-extensions", "--disable-sync", "--disable-translate", "--hide-scrollbars", "--metrics-recording-only", "--mute-audio", "--no-first-run", "--safebrowsing-disable-auto-update", "--ignore-certificate-errors", "--ignore-ssl-errors", "--ignore-certificate-errors-spki-list", "--remote-debugging-port=9277", "--remote-debugging-address=0.0.0.0" ], "puppeteerOptions": { "devtools": true, "dumpio": true, "protocolTimeout": 60000 } }, "mapper": { "enable": false, "prefix": "tagone-" }, "db": { "mongodbDatabase": "tokens", "mongodbCollection": "", "mongodbUser": "", "mongodbPassword": "", "mongodbHost": "", "mongoIsRemote": true, "mongoURLRemote": "", "mongodbPort": 27017, "redisHost": "localhost", "redisPort": 6379, "redisPassword": "", "redisDb": 0, "redisPrefix": "docker" }, "aws_s3": { "region": "sa-east-1", "access_key_id": null, "secret_key": null, "defaultBucketName": null, "endpoint": null, "forcePathStyle": null } }[en] Steps to Reproduce
wppconnect-serverin Docker Swarm (e.g., production).ProtocolErrorandNetwork.enable.[pt-br] Passos para Reproduzir
wppconnect-serverem Docker Swarm (por exemplo, para produção).ProtocolErroreNetwork.enable.Note: The standard Dockerfile in the repository uses a Multi-Stage build, but it currently includes development dependencies in the production stage, resulting in an image size of approximately 3GB. I have reorganized the Dockerfile to avoid this issue by ensuring that only production dependencies, libraries, and the compiled code are carried over to the production stage. Additionally, this requires adjustments in the
package.jsonfile, specifically moving the runtime dependencies,@babel/runtimeandprom-client, fromdevDependenciestodependencies. These changes are necessary if my Dockerfile is used to test the environment, as these runtime dependencies are missing in the official repository’s configuration. This could also be addressed in a separate issue or even a PR for correction.Observação: O Dockerfile padrão do repositório utiliza uma construção Multi-Stage, mas atualmente inclui dependências de desenvolvimento na fase de produção, gerando uma imagem de aproximadamente 3GB. Reorganizei o Dockerfile para evitar esse problema, garantindo que apenas as dependências de produção, bibliotecas e o código compilado sejam levados para a fase de produção. Além disso, são necessárias algumas correções no arquivo
package.json, especificamente movendo as dependências de runtime,@babel/runtimeeprom-client, dedevDependenciesparadependencies. Essas mudanças são necessárias caso meu Dockerfile seja utilizado para testar o ambiente, pois essas dependências de runtime estão faltando na configuração do repositório oficial. Isso também poderia ser abordado em uma nova issue ou até mesmo em um PR para correção.[en] Log Output
[pt-br] Saída de Log
[en] Additional context / Screenshot
While investigating this issue, I also identified a separate problem: an attachment upload limit of 60MB, which remains unresolved but will be reported in a separate bug report.
[pt-br] Contexto Adicional / Screenshot
Ao investigar o problema, também identifiquei uma limitação de upload de anexos de 60MB que ainda não foi resolvida, mas pretendo abrir um relatório de bug separado para tratar essa questão.
The text was updated successfully, but these errors were encountered: