上京东看了一下这本书已经缺货了。

看着很不错，感谢分享。

说得很有道理

我之前的做法是预打包一个足够简单又足够通用的基础镜像，公司所有 Rails 项目都基于它来打包，以保证快速扩容时可以在集群的任何一台机器上快速部署

我是否能把这理解成，COPY前面的部分可以打包成一个基础镜像？然后其他的Rails项目都用同一个基础镜像？

花时间清理这些倒也不是不行，不过区分了编译依赖还有运行依赖，并清理了之后其本质也是减少了容量而已吧？我当时考虑是清理这些似乎对减少容量没有太大的影响所以就把优先级放低了。

感谢指正。那个最大的基础镜像不是基于ubuntu的，是我先入为主了，已经更正。ubuntu的基础镜像确实只有几十M，基础镜像是buildpack-deps

This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

谢谢，应该不会用Docker Swarm 了，公司的运维都把K8S环境搭建好了，估计到时候会直接上K8S。

感谢，我稍后会去看看，最近公司也正准备做这个事情。目前我还停留在镜像打包的地步。

我相当同意。所谓最佳实践应该是基于前人方法以及技术的较为通用解决方案的总结。通俗来讲应该是“道” 层面上的东，不过现在很多地方都演化成“术”层面上的东西了。每个人的开发方式可能还有习惯都不太一样，把“术”都定死了难免让人觉得无所适从（当然团队协商结果就另当别论）。

很有价值的一篇文章，已收藏。感谢分享。

意见很中肯，其实我个人是不反对前后端分离的，好像许多读者都误解我的意思。我其实反对的只是两点 1. 不考虑实际情况盲目分离。 2. 不考虑上手成本和代码可读性而不断堆积最新语法（当然似乎每个人都觉得只有自己的代码才是可读的，这就没办法了）。 在有些场景我们其实也不得不分离吧，比如一个重交互的应用如果用jQuery去写是很闹腾的事情，这种时候我会考虑分离的。只不过如果是个人选择的话我会选择Webpacker这个Gem，毕竟我觉得并不是所有场景都需要把整个站点去分离。