feat: network option

[mathnogueira]

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-commenter]

Codecov Report

Merging #534 (c4d47cd) into master (07a49d8) will decrease coverage by 0.35%.
The diff coverage is 67.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%)	⬇️
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 data
Powered by Codecov. Last update 07a49d8...c4d47cd. Read the comment docs.

[orlangure]

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😼

[mathnogueira]

Sure, I'll improve the testing on this PR

[orlangure]

Thank you again for your contribution, I think this is a really cool and useful feature!

I have two thoughts I'd like to discuss with you a bit further.

1. As I wrote before, it seems that the networking configuration can and should be tested beyond "smoke tests". For that I released a new version of gnomock-test-image, which can be configured with a network-local URL i.e http://container (no domain - use exact container name). This address will be opened on every /request call, returning the target status code. It should be used to confirm that the two containers sharing the same network can communicate using their internal names. If you need help writing such test, please let me know.
2. I think we need a way to clean up unused networks. I don't think this is a blocker for this PR, but it definitely have to be considered. What are your thoughts?

[orlangure]

Since only the first ID is returned, I suggest to drop the slice, and just return whatever ID is found on line 376 instead of maintaining a list of existingNetwork.

[mathnogueira]

Thanks for patching the docker image. It will be very helpful to test this feature. I'll take a look at this this weekend.

[MotazBellah]

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 ?

[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.

[MotazBellah]

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 ? 🤔

[orlangure]

@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.