JNLP launcher broken since 1.1.3

Since update to 1.1.3, docker-plugin fails to launch containers on our Jenkins instance.

We use containers with java preinstalled, and the Connect with JNLP option. We did not need to configure any entrypoint or command, neither in Dockerfile, nor in Jenkins. Therefore, we could keep minimal configuration (convention over configuration).

This worked, but since 1.1.3, we get the following log messages:

Mar 12 06:25:08 bvsl05linux06 dockerd[27174]: time="2018-03-12T06:25:08.845787483+01:00" level=debug msg="Calling GET /images/l5-docker.mydomain.com/build-docker:latest/json"
Mar 12 06:25:08 bvsl05linux06 dockerd[27174]: time="2018-03-12T06:25:08.855256229+01:00" level=debug msg="Calling POST /containers/create?name=cc1448a549e4"
Mar 12 06:25:08 bvsl05linux06 dockerd[27174]: time="2018-03-12T06:25:08.856180879+01:00" level=debug msg="form data: {\"Cmd\":[\"-url\",\"http://jenkins.mydomain.com/jenkins/\",\"60651987a0fdca5e8ea707b3d509256cd68fe1b44483ddeb2a91da1658ef8e6b\",\"docker-cc1448a549e4\"],\"Env\":[\"COLLECTD_DOCKER_APP=jenkins-docker-agent\"],\"ExposedPorts\":{},\"HostConfig\":{\"Memory\":524288000,\"MemorySwap\":-1,\"NetworkMode\":\"host\",\"PortBindings\":{},\"Privileged\":false,\"PublishAllPorts\":false},\"Image\":\"l5-docker.mydomain.com/build-docker:latest\",\"Labels\":{\"JenkinsContainerImage\":\"l5-docker.mydomain.com/build-docker:latest\",\"JenkinsId\":\"295c19b7077fc8004251d87c5f81ef7d\",\"JenkinsServerUrl\":\"http://jenkins.mydomain.com/jenkins/\"},\"NetworkDisabled\":false,\"Tty\":false,\"Volumes\":{},\"name\":\"cc1448a549e4\"}"
...
Mar 12 06:25:08 bvsl05linux06 dockerd[27174]: time="2018-03-12T06:25:08.944657766+01:00" level=debug msg="Calling POST /containers/de8ca31fa47d95a6c4ef4ba4fb29a392f78aa0c5277c79497df3e31b33837ef1/start"
...
Mar 12 06:25:09 bvsl05linux06 dockerd[27174]: time="2018-03-12T06:25:09.189358823+01:00" level=error msg="containerd: start container" error="oci runtime error: container_linux.go:265: starting container process caused \"exec: \\"-url\\": executable file not found in $PATH\"

Seems that docker-plugin doesn’t invoke java anymore, but simply passes -url, which obviously doesn’t work without manually configuring an entrypoint: \"exec: \\"-url\\": executable file not found in $PATH\"

Seems to be introduced through commit 4ae1f17df29, where you dropped the java etc. arguments. The commit message says something from a “default behaviour”, but I don’t see how to switch back to the old behaviour.

Thank you for your work and for looking into this!

docker-plugin version: 1.1.3 jenkins version: 2.110 docker engine: 17.09.1-ce

[fxnn]

@pjdarton Tested with Jenkins LTS 2.107.3 and work’s like a charm for me!

I wonder whether the prerequisite text of the connect method could be misleading. It says:

Docker image must either have slave.jar pre-installed or have its entry point code download it.

To me, this sounds a bit like “okay, there’s a slave.jar somewhere, Jenkins will somehow find and launch it”. My suggestion would be

Docker image must launch the slave.jar program by itself or using the “EntryPoint Arguments” option below.

Anyways, thanks a lot for looking into this!

[pjdarton]

I’ve had a go at implementing a solution for this. Can you both (@fxnn and @magn2) please try it out and see if it resolves the situation?

To test it, download the .hpi file from https://ci.jenkins.io/job/Plugins/job/docker-plugin/view/change-requests/job/PR-654/lastSuccessfulBuild/artifact/target/, install it into a test Jenkins server, then drill down to the JNLP configuration for your container (Manage Jenkins -> Configure System -> Cloud -> your docker cloud -> Templates -> your JNLP-using template -> “Connect method”) and then take a look at the new field “EntryPoint Arguments”. Hopefully the (newly written) help text (which shows if you press the round ? icon) will tell you everything you need to know.

If you can try this out for me, and also let me know any comments/feedback you have (e.g. suggestions on different names, different wording on the help text), then there’s a good chance we can get this enhancement included in the next official version of the docker-plugin.