Skip to content
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

feat: automatic port forwarding for deployed services #1052

Merged
merged 2 commits into from
Aug 6, 2019

Conversation

edvald
Copy link
Collaborator

@edvald edvald commented Jul 31, 2019

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

@edvald edvald requested a review from eysi09 August 1, 2019 10:00
@eysi09 eysi09 requested a review from thsig August 5, 2019 10:39
@thsig thsig self-assigned this Aug 5, 2019
@@ -241,11 +241,11 @@ export async function syncToService(
targetName: string,
log: LogEntry,
) {
const targetDeployment = `${targetKind.toLowerCase()}/${targetName}`
const targetResource = `${targetKind.toLowerCase()}/${targetName}`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the block comment above this function (since we're now relying on a general port-forward cache that's used for more than just hot reloading).

import { isBuiltIn } from "./util"
import { LogEntry } from "../../logger/log-entry"

// TODO: implement stopPortForward handler
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a brief high-level comment here? Maybe something like:

Maintains a simple in-process cache of randomly allocated local ports that have been port-forwarded to a given port on a given Kubernetes resource. This removes the need for the user to manually establish port-forwards for e.g. services defined in Garden config files.

.required()
.description("The target port on the service."),
urlProtocol: joi.string()
.description("The protocol to use for URLs pointing at the port. This can be valid URI protocol."),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"This can be" -> "This can be any"

@edvald edvald force-pushed the automatic-forwarding branch from 2641015 to 7fc64ec Compare August 6, 2019 13:47
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
@thsig thsig force-pushed the automatic-forwarding branch from 7fc64ec to 43b414f Compare August 6, 2019 13:50
@eysi09 eysi09 removed their request for review August 6, 2019 14:02
@eysi09 eysi09 merged commit 0628bba into master Aug 6, 2019
@eysi09 eysi09 deleted the automatic-forwarding branch August 6, 2019 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automatic port-forwarding/tunneling
3 participants