2

I am trying to build a docker-compose app consisting of an angular ui and a .net core webapi. However, the UI cannot communicate with the webapi, as I get an ERR_NAME_NOT_RESOLVED when I try to refer to the webapi.

Here is my docker-compose.yml

   version: '3'
   services:
     ui:
       image: demoui
       container_name: demoui
       build:
         context: ./DemoUI/
         dockerfile: Dockerfile
       ports:
         - '8080:80'
     api:
       image: demoapi
       container_name: api
       build:
         context: ./DemoApi/DemoApi/
         dockerfile: Dockerfile
       ports:
         - '80'

And here are the corresponding dockerfiles:

WebApi

# Build Stage
FROM microsoft/aspnetcore-build:2 AS build-env
WORKDIR /api

COPY DemoApi.csproj .
RUN dotnet restore


COPY . .
RUN dotnet publish -c Release -o /publish

# Runtime Image Stage
FROM microsoft/aspnetcore:2
WORKDIR /publish
COPY --from=build-env /publish .
ENTRYPOINT ["dotnet", "/publish/DemoApi.dll"]

Angular UI:

#compile it up
FROM johnpapa/angular-cli as ng-build
WORKDIR /build
COPY . .

RUN npm rebuild node-sass
RUN npm i
RUN ng build --prod --build-optimizer

# copy compiled files to running container
FROM nginx as runtime
WORKDIR /usr/shared/nginx/html
#remove default contents of nginx directory
RUN rm *
COPY --from=ng-build /build/dist/ .

I can run a docker ps -a and both containers are running and I can get the correct response from both of them from the docker host.

docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                   NAMES
1beef15c8aaf        demoui              "httpd-foreground"       9 hours ago         Up 9 hours          0.0.0.0:8080->80/tcp    demoui
4d0ec94cdc51        demoapi             "dotnet /publish/D..."   9 hours ago         Up 9 hours          0.0.0.0:32776->80/tcp   api

and I can ping the api from the ui container.

docker exec 1beef ping api
PING api (172.19.0.3): 56 data bytes
64 bytes from 172.19.0.3: seq=0 ttl=64 time=0.087 ms
64 bytes from 172.19.0.3: seq=1 ttl=64 time=0.091 ms

BUT, when I try to refer to the api from the UI via an http.get("http://api/api/values") I get an ERR_NAME_NOT_RESOLVED. What am I missing?

EDIT: I have also successfully run a cURL against the api from the UI container. I.E.

curl http://api/api/values

(on port 80 as the default) returns the expected values. To me this means this is really an nginx question.

Braiam
  • 1
  • 11
  • 47
  • 78
attero
  • 21
  • 3

2 Answers2

1

For all browser apps, even you deploy with Docker, when calling APIs, you have to use localhost:<mapped_port>, because you're access and use your app on host machine, therefore your API will be resolved by host machine first, and of course there's no api on host machine.

Check my detail answer here

Duc Trung Mai
  • 2,141
  • 1
  • 24
  • 23
0

I'm not sure about the ports. Try to expose the port of the 'api' service:

     api:
       image: demoapi
...
       ports:
         - '8081:80'

Then, retry with a correct url: http.get("http://api:8081/api/values")

Matteo Tosato
  • 185
  • 3
  • 15
  • As I understand, the exposed port is just so you can hit it from the docker host. I am trying to hit it from inside the container. Also an exposed port gets assigned dynamically as you can see from the output of docker ps -a – attero Oct 22 '17 at 14:15
  • In the output of docker ps command that you posted the following: 0.0.0.0:32776->80/tcp, indicate that the api service is running on the 32776 port. You can reach the api container only though this port. Every container are isolated. – Matteo Tosato Oct 22 '17 at 14:18
  • from the docker host, this is true; but, again, I am trying to get it to resolve from within the container. Each service in the container gets its own virtual IP address, so they can each be served on port 80. Otherwise the 32776->80 wouldn't work. Right? Also the port mapping doesn't answer the question of the ERR_NAME_NOT_RESOLVED. – attero Oct 22 '17 at 14:21
  • I did attempt this solution, exposed the api on port 8081, and tried to access it via http.get from the UI and got the same result. – attero Oct 22 '17 at 14:29