docker 如何解决上线对用户的影响

k8s scale. 平滑扩展

@蜗牛 有没成本小一点的方案,一个小团队

公司项目用的jenkis + rancher 我觉得方便是方便，确实也挺大了，同蹲一个

3台机，刚好可以做 Docker Swarm，允许挂一台

@piupiu :smile:假设我只有2台呢,哈哈

@白纸 可以做，就是 manager 节点挂了就 gg 了 :satisfied:

哈哈，可以参考 Bule/Green 的解决方案。

location / {
    proxy_pass http://Bule:9000;
}

location / {
    proxy_pass http://Green:9000;
}

service nginx reload

一个基于 Nginx 的蓝绿思路，切流量的做法比较粗糙。

docker swarm 滚动更新

利用 HAProxy 配置好 Healthcheck，Down 之后自动把流量导到其他容器。不过这个方案是「被动」的，需要等待 HAProxy 的 Healthcheck 检测，做不到理论上的无感知（其实可以把 Healthcheck 的 Interval 配置到很小，比如几百毫秒）。

像 Docker Swarm，Kubernetes，包括 Rancher 之类的方案都是「主动」的，由一个「管理者」控制滚动更新，大致流程抽象如下：

1. 「管理者」通知入口，把某台机器（容器）从反向代理撤下。
2. 「管理者」修改容器配置，升级版本，随后重启。
3. 「管理者」将该容器加入到反向代理内。
4. 重复以上步骤直到所有容器保持最新版本。

可以看出，整个过程需要有「管理者」角色存在，且由它主导。所以复杂度是避免不了的。

最后，说说我自己的看法：

我个人更倾向于老派的 Nginx 和虚拟机的部署方式，可以通过 Linux 软链接实现快速切换线上版本；或者使用带有「管理」和「编排」功能的系统，例如 Kubernetes 是更优解。利用被动探测实现故障切换的机制更适用于「管理者」出现故障、无法恢复时的一个保底选项（比如配置多地域多集群时，某个集群整体宕机，Amazon Route53 Failover 切到 Disaster Recovery Backup）。希望你，以及其它团队不要走入误区，为了容器而容器 —— 放弃了稳定可靠的技术，却又没有足够的时间研究真正能够消灭问题的解决方案。

@Wi1dcard 感谢你码那么多字,我个人觉得应该抱着拥抱新技术的心态,花足够的时间研究真正能够消灭问题的解决方案.

继续看看有没更好的答案

@白纸 没有了，@Wi1dcard 的方案就是了。

楼主，为啥要stop旧的容器呢？我理解php代码不是挂载在目录外直接git拉取就可以了吗？