Skip to content

自动化部署

部署不等于发布

想象一下，如果产品对外发布的时间是 2019 年 1 月 4 日，那么是不是说我们只能在 2019 年 1 月 3 日晚将后端服务器部署好呢？
如果分不清部署与发布，答案就极有可能是肯定的。

经常有人会问: 没有完成的功能也能上线？

提出这样问题的人通常就是将部署与发布两个概念混淆了。作为技术人员，我们需要用非技术语言解释部署与发布的区别。

用通俗的话来说，部署就是将应用服务软件 "放" 在远程服务器上，但是并不代表真正的用户可以看到这些新功能。当用户能看到这些新功能时，才代表发布了新功能。

这时，不懂技术的管理者又问了: 怎么会呢？你把东西摆上货架，用户还看不到吗？

你可以这样回答管理者: 软件是一种知识的载体，与实体的商品是有区别的。就像在你的大脑里储存着你懂得弹棉花的信息，但是你不告诉用户，客户是不知道你懂得弹棉花的。

进而你可以解释如何做到部署，但是不发布: 通过一些技术，即使把最新的应用服务软件 "放" 到服务器上，但是用户也看不到这些功能。
这些技术就像是开关一样，能在后台控制开和关，只要打开某个功能的 "开关"，这个功能就可以呈现给用户。

对于部署与发送的理解达成共识，有助于团队成员之间的和谐

什么是自动化部署

自动化部署的逻辑可分为两部分: 自动化逻辑和部署逻辑。

自动化逻辑，即只需要 "描述" 第一步安装 Nginx，第二步配置 Nginx，第三步启动 Nginx 服务 ... 至于第一步是使用 yum 还是 apt 实现的，那是工具的事情；
第二步如何将 Nginx 配置复制到指定目录下，那也是工具的事情 ... 这部分是自动化逻辑。

部署逻辑，我们可以使用 shell 来描述，也可以使用 Python 来描述。
但是，不论是使用 shell 还是使用 Python，都太过于原始。就像是使用汇编语言来开发一个 HR 系统，虽然可以实现，但是效率和成本都没有办法保证。

所以，有人开发了 Puppet、Chef、Ansible 等这类表达力更强的自动化运维工具。我们使用这些工具提供的运维领域的特定语言来描述部署逻辑，而自动化逻辑就交给了这些工具来实现。

自动化运维工具解决的问题:

Puppet、Chef、Ansible 有一些共性 -- 它们都必须解决以下几大问题。

  • 如何与受控机器通信？
  • 如何组织成百上千台机器？
  • 如何描述部署逻辑，同时还应该是幂等的(同样的部署脚本，执行一次与执行多次的结果应该是一样的)？
  • 如果得到执行结果？

Puppet 使用的是 C/S 架构，分为主控机器(Puppet master) 与受控机器 (Puppet Client)，它们之间使用 HTTPS 进行通信。
也就是说，我们需要在所有的受控机器上安装 Puppet 的客户端，在主控机器上安装 Puppet 的服务器端。
Puppet 使用一种称为 manifest 的 DSL 来描述部署逻辑，并在 manifest 中组织机器。

在主控机器与受控机器认证成功后，受控机器会每隔一段时间就向主控机器发送一次请求，这个请求会把自己(受控机器)的信息告诉主控机器。
主控机器拿到这些信息后与 manifest 链接编译，最后生成一份受控机器可执行的 catalog。
受控机器在执行过程中，将执行情况返回给主控机器。

Chef 使用的是 C/S 架构，也是使用 HTTPS 进行通信的。其解决问题的方式与 Puppet 相似

而 Ansible 解决问题的方式就不一样了。

Jenkins 集成 Ansible 实现自动化部署

https://plugins.jenkins.io/ansible/

https://github.com/ansible/ansible

Ansible 采用了与 Puppet、Chef 不一样的解决方案，不需要在受控机器上安装额外的客户端软件。
原因是 Ansible 使用的是 SSH 协议与受控机器进行通信的，一般服务器默认有 SSH 服务。Ansible 也因此被称为 agentless(去客户端的)