首先明确：Docker没有直接替换镜像中某一层的原生命令，因为Docker镜像是由一系列只读的、有依赖关系的层构成的，修改底层会导致所有上层的哈希值变化，无法直接"替换"。但我们可以通过重新组合层的方式实现你的需求——保留原有应用层，切换到新版本的.NET Core 3.1运行时镜像，无需重新构建应用代码。

下面是两种可行的方案：

方案1：基于Dockerfile重新组合（推荐） #

这种方式最清晰、可维护，适合长期使用。核心思路是提取旧镜像中的应用文件，然后基于新的运行时镜像重新打包。

步骤： #

1. 从旧镜像中提取应用文件
   先启动一个临时容器，将应用相关的文件复制到本地：

   # 启动旧镜像的临时容器（sleep infinity让容器保持运行）
   docker run -d --name temp-app-container your-old-image sleep infinity
   # 将应用目录复制到本地（假设你的应用部署在/app目录，根据实际路径调整）
   docker cp temp-app-container:/app ./local-app-files
   # 清理临时容器
   docker rm -f temp-app-container
   

2. 编写新的Dockerfile
   创建一个新的Dockerfile，使用新版本的.NET Core 3.1运行时镜像，并复制提取的应用文件：

   # 使用最新版本的.NET Core 3.1 debian slim镜像
   FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim
   # 复制本地的应用文件到镜像中
   COPY ./local-app-files /app
   # 设置工作目录
   WORKDIR /app
   # 启动应用的命令（根据你的应用实际入口调整）
   CMD ["dotnet", "YourApplication.dll"]
   

3. 构建新镜像
   执行构建命令生成新镜像：

   docker build -t your-new-image .
   

这个方案的优势是保留了Dockerfile的可追溯性，后续维护和修改都很方便。

方案2：使用docker commit快速生成镜像 #

如果你需要快速验证，也可以通过临时容器复制文件后提交为新镜像，但这种方式不会生成Dockerfile，可维护性较差，适合临时场景。

步骤： #

# 1. 启动旧镜像的临时容器，用于获取应用文件
docker run -d --name old-app your-old-image sleep infinity
# 2. 启动新版本运行时的临时容器
docker run -d --name new-runtime-base mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim-new-version sleep infinity
# 3. 将旧容器中的应用文件复制到新运行时容器中
docker cp old-app:/app new-runtime-base:/app
# 4. 提交新容器为新镜像
docker commit new-runtime-base your-new-image
# 5. 清理临时容器
docker rm -f old-app new-runtime-base

关键说明 #

• 不管哪种方案，你都需要明确应用文件在镜像中的部署路径（比如/app、/publish等），如果不确定，可以用docker run --rm your-old-image ls /查看目录结构，或者用dive工具可视化查看镜像的层内容。
• 这种方式完全符合你的需求：使用新版本的运行时，保留原有应用代码，无需重新构建，从而减少升级后的测试范围。

内容的提问来源于stack exchange，提问作者Vaccano