How to publish ports for elastic agents that are created through this plugin

[alanzheng88]

I would like to have a webserver running on the elastic agent which would be accessible from the host (unconventional 😅 but i would like to make this happen).

Would there be an easy way to publish certain ports? Currently my elastic agent is launched via the custom bootstrapper script and I was hoping to have my web server built and running on the same instance as the elastic agent, but there doesn't seem to be any parameters I can pass into the autoregister.properties that will allow me to simulate the same behaviour as docker run -p <host_port>:<container_port> <image_name>

I also looked into the java class files that was used to create agent.jar (used to start up new elastic agents) and didn't notice anything evident that will allow me to pass additional parameters to the docker cli command.

Any help will be appreciated :)

[chadlwilson]

There's no way of doing this short of changing plugin code, as plugin code interacts with the docker daemon via its API using a Java client to create containers with the config from your elastic profile. It doesn't rely on docker cli tools.

This doesn't really sound like the right use of an ephemeral agent though. If you share what you're trying to achieve, perhaps there are alternate approaches that can be suggested.

[alanzheng88]

thanks @chadlwilson! that confirms my suspicions. Not a problem! I'll look into a workaround.. the intention was to be able to easily create temporary servers started by the goagent which i can quickly verify functionality from the host and then tear down. In order to do this, I would need to expose certain ports to be accessible by the host. I also wanted to avoid having the goagent create other docker containers which will only create unneeded complexity. I've been extending existing dockerfiles with the elastic goagent dockerfile so that I am able to reuse the goagent implementation for various use cases. I wanted the goagent to behave as anything that I would like it to, but this most likely goes outside the responsibility of an ephemeral agent (exactly like you said)

[chadlwilson]

I think perhaps you should look at your agent image differently from what actually runs on it. Normally folks will keep an agent image generic with perhaps a standard set of tools, but not their custom software baked into it.

Instead they will script or use build automation tools to do that inside their tasks, e.g to pull a server artifact from elsewhere (or an artifact store) and then start it from the wrapping agent process/container, run tests against it, then tear it down afterwards. This more loosely couples the agents from what they do inside them.

Ie the 'anything I want it to do' is addresed by tasks and source controlled build scripting/tooling rather than customizing the agent itself (except to perhaps provide common build tooling for their use case). Some use docker-in-docker to achieve that, but it's not the only way.