中小企业基于Ansible进行版本发布|云技术实名群分享实录

Posted 2021-04-25 云技术实践

嘉宾介绍：

年福瑞，现任职小牛资本旗下小牛在线运维总监、运维架构师，曾负责中国移动SaaS平台、Paas平台运维工作，带领团队维护过上万台规模的服务器。
分享主题：

中小企业基于Ansible实现集群版本发布

以下为分享实录：

背景

大家好，我是来自一家小公司的运维。

互联网+让很多企业都在往互联网转型，大部分都还在初级阶段，既然是初级阶段，运维干的最多的事情就是不停的进行版本发布、配置变更。

当一个企业服务器数量达到几十台的规模，集群规模不大（3－5台），各种应用按类型又分布在不同的集群中，对于运维发版本或改配置来说，是最痛苦的阶段，手工发版本已经不太现实，写脚本吧又要满足各种复杂场景，其实网上已经有很多人分享了自动化的版本发布案例，如svn钩子、jenkins等，也有ansible或saltstack实现的一些案例，我今天做个补充，把我们使用ansible实现集群版本发布的实现思路分享给大家。

简单介绍一下ansible

Ansible大家都知道，和salt/puppet等一样，是一款配置管理工具。为什么选择它，就是因为它简单，不需要安装agent，只要服务器能用ssh访问，就可以使用它去管理，大量的模块让大家只需要编写yaml脚本即可以实现集群服务的自动化操作。

Ansible的setup模块和local_facts本地变量

Ansible采用setup这个内置模块（和salt里面grains相似）获取主机运行情况，并把获取到的内容当成变量让我们可以根据变量进行下一步的处理。

但是模块内的获取到的默认变量远不能满足我们的需要，所以我们需要使用ansible的local_facts进行自定义变量，方法很简单：

1） 在被控服务器上创建/etc/ansible/facts.d目录，并创建以.fact文件结尾的文件，文件中直接使用key=value方式创建变量即可；

2） 在ansible控制服务器上使用 setup模块即可以获取到这些自定义变量

ansible<hostname> -m setup -a "filter=ansible_local"

上述是最简单实现local facts的方法，其实我们还可以在这个fact文件中编写shell，只要这个文件返回的是一个json格式的数据即可，那我们设想一下，是不是就可以向监控一样，获取到更多我们应用的信息了。

同时，我们在实现自动化的时候，会使用到playbook、jinja2模板，在这里就不多介绍了，推荐大家直接到ansible官网上读它的documentation。

示例场景

网站应用，SOA架构，N个应用，分别包含web类、app类，应用又分为支持集群（即可以同时运行）应用，支持高可用（A/S，一台运行，一台standby）的应用，那我们把它分为四类，即

• web集群应用：web-6001 web-6002web-6003

• web高可用应用： web-6101 web-6102

• app集群应用：app-7001 app-7002app-7003

• app高可用应用：app-7101 app-7102

四类应用在服务器上分布如下图：

应用部署在服务器上：

A1-A3、C1-C3用于部署集群应用，每个应用都需要部署并启动；

B1-B2、D1-D2部署高可用应用，都需要部署应用，但是只在B1和D1上启动；

假设以上所有应用均已标准化定义，采用文件夹方式部署，web应用由tomcat加载，app应用使用已经编写好的lsb脚本进行启停。

实现思路

1、版本控制

使用svn或git对上述所有应用进行版本控制，好处很多。

在这里我们为每个应用都创建一个单独的仓库，并使用svn的hooks实现在版本提交至svn时（具体如何提交版本，大家可以根据实际情况再定了），把版本update到指定的目录中。

（利用svn的版本控制进行回滚，也是一个不错的方法，当然还可以使用svn的版本号进行一些简单的校验）

2、编写local facts

为每台机器编写local_facts，这是一个基础的动作，如果机器多且没有cmdb的情况下，可能会花费一些时间，我们这里按上面的示例，实现满足我们需求的最简单的两条变量：

• 1）某个应用是否需要部署；

• 2）某个应用是否需要启动；

  
  

3、编写playbook脚本（我喜欢用roles方式）

想想我们上面的示例，如果我们想实现从svn里把程序包部署到某台服务器上，并且重启某个应用，我们需要做哪些动作：

• 1）判断这台机器是否需要安装此程序，然后把程序包使用rsync同步过去；

• 2）判断这台机器是否需要启动此程序，然后执行重启操作，（这是最简单的动作，这个步骤可以实现更多的动作）

所以，我们就为每个应用创建上面的动作任务吧，如下图

解释一下：

• 1）使用when模块，对获取到的local_facts进行判断，当服务器上install变量为yes时，执行synchronize模块（类似rsync），将文件同步过去；

• 2）同理，判断running变量，完成程序重启的动作；

• 3）为这两个动作添加了相同的tags ,可以实现对这个tags进行单独执行；

• 4）还可以扩展register、handles等模块，完成更多的动作。

当应用的动作创建完成后，编写一个入口的playbook文件，把这些应用都include进来，以后就直接对执行这个入口文件即可（假设我们把这个文件起名为update.yml）。

4、执行方式：

上述所有准备工作都完成后，我们就可以使用这个ansible的playbook进行版本更新了，方法如下：

• 对所有服务器上的版本更新并启动

• ansible-playbook update.yml

• 对单台或某几台服务器上版本进行更新并启动（使用limit参数）

• ansible-playbook update.yml --limit=d1:d2:c1

• 对所有服务器上某个应用进行版本更新并启动（使用 tags参数）

• ansible-playbook update.yml --tags=app-6001

OK，这样就可以利用ansible实现简单的集群版本发布了，当然，这里只是提供给大家实现的思路，可以在这些步骤中进行各种扩展，比如结合cmdb和监控实现集群资源的迁移等等。

谢谢大家。

欢迎加入“云技术实名群”，入群要求如下：

1 工作满5年；

2 目前从事云相关技术工作；

3 实名；

4 愿意分享。

入群联系北极熊：