Edition 0 Updated to asp. Net core 0

-
ASPNETCORE_ENVIRONMENT=Development 
-
IdentityUrl=http:
//identity-api
ports:
-
"5200:80"
volumes:
-
./src/ApiGateways/Mobile.Bff.Shopping/apigw:
/app/configuration
mobilemarketingapigw:
environment:
-
ASPNETCORE_ENVIRONMENT=Development 
-
IdentityUrl=http:
//identity-api
ports:
-
"5201:80"
volumes:
-
./src/ApiGateways/Mobile.Bff.Marketing/apigw:
/app/configuration
webshoppingapigw:
environment:
-
ASPNETCORE_ENVIRONMENT=Development 
-
IdentityUrl=http:
//identity-api
ports:
-
"5202:80"
volumes:
-
./src/ApiGateways/Web.Bff.Shopping/apigw:
/app/configuration
webmarketingapigw:
environment:
-
ASPNETCORE_ENVIRONMENT=Development 
-
IdentityUrl=http:
//identity-api
ports:
-
"5203:80"

---

174 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
volumes:
-
./src/ApiGateways/Web.Bff.Marketing/apigw:
/app/configuration
Because of that previous code, and as shown in the Visual Studio Explorer below, the only file needed 
to define each specific business/BFF API Gateway is just a configuration.json file, because the four API 
Gateways are based on the same Docker image. 
Figure 6-34. The only file needed to define each API Gateway / BFF with Ocelot is a configuration file 
By splitting the API Gateway into multiple API Gateways, different development teams focusing on 
different subsets of microservices can manage their own API Gateways by using independent Ocelot 
configuration files. Plus, at the same time they can reuse the same Ocelot Docker image. 
Now, if you run eShopOnContainers with the API Gateways (included by default in VS when opening 
eShopOnContainers-
ServicesAndWebApps.sln solution or if running “docker
-
compose up”), the 
following sample routes will be performed. 
For instance, when visiting the upstream URL 
http://host.docker.internal:5202/api/v1/c/catalog/items/2/
served by the 
webshoppingapigw API Gateway, you get the same result from the internal Downstream URL 
http://catalog-api/api/v1/2
within the Docker host, as in the following browser. 
Figure 6-35. Accessing a microservice through a URL provided by the API Gateway 
Because of testing or debugging reasons, if you wanted to directly access to the Catalog Docker 
container (only at the development environment) without passing through the API Gateway, since 
‘catalog
-
api’ is a DNS resolution internal to the Docker host (service discovery handled by docker
-
compose service names), the only way to directly access the container is through the external port 
published in the docker-compose.override.yml, which is provided only for development tests, such as 
http://host.docker.internal:5101/api/v1/Catalog/items/1
in the following browser. 

---

175 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Figure 6-36. Direct access to a microservice for testing purposes 
But the application is configured so it accesses all the microservices through the API Gateways, not 
through the direct port “shortcuts”.