search

KostyaSha / yet-another-docker-plugin

Jenkins Yet Another Docker Plugin
https://plugins.jenkins.io/yet-another-docker-plugin
MIT License
83 stars 48 forks source link

Cannot use yet-another-docker-plugin JNLP agents in Jenkins 2.248+ #288

Open orsoly opened 4 years ago

orsoly commented 4 years ago

After upgrading to Jenkins version 2.248 yad slaves cannot connect to Jenkins master. I'm using the "Different Jenkins master URL" option, but the slaves only try to connect to the primary URL of the Jenkins master (the one specified in Jenkins global config). In previous Jenkins versions yad slaves also tried to connect using the primary URL, but when that failed they tried to connect using the "Different Jenkins master URL". The fix for the following issue introduced this regression: https://issues.jenkins-ci.org/browse/JENKINS-63014.

I opened a ticket in Jenkins Jira for the issue: https://issues.jenkins-ci.org/browse/JENKINS-63222. In the discussion they suggest that the way yad plugin uses the agent launcher is incorrect. It shouldn't use -jnlpUrl option to pass the different URL, instead it should use directly a lower level launch mode. So instead of: java -jar agent.jar -jnlpUrl https://jenkins/computer/myagent/slave-agent.jnlp -secret xxx123 use it this way: java -classpath agent.jar hudson.remoting.jnlp.Main -headless -url https://jenkins/ xxx123 myagent

Jenkins version: 2.248+ YAD version: 0.2.0

KostyaSha commented 4 years ago

According to comments it will loose workdir parameter that is really need, so it needs more investigation.

jglick commented 4 years ago

If you are defining special workdir parameters then those should be added as well.

KostyaSha commented 4 years ago

Need find some time to double check everything. Afair i used all available features during implementation...

jglick commented 4 years ago

Basically the -jnlpUrl form is just a convenience that starts off by asking Jenkins for arguments to pass to the lower-level hudson.remoting.jnlp.Main form based on the JNLPLauncher configuration, including where applicable -webSocket, -workDir, etc. This always defined -url preferentially as the configured Jenkins root URL. It used to also pass a second -url based on the prefix of -jnlpUrl if that was different, which TCP-based (but not WebSocket-based) agents honored by trying and failing to use the first URL and then falling back to the second. As of https://github.com/jenkinsci/jenkins/pull/4839 this trick was dropped and only the one -url based on the official Jenkins root URL is listed. If YAD allows you to explicitly request an alternate URL to access Jenkins from, that is fine, but it should use the lower-level form and pass that -url (exclusively, not as a fallback).

If you are using the inbound-agent image (as for example the kubernetes plugin does), then it uses hudson.remoting.jnlp.Main directly, configured typically via environment variables. The kubernetes plugin actually has a similar feature to allow you to specify a custom Jenkins access URL (per KubernetesCloud), useful for bypassing ingress for agents inside the same cluster as the controller; it implements this by defining that alternate URL as an environment variable which the entry point image in the script honors.

Hope that clears things up.

danieleagle commented 4 years ago

I too am affected by this issue. I had to revert back to Jenkins 2.235.5. @KostyaSha, thanks for looking into this. Also, @jglick, thanks for providing the insights on why the issue exists and how best to resolve it.

Sherpard commented 4 years ago

Same here, affected by this Issue, I've been looking for a way to override the Jenkins url at jnlp file, but seems that is not possible.,

Sherpard commented 4 years ago

I ended up switching from JNLP launch method to SSH, SSH works quite well if you can solve the issues with JNLP missing URL, as it relies on Master being able to see the slaves, and not the other way arround