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

时间 2019-11-07

标签开源自动化部署工具探索栏目测试自动化繁體版

原文原文链接

1 前言

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

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

运维自动化前三阶段 python

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

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

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

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

在DevOps出现以前，运维工做者在工做中仍是以这两种方式为主。 docker

下面的研究，都是一些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的对比

相同点：

一、都是基于ruby语言

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

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

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

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

不一样点：

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

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

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

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

五、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优缺点

优势：

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

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

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

三、节省开支：一方面，云计算时代到来，使开发者没必要为了追求效果而配置高额的硬件，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部分。

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均可以再好好的研究下，看是否适合咱们的业务。