开源的自动化部署工具探索

1      前言

即使是在传统的企业当中，日常的备份、服务器状态监控和日志，通过手动的方式来进行的效率也很低，是一种人力的浪费。因此，自动化早已是每个运维都必须掌握的看家本领。

在不同的企业中，自动化的规模、需求与实现方式都各不相同，因此在技术细节层面，运维之间很难将别的企业的方法整个套用过来。然而在很多情况下，自动化的思路是有共通之处的。

运维自动化前三阶段

◆纯手工阶段：手工操作重复地进行软件部署和运维。

◆脚本阶段：通过编写脚本、方便地进行软件部署和运维。

◆工具阶段：借助第三方工具高效、方便地进行软件部署和运维。

这几个阶段是随着运维知识、经验、教训不断积累而不断演进的。而且，第2个阶段和第3个阶段可以说是齐头并进，Linux下的第三方工具虽说已经不少了，但是Linux下的脚本编写对运维工作的促进作用是绝对不可以忽视的。

在DevOps出现之前，运维工作者在工作中还是以这两种方式为主。

下面的研究，都是一些linux下开源的第三方工具，借助第三方工具高效、方便地进行软件部署和运维。

 

2      业界开源的自动化部署工具

2.1   chef

Chef 是一款自动化服务器配置管理工具，可以对所管理的对象实行自动化配置，如系统管理，安装软件，基于ruby语言编写的。

2.1.1    Chef的架构

2.1.2    Chef的工作原理：

Chef 由三大组件组成：Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器，维护了一套配置脚本（Cookbook），与每个被管节点（Chef Node）交互并给出配置指令。

 

Chef Workstation 提供了我们与 Chef Server 交互的接口：我们在 Workstation 上创建定义 Cookbook，并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

 

Chef Node 是安装了 chef-client 并注册了的被管理节点，可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令（Cookbook）并按照指令配置自己。

如果忽略所有的细节,Chef是这样工作的:

1在Workstation上定义各个Client应该如何配置自己,然后将这些信息上传到中心服务器

2每个Client连到中心服务器查看如何配置自己,然后进行自我配置。

2.1.3    优缺点

优点：

          1.可以部署云计算的业务。

缺点：

1.     用户需要了解比较多的ruby语言，用户在 Workstation 上编写 Cookbook。然后，通过 knife 命令上传到 Chef Server。最后，在 Chef Client 上实施安装和部署工作，但是Cookbook是基于ruby编写的。（个人感觉这个Cookbook就像我们的配方一样）。

2.     chef在配置中心服务器端需要依赖软件比较多，需要couchdb、RabbitMQ和Solr，这样连带需要安装java和erlang，这样配置服务器过程要复杂很多。

 3.chef提供了扩展的方式就是Cookbook,我们要安装配置自己的应用，就去编写一个Cookbook，然后上传到Chef  Server, 似乎没有提供基于chef这个做二次编程开发。

2.1.4    关于chef详细的内容，可以查看以下的网站

chef基本入门的介绍讲的非常好：

http://my.oschina.net/williamherrychina/blog/63576

关于check 的Cookbook的讲解非常到位的网站：

http://www.ibm.com/developerworks/cn/cloud/library/1504_wangqw_chefcookbook/index.html

其余一些Chef相关的一些网站

http://it.taocms.org/07/4103.htm

http://www.csdn.net/article/2014-07-16/2820672

http://ju.outofmemory.cn/entry/49489

http://www.ibm.com/developerworks/cn/cloud/library/1506_wangqf_chefforweb/index.html

https://www.aliyun.com/zixun/content/3_12_517313.html

http://www.ithov.com/linux/136837.shtml

觉得chef可以参考下

2.2   puppet

     puppet是一个开源的软件自动化配置和部署工具，它使用简单且功能强大，正得到了越来越多地关注，现在很多大型IT公司均在使用puppet对集群中的软件进行管理和部署，如google利用puppet管理超过6000台地mac桌面电脑（2007年数据）。

Puppet是开源的基于Ruby的系统配置管理工具，基于C/S的部署架构。是一个为实现数据中心自动化管理而设计的配置管理软件，它使用跨平台语言规范，管理配置文件、用户、软件包、系统服务等。客户端默认每隔半小时会和服务器通信一次，确认是否有更新。当然也可以配置主动触发来强制客户端更新。这样就把日常的系统管理任务代码化了，代码化的好处是可以分享，保存，避免重复劳动，也可以快速恢复以及快速的大规模部署服务器。

2.2.1    puppet的架构

2.2.2    Puppet的工作原理

     Puppet是一个C/S架构的配置管理工具，在中央服务器上安装puppet-server软件包（被称作Puppet master）。在需要管理的目标主机上安装puppet客户端软件（被称作Puppet Client）。当客户端连接上Puppet master后，定义在Puppet master上的配置文件会被编译，然后在客户端上运行。每个客户端默认每半个小时和服务器进行一次通信，确认配置信息的更新情况。如果有新的配置信息或者配置信息已经改变，配置将会被重新编译并发布到各客户端执行。也可以在服务器上主动触发一个配置信息的更新，强制各客户端进行配置。如果客户端的配置信息被改变了，它可以从服务器获得原始配置进行校正。

2.2.3    chef与puppet的对比

相同点：

1、都是基于ruby语言

2、对要配置的对象提供了跨平台的抽象，用户大部分时间只跟这些抽象的资源打交道，而不用心实现，如只需关心要添加什么软件或用户，不需要关心这些用户或软件是怎么添加上去的

3、都有配置中心服务器，在每台要配置的客户端上都需要安装客户端，客户端跟服务器端用证书认证

4、配置应用过程都有两个阶段，第一个阶段在配置中心进行，由配置中收服务器针对客户端生成资源列表，第二个阶段在客户端运行，将应用收到的资源列表。

5、都提供了扩展的方式，puppet用的是模块的方式，而chef用的是cookbook的方式。虽然感觉(我没有真正用过chef)chef的cookbook方式更灵活和易于分享，但是这两者实质是一样的。

不同点：

1、puppet提供的配置语言更通用和高级一些，用户不需要懂ruby语言。而对于chef，没有专门的配置语言，用户需要了解比较多的ruby语言。

2、puppet资源之间有显式的依赖关系，按照这些关系去实现，而跟这些资源在配置文件的位置或前后没有关系。而看了一下chef的一些例子，更像是ruby脚本，从前到后按顺序执行

3、puppet安装简单，需要的支持软件也少，服务器端也是这样。而chef在配置中心服务器端需要依赖软件比较多，需要couchdb、RabbitMQ和Solr，这样连带需要安装java和erlang，这样配置服务器过程要复杂很多

4、puppet服务端的配置都是一个一个的文本文件，这样易于发布、备份和扩展。而chef的服务器端的配置放在couchdb和solr索引等二进制文件中，通过远程命令工具knife来操作这些配置。这样，puppet更符合unix管理员的使用习惯。

5、puppet的用户很多，象Google、Redhat等大公司都在用它。而chef的用户就少多了，而且没有什么大的公司

个人觉得，所以chef和puppet的话，更推荐使用puppet，

2.2.4    关于puppet的相关的网站

http://369369.blog.51cto.com/319630/785895/

http://dongxicheng.org/cluster-managemant/puppet/

http://www.educity.cn/linux/1147307.html

http://os.51cto.com/art/201306/398025.htm

http://www.kisspuppet.com/

2.3   Ansible—轻量级的自动化部署工具

Ansible是新出现的运维工具是基于Python研发的糅合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能。

ansible是基于模块工作的ansible本身没有批量部署的能力。真正具有批量部署的是ansible所运行的模块ansible只是提供一种框架。架构包括

连接插件connection plugins负责和被监控端实现通信。

Host Inventory:指定操作的主机,是一个配置文件里面定义监控的主机

各种模块核心模块command模块自定义模块

借助于插件完成记录日志邮件等功能

PlayBooks:剧本执行多个任务时。并非必需可以让节点一次性运行多个任务

2.3.1    ansible的架构

2.3.2    Ansible的优缺点

优点：

1比起来其他自动化集群管理和运维工具 Puppet、Chef、Ansible 显得很简单并且轻量级, 但是 Ansible 又不像 Fab 那样功能单一只能做批量命令，也可以和puppet一样进行模块扩展。

2轻量级的好处是学习门槛低、问题少、安装快、执行快。操作完全依赖 SSH 而不需要安装 agent 。这样的好处是不再需要维护 agent 的状态，不用担心 Agent 挂掉。而 SSH 是每台服务器必备的服务。它非常适合安全补丁更新的场景。比如，100 台服务器打 bash vulnerability 安全补丁只需要 10 分钟。

3.Ansible 结合 Docker、Mesos、Puppet、Vagrant、Git 等系统可以构建出非常好的自动化运维平台。Ansible 比起其他自动化运维工具更适合对 Docker 实例进行维护和管理。如果你的机器实例数量超过 1000，也可以选择Ansible 的 Web 控制工具 Ansible Tower 。

缺点：

1.同样这样的简单设计的劣势是没有依赖管理功能（感觉不适合我们公司，或者和别的一起用）。但是 Ansible 对于一般的使用场景已经足够了。

 

2.3.3    Ansible的相关网站

http://cloud.51cto.com/art/201508/488525_all.htm

http://www.wtoutiao.com/p/t91hrd.html

http://ju.outofmemory.cn/entry/67581

 http://sofar.blog.51cto.com/353572/1579894/

http://www.aikaiyuan.com/6299.html

2.4   ControlTier

ControlTier是一个完全开放源码系统的自动化服务管理活动的多个服务器和多个应用层(代码，数据，配置和内容) 。共同使用的ControlTier包括部署应用程序，控制它们的状态，并运行按需行政工作在多个服务器上。ControlTier是跨平台和工程同样的物理服务器，虚拟机，或云计算基础设施。是基于java开发的

2.4.1    ControlTier的架构

 

由于网上现在controlTier的资料较少，现在对其优缺点还不是非常清楚，有待研究。

ControlTier相关的网站

https://github.com/gschueler/controltier-wiki/wiki/ControlTier

http://blog.csdn.net/kongqz/article/details/6636697

http://www.docin.com/p-299917803.html

2.5   docker

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上。

Docker是基于go语言开发的一个重新定义了程序开发测试、交付和部署过程的开放平台，Docker则可以称为构建一次，到处运行，这就是Docker提出的"Build once，Run anywhere"。

2.5.1    Docker总架构图

Docker对使用者来讲是一个C/S模式的架构，而Docker的后端是一个非常松耦合的架构，模块各司其职，并有机组合，支撑Docker的运行。

用户是使用Docker Client与Docker Daemon建立通信，并发送请求给后者。

 

而Docker Daemon作为Docker架构中的主体部分，首先提供Server的功能使其可以接受Docker Client的请求；而后Engine执行Docker内部的一系列工作，每一项工作都是以一个Job的形式的存在。

 

Job的运行过程中，当需要容器镜像时，则从Docker Registry中下载镜像，并通过镜像管理驱动graphdriver将下载镜像以Graph的形式存储；当需要为Docker创建网络环境时，通过网络管理驱动networkdriver创建并配置Docker容器网络环境；当需要限制Docker容器运行资源或执行用户指令等操作时，则通过execdriver来完成。

 

而libcontainer是一项独立的容器管理包，networkdriver以及execdriver都是通过libcontainer来实现具体对容器进行的操作。

 

当执行完运行容器的命令后，一个实际的Docker容器就处于运行状态，该容器拥有独立的文件系统，独立并且安全的运行环境等。

 

2.5.2    Docker优缺点

优点：

1、简化程序：Docker让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，便可以实现虚拟化。

Docker改变了虚拟化的方式，使开发者可以直接将自己的成果放入Docker中进行管理。方便快捷已经是Docker的最大优势，过去需要用数天乃至数周的任务，在Docker容器的处理下，只需要数秒就能完成。

2、避免选择恐惧症：如果你有选择恐惧症，还是资深患者。Docker帮你打包你的纠结！比如Docker镜像；Docker镜像中包含了运行环境和配置，所以Docker可以简化部署多种应用实例工作。比如Web应用、后台应用、数据库应用、大数据应用比如Hadoop集群、消息队列等等都可以打包成一个镜像部署。

3、节省开支：一方面，云计算时代到来，使开发者不必为了追求效果而配置高额的硬件，Docker改变了高性能必然高价格的思维定势。Docker与云的结合，让云空间得到更充分的利用。不仅解决了硬件管理的问题，也改变了虚拟化的方式。

另一方面，Docker能够是自愿额达到充分利用。举个简单地例子：凌晨三点的时候只有很少的人会去访问你的网站，同时你需要比较多的资源执行夜间的批处理任务，通过Docker可以很简单的便实现资源的交换。

Docker采用了一种特别的方式，以便可以整合到大多数DevOps（开发运营）应用程序当中，包括Puppet、Chef、Vagrant和Ansible。或者可以独自使用，以管理开发环境。

主要卖点是，它简化了通常由另外这些应用程序执行的好多任务。具体来说，有了Docker，人们就可以搭建与活动服务器一模一样的本地开发环境，从同一个主机运行多个开发环境（每个开发环境有独特的软件、操作系统和配置），在新的或不同的服务器上测试项目，以及让任何人都可以在设置一模一样的情况下处理同一项目，无论本地主机环境怎样。”

缺点：

可能最大的障碍在于管理实例之间的交互。由于所有应用组件被拆分到不同的容器中，所有的服务器需要以一致的方式彼此通信。这意味着任何人如果选择复杂的基础设施，那么必须掌握应用编程接口管理以及集群工具，比如Swarm、Mesos或者Kubernets以确保机器按照预期运转并支持故障切换。

Docker是基于Linux 64bit的，无法在32bit的linux/Windows/unix环境下使用

LXC是基于cgroup等linux kernel功能的，因此container的guest系统只能是linux base的

隔离性相比KVM之类的虚拟化方案还是有些欠缺，所有container公用一部分的运行库

网络管理相对简单，主要是基于namespace隔离

cgroup的cpu和cpuset提供的cpu功能相比KVM的等虚拟化方案相比难以度量(所以dotcloud主要是按内存收费)

docker对disk的管理比较有限

container随着用户进程的停止而销毁，container中的log等用户数据不便收集

对linux系统的内核要求太高了，要3.8版本的linux内核。

2.5.3    Docket的相关网站

一个讲解docker非常好的网站，非常到位

http://www.infoq.com/cn/articles/docker-source-code-analysis-part1/

其余一些网站

http://www.infoq.com/cn/news/2013/04/Docker/

http://www.docker.org.cn/docker/71.html

2.6   AppOSS

AppOSS(Easy Commander) 是一个自动化的通用运维平台，它的目的是协助devops减少重复劳动，积累运维工作实践。

AppOSS设计的初衷是对大型的、混合多种类型的互联网应用系统进行运维，它虽然诞生于淘宝的内部需求，但实际场景并不比别人更特别，因此我希望能够对其它类似的场景也有帮助。

从功能角度看，AppOSS仅仅是一个基于Web的ssh并发执行工具（感觉过于简单，不适合我们的系统），这意味着它不会对你的运维工作做过多的干预，你可以使用任何你觉得合适的技术和框架来操作自己的系统。

AppOSS作为一个运维自动化平台，主要包括两个部分：Center 和 Agent。前者是一个基于Ruby on Rails的 web 应用，后者是一个基于 erlang 的并发 ssh 处理进程，这个项目是center部分。

AppOSS相关网站

http://www.open-open.com/lib/view/open1403058352090.html

 

2.7   disconf ----分布式管理配置平台

disconf 是基于java开发可以为各种业务平台提供统一的配置管理服务。

专注于各种 分布式系统配置管理 的通用组件/通用平台, 提供统一的配置管理服务。包括 百度、滴滴打车、银联、网易、拉勾网 等知名互联网公司正在使用!

1部署极其简单：同一个上线包，无须改动配置，即可在 多个环境中(RD/QA/PRODUCTION) 上线

2部署动态化：更改配置，无需重新打包或重启，即可 实时生效

3统一管理：提供web平台，统一管理 多个环境(RD/QA/PRODUCTION)、多个产品 的所有配置

4支持微服务架构

 

2.7.1    Disconf的架构图：

重要功能特点

·         支持配置（配置项+配置文件）的分布式化管理

·         配置发布统一化

·         配置发布、更新统一化（云端存储、发布）:配置存储在云端系统，用户统一在平台上进行发布、更新配置。

·         配置更新自动化：用户在平台更新配置，使用该配置的系统会自动发现该情况，并应用新配置。特殊地，如果用户为此配置定义了回调函数类，则此函数类会被自动调用。

 

·         配置异构系统管理

·         异构包部署统一化：这里的异构系统是指一个系统部署多个实例时，由于配置不同，从而需要多个部署包（jar或war）的情况（下同）。使用 Disconf后，异构系统的部署只需要一个部署包，不同实例的配置会自动分配。特别地，在业界大量使用部署虚拟化（如JPAAS系统，SAE，BAE） 的情况下，同一个系统使用同一个部署包的情景会越来越多，Disconf可以很自然地与他天然契合。

·         异构主备自动切换：如果一个异构系统存在主备机，主机发生挂机时，备机可以自动获取主机配置从而变成主机。

·         异构主备机Context共享工具：异构系统下，主备机切换时可能需要共享Context。可以使用Context共享工具来共享主备的Context。

 

·         极简的使用方式（注解式编程 或 XML代码无代码侵入模式）：我们追求的是极简的、用户编程体验良好的编程方式。目前支持两种开发模式：基于XML配置或才基于注解，即可完成复杂的配置分布式化。

·         需要Spring编程环境

 

2.7.2    disconf项目信息

CLIENT 端：

Java: 目前唯一支持语言

python：打算支持

PHP：暂未支持

WEB 管理端：

Java SpringMvc 实现，前后端分离 实现方式(基于Spring 4.1.7.RELEASE)

2.7.3    Disconf相关网站

Disconf介绍比较好的网站，就是github上面的

https://github.com/knightliao/disconf

其余的网站

https://github.com/knightliao/disconf/tree/master/disconf-web

http://blog.csdn.net/wanggang421338916/article/details/45889561

 

3      总结

其实还有很多一些相关的开源的自动化部署的工具，比如slatstack与ansible非常像，就没有详细介绍了 ，ansible没有依赖管理，有点不适合我们的业务。Chef与puppet的话，puppet可能更好一点，AppOss也是过于简单，感觉可以puppet、docker、controlTier，disconf都可以再好好的研究下，看是否适合我们的业务。