feat: network option
Context
gnomock works great when you have to run a couple of independent containers to test your application, but as soon as you require communication between those containers, things get tricky. I've tried a couple of approaches but couldn't manage to make a container communicate with another.
Solution
This PR adds a new option gnomock.WithNetwork("network name") that allows a user to define which network the containers should run on. This allows communication between containers using the container name as its hostname.
Example
dbContainerName := "db"
_, err := gnomock.Start(
postgresPreset,
gnomock.WithNetwork("example"),
gnomock.WithContainerName(dbContainerName),
)
_, err := gnomock,StartCustom(
"custom/my-api",
gnomock.DefaultTCP(80),
gnomock.WithEnv(fmt.Sprintf("DATABASE_HOST=%s", dbContainerName)),
gnomock.WithNetwork("example"),
)
How it works
If options.Network is provided, check if there is an existing network with that name, if yes, use the existing network. Otherwise, create a new one and use it.
Codecov Report
Merging #534 (c4d47cd) into master (07a49d8) will decrease coverage by
0.35%. The diff coverage is67.44%.
@@ Coverage Diff @@
## master #534 +/- ##
==========================================
- Coverage 85.97% 85.62% -0.36%
==========================================
Files 48 48
Lines 2267 2309 +42
==========================================
+ Hits 1949 1977 +28
- Misses 165 172 +7
- Partials 153 160 +7
| Impacted Files | Coverage Δ | |
|---|---|---|
| docker.go | 85.89% <65.00%> (-4.21%) |
:arrow_down: |
| options.go | 100.00% <100.00%> (ø) |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update 07a49d8...c4d47cd. Read the comment docs.
Hi @mathnogueira and thank you for contribution, this looks great!
I will properly review the change this weekend. So far I only noticed that the test you added is basically a smoke test, and I wonder can the test be improved to actually confirm that the containers can communicate one with the other over the shared network? I'm thinking about extending https://github.com/orlangure/gnomock-test-image to support this case. If you have time until then, feel free to explore this direction. If not, no problem, I'll think about something later😼
Sure, I'll improve the testing on this PR
Thanks for patching the docker image. It will be very helpful to test this feature. I'll take a look at this this weekend.
I am facing the same issue, I am using clickhouse from gnomock, but also I am using the dockertest to run kafka, but I am not able to run the test end to end because of the network issue, any idea how to resolve this @orlangure ?
Hi @MotazBellah, thanks for reporting. It's been a while here since @mathnogueira last appeared in the comments. We still have 2 remaining points here to take care of: testing, and network cleanup (for networks created by gnomock). Would you like to complete the work?
Also, will it help if you run all your services via gnomock, so they don't have to share a network with other libraries? We do have a kafka preset that runs in a single container without network configuration.
Hi @MotazBellah, thanks for reporting. It's been a while here since @mathnogueira last appeared in the comments. We still have 2 remaining points here to take care of: testing, and network cleanup (for networks created by gnomock). Would you like to complete the work?
Also, will it help if you run all your services via gnomock, so they don't have to share a network with other libraries? We do have a kafka preset that runs in a single container without network configuration.
@orlangure but also even if I use the kafka from gnomock, both (clickHouse and Kafka) will run on separate containers and the network issue would still there ? or am i missing something ? 🤔
@MotazBellah, maybe you can work around the network issue by passing mapped host address:port to the container that needs to access the other one. That way the container that issues requests will go out to the host by its IP address and access the mapped port on the host just like your other code would. Of course using a shared network in this case would be better, but if the work isn't complete, you can try this solution as well.