Bridge network for communication between ApiServerContainer and Etcd

[MikeEdgar]

Fixes #419

[dajudge]

Thanks for the contribution!

I noticed there are a few other places using the same withNetworkMode("container:" + ...) pattern:

• KubectlContainer.java:55
• Helm3Container.java:25
• AdmissionControllerManager.java:63+71

Since ApiServerContainer extends KubernetesContainer, it also has these sidecar containers. Did you encounter similar cleanup issues with these when using podman?

Summoning @kiview - have you seen similar podman incompatibilities with container network mode in other Testcontainers projects? Is this a known limitation where podman behaves differently than Docker when it comes to container dependencies and cleanup?

[MikeEdgar]

Since ApiServerContainer extends KubernetesContainer, it also has these sidecar containers. Did you encounter similar cleanup issues with these when using podman?

Ah, no. I have only been using a limited number of the containers (via Quarkus's Kubernetes devservices) and I haven't tried those. I suspect the behavior would be similar though. Using Network in KubernetesContainer would impact the k3s and Kind containers and I'm unclear how networking applies in those tools.

I wasn't able to run the tests locally due to what seems like DockerHub rate/authentication limits.

[kiview]

@dajudge yeah, I'm pretty sure that's due to the fact, that Podman networking works quite differently, and it doesn't surprise me at all, that this "implementation detail hack" of using the container ID to reuse the same network namespace doesn't work for them.

I even remember, that the entre tc-java test suite, when run with Podman, would reach a broken state, since Podman ended up in a broken state (potentially even around networking).

However, it's always also worth to open an issue on such incompatibilities with Docker upstream with Podman, since they are generally interested in achieving API parity when run in their Docker compatibility mode.