#13 楼 @msg7086 你们的问题看来已经拖了很久了，所以还是尽早开始迁比较好，当然要掌握好节奏，循序渐进的进行 systemd-nspawn 我不了解，你不妨学习一下发个帖子在论坛上介绍介绍？

#11 楼 @msg7086 这个问题其实和 docker 关系不大，不过问题本身很有价值。

简单说，这个开发进度流失可以减少（比如合理的设计，或者借助 docker 这种技术做一些简化）但不可能消除，所以答案是：“不能解决”

业务逻辑拆分带来的开发进度流失不可避免！！！ 业务逻辑拆分带来的开发进度流失不可避免！！！ 业务逻辑拆分带来的开发进度流失不可避免！！！

重要的话说三遍 :-D

那为什么还要做拆分呢？很简单，如果没好处我们并不建议拆分，这件事不能变成一个教条。通常情况下，我们从单体架构走向服务化应该有业务上的驱动原因（比如需要增强水平扩展能力以应对压力的急剧变化，或者需要将某个部分独立出来快速演化，以及商业上需要的某些必要的逻辑分离等等）。这时考虑拆分，就不能设想它是一顿免费的午餐，而是产品为了走的更好而付出的必要代价。

#8 楼 @lazybios 以前在 RailsConf 上的一个 topic，链接在这里： http://www.slideshare.net/jpalley/railsconf-2010-from-1-to-30-how-to-refactor-one-monolithic-application-into-an-application-ecosystem

#1 楼 @ithelloworld 谢谢补充 #2 楼 @i5ting 完全赞同，docker 和微服务是好基友 #3 楼 @linuxgit 我对网络不精通，不过 DR 工作在数据链路层，理论上应该不影响基于 tcp 的上层应用，docker 的网络解决方案有好几个，建议了解一下，如果能在论坛上做个介绍就更好了 #4 楼 @darkbaby123 对 Core OS 关注不多，因为我更看重 Docker 的使用，目前知道 Core OS 不会影响我们使用 docker 的方式就可以了，基础选型要根据实际业务做测试 #5 楼 @rei 这篇文章槽点好多啊，我猜你的意思是不要过多考虑 future，我也同意，不过 Docker 不算想多了，做现有的项目时可以不考虑它，但是对于个人和团队技术规划是有必要做出选择的，当然不选择也是一种选择。顺便八卦一下，我以前比较过，circle 是我知道对 CI 理解最好的一个团队，但是原因倒不记得了 :-P #6 楼 @springwq 见笑，不知道怎么归类，所以扯扯淡吧 :-)

#13 楼 @ithelloworld 你的 dockerfile 太复杂啦，这些逻辑官方的 image 已经都包含了，何必麻烦两遍

FROM ruby:2.2.2-onbuild

CMD "sh init.sh"

就行了。 另外，compose 还是值得效仿的，这个和 k8s 不矛盾

#54 楼 @mywillbe 这么老的帖子啊，辛苦你挖坟了，不过我真的很冤枉......

首先要申明一下角度，我是一个工程师，讨论问题也是从工程师角度出发，但是请注意，“从工程师角度出发”不等于偏向工程师的利益，事实上在自由博弈的市场环境中，任何偏向最后都会被博弈过程所纠正，典型的例子比如最低工资制度等（看不懂的同学可能无法一言两语解释清楚，能看懂的也不必我来废话）

在这个角度下我们再看看楼主的问题，显然包括楼主在内的很多同学不可能改变各公司 HR 的做法，但是，虽然 HR 的处理方式千差万别，至少在“如果录用，那么一到两周会给出回复”这一点上是比较一致的，从面试者的角度看，与其在一个技术论坛抱怨 HR 的不专业，不如了解情况后选择有利的策略（比如，面试后不消极等待，主动寻找其它机会，任何面试，超过 2 周没消息就认定已经失败，等等）。

另一方面，HR 的做法有没有可能改变呢？也有机会，那就是你足够强大，某些 HR 可能不专业，但这是市场经济，如果你确实有足够的价值，HR 会令企业付出代价，这样，无论是企业还是 HR 自己，都会在竞争中得到教育，这比在论坛上发牢骚有用得多。

第三个方面，其实 HR 如何处理根本不重要，实际上，对于楼主的这个问题，我从刚出校门到现在从来都没当做是个问题，能制约一个人的只有商业契约（包括口头非正式的），一个暂不录用的通知，对我来说信息量为零，不会影响我的任何决策，他说与不说又有何妨呢？

最后一个方面，我们也有面试别人的时候，这时楼主的问题就变得重要了，不为别的，只因为这体现你的专业水平，如果你在乎自己的职业素养和职业形象的话。

所以，你是面试者，还是面试官？知道应该怎么处理了么？

#15 楼 @rei 这个支持其实已经很不自然了，特别是涉及到容器协作的时候，不如直接 docker-machine + docker compose

BTW：compose 未来可能会成为标准，docker 已经在整合各路神仙了

#13 楼 @rei docker-machine 在驱动 virtualbox 的时候会借助 boot2docker 的现有资源（比如 boot2docker.iso 之类），不过它可以适配其它 provider，因此更广泛一些

Heroku 是个好东西，虽然我一直没用它......

#20 楼 @cassiuschen 原来指的是这个，那倒不稀奇，面向分布式领域的技术必须解决软件包自包含的问题，所以 erlang 有这个基础设施，elixir 也继承了这份遗产。我本以为你说的是类似 golang 那样的静态编译技术呢

#9 楼 @rei 有没有兴趣聊聊你期待的工具是什么样子的？

#3 楼 @cassiuschen 如果觉得开发环境没必要用 docker，那我猜你可能不太做测试。如果做了很多的测试，那就会很在意开发环境和线上的一致性，否则测了半天，上线根本不是那么回事，事情就糟了

也可能，你让自己的开发用操作系统和线上对齐，然后就觉得没问题了。但这个其实也是不靠谱的做法，主要是开发环境出于使用便利性，会多出很多东西，dll hell 的问题其实可以出现在 jar 和 rpm 上（我遇到过），并且不排除出现在 gem 上

还有一个因素——多项目情况，除了很小的产品，一般的产品都不会只有一个应用，所以开发者的笔记本上会有多个项目，这时对环境隔离的要求就更必要了

开发环境不用 docker 只有一个原因是可以接受的——开发用了 vagrant，也就是使用了更重量级的方式确保隔离开发的自测环境，这时确实可以不必用 docker，不过 vm 很重，用 docker 可以更轻量级，哪怕是 boot2docker（现在可以用 docker-machine）也比多个 virtualbox 要好些

#11 楼 @cassiuschen 还能直接编译为二进制？

I'm in

嗯，俺也去报名了，就算闲聊也好

#32 楼 @tq0fqeu ft，你隐藏的好深，话说我是背景啊

今年的 slides 出炉好快啊，赞一个

#15 楼 @zoker 有时候是被迫，比如需要看小孩，不过无论如何，remote 是有代价的

话说明年会不会有很多人就不来现场了？

今天晚上和中学同学聚餐，居然又选了香蜜湖，各种感受......

#13 楼 @zoker remote 有很多特别的沟通成本

#3 楼 @greatghoul 居然连这个都有社区，醉了

基本同意 robbin

#15 楼 @rei 考虑到现在国内的创业者都很重视技术含量，我对他们提供的服务水平比较乐观，而且 docker 是个标准，绑定供应商的问题不是很大，以后可以换 http://dockone.io/article/707

#6 楼 @codemonkey #7 楼 @googya 是的，chef/puppet 是配管神器，不过在云平台上会简单很多，docker 化以后更是大大降低了配管复杂度，而且很大程度上消除了各种环境的差异，所以 puppet/chef 就不重要了

#10 楼 @rei 不明白你说的“docker 更新或 rebuild”是什么意思？如果指的是“代码变更 => 镜像 rebuild”这个自动化过程，那各种 docker 平台都有支持的，我觉得现在已经不必自己搭建 PaaS 了

文章不错，不过研究方向可以调整了，puppet/chef 未来将越来越不重要，整体退出主流也不是不可能

#59 楼 @ericwu 收到

u32 在哪里啊？

好像还没留名，补上

最近终于有空出门了，我想去看看

#13 楼 @lgn21st 其实我说的就是产品形态，技术服务就是应该以托管的形式，最好是 saas，不然容易增加学习成本。我觉得 passenger 就是个配置简化工具，如果我要学习，不如直接学习如何运维 unicorn 等等。