Allow specifying DNS names in addition to ports that should be forwarded

[bamurtaugh]

Feature that allows you to specify DNS names (other than “localhost.*") that resolve to 127.0.0.1 and that are then auto-forwarded.

I searched through existing issues and didn't seem to find one, but please feel free to let me know if I might've missed one.

cc @Chuxel

[Chuxel]

//cc: @kieferrm @roblourens @mjbvz - FYI, the specific scenario here is wanting to use SSL certificates locked to a host name, but the host name is set to 127.0.0.1 via a hosts file both remotely and locally (or corp DNS). The request is to be able to have the "click on link" feature in the terminal or when a browser is opened via launch.json to work in the scenario, while now we only consider localhost, 127.0.0.1, and 0.0.0.0 as far as I know.

[tvvignesh]

@bamurtaugh @Chuxel I am not sure if this is related, but having ability to forward DNS along with ports would be very helpful.

For instance, if I use kubefwd in my VM with remote ssh, and it forwards all the cluster urls at http://my-service:port in my remote machine which I would like to forward to my host machine at http://my-service:port so that I can open it in my browser.

Currently, I don't think it is possible since I can only forward ports via VSCode. Doing this manually via a Socks5 proxy across a SSH with IAP Tunnel as of now.

Adding this may be really helpful.

[Chuxel]

Forward DNS along with ports would be very helpful.

@tvvignesh I'd suggest we pull that out into a separate issue since its local to remote. This is more remote to local.

I tweaked the subject because we've seen an expansion in where this is needed when it comes to Docker Compose - particularly with Codespaces in addition to Remote - SSH. This Docker Compose case makes the problem really obvious, so we'll use that - but the same types of issues exist in the Remote - SSH case as well.

Example

In terms of a concrete example here, let's take a look at a typical Docker Compose definition. This is what you'd normally want to be able to do:

services:
  app:
    build:
      context: ..
      dockerfile: .devcontainer/Dockerfile
    volumes:
      - ..:/workspace:cached
    command: sleep infinity

  db:
    image: postgres:latest
    restart: unless-stopped
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
      POSTGRES_PASSWORD: postgres

volumes:
  postgres-data:

If you connect to the app container that is created, you then have access to postgres in the db container. The database is available on port 5432 in this case. However, the following does not work in devcontainer.json:

{
    "forwardPorts": [ "5432" ]
}

The same is true for automated forwarding and if you use the forward ports UI. Why? Because this port is available at db:5432 not localhost:5432.

Today we have a hack in place in our vscode-dev-containers definitions that uses the same network for all containers. This results in db being on localhost as well from the app container's point of view. That said, this is not a typical setup.

Ideally, you'd be able to do the following:

{
    "forwardPorts": [ "db:5432" ]
}

This would then need support in the UI as well.

Auto-forwarding

Its unclear if we can automatically detect this scenario and auto-forward, but it's also worth noting that these URIs will show up in debug output and the terminal. So, we would want a declarative way to indicate which domains/IPs should be treaded like they are in the container. Consider this terminal output:

Application running at http://localhost:3000
Database admin running at http://db:1234

Clicking on http://db:1234 should trigger port forwarding and a browser then appears at localhost on the local machine if db is configured as a known domain.

Perhaps devcontainer.json could include something like this to make this possible:

{
    	"otherPortsAttributes": {
		"autoForwardDomains": [
			"db",
                       "my.domain.in.etc.hosts",
			"142.134.1.22"
		]
	}
}

Remote - SSH

There have been similar asks for Remote - SSH, but in this case devcontainer.json is not available. That said, the otherPortsAttributes property above could be used for Remote - SSH in settings.json.

I also would assume we would want to include the option to specify a different domain in the general port forwarding UX so it could be used across the board for more ad-hoc use that would be typical for Remote - SSH.

[alexdima]

Some part of this is now done via microsoft/vscode#131399. It is now possible (at the low-level layer) to create a tunnel to a destination host that is reachable via the remote machine's network.

[alexr00]

What already works:

• Entering host:port in the Ports UI

What needs work:

• 🏃 Handle host:port in the portsAttributes setting/devcontainer.json (schema is already ok with it, so not changes needed to the schema)
• 🏃 Allow and handle host:port in "forwardPorts" in devcontainer.json.
• 🏃 When the host isn't localhost or 0.0.0.0, we should show the host in the Ports view.

[alexr00]

Examples of the host+port displaying in the "Port" column in the Ports view: