Skaffold: Change the default behavior to forward ports?

Created on 13 May 2020  路  10Comments  路  Source: GoogleContainerTools/skaffold

Expected behavior

Running skaffold dev would bind user-defined port-forwarding by default - OR - allow you to configure it to be bound automatically without the need for the --port-forward argument.

Actual behavior

I couldn't find a way to do this. Additionally, I tried defining them in a profile that auto-activates but the ports still don't forward without adding the --port-forward argument.

Information

Running skaffold dev is expected to start a development environment, but the default functionality is that you can't interact with any of the services you are developing and the user-defined port forwarding rules are ignored?

I may have missed the intended way of doing this

areportforward fixit kinfeature-request kinfriction needs-design-proposal prioritp1

Most helpful comment

FWIW I would prefer skaffold dev to:

  1. By default forward no ports
  2. If there are user defined ports in the skaffold.yaml file then forward them (if you don't want them don't add them)
  3. If autoPortForwarding (or some other field) is true in skaffold.yaml then forward ports for all services automatically (if you don't want this don't enable it)

All of this helps to create a simple workflow. You configure everything in the skaffold file and then a simple skaffold dev lets you start developing and skaffold run lets you deploy a production build.

I guess i'm spoiled by the npm ecosystem, javascript devs set things up in their package.json file, hide all the configuration in source control and use simple commands for development and deployment

All 10 comments

--port-forward has to be set to true manually, on the command line. Is that pointless, I don't know... It used to be on by default but people found that too intrusive.

I wonder if the reason they find it intrusive was due to auto port forwarding as opposed to the user defined port forwards.

I'm curious how people are developing applications if they can't access them.

The two common use cases I would have assumed are Websites and API's

Websites need a port forwarded so that you can view it in the browser while developing.

API's need the port forwarded so the website can make requests to it.

So when I say pointless, i'm thinking from this point of view. skaffold dev does nothing for almost everything i've ever built without the --port-forward arg.

I might be in the minority and people are using skaffold for completely different use-cases?

For eg, users that develop with Docker Desktop have automatic port forwarding so they don't need skaffold to start its own.

FWIW I would prefer skaffold dev to:

  1. By default forward no ports
  2. If there are user defined ports in the skaffold.yaml file then forward them (if you don't want them don't add them)
  3. If autoPortForwarding (or some other field) is true in skaffold.yaml then forward ports for all services automatically (if you don't want this don't enable it)

All of this helps to create a simple workflow. You configure everything in the skaffold file and then a simple skaffold dev lets you start developing and skaffold run lets you deploy a production build.

I guess i'm spoiled by the npm ecosystem, javascript devs set things up in their package.json file, hide all the configuration in source control and use simple commands for development and deployment

Oh my god! Finally! I could no figure out for the life of me why I couldn't access any of my services.

Yup, absolutely second @ashconnell - if skaffold aims to be simple enough for junior developers (and senior developers like me :cry: ), rather than devops engineers, I think this'd be helpful as a default. Because I was looking at all the files in my k8s directory and going "But the ports are mapped! Why no worky!!!".

If not possible (or wise) to reintroduce as a default, making this settable (like option 3 in the above comment) and adding that to the getting-started examples (so people like me pick up on that being a thing we need to do) would be a very good compromise :)

I think we probably want to keep the default the way it is right now (port forwarding OFF by default), but I also understand that it isn't great UX to have to provide the --port-forward flag just to get any forwarding to happen. I'd be ok adding a portForward or autoPortForward boolean to the deploy section of the skaffold.yaml to give devs a "happy path" for running skaffold dev with the behavior they expect.

@briandealwis also had the idea of changing the --port-forward flag to accept the list of resources users want to see automatically forwarded - so something like --port-forward=pods,services to automatically forward all pods and services, or --port-forward=services,manual to honor user-defined forwarding supplemented with automatic forwarding of all services. something that can happen independently of configuring port forwarding through the skaffold.yaml though.

I'm all for this improvement :P

Every time i come back to a skaffold project i run skaffold dev and then stumble around remembering whether it was --forward-ports or --port-forwarding or something just to get the dev environment up.

Much better to have this configuration in the code itself!

We could also add a debug option to allow forwarding debug ports (these are identified in the debug metadata added as an annotation). That would avoid us magically port-forwarding all pod containerPorts when in debug mode (e.g., port 8080).

My suggested values would be:

  • "pods": all containerPorts
  • services
  • user: the portForwards listed in the skaffold.yaml
  • debug: an internal port strategy
  • none: no ports are ever forwarded

I'd suggest that we'd default to user. Maybe service too?

Note: This issue GoogleCloudPlatform/cloud-code-vscode-internal#2155 is p1 and we should probably also mark it as p1.

I thought for more than one week now this was a bug. Glad that it's just friction, though. :smile: — based on my intuitive judgment of what skaffold dev would do.

When somebody decides to work on this: as a collateral, those should be valid URLs — so they are clickable in some terminals:
image

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stanislav-zaprudskiy picture stanislav-zaprudskiy  路  4Comments

nathanph picture nathanph  路  3Comments

woodcockjosh picture woodcockjosh  路  4Comments

abatilo picture abatilo  路  4Comments

emichaf picture emichaf  路  4Comments