4
respostas

Nenhum processo funciona

Apos clonar o repositorio, instalar docker e subir tudo (docker-compose up --build)

Preencho a aba "dados pessoais" o log retorna:

api-gateway-1 | 172.18.0.1 - - [06/Oct/2025:16:50:51 +0000] "OPTIONS /mkt/leads HTTP/1.1" 204 0 "http://localhost:4200/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0.1 Safari/605.1.15" "-"

e só, nada mais... Entro em /mkt/leads e nada aparece

Na aba "detalhes pagamento", mesma coisa
api-gateway-1 | 2025/10/06 16:51:32 [error] 29#29: *34 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, server: , request: "OPTIONS /financeiro/clients HTTP/1.1", upstream: "http://172.18.0.9:9501/clients", host: "localhost", referrer: "http://localhost:4200/"

nem direciona pra outra tela

oq mostra de diferente seria

mongo-mkt-1 | {"t":{"$date":"2025-10-06T16:53:51.115+00:00"},"s":"I", "c":"WTCHKPT", "id":22430, "ctx":"Checkpointer","msg":"WiredTiger message","attr":{"message":{"ts_sec":1759769631,"ts_usec":115359,"thread":"1:0xffff8540e640","session_name":"WT_SESSION.checkpoint","category":"WT_VERB_CHECKPOINT_PROGRESS","log_id":1000000,"category_id":7,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"saving checkpoint snapshot min: 43, snapshot max: 43 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 32"}}}

Garanta sua matrícula hoje e ganhe + 2 meses grátis

Continue sua jornada tech com ainda mais tempo para aprender e evoluir

Quero aproveitar agora
4 respostas

Olá Leonardo.
Tudo bem?
Estou tentando entender seu problema.
Vamos lá...
Após clonar o repositório, instalar o Docker e subir os containers com docker-compose up --build, ao tentar preencher dados no frontend (em localhost:4200), o navegador envia uma requisição OPTIONS para /mkt/leads, e o log retorna:

api-gateway-1 | "OPTIONS /mkt/leads HTTP/1.1" 204 ...

Essa resposta 204 indica que o servidor respondeu corretamente ao preflight CORS.
Isso é esperado e não indica erro.
No entanto, ao tentar preencher a aba "detalhes pagamento", o log apresenta:

api-gateway-1 | connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, request: "OPTIONS /financeiro/clients HTTP/1.1", upstream: "http://172.18.0.9:9501/clients"

Esse erro indica que o api-gateway (provavelmente um proxy como Nginx) tentou encaminhar a requisição para o serviço que deveria estar rodando no endereço interno 172.18.0.9:9501, mas não conseguiu conectar.
Isso normalmente acontece por três motivos:
O container do serviço financeiro não está rodando. Para verificar:

docker ps

Se não estiver na lista, veja os logs para entender o motivo:

docker-compose logs financeiro-api

Se o container estiver rodando, pode ser que a aplicação dentro dele não esteja escutando na porta 9501.
Verifique isso dentro do container:

docker exec -it financeiro-api sh
netstat -tuln

O correto seria a aplicação escutar na porta 9501 e essa porta estar exposta no docker-compose.yml:

financeiro-api:
  build: ./financeiro
  ports:
    - "9501:9501"

Outra possibilidade é que o api-gateway esteja configurado para usar um IP fixo (como 172.18.0.9) em vez do nome do serviço Docker.
Isso não é recomendado, pois o IP pode mudar.
Em vez disso, a configuração no Nginx (ou qualquer gateway) deve ser feita usando o nome do serviço:

location /financeiro/ {
    proxy_pass http://financeiro-api:9501/;
}

Sobre o log do MongoDB:

mongo-mkt-1 | {"msg":"saving checkpoint snapshot..."}

Esse log é apenas informativo, relacionado ao mecanismo de checkpoint do banco (WiredTiger). Não representa erro.
Para investigar melhor, é importante também abrir o console do navegador (F12) na aba Network, verificar se a requisição real (POST, GET etc.) está sendo enviada após o OPTIONS e se há algum erro de CORS ou resposta com código 500, 502, 504 etc.
Verifique:

docker-compose ps
docker-compose logs financeiro-api
docker exec -it financeiro-api sh
netstat -tuln

E revise o proxy para garantir que ele está apontando para financeiro-api:9501 em vez de um IP.
Teste cada etapa até encontrar o problema.
Me mande um feedback dos resultados.
Fico esperando...
Bons estudos.
Obrigado.

Apos rodar o docker-compose up --build
e tentar preencher formulario:

print

Nao aparece nada em 'network' como se nao tivesse chamado as rotas

Olá Leonardo.
Vamos tentar mais uma vez...
Perfeito! Aqui está a versão em formato de tutorial passo a passo:
Ao subir uma aplicação Angular integrada a um API Gateway via Docker, é comum encontrar dois problemas:

  • Erro de CORS (Access-Control-Allow-Origin)
  • Erro de conexão recusada com serviços upstream (financeiro, mkt, etc.)
    Primeiro, confirme se todos os containers realmente subiram:
docker ps

Confira se os serviços api-gateway, financeiro, mkt, mongo (ou outros necessários) estão rodando e em quais portas estão expostos.
Execute um teste dentro do container do gateway para verificar se ele consegue acessar os serviços internos:

docker exec -it api-gateway-1 curl http://financeiro:9501/clients
  • Se a resposta vier corretamente, o problema está no CORS.
  • Se não houver resposta ou aparecer connection refused, o serviço financeiro não está acessível.
    Caso o serviço não esteja acessível, visualize os logs:
docker logs <id_do_container_financeiro>

Isso mostra se houve erro de inicialização, porta incorreta ou falha na aplicação backend.
No arquivo docker-compose.yml, verifique se o serviço expõe a porta correta. Exemplo:

services:
  financeiro:
    build: ./financeiro
    ports:
      - "9501:9501"

Se a aplicação interna rodar em outra porta (como 3000), ajuste o upstream no gateway para refletir isso.
Se os serviços estiverem respondendo, mas o Angular continuar bloqueado, é necessário liberar o CORS.
Em uma configuração baseada em Nginx, adicione as seguintes diretivas:

add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';

if ($request_method = OPTIONS) {
    return 204;
}

Isso garante que chamadas do Angular (porta 4200) não sejam bloqueadas.
Após realizar ajustes, reinicie os serviços para aplicar as mudanças:

docker-compose down
docker-compose up --build

O erro ocorre geralmente por dois motivos:

  1. O container do serviço backend não está rodando ou a porta configurada está incorreta.
  2. O API Gateway não permite requisições vindas do Angular por falta de configuração de CORS.
    Seguindo os passos acima, é possível identificar a causa e corrigir rapidamente, garantindo que o frontend consiga se comunicar com os serviços via gateway.
    Me envia o link do repositorio do github para que eu possa testar o codigo e verificar os arquivos.
    E me envia um feedback dos resultados.
    Bons estudos.
    Até...
    :)

E para complementar: Pode ser o docker!
Ao subir uma aplicação com Docker e Docker Compose, pode acontecer de tudo funcionar em outras máquinas, mas não na sua.
Isso geralmente indica um problema local no Docker e não no código em si.
Abaixo estão os principais cenários que podem causar falhas de comunicação entre containers e como corrigi-los.

Problema 1: Rede interna do Docker não resolve nomes de serviços

O Docker cria uma rede interna para os containers se comunicarem usando os nomes definidos no docker-compose.yml.
Se essa resolução não funcionar, o API Gateway pode tentar acessar o serviço por IP (como 172.18.0.9), o que pode mudar a cada execução.
Como verificar:

docker exec -it api-gateway-1 ping financeiro
docker exec -it api-gateway-1 curl http://financeiro:9501/clients

Como resolver:

  • Verifique se o serviço tem o nome correto no docker-compose.yml.
  • Certifique-se de que todos os serviços estão na mesma rede (por padrão, project_default).
  • Se necessário, crie uma rede manual no docker-compose.yml e conecte todos os containers nela.

Problema 2: Porta em conflito no host

Se a porta que o container expõe já estiver sendo usada no host, o mapeamento pode falhar silenciosamente.
Como verificar:

netstat -tuln | grep 9501

Como resolver:

  • Se a porta estiver ocupada, altere o mapeamento no docker-compose.yml, por exemplo:
    ports:
      - "9600:9501"
    

Problema 3: Diferenças de versão do Docker ou Docker Compose

Versões diferentes podem mudar como redes são criadas e como os containers são nomeados.
Como verificar:

docker --version
docker-compose --version

Como resolver:

  • Atualize para a mesma versão usada na máquina onde funciona.
  • Se não for possível, revise o docker-compose.yml para garantir compatibilidade.

Problema 4: Firewall ou restrições do sistema operacional

Em alguns sistemas, o firewall ou SELinux pode bloquear a comunicação entre containers.
Como verificar:

  • Teste desabilitar temporariamente o firewall e veja se a comunicação entre containers funciona.
  • Em Linux com SELinux, veja os logs (/var/log/audit/audit.log) para identificar bloqueios.
    Como resolver:
  • Ajuste as regras do firewall para permitir tráfego interno do Docker.
  • Configure o SELinux em modo permissivo ou adicione políticas adequadas.

Problema 5: Cache de containers, imagens ou redes antigas

Resíduos de execuções anteriores podem causar conflitos, especialmente em redes internas.
Como verificar e resolver:
Recrie o ambiente do zero:

docker-compose down -v --remove-orphans
docker system prune -af --volumes
docker-compose up --build

Quando uma aplicação funciona em outras máquinas mas falha na sua, geralmente não é problema do código e sim da configuração local do Docker. Os principais pontos a verificar são: resolução de nomes na rede interna, conflitos de porta, versão do Docker/Compose, firewall do sistema e cache de containers ou redes antigas. Ajustando esses aspectos, a comunicação entre os containers deve funcionar normalmente.
As vezes é necessario remover todas as imagens e containeres e reiniciar a aplicação do zero.
Rodando docker system prune -a --volumes você literalmente zera o ambiente Docker da máquina.
Isto pode resolver os conflitos.
Testa ai e me avise .
Até...
:)