Hello World

总结得很好，感谢分享。

感谢关注。

谢谢。

https://stackoverflow.com/questions/8334573/asset-path-in-scss-file-rails 类似这种吧。 这种需走sprocket，迁移起来有点麻烦。

Cool thinks. 篇幅太长，需慢慢看。

我之前是懒得折腾，因为sass文件里面有些变量需要通过sprocket才能编译过。不知道现在webpack支持没有，考虑到迁移成本（加上自己比较懒）所以一直没有把所有东西都统一放到webpack那边去。 又因为有些单页面的样式跟一些原生组件的样式都是公用的就干脆把所有样式都放到sprocket上去打包了。

这放面还没怎么了解过。

可采用union，我稍后再总结一下，感谢提醒。

谢谢，初窥门径有些地方总结得不是很到位。

挺好，不过目前的项目中是两个工具混着用。Vue相关的用webpacker打包，其他的样式相关的还有JQuery的就走原来的sprockets

广州，我主要是做前端的，主要维护着一个Rails的商城项目。

向量化指令还没怎么看过，我稍后看一下，谢谢提醒。

对的，已经更正。

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

看着很不错，感谢分享。

说得很有道理

我之前的做法是预打包一个足够简单又足够通用的基础镜像，公司所有 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，毕竟我觉得并不是所有场景都需要把整个站点去分离。

哈哈，其实我也就用Digital Ocean的api来创了两个实例操作了一下而已，其实没遇到什么大坑，因为不够深入。