testcontainers-java: Not working in Bitbucket pipeline: "authorization denied by plugin pipelines: Command not supported."
It seems to be both docker and testcontainers issue:
Running name.antonsmirnov.apptogether.dao.DeveloperDaoTest
08:08:56.040 [main] INFO EnvironmentAndSystemPropertyClientProviderStrategy - Found docker client settings from environment
08:08:56.060 [main] INFO DockerClientProviderStrategy - Found Docker environment with Environment variables, system properties and defaults. Resolved:
dockerHost=tcp://localhost:2375
apiVersion='{UNKNOWN_VERSION}'
registryUrl='https://index.docker.io/v1/'
registryUsername='root'
registryPassword='null'
registryEmail='null'
dockerConfig='DefaultDockerClientConfig[dockerHost=tcp://localhost:2375,registryUsername=root,registryPassword=<null>,registryEmail=<null>,registryUrl=https://index.docker.io/v1/,dockerConfigPath=/root/.docker,sslConfig=<null>,apiVersion={UNKNOWN_VERSION},dockerConfig=<null>]'
08:08:56.066 [main] INFO DockerClientFactory - Docker host IP address is localhost
08:08:56.227 [main] INFO DockerClientFactory - Connected to docker:
Server Version: 17.12.0-ce
API Version: 1.35
Operating System: Alpine Linux v3.7 (containerized)
Total Memory: 32171 MB
08:08:57.182 [testcontainers-netty-1-6] ERROR ResultCallbackTemplate - Error during callback
com.github.dockerjava.api.exception.DockerException: {"message":"authorization denied by plugin pipelines: Command not supported."}
at com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:111) [testcontainers-1.7.2.jar:na]
at com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:33) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) [testcontainers-1.7.2.jar:na]
at org.testcontainers.shaded.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138) [testcontainers-1.7.2.jar:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.211 sec <<< FAILURE!
Fabric docker plugin had the same issue and they were able to fix it with relatively small changes in plugin. See issues:
- https://bitbucket.org/site/master/issues/15844/bug-in-authorization-plugin#comment-45553072
- https://bitbucket.org/site/master/issues/15505/maven-fabric8-plugin-fails-to-run-docker
This is blocker issue and can be easily fixed.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 44 (14 by maintainers)
We’ve now released this in Testcontainers 1.10.6!
Please upgrade as soon as you can and follow the steps here for disabling Ryuk: https://www.testcontainers.org/features/configuration/#disabling-ryuk
I’ll close this ticket now, but please keep us posted if there are any new issues with this.
Hi,
Im a developer on bitbucket pipelines, since ryuk can only communicate with a docker daemon over its unix socket currently (and the fact that pipelines only allows communication with the steps docker daemon over TCP), we have since relaxed the mounts allowed in pipelines to allow mounting in the unix socket for the steps docker daemon, which now allows ryuk to run correctly 😃
Kind Regards, Nathan Burrell
@bsideup, I tried to use your PR and now I can start containers with a docker setup providing container isolation with a user namespace mapping (see #712).
Thanks a lot, this is working like a charm in Bitbucket 😄
Hi @raulgomis & @nathanburrell,
I just pushed a PR: https://github.com/testcontainers/testcontainers-java/pull/1181
If you set
TESTCONTAINERS_RYUK_DISABLEDenvironment variable totrue, we will not start Ryuk: https://5c4c37a5560ab600080292aa--testcontainers.netlify.com/features/configuration/#disabling-ryukPlease try it with Jitpack (revision
03a5c368ae) if you have time: https://www.testcontainers.org/jitpack_dependencies/Thanks for actioning this quickly 😃
We are organising some communicuations to customers in the coming weeks to tell them to update and set that variable, and I can also continue to start using test-containers more in the pipelines codebase itself 😉
Hi,
We rolled out a change yesterday to enable user namespace remapping on the docker daemons we provide to users for security reasons.
Thats an odd failure but, with this change I would expect to see
Have you got a link to a reproducible test case showing this, or alternatively can you raise a support ticket at https://support.atlassian.com/contact, so I can investigate further.
Kind Regards, Nathan Burrell
@erikvanzijst We’re working on mount-less file sharing (with copyFileToContainer with InputStream on container creation), it should fix the issue you mentioned. Will be released very soon 😃
I’ve been trying to get up to speed on this issue, as seen here and in #712. Sorry for only recently looking into this. To summarise my understanding so far:
I’d like to think carefully about the options; disabling Ryuk might be one way of avoiding access from TC-spawned to the docker daemon. However, it’s less desirable because it is not the only feature that will suffer (Docker Compose is another). Also, it creates yet another permutation for Testcontainers to operate in, one which lacks a lot of the safeguards for cleanup that we think are important. I don’t feel comfortable yet with the implications of that.
Still, this is probably something that @kiview, @bsideup and I need to have a discussion about soon.
is there an interest in a PR for such a property? For our use cases we don’t really need ryuk.
being able to disable ryuk would be great. For many cases this should be sufficient since the cloud provider will cleanup by itself. Even if it does not solve the problem completely, it would at least allow to work around it.
I understand your frustration when we make changes like this and I apoligise, but unfortunately security fixes may sometimes break some builds for the good of all the users of pipelines.
For test containers we don’t test it specifically as we have lots of users that use 1000s of different libraries from a broad range of different languages that perform similar functionality and we can’t test all the things unfortunately.
I haven’t had a chance to look into why test containers is failing yet due to other urgencies, and as I listed above I’m surprised a connection to local host is failing as I expect only the two cases above to fail.
For now I have added your account to the exclusion list to allow you to work, next time can you raise a support ticket with Atlassian directly so we can back to you in a more timely manner as I also don’t monitor GitHub issues alot only in my spare time 😃
Kind Regards Nathan Burrell
Hey @kiview test-containers works in pipelines, the issue above (as I described here: https://bitbucket.org/site/master/issues/15844/bug-in-authorization-plugin#comment-45561539) is not an issue in the auth plugin interaction with the custom java docker client nor an issue with how the library talks to docker (its working fine over tcp) its in how the MySqlContainer class by default mounts the mysql.conf file.
Users will (in order for this to work on pipelines), need to reconfigure the default (hostPath) directory for this file as we limit what paths can be mounted into docker containers due to the layout of how the containers and filesystems interact, and than the library works fine 😃