Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing Kafka container from another container #732

Closed
iNikem opened this issue Jun 5, 2018 · 16 comments
Closed

Accessing Kafka container from another container #732

iNikem opened this issue Jun 5, 2018 · 16 comments

Comments

@iNikem
Copy link
Contributor

iNikem commented Jun 5, 2018

For my test I have to run 2 containers. One of them is KafkaContainer, another one is our application which uses that Kafka. Now, the problem is that KafkaContainer starts Kafka with ADVERTISED_LISTENER set to host ip of the Socat proxy container. Which is, obviously, not accessible from another container. #452 (comment) seems to be relevant here as well.

So my question is: how can I run another testcontainer which needs to access KafkaContainer?

@bsideup bsideup self-assigned this Jun 5, 2018
@iNikem
Copy link
Contributor Author

iNikem commented Jun 5, 2018

Well, I can confirm it does work. But it's absolutely not obvious from public API. kafka.getNetworkAliases().get(0) + ":9093" looks like dark magic incantation. You have to read source code even to understand it.

@iNikem
Copy link
Contributor Author

iNikem commented Jun 5, 2018

Essentially we have 2 addresses here. One is "external", for using from the tests, another one is "internal" for using from other containers on the same network. May be both should be exposed as public API?

@bsideup
Copy link
Member

bsideup commented Jun 5, 2018

@iNikem well, ask Kafka guys why it is so 😄 Also, for your usecase, you don't really need KafkaContainer because the purpose of it is to simplify Kafka usage from the host because of NAT. In your case, simple GenericContainer will do the job

@iNikem
Copy link
Contributor Author

iNikem commented Jun 5, 2018

Well, I want to communicate with Kafka from tests as well, so your proxy is still convenient. And I will make a PR to you, exposing 9093 endpoint in public API as well, if you don't mind.

@bsideup
Copy link
Member

bsideup commented Jun 5, 2018

@iNikem um... exposing 9093 doesn't make sense o_O What we could do, however, is to change the defaults and keep 9092 for the internal communication and some other port for the socat proxy

@iNikem
Copy link
Contributor Author

iNikem commented Jun 5, 2018

@bsideup Why? By "exposing" I mean providing a nice method wrapping kafka.getNetworkAliases().get(0) + ":9093" in addition to existing getBootstrapServers method. So that other containers could use it.

@kiview
Copy link
Member

kiview commented Jun 5, 2018

Like getBootstrapServersForDockerNetwork()?

@bsideup
Copy link
Member

bsideup commented Jun 5, 2018

@iNikem ah, I see now. I'm afraid if we add such public method, users will try to use it instead of getBootstrapServers :(

@iNikem
Copy link
Contributor Author

iNikem commented Jun 5, 2018

@bsideup I will try to come up with some scary name :)

@bsideup
Copy link
Member

bsideup commented Jun 5, 2018

The method doesn't really makes any sense. What makes sense is to change the port back to 9092. I just submitted a PR for it:
#733

This way, you can use KafkaContainer as any other container (alias:9092 ) - what you would normally espect

@iNikem
Copy link
Contributor Author

iNikem commented Jun 5, 2018

You still have to know that there are 2 different ways to communicate with Kafka: inside docker network and from your tests.

@kiview
Copy link
Member

kiview commented Jun 5, 2018

Sounds like a good solution 👍

@iNikem You are right, but I'm afraid, this would also be the case if we add an additional public API method.

@bsideup
Copy link
Member

bsideup commented Jun 5, 2018

@iNikem this applies to any container, actually. Either use exposed port on host or exposed inside the network

@iNikem
Copy link
Contributor Author

iNikem commented Jun 5, 2018

Ok, thinking one more time about our requirements, the solution of #733 will satisfy us nicely :) Thanks!

@bsideup bsideup added this to the next milestone Jun 11, 2018
@bsideup
Copy link
Member

bsideup commented Jun 15, 2018

Released as 1.8.0 🎉

@bsideup bsideup closed this as completed Jun 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants