不能为了优化而优化。镜像的构建过程视业务情况情况不同，指令就有多到少的区别，在很多情况下，我们先要以满足业务目标为准，而不是镜像层数。如果需要减少镜像的层数，我们一定要选择合适的基础镜像，或者创建符合我们需要的基础镜像。
下面是一些优化的准则：
选择合适的基础镜像
这点相对最为重要。为什么这么说，我们结合现实社会也可以看到，在大部分情况下，一个人一生的成就更多的是看出身。很多情况下，基因和出身决定了你的高度和终点，这点拿到技术层面来说，也是有很大道理的，因此我们需要选择合适的父母——一个合适的镜像。
一个合适的基础镜像是指能满足运行应用所需要的最小的镜像，理论上是能用小的就不要用大的，能用轻量的就不要用重量级的，能用性能好的就不要用性能差的。这里有时候还需要考虑那些能够减少我们构建层数的基础镜像。
优化指令顺序
Docker会缓存Dockerfile中尚未更改的所有步骤，但是，如果更改任何指令，将重做其后的所有步骤。也就是指令3有变动，那么4、5、6就会重做。因此，我们需要将最不可能产生更改的指令放在前面，按照这个顺序来编写dockerfile指令。这样，在构建过程中，就可以节省很多时间。比如，我们可以把WORKDIR、ENV等命令放前面，COPY、ADD放后面。
合并指令
前面其实我们提到过这点，甚至还特地讲到了转义字符，其实主要是为此服务。前面我们说到了，每一个指令都会创建一层，并构成新的镜像。当运行多个指令时，会产生一些非常臃肿、非常多层的镜像，不仅仅增加了构建部署的时间，也很容易出错。因此，在很多情况下，我们可以合并指令并运行，例如：RUN apt-get update && apt-get install -y libgdiplus。在命令过多时，一定要注意格式，比如换行、缩进、注释等，会让维护、排障更为容易，这是一个比较好的习惯。
删除多余文件和清理没用的中间结果
这点很易于理解，通常来讲，体积更小，部署更快！因此在构建过程中，我们需要清理那些最终不需要的代码或文件。比如说，临时文件、源代码、缓存等等。
使用 .dockerignore
.dockerignore文件用于忽略那些镜像构建时非必须的文件，这些文件可以是开发文档、日志、其他无用的文件。例如:
说了这么多，其实我们更多的还是需要根据命令的实际执行情况来进行调整。
Visual studio和dockerfile
如上所示，要生成自定义镜像，需为每个自定义镜像提供一个 Dockerfile。无论是从Visual Studio 自动部署，还是使用 Docker CLI（docker run 和 docker-compose 命令）手动部署，都需为每个要部署的容器提供一个 Dockerfile。如果应用程序只包含一个自定义服务，则只需要一个 Dockerfile。如果应用程序包含多个服务（如在微服务体系结构中），则每个服务都需要一个 Dockerfile。Dockerfile文件需要放在应用程序或服务的根文件夹中。
但是，对于.NET开发人员来说，利用Visual Studio只需单击几次鼠标即可完成此任务。如下图所示：
还可通过在 Visual Studio 中右键单击项目文件，选择“添加 Docker 项目支持”选项，为新项目或现有项目启用 Docker 支持：
对项目（如 ASP.NET Web 应用程序或 Web API 服务）应用此操作后，系统会向含有所需配置的项目添加 Dockerfile。
在更多的情况下，笔者建议大家选择下面的菜单——容器业务流程协调程序支持：