Repository navigation
Kubernetes Support #449
Description
It seems that testcontainers-java does not work well in a kubernetes environment. I run my tests on a jenkins which uses the jenkins kubernetes-plugin to provide slaves.
I'm by fare not an export in kubernetes and/or docker but I think I have an idea why testcontainers-java is not working. Please correct me if I may mix up things.
The jenkins-slave which runs maven and executes my tests is managed by kubernetes. The network of this docker container is managed by flannel and thus the network device of the slave container is not attached to the docker0 bridge. Instead it is being attached to the flannel bridge device.
It seems that it is not possible to (by default) to connect from a kubernetes managed container to a pure docker container. Thus the connection from my jenkins-slave container to 172.17.0.1:32785 fails.
testcontainers-java version: 1.3.0
org.testcontainers.containers.ContainerLaunchException: Container startup failed
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:179)
at com.gentics.mesh.distributed.containers.MeshDockerServer.start(MeshDockerServer.java:147)
at org.testcontainers.containers.GenericContainer.starting(GenericContainer.java:531)
at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:29)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: org.rnorth.ducttape.RetryCountExceededException: Retry limit hit with exception
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:83)
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:172)
... 11 more
Caused by: org.testcontainers.containers.ContainerLaunchException: Could not create/start container
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:246)
at org.testcontainers.containers.GenericContainer.lambda$start$0(GenericContainer.java:174)
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:76)
... 12 more
Caused by: org.testcontainers.containers.ContainerLaunchException: Timed out waiting for container port to open (172.17.0.1:32785 should be listening)
at org.testcontainers.containers.wait.HostPortWaitStrategy.waitUntilReady(HostPortWaitStrategy.java:90)
at org.testcontainers.containers.GenericContainer$AbstractWaitStrategy.waitUntilReady(GenericContainer.java:910)
at org.testcontainers.containers.GenericContainer.waitUntilContainerStarted(GenericContainer.java:453)
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:225)
... 14 more
The best solution (afaik) would be to create the testcontainer via kubernetes API instead of docker. This way the testcontainer would utilize the flannel network and could be reached.
Activity
bsideup commentedon Aug 29, 2017
Hi @Jotschi,
Thanks for reporting! We added pre-flight checks and did a couple of fixes in 1.4.x, could you please update to 1.4.2, so that we see that it also fails? Thanks!
Jotschi commentedon Aug 29, 2017
@bsideup Same error using version 1.4.2:
Earlier I see the following messages:
bsideup commentedon Aug 29, 2017
@Jotschi interesting! "Exposed port is accessible" passed. It means that it works, in general, just you container failed to expose the port. Does it work locally?
Jotschi commentedon Aug 29, 2017
@bsideup The Test runs just fine locally. What is that check actually doing?
bsideup commentedon Aug 29, 2017
@Jotschi it starts a container and checks that the port is accessible, with exactly the same approach we use to expose ports from GenericContainers. If it passes - I would check container's configuration first because it seems that networking is not the root cause of the issue you have
Jotschi commentedon Aug 30, 2017
@bsideup Yes you were right. The issue I'm seeing seems to be related to the container I'm running. The application is not starting correctly and thus the startup check fails.
Jotschi commentedon Sep 13, 2017
@bsideup It is still not working for me but I assume it is a problem with my setup and the used data volume permissions. I'll close the issue. Thank you for your time.