Unable to simultaneously run services in VS and VS Code via Bridge for Kubernetes

[a-keen]

Describe the bug I have the need to simultaneously run one or more services in VS and another service in VS Code. When doing so, I get an error that Port 80 is already in use. This used to work sometimes, based on the order of running the services but now I cannot get it to work anymore regardless of the order. I can run the services with no problem on their own.

To Reproduce Error 1 - Error in VS Code:

1. Run service A (Asset.RestAPI) in VS and wait for it to come up.
2. Run service B (webbff) in VS Code
   • Error seen in VS Code:

     Waiting for EndpointManager to come up ...
     EndpointManager came up successfully.
     Hosts file updated.
     Port 80 is already in use on your machine. Please free this port and try again. If you are using Windows please disable the BranchCache service to free port 80. Services such as IISAdmin, HTTP or World Wide Web Publishing Service could also use port 80. Please stop them.
     Stopping workload and cleaning up...
     Restore: Pod 'andrewke-webbff-9b64474c4-68tql' deleted.
     Failed to establish a connection. Error: Port 80 is already in use on your machine. Please free this port and try again. If you are using Windows please disable the BranchCache service to free port 80. Services such as IISAdmin, HTTP or World Wide Web Publishing Service could also use port 80. Please stop them.

     

• Also received the attached screenshot as an error once.

Error 2 - Error in VS:

1. Run service B (webbff) in VS Code and wait for it to come up.
2. Run service A (Asset.RestAPI) in VS
   • Error seen in VS:

Expected behavior I expect that I can run a service in VS and another service in VS code at the same time.

Logs 2021-09-13T16-06-16.1108604.log

Environment Details Client used: Visual Studio:

• Microsoft Visual Studio Enterprise 2019 Version 16.11.2

VS Code:

• Visual Studio Code Version 1.60.0
• mindaro-dev.file-downloader@1.0.11
• mindaro.mindaro@1.0.120210803

Operating System: Windows 10 Enterprise

[a-keen]

Update: It seems to work sometimes with mindaro.mindaro@v1.0.120210709

[pragyamehta]

Hi @a-keen As per the error displayed, you need to disable BranchCache service on your machine to use Bridge to Kubernetes to debug a service running on port 80. Once you do that, you should be unblocked. Please make sure you disable it in such a way that it does not automatically start up again. Let us know if you have any questions. Thanks!

[a-keen]

Hi @pragyamehta, thank you for the response. The BranchCache service has been disabled, but I still have sporadic issues. Do you have any other suggestions?

[pragyamehta]

Hi @a-keen thanks for your response. The 2 services you are trying to debug simultaneously - what ports do they run on locally? Also when the debugging for the first service starts in VSCode, can you send the output you see in the output window?

[a-keen]

The webff service runs on port 8000 and the Asset service runs on port 8011. Here is the VSCode output for a successful debugging session start:

Redirecting Kubernetes service webbff to your machine...
Target cluster: Dev
Current cluster: Dev
Target namespace: default
Current namespace: default
Target service name: webbff
Target service ports: 8000
Isolating service with routing header: andrewke
Using kubernetes service environment variables: false

Retrieving the current context and credentials...
Validating the credentials to access the cluster...
Validating the requirements to replicate resources locally...
Redirecting traffic from the cluster to your machine...
Loaded Bridge To Kubernetes environment file 'KubernetesLocalProcessConfig.yaml'.
Routing successfully enabled for service through pod 'andrewke-webbff-58865cf754-mt52f' in namespace 'default'.
Waiting for 'andrewke-webbff-58865cf754-mt52f' in namespace 'default' to reach running state...
Pod 'andrewke-webbff-58865cf754-mt52f' created in namespace 'default'.
Remote agent deployed in container 'webbff' in pod 'andrewke-webbff-58865cf754-mt52f'.
Preparing to run Bridge To Kubernetes configured as pod default/andrewke-webbff-58865cf754-mt52f ...
Connection established.
Waiting for EndpointManager to come up ...
EndpointManager came up successfully.
Hosts file updated.
Service 'tenantrelationshiprestapi' is available on 127.1.1.1:80.
Service 'traefik' is available on 127.1.1.2:80.
Service 'traefik' is available on 127.1.1.2:443.
Service 'asseteventproducerservice' is available on 127.1.1.3:80.
Service 'tenantrelationshipeventproducerservice' is available on 127.1.1.4:80.
Service 'documenteventproducerservice' is available on 127.1.1.5:80.
Service 'jobrestapi-cloned-routing-svc' is available on 127.1.1.6:80.
Service 'documentrestapi' is available on 127.1.1.7:80.
Service 'jobrestapi' is available on 127.1.1.8:80.
Service 'assetrestapi' is available on 127.1.1.9:80.
Service 'integrationeventproducerservice' is available on 127.1.1.10:80.
Service 'kubernetes' is available on 127.1.1.11:443.
Service 'tenanteventproducerservice' is available on 127.1.1.12:80.
Service 'webbff-cloned-routing-svc' is available on 127.1.1.13:80.
Service 'taskeventproducerservice' is available on 127.1.1.14:80.
Service 'jobeventproducerservice' is available on 127.1.1.15:80.
Service 'webbff' is available on 127.1.1.16:80.
Service 'notificationrestapi' is available on 127.1.1.17:80.
Service 'tenantrestapi' is available on 127.1.1.18:80.
Service 'authorizationrestapi' is available on 127.1.1.19:80.
Service 'authorizationeventproducerservice' is available on 127.1.1.20:80.
Service 'jobcosteventproducerservice' is available on 127.1.1.21:80.
Service 'traefik-cloned-routing-svc' is available on 127.1.1.22:80.
Service 'traefik-cloned-routing-svc' is available on 127.1.1.22:443.
Service 'notificationeventproducerservice' is available on 127.1.1.23:80.
Service 'taskrestapi' is available on 127.1.1.24:80.
Service 'integrationrestapi-cloned-routing-svc' is available on 127.1.1.25:80.
Service 'jobcostrestapi-cloned-routing-svc' is available on 127.1.1.26:80.
Service 'reporteventproducerservice' is available on 127.1.1.27:80.
Service 'automationrestapi' is available on 127.1.1.28:80.
Service 'reportrestapi' is available on 127.1.1.29:80.
Service 'integrationrestapi' is available on 127.1.1.30:80.
Service 'jobcostrestapi' is available on 127.1.1.31:80.
Container port 80 is available at localhost:8000.
##################### Environment started. #############################################################
Run C:\Users\AndrewKe\AppData\Local\Temp\tmp-13980LRo5jvTVcf7B.env.cmd in your existing console to also get connected.```

[a-keen]

It seems to have been working if I retry immediately 1x or 2x after the port 80 error regardless of if it's VS or VS Code that is started second and throwing the error.

[pragyamehta]

@a-keen Can you try this in VSCode and let us know what you observe - Start the first debugging session. Check and kill BranchCache and IIS if they are running on your machine. Also try to see if anything else is occupying port 80 on your machine using netstat -ano and try to kill it. Then try starting the second debug session. Kindly let us know what you observe.

[a-keen]

IIS and BranchCache are off and I have been trying to monitor the result of netstat -ano to see if there was anything running on port 80 when it failed and I did not see anything that stuck out. The only things I saw on port 80 were these services for Bridge:

Based on what I saw in the command output, there didn't seem to be any indication of it was going to fail or not.