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

Automatic port-forwarding/tunneling #967

Closed
baspetersdotjpeg opened this issue Jul 15, 2019 · 1 comment · Fixed by #1052
Closed

Automatic port-forwarding/tunneling #967

baspetersdotjpeg opened this issue Jul 15, 2019 · 1 comment · Fixed by #1052

Comments

@baspetersdotjpeg
Copy link
Contributor

Adding feature request here for visibility of a user.

@edvald please expand your thoughts here!

@psoares
Copy link

psoares commented Jul 24, 2019

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:

FROM adoptopenjdk/openjdk11-openj9:jdk-11.0.1.13-alpine-slim
COPY build/libs/*.jar /app/backend.jar
EXPOSE 8080 5005
CMD java  -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dcom.sun.management.jmxremote -noverify ${JAVA_OPTS} -jar /app/backend.jar

And this is what my garden.yml file looks like for that module:

kind: Module
name: backend
description: Backend service container
type: container
hotReload:
  sync:
    - target: /app/build
      source: build
services:
  - name: backend
    env:
      JAVA_OPTS: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
    ports:
      - name: http
        containerPort: 8080
        # Maps service:80 -> container:8080
        servicePort: 80
      - name: debug
        containerPort: 5005
    ingresses:
      - path: /
        port: http

Now... when I run garden dev, I need to do an extra step of kubectl -n my-namespace port-forward backend-xyz 5005. Only then am I able to attach a remote debugger on localhost:5005 to the project from my IDE (IntelliJ).

edvald added a commit that referenced this issue 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 added a commit that referenced this issue Aug 6, 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
thsig pushed a commit that referenced this issue Aug 6, 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants