我有一个非常简单的 docker 设置——React WebApp(管理面板)和 .netCore Customer Api,它们连接到桥接网络。我实际上是在创建健康检查监视器。
两个容器都已连接,我可以通过 ip 和容器名称进行 ping 操作,没有任何问题。当我 curl 健康检查端点时,它工作正常。
但是,当我从 admin-app react 代码的相同 url 中获取数据时,它会抛出 net::ERR_NAME_NOT_RESOLVED docker。请在此处查看代码
async loadData() {
try {
fetch('http://customer-api:5000/api/hc')
.then(function (response) {
console.log(response)
});
} catch (e) {
console.log(e);
}
}
到目前为止我做了什么-
- 确保两者在同一网络中
- 端口正确
- 可从外部浏览器和容器访问客户 api
管理应用程序 docker
# pull official base image
FROM node:13.12.0-alpine
# set working directory
WORKDIR /app
# add `/app/node_modules/.bin` to $PATH
ENV PATH /app/node_modules/.bin:$PATH
# install app dependencies
COPY admin-app/package.json ./
COPY admin-app/package-lock.json ./
RUN npm install --silent
RUN npm install react-scripts@3.4.1 -g --silent
# add app
COPY ./admin-app ./
# start app
CMD ["npm", "start"]
客户 api docker
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
WORKDIR /app
ENV WEB_PORT=5000 \
ASPNETCORE_URLS=http://+:5000 \
ASPNETCORE_ENVIRONMENT="Local"
FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY ["customerprofile/Figg.Customer.Api/Figg.Customer.Api.csproj", "Figg.Customer.Api/"]
COPY ["core/Figg.Shared/Figg.Shared.csproj", "Figg.Shared/"]
COPY ["core/Figg.Core/Figg.Core.csproj", "Figg.Core/"]
COPY ["customerprofile/Figg.Customer.Domain/Figg.Customer.Domain.csproj", "Figg.Customer.Domain/"]
RUN dotnet restore "Figg.Customer.Api/Figg.Customer.Api.csproj"
COPY . .
WORKDIR "/src/customerprofile/Figg.Customer.Api"
RUN dotnet build "Figg.Customer.Api.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "Figg.Customer.Api.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
EXPOSE $WEB_PORT
ENTRYPOINT ["dotnet", "Figg.Customer.Api.dll"]
任何想法
ping 正常
/app # ping customer-api
PING customer-api (172.21.0.2): 56 data bytes
64 bytes from 172.21.0.2: seq=0 ttl=64 time=0.062 ms
64 bytes from 172.21.0.2: seq=1 ttl=64 time=0.049 ms
64 bytes from 172.21.0.2: seq=2 ttl=64 time=0.068 ms
64 bytes from 172.21.0.2: seq=3 ttl=64 time=0.049 ms
64 bytes from 172.21.0.2: seq=4 ttl=64 time=0.094 ms
我找到了它没有到达我的容器的原因 - 但如何解决这个问题?请看这里的图片,这会解释
最佳答案
您的 Docker 容器正在您的主机(您自己的系统)上运行
Docker 向主机发布了以下端口:
- ClientAPI 为 8092(“8092:3000”中的第一个字符串)
- 3000 用于 AdminApp。 (这是“3000:3000”字符串中的前 3000。这就是为什么我总是建议使用不同的端口以免混淆)
顺便说一句:您提到的这 5000 是从哪里来的?我猜那是“8092:3000”字符串中的“3000”。打字错误?
主机可以到达 localhost:3000 (admin-app) 和 localhost:8092 (ClientAPI)。
如果一个容器需要到达另一个容器,它需要解决服务和内部端口。 在您的图片中:AdminApp 可以使用 customer-api:3000(或 5000?打字错误?:-))访问 ClientAPI
如果您客户端渲染 AdminApp,那么它需要一个外部世界(主机之外)的 ClientAPI 地址。这意味着到达主机(您运行容器的计算机)并且该主机可以将请求传递给 customer-api:3000。
结论:您需要一个 ProxyServer(Nginx?)。 将 Nginx 放在主机上(不建议)或作为另一个容器旁边的单独容器。 在最后(也是最好的)选项中,您为每个容器提供一个 IP 地址,并让 Nginx 代理(动词)向正确的容器请求。
我们在自己的环境中运行这个,Nginx 为大约 6 个不同的容器提供服务。 在主机上,我们有一个 docker(外部)网络,它将端口 80 和 443 的每个请求传递到 Nginx 容器中的 ProxyServer。该容器将每个请求(基于 Nginx 配置文件中的 server_name)传递到正确的容器。
关于c# - net::ERR_NAME_NOT_RESOLVED docker ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/69115729/