dotnet-architecture / eShopOnContainers

Cross-platform .NET sample microservices and container based application that runs on Linux Windows and macOS. Powered by .NET 7, Docker Containers and Azure Kubernetes Services. Supports Visual Studio, VS for Mac and CLI based environments with Docker CLI, dotnet CLI, VS Code or any other code editor. Moved to https://github.com/dotnet/eShop.
https://dot.net/architecture
24.57k stars 10.36k forks source link

System.IO.IOException: 'Failed to bind to address http://[::]:80: address already in use.' #1530

Closed Steel9561 closed 3 years ago

Steel9561 commented 3 years ago

Hi there, this is the first time I setup the eShopOnContainers on my local Windows 10 PC. I setup docker desktop and all the required tools (.Net Core 3.1, etc...).

After setting everything up, I ran the application. The app itself is loading on my browser BUT I am getting an error while running it. Anyone has any idea where I need to update the port? This is happening on the ApiGw-Base project, any ideas please?

image

sughosneo commented 3 years ago

Hi @Steel9561, thank you for reaching out.

From the screenshot I notice 2 things :

1) Could you please check if any other service is listening on port 80 ? 2) You are using the master branch which is not the latest. Could you please test out the dev branch ? Please note, master branch is the previous LTS release branch where dev always contains the latest changes. Similarly, when we would update the eShopOnContainers app to .NET 5.0, all the changes will happen in the dev branch and the previous changes would be merged to master for future reference

You could refer eShopOnContainers - wiki for more deails.

Steel9561 commented 3 years ago

Hi @sughosneo , appreciate the reply.

I am going to try working on the DEV branch and see if that helps. For now, I checked port 80, System is running under port 80:

image

Steel9561 commented 3 years ago

Hi @sughosneo ,

After cloning the Dev branch, I think I might be on a better direction. However, I Am getting a DB connection error when calling the MIgrate method. Where am I suipposed to update this connection string?

Also, on top of my head, I have 2 quick questions for you please, if you can answer them for me would really and greatly appreciate it:

  1. Why the decision of running each microservice inside a container instead of running them as independent services with no container?

  2. Why each microservice uses a different database, in a real world production app all microservices would point to one single database?

  3. What's the reason you moved from Ocelot to Envoy?

image

sughosneo commented 3 years ago

Hi @Steel9561, thanks for the update.

If you are running the application in your local in VS environment then you can update the ConnectionString property in the appsettings.json file. For e.g : In Catalog.API project, you can update ConnectionString property in appsettings.Development.json file.

Q-1) Technically you can do that. But with the use of a container you can build once and deploy anywhere. You may want to refer .NET microservices - DevOps e-book to understand more benefits of the containerized application.

Q-2) An important rule for microservices architecture is that each microservice must own its domain data and logic. In a real production scenario also you should follow the same approach. For more details, you can refer Data sovereignty per microservice

Q-3) We made this design choice because of Envoy's built-in support for the WebSocket protocol, required by the new gRPC inter-service communications implemented in eShopOnContainers. However, we've retained this section in the guide so you can consider Ocelot as a simple, capable, and lightweight API Gateway suitable for production-grade scenarios.

Hope this helps !

Steel9561 commented 3 years ago

Thanks so much @sughosneo. Appreciate the answers!!