-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic port-forwarding/tunneling #967
Comments
I have a use case like this. I run a java application with remote-debugging arguments. Those expose a remote debugger on port 5005. This is what the dockerfile for my java project looks like:
And this is what my garden.yml file looks like for that module:
Now... when I run |
This adds a built-in TCP proxy for long-running Garden processes, that immediately opens a port for each forwardable service port (as specified by providers) and creates a tunnel on-demand when the port is accessed. This should work for any TCP port, and is implemented here for the kubernetes provider, but the proxy itself could be implemented for other providers through the fairly simple `getPortForward` handler interface. Unlike kubefwd, for example, this implementation avoids any need to mess with domain names or host files (and by extension running as root) since a random free port is assigned directly on localhost. The tunnels are only created when a connection is first made, and are then kept alive while the Garden agent is running. Closes #967
This adds a built-in TCP proxy for long-running Garden processes, that immediately opens a port for each forwardable service port (as specified by providers) and creates a tunnel on-demand when the port is accessed. This should work for any TCP port, and is implemented here for the kubernetes provider, but the proxy itself could be implemented for other providers through the fairly simple `getPortForward` handler interface. Unlike kubefwd, for example, this implementation avoids any need to mess with domain names or host files (and by extension running as root) since a random free port is assigned directly on localhost. The tunnels are only created when a connection is first made, and are then kept alive while the Garden agent is running. Closes #967
This adds a built-in TCP proxy for long-running Garden processes, that immediately opens a port for each forwardable service port (as specified by providers) and creates a tunnel on-demand when the port is accessed. This should work for any TCP port, and is implemented here for the kubernetes provider, but the proxy itself could be implemented for other providers through the fairly simple `getPortForward` handler interface. Unlike kubefwd, for example, this implementation avoids any need to mess with domain names or host files (and by extension running as root) since a random free port is assigned directly on localhost. The tunnels are only created when a connection is first made, and are then kept alive while the Garden agent is running. Closes #967
Adding feature request here for visibility of a user.
@edvald please expand your thoughts here!
The text was updated successfully, but these errors were encountered: