还记得【One by one系列】一步步学习docker（三）——实战部署dotnetcore中遇到的问题么？容器内部启动始终是80端口，并不由命令左右。

docker run --name container-name -p 81:5000 mywebapi

所谓知其然就要知其所以然，浅尝辄止并不是个好习惯，主要是以下几个因素共同导致了这种情况。

1.Kestrel配置

ASP.NET Core项目使用Kestrel作为默认的web服务器。

而集成Kestrel的ASP.NET Core有4种方式指定终结点URL：

• ASPNETCORE_URLS 环境变量

• --urls命令行参数

• urls 主机配置键

• UseUrls扩展方法

2.按图索骥-Dockerfile

2.1 Asp.Net Core Runtime

首先我们按照asp.net core的其中一个版本构建镜像的Dockerfile

ARG REPO=mcr.microsoft.com/dotnet/core/runtimeFROM $REPO:3.1-buster-slim# Install ASP.NET CoreRUN aspnetcore_version=3.1.4 \    && curl -SL --output aspnetcore.tar.gz https://dotnetcli.azureedge.net/dotnet/aspnetcore/Runtime/$aspnetcore_version/aspnetcore-runtime-$aspnetcore_version-linux-x64.tar.gz \    && aspnetcore_sha512='a761fd3652a0bc838c33b2846724d21e82410a5744bd37cbfab96c60327c89ee89c177e480a519b0e0d62ee58ace37e2c2a4b12b517e5eb0af601ad9804e028f' \    && echo "$aspnetcore_sha512  aspnetcore.tar.gz" | sha512sum -c - \    && tar -ozxf aspnetcore.tar.gz -C /usr/share/dotnet ./shared/Microsoft.AspNetCore.App \    && rm aspnetcore.tar.gz

“

• 基于.net core基础镜像

• 运行命令，下载asp.net core指定版本的运行时压缩包

• 验证压缩包正确性

• 解压压缩文件

• 删除压缩文件

”

2.2 .Net Core Runtime

根据上面的Dokcerfile,可以看到asp.net core的镜像是在.net core的基础上构建的，所以继续找到.net core的构建镜像的Dockerfile

ARG REPO=mcr.microsoft.com/dotnet/core/runtime-depsFROM $REPO:3.1-buster-slimRUN apt-get update \    && apt-get install -y --no-install-recommends \        curl \    && rm -rf /var/lib/apt/lists/*# Install .NET CoreRUN dotnet_version=3.1.4 \    && curl -SL --output dotnet.tar.gz https://dotnetcli.azureedge.net/dotnet/Runtime/$dotnet_version/dotnet-runtime-$dotnet_version-linux-x64.tar.gz \    && dotnet_sha512='1869565558e5a85b6a898e792d7b5dece611b25f7f6fd8f015ffb16dccc7485f1412e04809da2e3f56744d24c75e1d3addbd2856c45ae7e66a2c7b71ea23e827' \    && echo "$dotnet_sha512 dotnet.tar.gz" | sha512sum -c - \    && mkdir -p /usr/share/dotnet \    && tar -ozxf dotnet.tar.gz -C /usr/share/dotnet \    && rm dotnet.tar.gz \    && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet

2.3 .NET Core Runtime Dependencies

根据上面的Dokcerfile,可以看到.net core的镜像是在runtime-deps的基础上构建的，所以继续找到runtime-deps的构建镜像的Dockerfile

FROM amd64/debian:buster-slimRUN apt-get update \    && apt-get install -y --no-install-recommends \        ca-certificates \        \# .NET Core dependencies        libc6 \        libgcc1 \        libgssapi-krb5-2 \        libicu63 \        libssl1.1 \        libstdc++6 \        zlib1g \    && rm -rf /var/lib/apt/lists/*# Configure web servers to bind to port 80 when present  # 这就是真相ENV ASPNETCORE_URLS=http://+:80 \    # Enable detection of running in a container    DOTNET_RUNNING_IN_CONTAINER=true

3.真相浮出水面

ENV ASPNETCORE_URLS=http://+:80 \

没错正是在基础镜像.NET Core Runtime Dependencies构建镜像的Dockerfile中指定了应用终结点URL

ENV ASPNETCORE_URLS=http://+:80

所以你想修改默认端口,在你的Dockerfile添加如下，修改默认值即可：

ENV ASPNETCORE_URLS=http://+:5000

4.写在末尾

• 通过这样剥洋葱般的溯源镜像，你会发现到最后，最后一个镜像一定是操作系统镜像，这也说明了一个镜像就是在一个操作系统镜像上不断增加运行环境、SDK等等，进而形成特定的新镜像.

• Docker容器的最佳实践是一个容器只运行一个进程，意味着一个容器就暴露一个端口，所以去修改默认端口没有很大的必要性。这里对其问题溯源只是作为一个了解.