search

microsoft / mindaro

Bridge to Kubernetes - for Visual Studio and Visual Studio Code
MIT License
307 stars 106 forks source link

VS Code Remote-WSL not working #90

Open Zetanova opened 3 years ago

Zetanova commented 3 years ago

Describe the bug vscode with remote-wsl: ubuntu startup of the EndpointManager fails. The same setup without remote-wsl works.

To Reproduce Try to debug the sample-app over vs code remote-wsl: ubuntu

Logs VS Code Output:

Bridge to Kubernetes initialization (VS Code v1.51.1 - Extension v1.0.120201118)
Logs: /home/zeta/.vscode-server/data/logs/20201208T170225/exthost1/mindaro.mindaro/mindaro-vscode-2020-12-08T16-02-33.065Z.txt
Waiting for EndpointManager to come up ...
The process has exited.
Failed to establish a connection. Error: The process has exited.

mindaro-vscode-2020-12-08T16-02-33.065Z.txt

Environment Details Client used: VS Code Client's version: mindaro.mindaro@1.0.120201118 Operating System: Windows 10, WSL2 ubuntu 20.04

Info The warning message that the hosts file will be modified still comes, indicate the extension does not recognize that it is running under linux / remote-wsl

pragyamehta commented 3 years ago

Hi @Zetanova Thanks for reporting this issue. We will investigate and get back to you soon!

pragyamehta commented 3 years ago

Hi @Zetanova We cannot start the EndpointManager in the case of WSL because we require elevated permissions for this process, and we cannot request them when working in remote development scenarios. We're investigating workarounds (typically: removing our elevated permissions requirements) but we don't have something to share yet. We want to understand how big of a blocker this is for you. Is it possible for you to use Bridge to Kubernetes without WSL? Could you provide details about your setup? We do have a Visual Studio solution as well.

Zetanova commented 3 years ago

Thx, for your reply

I can't use the visual studio extension because it supports only AKS, so I looked into the vs code option.

I would need to connect to my akka.net cluster and expose one tcp port for it.

some other drawback of this extension is that it is discovering only service endpoints of the k8s and not headless service.

Meanwhile I looked at telepresence and is working somehow with wsl2 and it can start an docker-container and with vscode remote: container it is possible to connect to it.

It would be great to have some kind of visual studio over docker-compose option.

pragyamehta commented 3 years ago

Hi @Zetanova We are releasing an update to the Visual Studio extension next week which will support any Kubernetes - as long as you have a kubeconfig to connect to your Kubernetes cluster, you should be able to use Bridge to Kubernetes on Visual Studio to debug. This functionality is already supported in VS Code.

Regarding headless service support, we have not heard a lot of customers asking for this, but we will explore supporting this in future.

For Visual Studio over docker-compose option - could you elaborate on what experience you expect to be supported here? What's the scenario that you have where that integration would be valuable?

Zetanova commented 3 years ago

In my experience all dotnet core apps for kubernetes are concertized.

In Visual Studio docker-compose is used to debug a concertized dotnet core app. It is overriding the docker-compose.yaml with an entrypoint tail -f /dev/null and using the running container as the debug environment. https://docs.microsoft.com/en-us/visualstudio/containers/container-build?view=vs-2019

My point is that an sidecar container could be hosted and added to the same network to provide the local debug-container the bridge to kubernetes.

lippylee commented 3 years ago

I'm currently facing this issue as well. It'd be nice to have a means of running EndpointManager without elevated permissions. Or to use a workaround for this if there's any?

I'm currently building a new cross platform development environment for my team with multi OS support. WSL2 + docker desktop would allow us to re-use most of what we're preparing for the Linux & MacOS.

Zetanova commented 3 years ago

@lippylee I tested now view methods. I am using vscode for everything but never before for dotnet / c# projects.

1) vscode: bridge to kubernetes Pro: easy for simple services Cons: usage of vscode for now, only working on the windows host, not as a container, proxies all service ports in the k8s. 2) vscode remote connect directly to a development pod running into kubernetes. Pro: working, direct network Cons: usage of vscode, hat some reconnection issues when vscode tries to access large files. 3) vscode remote: container + container hosted local by telepresence Pro: working, full routing Cons: usage of vscode, telepresence prestart required 4) vscode remote: wsl2 + telepresence running in wsl2 Pro: easy, working, near everything is routed Cons: usage of vscode, not a container, only a single project can be debugged at a time, ENV vars are not automatically in the debug session 5) visual studio 2019 + Extension wsl2 + running telepresence in wsl2 Pro: working, near everything is routed Cons: not as a container, only a single project can be debugged at a time ENV vars are not automatically in the debug session

greenie-msft commented 3 years ago

Hi @Zetanova,

Thank you for the feedback and for clarifying the scenarios you would like to see Bridge support. We are in the early stages of exploring running a local container(s) in combination with Bridge to Kubernetes. If it is okay with you, I might reach out with some additional questions as we make progress in our explorations.

Thank you, Nick

Zetanova commented 3 years ago

@greenie-msft I got yesterday option 5. working for me and should be enough for now. But an option directly over vs2019 hosted containers would be better.

Pls fill free to ask me.

daniv-msft commented 3 years ago

Thanks @Zetanova for your reply. @lippylee > As of today, we require elevated permissions to run the EndpointManager. However, we're investigating other possibilities to use Bridge without administrator rights, and we'll keep you updated once we have something to share. Adding @rakeshvanga who is working on this.

rakeshvanga commented 3 years ago

@Zetanova We have released a feature Use Kubernetes Service Environment variables which wouldn't require administrator rights to debug on WSL. Please find more information about this feature and the required changes to make it work here: VS Code docs.

Let me know if you have any more questions or issues while using this feature.