Edition 0 Updated to asp. Net core 0

if
(item != 
null
) 
{ 
return
Ok
(item); 
} 
return
NotFound
(); 
} 
The HTTP request will end up running that kind of C# code accessing the microservice database and 
any additional required action. 
Regarding the microservice URL, when the containers are deployed in your local development PC 
(local Docker host), each microservice’s container always has an internal port (usually port 80) 
specified in its dockerfile, as in the following dockerfile: 
FROM
mcr.microsoft.com/dotnet/aspnet:7.0 AS base 
WORKDIR
/app 
EXPOSE
80 
The port 80 shown in the code is internal within the Docker host, so it can’t be reached by client apps.
Client apps can access only the external ports (if any) published when deploying with 
docker-
compose
. 
Those external ports shouldn’t be published when deploying to a production environment. For this 
specific reason, why you want to use the API Gateway, to avoid the direct communication between the 
client apps and the microservices. 
However, when developing, you want to access the microservice/container directly and run it through 
Swagger. That’s why in eShopOnContainers, the external ports are still specified even when they won’t 
be used by the API Gateway or the client apps. 
Here’s an ex
ample of the 
docker-compose.override.yml
file for the Catalog microservice: 
catalog-api:
environment:
-
ASPNETCORE_ENVIRONMENT=Development 
-
ASPNETCORE_URLS=http:
//0.0.0.0:80
-
ConnectionString=YOUR_VALUE 
-
... Other Environment Variables 

---

167 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
ports:
-
"5101:80"
# Important: In a production environment you should remove the external 
port (5101) kept here for microservice debugging purposes.
# The API Gateway redirects and access through the internal port (80).
You can see how in the docker-compose.override.yml configuration the internal port for the Catalog 
container is port 80, but the port for external access is 5101. But this port shouldn’t be used by the 
application when using an API Gateway, only to debug, run, and test just the Catalog microservice. 
Normally, you won’t be deploying with docker
-compose into a production environment because the 
right production deployment environment for microservices is an orchestrator like Kubernetes or 
Service Fabric. When deploying to those environments you use different configuration files where you 
won’t publish directly any external port for the microservices but, you’ll always use the reverse proxy 
from the API Gateway. 
Run the catalog microservice in your local Docker host. Either run the full eShopOnContainers solution 
from Visual Studio (it runs all the services in the docker-compose files), or start the Catalog 
microservice with the following docker-compose command in CMD or PowerShell positioned at the 
folder where the 
docker-compose.yml
and 
docker-compose.override.yml
are placed. 
docker-compose run --service-ports catalog-api 
This command only runs the catalog-api service container plus dependencies that are specified in the 
docker-compose.yml. In this case, the SQL Server container and RabbitMQ container. 
Then, you can directly access the Catalog microservice and see its methods through the Swagger UI 
accessing directly through that “external” port, in this case 
http://host.docker.internal:5101/swagger
: 

---

168 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Figure 6-31. Testing the Catalog microservice with its Swagger UI 
At this point, you could set a breakpoint in C# code in Visual Studio, test the microservice with the 
methods exposed in Swagger UI, and finally clean-up everything with the 
docker-compose down
command. 
However, direct-access communication to the microservice, in this case through the external port 
5101, is precisely what you want to avoid in your application. And you can avoid that by setting the 
additional level of indirection of the API Gateway (Ocelot
, in this case). That way, the client app won’t 
directly access the microservice.