Docker container não dispara as requests ao usar o name

Estou com um problema muito estranho, tenho uma infraestrutura em docker, a qual criei um network chamado microservices e conectei alguns containers a ela. Eles estão em pé consigo pingar de um para o outro sem problemas, consigo fazer suas requisições se usar o ip e porta deles, exemplo:

http://172.26.0.2:8888/auth-service/refresh

Funciona bem, porém se passar o nome dele que é config-server no lugar do ip, ele deixa de funcionar. Alguém saberia me instruir como habilitar esse tipo de consulta?

A chamada pelo nome do container acredito que só funciona na própria rede do docker se não me engano.

A chamada partindo do host local tem que apontar pro IP do docker ou localhost, ambos com a porta que foi exposta e feito o binding.

2 curtidas

Opa jonathan obrigado por responder, estava vendo uma vídeo aula e vi o cara fazer por isso tentei implementar e não consegui. Estou tentando implementar porque a infra da minha empresa pretende coloca-ló em uma esteira de execução de alta disponibilidade para caso de quedas ou coisas parecidas e o ip seria dinâmico.

Você saberia se teria alguma forma de no aplication.properties do spring eu passar uma dns ou algo do tipo?

Sem saber os detalhes da sua infra fica difícil de avaliar, mas talvez para seu projeto não seria mais interessante criar um proxy reverso com balanceador de carga para garantir a alta disponibilidade?

Por exemplo um Nginx que recebe as requisições e distribui elas entre dois ou mais servidores rodando a mesma aplicação, assim no caso da queda de um deles o sistema continua funcionando.

2 curtidas

O ideal é colocar um proxy na frente como já foi sugerido, ainda mais que no seu caso seria um ambiente produtivo pelo que você comentou!

3 curtidas

Opa Lucas obrigado por responder, meu conhecimento de infra infelizmente não é muito grande e na empresa que atualmente trabalho temos um setor para cuidar dessa parte (menos mal kkk) ficou direcionado a mim configurar o sistema de microservices que criei para receber a infra.

Então algumas coisas eu já descobri, o ambiente do spring cloud, microservices, deve ter todos os módulos na mesma rede, vendo umas vídeo aulas vi que era possível criar uma rede docker e apontar todos os containers nela, fazendo assim com que eles possam se comunicar pelos seus respectivos nomes de containers. O docker chama essa funcionalidade de automatic service discovery, mas infelizmente ela não funcionou pra mim.

Minha ideia era aplicar essa configuração do docker, porque assim resolveria meu problema visto que todos os módulos estão sendo chamados por seus nomes e portas.

Essa funcionalidade é provida pelo swarm, não?

Pelo que me recordo esse recurso não funciona em uma infra docker simples, você precisaria utilizar o swarm para utilizar esse tipo de recurso.

2 curtidas

Eu ainda não entendi muito bem o que você está tentando fazer, por um momento eu achei que você estava confundindo microsserviços com talvez docker swarm, mas isso foi mais uma impressão que eu tive. Mas acho que você deveria fazer uma reunião com a infra da sua empresa para avaliar essa situação de alta disponibilidade.

No meu ponto de vista a melhor forma de chegar em alta disponibilidade seria ter um proxy reverso na frente dos seus serviços redundantes, assim se algum deles cair o outro pode manter o sistema funcionando.

1 curtida

Vou dar uma olhada sobre, não conhecia.

Mais fácil do que explicar é mostrar, tenho uma rede docker chamada microservices e nela tenho esse container com esse ip e rodando nessa porta:

config-server	172.26.0.2:8888

Quando chamo o endpoint:

http://172.26.0.2:8888/rh-service-homo/refresh

Tenho a conexão normal, porém quando chamo ele pelo nome do container:

http://config-server:8888/rh-service-homo/refresh

Ele diz que não é possível se conectar a este caminho.

Acredito que o problema deve ser pela falta desse swarm que vocês falaram, não me recordo na vídeo aula que vi ele falar sobre isso.

Essa abordagem do proxy reverso, vou dar uma estudada sobre e propor a eles.

Acho que você está confundindo um pouco as coisas, quando você cria uma rede no docker você está isolando os containers dessa rede do resto do sistema, isso serve para facilitar a comunicação dos containers da rede e aumentar a segurança, normalmente você coloca seus containers de microsserviços na mesma rede.

A ideia do proxy reverso é que você tenha mais de um container desse rh-service-homo respondendo em um mesmo end-point, pois vai ser o proxy que vai distribuir as requisições entres esses containers e garantir que se um deles cair o outro mantenha o serviço funcionando.

2 curtidas

Entendi, tive essas dúvidas pois na vídeo aula que vi o cara não teve problemas e funcionou de forma muito fácil e simples. Estava pensando que talvez tivesse feito algo errado, mas aparentemente o buraco é mais embaixo.

Pensando mais um pouco sobre esse exemplo que você deu, no meu ambiente de microservices tenho um service chamado gateway que ele tem justamente essa funcionalidade. Ele direcionado todos os serviços pela mesma porta e faz o controle de carga de cada módulo, mesmo tendo mais de um em pé repetido ele vai daber distribuir a carga entre eles.

Nesse caso que mostrei é o servidor de configuração chamado config-server e esse rh-service-homo são as configurações de um serviço. Um arquivo para ele pegar essas informações sem a necessidade de derubar o serviço para isso.

Cara só com o que você descreveu eu não entendi como a infra na sua empresa está funcionado, voltando nas conversas eu tive a impressão que talvez você tenha que criar um docker swarm com alguns containers do serviço rh-service-homo e esse gateway que provavelmente é o proxy irá fazer o trabalho de distribuição das requisições.

O melhor que você pode fazer agora é uma reunião com a infra ou com seu superior para entender o que realmente você tem que fazer, com essa quantidade de informações a gente só vai ficar chutando soluções.

1 curtida