testcontainers
Build fails on Fedora 22 Linux
The build command mvn clean install fails dependency resolution with this message
[ERROR] Failed to execute goal on project redis-backed-cache: Could not resolve dependencies for project org.testcontainers.examples:redis-backed-cache:jar:NOVERSION: Failed to collect dependencies at org.rnorth.visible-assertions:visible-assertions:jar:1.0.2 -> org.fusesource.jansi:jansi:jar:[,1.11): No versions available for org.fusesource.jansi:jansi:jar:[,1.11) within specified range -> [Help 1]
If I apply the fix from https://github.com/testcontainers/testcontainers-java-examples/pull/3 the code can be built, but the tests fail with these messages:
13:07:58.079 [main] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Looking for Docker environment. Trying Environment variables, system properties and defaults. Resolved:
uri=https://localhost:2376
sslConfig='LocalDirectorySSLConfig{dockerCertPath=/home/sflaniga/.docker}'
version='{UNKNOWN_VERSION}'
username='sflaniga'
password='null'
email='null'
serverAddress='https://index.docker.io/v1/'
dockerCfgPath='/home/sflaniga/.dockercfg'
13:07:58.467 [main] INFO org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - I/O exception (org.testcontainers.shaded.org.apache.http.conn.UnsupportedSchemeException) caught when processing request: https protocol is not supported
13:07:58.467 [main] INFO org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - Retrying request
13:07:58.468 [main] INFO org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - I/O exception (org.testcontainers.shaded.org.apache.http.conn.UnsupportedSchemeException) caught when processing request: https protocol is not supported
13:07:58.468 [main] INFO org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - Retrying request
13:07:58.468 [main] INFO org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - I/O exception (org.testcontainers.shaded.org.apache.http.conn.UnsupportedSchemeException) caught when processing request: https protocol is not supported
13:07:58.468 [main] INFO org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - Retrying request
13:07:58.469 [main] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Looking for Docker environment. Trying docker-machine
13:07:58.537 [main] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Found docker-machine, and will use machine named
13:07:58.545 [main] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Looking for Docker environment. Trying local Unix socket (unix:///var/run/docker.sock)
13:07:58.588 [main] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Accessing docker with local Unix socket
13:08:02.419 [main] WARN org.testcontainers.DockerClientFactory - Encountered and ignored error while checking disk space
org.testcontainers.shaded.com.github.dockerjava.api.DockerClientException: Could not pull image: null
at org.testcontainers.shaded.com.github.dockerjava.core.command.PullImageResultCallback.awaitSuccess(PullImageResultCallback.java:49) ~[testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
at org.testcontainers.DockerClientFactory.checkDiskSpace(DockerClientFactory.java:142) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
at org.testcontainers.DockerClientFactory.checkDiskSpaceAndHandleExceptions(DockerClientFactory.java:125) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:89) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:70) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:101) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
at RedisBackedCacheTest.<init>(RedisBackedCacheTest.java:18) [test-classes/:na]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.8.0_91]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [na:1.8.0_91]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [na:1.8.0_91]
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) [na:1.8.0_91]
at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217) [junit-4.12.jar:4.12]
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266) [junit-4.12.jar:4.12]
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [junit-4.12.jar:4.12]
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263) [junit-4.12.jar:4.12]
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) [junit-4.12.jar:4.12]
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) [junit-4.12.jar:4.12]
at org.junit.runners.ParentRunner.run(ParentRunner.java:363) [junit-4.12.jar:4.12]
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) [surefire-junit4-2.12.4.jar:2.12.4]
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) [surefire-junit4-2.12.4.jar:2.12.4]
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) [surefire-junit4-2.12.4.jar:2.12.4]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_91]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_91]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_91]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_91]
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) [surefire-api-2.12.4.jar:2.12.4]
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) [surefire-booter-2.12.4.jar:2.12.4]
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) [surefire-booter-2.12.4.jar:2.12.4]
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) [surefire-booter-2.12.4.jar:2.12.4]
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) [surefire-booter-2.12.4.jar:2.12.4]
13:08:02.508 [main] INFO 🐳 [redis:3.0.6] - Pulling docker image: redis:3.0.6. Please be patient; this may take some time but only needs to be done once.
13:08:13.691 [main] ERROR 🐳 [redis:3.0.6] - Retry limit reached while trying to pull image: redis:3.0.6. Please check output of `docker pull redis:3.0.6`
Despite the messages, I'm not out of disk space. If I try docker pull redis:3.0.6 as suggested, there is no error:
Trying to pull repository docker.io/library/redis ... 3.0.6: Pulling from library/redis
cb6fb082434e: Already exists
d4b2ba78e3b4: Already exists
96ee3f6ffa87: Already exists
2feb6003bd2b: Already exists
0ab2b63da119: Already exists
049c59590de6: Already exists
3c19570e002d: Already exists
70f598fa4206: Already exists
62c1a48300f5: Already exists
0f997ba7600c: Already exists
b97dabec1a3d: Already exists
25ff6ad2020c: Already exists
51dfd40e6465: Already exists
30084b4aa8fb: Already exists
e174820a222a: Already exists
8b1a71a14171: Already exists
ba4630529798: Already exists
Digest: sha256:6a692a76c2081888b589e26e6ec835743119fe453d67ecf03df7de5b73d69842
Status: Image is up to date for docker.io/redis:3.0.6
Also, I have tried building with the latest release instead of "-SNAPSHOT":
mvn clean install -Dtestcontainers.group=org.testcontainers -Dtestcontainers.version=1.0.5
and the results are similar.
Thanks - that looks really odd. I'm not quite sure what's happening yet but from those logs it looks like:
- configuring the docker client from your environment variables is failing due to docker-java/docker-java#419, whereby https DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is falling back to using docker-machine, then local unix socket, to discover your docker daemon
- curiously the docker-machine name is not resolving (it's coming up blank). There's possibly a display-related or other bug here.
- for some reason Testcontainers is encountering an error checking your host disk space - however this is non-fatal. This is quite likely to be related to output format from the
dfcommand, probably related to reporting of volumes. - the
Could not pull image: nullis a red flag that something is going wrong after this, though. It seems very odd for a string to be going missing - warrants investigation of the data flow.
It doesn't make much sense for this to be a Fedora 22-specific issue, but we'll have to see!
Richard
I didn't realise docker-machine was installed on this box. I'm not sure why it is installed, but I haven't set up any machines.
Perhaps it would be better to try the unix socket, and then docker-machine?
On 10 June 2016 at 13:56, Richard North [email protected] wrote:
Thanks - that looks really odd. I'm not quite sure what's happening yet but from those logs it looks like:
- configuring the docker client from your environment variables is failing due to docker-java/docker-java#419 https://github.com/docker-java/docker-java/issues/419, whereby https DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is falling back to using docker-machine, then local unix socket, to discover your docker daemon
- curiously the docker-machine name is not resolving (it's coming up blank). There's possibly a display-related or other bug here.
- for some reason Testcontainers is encountering an error checking your host disk space - however this is non-fatal. This is quite likely to be related to output format from the df command, probably related to reporting of volumes.
- the Could not pull image: null is a red flag that something is going wrong after this, though. It seems very odd for a string to be going missing - warrants investigation of the data flow.
It doesn't make much sense for this to be a Fedora 22-specific issue, but we'll have to see!
Richard
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/testcontainers/testcontainers-java-examples/issues/4#issuecomment-225087699, or mute the thread https://github.com/notifications/unsubscribe/AADTi_BbJinX2XHMYVDMmM15kTHdDZY-ks5qKOBqgaJpZM4IwjvT .
I don't have any DOCKER* environment variables, https or otherwise.
Here's the output of docker-machine ls:
$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
$
As I said, no machines, so I guess that output isn't entirely strange.
The problem might be with the socket:
$ ll /var/run/docker.sock srw-rw----. 1 root docker 0 Jun 9 16:31 /var/run/docker.sock
$
As I recall, I had some contortions getting docker commands to work without needing sudo in front of them, so I may have changed the permissions on the socket. Perhaps only docker can talk to the socket with those permissions... but /usr/bin/docker is not suid, so I'm not sure how it's working.
On 10 June 2016 at 14:00, Sean Flanigan [email protected] wrote:
I didn't realise docker-machine was installed on this box. I'm not sure why it is installed, but I haven't set up any machines.
Perhaps it would be better to try the unix socket, and then docker-machine?
On 10 June 2016 at 13:56, Richard North [email protected] wrote:
Thanks - that looks really odd. I'm not quite sure what's happening yet but from those logs it looks like:
- configuring the docker client from your environment variables is failing due to docker-java/docker-java#419 https://github.com/docker-java/docker-java/issues/419, whereby https DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is falling back to using docker-machine, then local unix socket, to discover your docker daemon
- curiously the docker-machine name is not resolving (it's coming up blank). There's possibly a display-related or other bug here.
- for some reason Testcontainers is encountering an error checking your host disk space - however this is non-fatal. This is quite likely to be related to output format from the df command, probably related to reporting of volumes.
- the Could not pull image: null is a red flag that something is going wrong after this, though. It seems very odd for a string to be going missing - warrants investigation of the data flow.
It doesn't make much sense for this to be a Fedora 22-specific issue, but we'll have to see!
Richard
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/testcontainers/testcontainers-java-examples/issues/4#issuecomment-225087699, or mute the thread https://github.com/notifications/unsubscribe/AADTi_BbJinX2XHMYVDMmM15kTHdDZY-ks5qKOBqgaJpZM4IwjvT .
I forgot that I had downloaded docker-machine to /usr/local/bin/
But removing it doesn't seem to have changed the error messages except to eliminate this line:
13:07:58.537 [main] INFO org.testcontainers.dockerclient.DockerConfigurationStrategy - Found docker-machine, and will use machine named
As for the socket permissions, my user is in the docker group, so the socket should be readable and writeable.
Also, if both a docker socket and docker-machine are found, is it better to use the socket and ignore docker-machine? And what if there is no "default" machine yet? Perhaps it should offer to create one? (Not that I want it to in this case, on Linux. I want to use Docker directly, even though docker-machine may be installed.)
On 10 June 2016 at 14:08, Sean Flanigan [email protected] wrote:
I don't have any DOCKER* environment variables, https or otherwise.
Here's the output of docker-machine ls:
$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
$
As I said, no machines, so I guess that output isn't entirely strange.
The problem might be with the socket:
$ ll /var/run/docker.sock srw-rw----. 1 root docker 0 Jun 9 16:31 /var/run/docker.sock
$
As I recall, I had some contortions getting docker commands to work without needing sudo in front of them, so I may have changed the permissions on the socket. Perhaps only docker can talk to the socket with those permissions... but /usr/bin/docker is not suid, so I'm not sure how it's working.
On 10 June 2016 at 14:00, Sean Flanigan [email protected] wrote:
I didn't realise docker-machine was installed on this box. I'm not sure why it is installed, but I haven't set up any machines.
Perhaps it would be better to try the unix socket, and then docker-machine?
On 10 June 2016 at 13:56, Richard North [email protected] wrote:
Thanks - that looks really odd. I'm not quite sure what's happening yet but from those logs it looks like:
- configuring the docker client from your environment variables is failing due to docker-java/docker-java#419 https://github.com/docker-java/docker-java/issues/419, whereby https DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is falling back to using docker-machine, then local unix socket, to discover your docker daemon
- curiously the docker-machine name is not resolving (it's coming up blank). There's possibly a display-related or other bug here.
- for some reason Testcontainers is encountering an error checking your host disk space - however this is non-fatal. This is quite likely to be related to output format from the df command, probably related to reporting of volumes.
- the Could not pull image: null is a red flag that something is going wrong after this, though. It seems very odd for a string to be going missing - warrants investigation of the data flow.
It doesn't make much sense for this to be a Fedora 22-specific issue, but we'll have to see!
Richard
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/testcontainers/testcontainers-java-examples/issues/4#issuecomment-225087699, or mute the thread https://github.com/notifications/unsubscribe/AADTi_BbJinX2XHMYVDMmM15kTHdDZY-ks5qKOBqgaJpZM4IwjvT .
Yes, I think the docker-machine aspect is a red herring - the real problem seems to be coming when, for whatever reason, it's trying to pull a container image named null.
In the 1.1-rc1 branch the issue of over-eagerly using docker-machine is resolved; it will use environment variables, followed by unix socket, followed by docker-machine if all else fails.
On 10 June 2016 at 14:54, Richard North [email protected] wrote:
Yes, I think the docker-machine aspect is a red herring - the real problem seems to be coming when, for whatever reason, it's trying to pull a container image named null.
Also, why does it keep trying to pull another image (not null) afterwards?
In the 1.1-rc1 branch the issue of over-eagerly using docker-machine is resolved; it will use environment variables, followed by unix socket, followed by docker-machine if all else fails.
Yes, that sounds right.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/testcontainers/testcontainers-java-examples/issues/4#issuecomment-225092997, or mute the thread https://github.com/notifications/unsubscribe/AADTi_csZ1BK2nu0eIVsmrJLJZ7mFFbFks5qKO3_gaJpZM4IwjvT .
Actually re-reading the stack trace, it's not trying to pull a null image - null is the exception message, and it's a failure when pulling the image used for disk space checks. Furthermore, it's getting a second pull failure when trying to pull the redis image.
I'm not quite sure why yet, though.
Please could you let me know the versions of docker daemon you have and the version of docker-machine you [have/]had?
On 10 June 2016 at 22:08, Richard North [email protected] wrote:
Actually re-reading the stack trace, it's not trying to pull a null image
- null is the exception message, and it's a failure when pulling the image used for disk space checks. Furthermore, it's getting a second pull failure when trying to pull the redis image.
I forgot to mention - every time it said to run 'docker pull redis' (or similar) for a better error message, I did that, but there was no error. Not for "null" though, obviously. I could pull that one manually if you let me know what the image name is, but I suspect it won't tell us anything, given that fetching redis manually didn't help.
I'm not quite sure why yet, though.
Please could you let me know the versions of docker daemon you have and the version of docker-machine you [have/]had?
From memory it's docker (daemon) 1.9 (although if I installed from Fedora repos it must have been 1.8 according to https://apps.fedoraproject.org/packages/docker), and docker-machine must have been docker-machine-Linux-x86_64 v0.7.0. I'll have to check the exact version of docker later. Probably 1.8, not 1.9.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/testcontainers/testcontainers-java-examples/issues/4#issuecomment-225165302, or mute the thread https://github.com/notifications/unsubscribe/AADTi2vVKtFi5bsOInrOI2nEVM1TACIMks5qKVO-gaJpZM4IwjvT .