search

jenkinsci / azure-vm-agents-plugin

This repo is for azure vm agents plugin for jenkins. Azure devops CICD is the team which owns it for now
https://plugins.jenkins.io/azure-vm-agents/
46 stars 102 forks source link

Inbound: support for websockets #421

Open dduportal opened 1 year ago

dduportal commented 1 year ago

What feature do you want to see added?

In https://github.com/jenkinsci/azure-vm-agents-plugin/pull/406, a new launch method for inbound agents on Linux was introduced.

The documentation states that it requires the TCP port for agent protocol to be set up, static and reachable.

I would like to be able to specify "Websockets" like I can do with permanent agents or Kubernetes agents, so the agent would connect to the controller through HTTP+Websockets to avoid setting up and opening this TCP port (which cannot be load balanced).

Upstream changes

https://github.com/jenkinsci/azure-vm-agents-plugin/pull/406

timja commented 1 year ago

This makes sense although it could be worked around by explicitly telling it to use websockets in a similar manner to https://github.com/jenkinsci/azure-vm-agents-plugin/issues/422#issuecomment-1544727885

I've tested locally (with just a permanent agent) and this worked:

java -cp ~/Downloads/agent.jar hudson.remoting.jnlp.Main -headless -webSocket -url http://localhost:8080/jenkins -workDir /tmp/work $SECRET $AGENT_NAME

opening this TCP port (which cannot be load balanced).

What do you mean by cannot be loadbalanced? You can't load balance Jenkins anyway?

dduportal commented 1 year ago

Thanks I'm going to try the solution with init script, and if it works I'll send a documentation PR.

Same as https://github.com/jenkinsci/azure-vm-agents-plugin/issues/422#issuecomment-1545158636: it would we a nice UX if the end user could set up the agent through the UI and have it preconfigured (I guess passing userdata to the VM would help for this one, I'll give it a try as well).

What do you mean by cannot be loadbalanced? You can't load balance Jenkins anyway?

The controller itself: no. But the route from the agent process location to a given controller can have many moving paths and my experience with the JNLP over TCP is such setup is not the most positive one, while websockets has embeded retries mechanisms (also, easier to expose as HTTP(s) already is and less configuration).

But it's a nice to have of course :)