You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm experiencing an issue running multiple instances of the wppconnect-server in 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-server em 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.
Configure a stack for wppconnect-server in Docker Swarm (e.g., production).
Run the service, which will work as expected.
Try launching a second stack (e.g., for homologation).
Observe that Puppeteer/Chromium fails to initialize, showing errors related to ProtocolError and Network.enable.
Note: If the developer does not have access to a Docker Swarm environment, they can reproduce the issue using Docker Standalone by running two containers on different ports. This setup will also demonstrate the same behavior. Below is the Dockerfile I am using, which has been optimized to utilize three stages, unlike the example Dockerfile from the repository. This Dockerfile prepares the production-ready application with only the necessary production dependencies.
[pt-br] Passos para Reproduzir
Configure uma stack para o wppconnect-server em Docker Swarm (por exemplo, para produção).
Execute o serviço, que funcionará conforme o esperado.
Tente iniciar uma segunda stack (por exemplo, para homologação).
Observe que o Puppeteer/Chromium não inicializa corretamente, exibindo logs de erro relacionados a ProtocolError e Network.enable.
Observação: Caso o desenvolvedor não tenha acesso a um ambiente Docker Swarm, ele pode reproduzir o problema usando Docker Standalone, subindo dois containers em portas diferentes. Essa configuração também apresentará o mesmo comportamento. Abaixo está o Dockerfile que estou utilizando, otimizado para utilizar três estágios, diferente do Dockerfile de exemplo no repositório. Esse Dockerfile prepara a aplicação para produção com apenas as dependências necessárias.
# Estágio 1: Dependências base com cacheFROM node:lts-alpine3.20 AS base
WORKDIR /usr/src/wpp-server
COPY package.json yarn.lock ./
# Instalar dependências do sistema e cachearRUN --mount=type=cache,target=.cache \
apk add --no-cache \
vips-dev \
fftw-dev \
libc6-compat
# Instalar dependências do Node.js (remover o mount temporariamente para testar)RUN yarn install --production --pure-lockfile && \
yarn cache clean
# Estágio 2: Build com ferramentas de compilaçãoFROM base AS build
# Instalar ferramentas de compilação e dependênciasRUN apk add --no-cache \
gcc \
g++ \
make \
python3
COPY . .
RUN yarn install --production=false --pure-lockfile && \
yarn build && \
yarn cache clean
# Estágio 3: Imagem finalFROM node:lts-alpine3.20
WORKDIR /usr/src/wpp-server
ENV NODE_ENV=production
# Instalar dependências de runtime e ChromiumRUN apk add --no-cache \
vips-dev \
fftw-dev \
libc6-compat \
chromium
# Copiar as dependências e artefatos do buildCOPY --from=base /usr/src/wpp-server/node_modules ./node_modules
COPY --from=build /usr/src/wpp-server/dist ./dist
COPY package.json ./
EXPOSE 21465
ENTRYPOINT ["node", "dist/server.js"]
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.json file, specifically moving the runtime dependencies, @babel/runtime and prom-client, from devDependencies to dependencies. 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/runtime e prom-client, de devDependencies para dependencies. 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.
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:
[en] Description
I'm experiencing an issue running multiple instances of the
wppconnect-server
in 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-server
em 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
[en] Steps to Reproduce
wppconnect-server
in Docker Swarm (e.g., production).ProtocolError
andNetwork.enable
.[pt-br] Passos para Reproduzir
wppconnect-server
em Docker Swarm (por exemplo, para produção).ProtocolError
eNetwork.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.json
file, specifically moving the runtime dependencies,@babel/runtime
andprom-client
, fromdevDependencies
todependencies
. 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/runtime
eprom-client
, dedevDependencies
paradependencies
. 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: