部署不等于发布
想象一下，如果产品对外发布的时间是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解决问题的方式就不一样了。下面我们会详细介绍。
