Docker Swarm 教程-第1部分: 介绍

看完之后，作为读者你能学到什么？

如何手动部署程序到 Docker Swarm（只用一台机器）
（这里一台机器指的是普通的云主机，比如阿里云的主机，Amazon 的 EC2，等等）
我这里会用 Azure 的机器（因为有代金券……）外加随便找一个免费的私有容器仓库（还挺多的，国内外都有，可以参考这篇文章）

Docker 的好处是什么？Docker Swarm 的好处是什么？

（注：如果你已经知道了，这一大段可以跳过）

Docker 的好处：

把环境和代码打包在一起。

• 这样到一台新机器上你就不用手动去装 nginx 装 ruby 装 rails 装 bundle 装 gem 装一些你程序要用的依赖。装环境很烦的。
• 因为环境不一致带来的问题也很烦的。（解决：可是在我的机器上能运行啊？）
• 再想象不同程序依赖不同版本，一个要 python3 一个要 python2.7。你怎么办？

举个例子，有了 Docker 你只需要运行 docker run -p 8080:80 nginx
然后访问 8080 端口就可以看到 nginx 了。

（配图是在云主机上运行的，你可以在自己的机器上运行后访问 localhost:8080)

注意，这里的重点是：Docker 只解决了隔离的问题，真实环境中的程序需要解决更高层的问题。
那些更高层的问题应该用更高层的工具来解决，而不是把所有功能都塞进去一个工具里。

Docker Swarm 的好处：

（解决了更高层的问题）
一个实际面向客户的程序，不止有1个组件，你可能有 nginx, python, redis 等。
如果每次都 docker run 跑起来：

docker run (省略参数) nginx,
docker run (省略参数) redis
docker build 你的主程序，
然后 docker run (省略参数) 你的主程序。

这样很烦，因为：

1. 你需要记住3个 docker run 命令（参数和镜像名）。
2. 你需要手动跑3条命令。

别忘了，不同环境需要不同环境变量
(docker run 环境变量的官方文档)

想象一下你在本地开发环境要这样跑，测试环境要这样跑，在 staging/qa 环境要这样跑，在生产环境要这样跑。
想象一下你有一大堆带了环境变量的命令，比如：
docker run -e development [镜像名]
docker run -e production [镜像名]

你可能马上想到了如下的解决方案（这个方案不够好，后面会解释为什么）：

为了不用记住命令：把 docker run 命令写在 README.md 里。每次需要就复制黏贴。
为了不用每次复制黏贴跑命令：写一个 shell script，把所有 docker run 命令 docker build 命令或任何你需要的命令，都放进去这个文件，每次执行这个文件。这样就变成只有1条命令了。

以上方案解决了一部分问题，没有解决的问题：

1. 如果需要跑同一个镜像的多个容器（为了支撑更多用户），应该怎么做？

在 shell script 里多几行 docker run [镜像名] 命令？
ok，那你现在怎么 load balance？
如果你多开了几个容器，但是流量全部导向一个容器，那开了跟没开一样。
你肯定要把流量分给这几个容器，让它们干活，这样才能支持更多用户。

以上还只是单台机器的情况。
如果有多台机器，3个容器在机器A，2个容器在机器B。怎么 load balance？

2. 需要 0 downtime 更新的时候，应该怎么做？

0 downtime 意思是：更新期间用户依然可以访问。
这个也叫 blue/green deployment，蓝绿部署。

你很少（同时也越来越少）看到一个网站或 App。
每隔1，2天就贴一个公告说：
“不好意思我们今天下午2点到4点维护，维护期间不能访问，对造成的不便我们深感抱歉”
这种公告会有，但是频率非常低，一般是升级硬件，或者其他难以不停机就修改的东西。被逼无奈才会做这个。没有人希望时不时的就因为更新程序导致无法访问

理论上，更新程序做法是：比如你有3个容器，镜像都是 my-app:v1。
先关掉一个容器，剩下2个容器。然后开一个新容器，这次用镜像 my-app:v2。
然后依次类推，关一个开一个，把3个容器都变成 my-app:v2。
此时你再想象一下多台机器，多个环境的更新。
结论：手动更新不但很烦，而且容易犯错，而且速度还慢。

正确方法：用容器编排工具（比如 Docker Swarm 或者 Kubenetes）
提供的 rolling update 功能。
让工具来帮你一个个更新（可能散布在多台机器上）的容器。而且还能控制 rollback (回滚)。
rolling update 可以控制一些配置。比如跑10个容器的时候，一次性更新2个。2个2个的来更新。或者3个3个的来更新。还可以加 health check (健康检查)，比如访问容器的某个 url，确保返回 http 200 状态码。

另外，因为容器包着你的程序，而你的程序要花多久才能启动起来，是看情况的。
所以 health check 是需要稍微调整的，比如容器开起来之后，等10秒才进行第一次 health check，如果超时了3秒就算是失败，然后隔15秒再试一次，一共试3次，如果3次都不行，那就算失败。

所以可以这样配置：先更新2个容器，通过 health check 检查容器健康了才继续更新接下来的2个。
如果期间碰到任何问题。回滚到之前的版本。

3. Secret 和 Config，应该怎么做？

Secret 是秘密，比如 https 证书，你的微信支付证书，各种第三方工具的 api 访问密码。
任何不希望公开的东西就是 Secret。

Config 就是配置，就是一些不太重要的东西。
比如网站的多语言配置或什么其他配置，我暂时想不到好例子，┑(￣Д ￣)┍

再想一下多容器，多台机器应该怎么管理 Secret 和 Config？
(肯定不能塞到源代码里然后提交到 Github ……，不但不安全，而且不能依据不同环境进行调整)

结论

一句话总结：
Docker Swarm 是用于实际生产环境的。它基于 Docker 之上，解决更高层的问题。

一段话总结：
如果单单依靠 Docker，它只是把环境和代码打包在一起，仅仅解决了环境不一致这一个问题。
实际生产环境中，需要跑多个 container。而且可能跑在多台机器上。需要处理更新，需要处理回滚，需要管理 secret 和 config。某些容器可能只需要跑1份，只跑在 manager 节点上
所有这些要求，加在一起就复杂了。所以需要 container orchestration tools（容器编排工具）

（解释下什么是 manager：所谓 manager 节点就是管理 Docker Swarm 的机器，
一个 Swarm 里可以有多个 manager，建议奇数个，比如1，3，5，7个mangager。
另外，在一个 Docker Swarm 里，机器只有2种身份，mangaer 和 worker，worker 是干活的，mangaer 是管理的。）

为什么选 Docker Swarm？（而不是其他容器编排工具？）

容器编排工具有 Kubenetes，Docker Swarm。
还有几个工具因为我没接触过，不太确定怎么分类：Nomad, Openshift, Mesos。

如果想知道整个生态圈有多少工具，可以看 CNCF：

（各种工具）：

（容器编排工具有这些）：

简单对比下 Kubenetes 和 Docker Swarm：
安装：Swarm 自带在 docker 里，无需额外安装。
学习：Swarm 比 kubenetes 简单。
使用：Swarm 比 kubenetes 方便。

当然，业界还是以 kubenetes 为主流，因为稍大一点的公司的确需要 kubenetes。
第三方工具对 k8s 的支持度也好过 Swarm。

说明

我们用 Ruby on Rails 5 新建一个全新的项目进行演示。
解释一下为什么用 Rails：
因为我比较熟悉 Rails...
后端这么多语言 PHP/Python/Nodejs/等，没有一个语言是所有人都会的，我总得选一个吧。

本文适合个人或小团队。
因为演示的是把程序部署到1台机器上的 Docker Swarm。
（本文没有讲：数据库, Secret, Config）

本文假设读者有一定 Docker Swarm 知识，
文章是直接教你怎么用 Swarm
而不是把重点放在学 Docker Swarm 本身的概念。

问题：为什么要手动部署？自动部署不行吗？

回答1：学习意义

手动部署都不会的话，自动部署你知道怎么做吗？(:зゝ∠)

回答2：省钱省时间。

省钱的意思是：完全不用第三方 CI/CD 工具 (CircleCI, TravisCI, CodeFresh, Buddy)。
这些第三方工具都是几十美金起步的，对于个人来说还是挺贵的。对公司来说可能没什么所谓。
不过这些工具一般有免费限额，TravisCI 100次一个月，CodeFresh 120次 build 一个月。 Buddy 是 120次 Execution 一个月。

“省时间”的意思是（这里打个引号，因为不是一直是对的）：

1. 每一个 CI/CD 工具都有自己的语法。
   比如 Gitlab 的 .gitlab-ci.yml。 Drone 的 drone.yml。Codefresh 的 codefresh.yml。等等等等。一家一个语法。这是没办法的事情，因为各家是独立的，而且提供的功能也略有不同。
   照着文档和 example 学呗，还能咋样。这得花时间

2. 每一个 CI/CD 工具都有一些自己的概念
   比如 Gitlab 有所谓的 Runner。Runner 就是负责跑代码的东西。Runner 负责跑你的 .gitlab-ci.yml。Gitlab 有几个 share runner，你可以凑合着用。但是如果有更高的性能要求，定制要求，或者你自己是 self-host Gitlab 的。那就要自己部署一个 Runner。要照着文档看怎么部署 Runner。这得花时间

3. 有的 CI/CD 工具可能需要你自己部署
   比如 Drone 就可以自己部署。这得花时间

"省时间"这个不是一直为真的，看阶段，1个人的时候，如果急着写代码不想折腾这些（部署的东西）
那么手工做就是省时间。因为说白了也就只是
build docker image -> push docker image -> tell Docker Swarm to use that new docker image

坏处是什么？

因为手动操作是和命令行打交道。
没有一个 Web UI 进行中心管理（所有人都可以登录上去看）

如果只有1个人，那么手动部署没什么问题，只要你不嫌烦。
2个人3个人可能需要一定沟通，也还可以。
如果十几个人就容易冲突了。不好管。

结论：1个人的时候+急着做业务逻辑。
那就手动部署吧。真的没时间没心情去折腾第三方CI/CD工具。
如果人多了，也说明你有钱雇那么多人了。那一个月掏个不到1000块钱人民币来提升效率就不是问题了。

题外话：当然如果你愿意折腾 Jenkins，那当我没说。
我不喜欢 Jenkins 是嫌弃太丑 + 觉得过于复杂，学习成本高。

补充：解释下为什么题图里 Docker Swarm 写着 18.09.1

这个可能有点让人困惑。因为 Swarm 的版本一般不会单独拿出来提。
其实这个 18.09.1 来自 docker version 命令。

讲了一堆为什么，现在该动手做了 👇👇👇

第2部分点这里

（因为塞在同一篇文章里会很长。所以拆出去单独变成一篇文章）