运维自动化总结-自动化架构演变过程

Posted by Yancy on 2017-03-14

记录自己自动化运维技术提升👍

前言:

个人2014年开始玩自动化的也是刚从业自动化运维岗位第一份工作,在一家上市公司做IDC+APM+CDN做云加速的应该很多玩cdn的都听说这家公司-mmtrix.com

一开始开始深度学习的是SaltStack所以掌握的比较深更加熟练,其实也是一个好朋友推荐我看了一本书python入门到精通 里面有详细讲到salt安装和使用部署自动化各种操作,的确很方便。后面在测试环境我自己管理几十台服务器-学习使用Ansible去操作,因为salt跟ansible最大的区别,除了ansible快速上手和不需要复杂的安装,主要在内网方面比salt更稳定架构也比salt好。

在线上我们都是用salt去操作的,可是当时公司还没有运维开发的人员,所以后来salt在终端操作出了很多错:

1
2
第一:人员操作失误一次,可能会导致所有的服务器都会受影响。
第二:命令太多服务权限需要一一统一分配登陆终端操作。

那时候服务器有500多台那时候运维操作起来还是挺费力的。

经历:

2016年初3月份去参加360的一次运维大会,王浩宇360的运维开发人员分享了一片文章:大规模集群上的多业务线环境部署.

讲的非常好,用的是Puppet去实现3000多台的服务器部署,指定部署安装包等等。非常方便。

这里也在Infoq上面有他的分享作品我这里粘贴出来了:大规模集群上的多业务线环境部署

个人现在运维自动化演变过程经验:

第一个版本公司整体服务架构:

2016年2月份脚本形式自动化发布:

16年2月份这里的Tomcat自动化 发布我一开始使用shell脚本去实现自动化发布和回滚。

2016年4月份salt自动化远程控制脚本发布:

16年4月份这里的tomcat服务增多,发现脚本发布手工操作太繁琐,而且出现问题几率大,效率不高。每次一次大版本改动发布会出现很多问题。

这里跟随服务模块增多,现在服务器90多台,统一salt自动化调用每台对应脚本发布回滚。

这里贴上我写的salt结合调用脚本命令,写在发布机器上面。这样就不需要进入机器每台执行对应发布脚本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#!/bin/bash
#author chengyangyang
#2016年5月25日
#this script is only for CentOS 6
#check the OS
#This script is used for the project release, which needs to be run by the root user
platform=`uname -i`
if [ $platform != "x86_64" ];then
echo "this script is only for 64bit Operating System !"
exit 1
fi
echo "the platform is ok"
version=`cat /etc/redhat-release |awk '{print substr($3,1,1)}'`
if [ $version != 6 ];then
echo "this script is only for CentOS 6 !"
exit 1
fi
cat << EOF
+----------------------------------------+
| your system is CentOS 6 x86_64 |
| start Update release tomcat....... |
+----------------------------------------+
EOF
#To determine whether the root permissions
if [ "$UID" != '0' ]
then
echo 'Permission denied, please switch the root tomcat.'
exit 60
fi
salt "node" cmd.run "curl -O http://10.47.100.90/ihaozhuo/war/haozhuo-tomcat.war"
[ $? -ne 0 ] && exit 1
salt "node" cmd.run "md5sum haozhuo-tomcat.war"
[ $? -ne 0 ] && exit 1
salt "node" cmd.run "mv haozhuo-tomcat.war java_war/"
[ $? -ne 0 ] && exit 1
salt "node" cmd.run "sh /root/update/tomcat.sh"
[ $? -ne 0 ] && exit 1
salt 'node' cmd.run '/etc/init.d/tomcat-tomcat stop' env='{"LC_ALL": "zh_CN.UTF-8"}'
salt 'node' cmd.run '/etc/init.d/tomcat-tomcat start' env='{"LC_ALL": "zh_CN.UTF-8"}'
[ $? -ne 0 ] && exit 1

2016年5月份去除了salt替换更新Ansible + Jenkins+Maven+Nginx搞定自动发布,构建程序的持续集成平台

Ansible vs SaltStack 对比?

1. 自身运维

SaltStack需要在Master和Minion主机启动守护进程,自身需要检测守护进程的运行状态,增加运维成本。Ansible和远端主机之间的通信是通过标准SSH进行,远程主机上只需要运行SSH进程就可以进行运维操作,SSH是机房主机中一般都安装和启动的进程,所以在Ansible进行运维的时候只需要关注Ansible主机的运行状态。Ansible对机房运维不会增加过多的运维成本。从工具本身的运维角度来说,Ansible要比SaltStack简单很多。

2. 使用语法

AnsiblePlaybook语法要比SaltStack的State语法具有更好的可读性。在使用的过程中发现Ansible在实现loop的更加的简洁,也可以使用相对路径。

同样Ansible的Notify模块和Handler模块实现的功能和SaltStack的watch和module.wait的模块实现功能也类似,也比SaltStack要简洁明了。

总之,Ansible的安全性能比SaltStack好,自身运维简单,使用语法可读性更强,虽然在响应速度方面不如SaltStack,但是在大部分应用场景下Ansible的响应速度能满足需求。因此,在金融行业的自动化运维系统,Ansible工具是最好的选择。

对应模块 account.yml 在Jenkins自动化写上变量对应.yml前缀名称。
这里依然调用脚本去跑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
- hosts: tomcat-account_01
environment:
LC_ALL: zh_CN.UTF-8
LANG : zh_CN.UTF-8
tasks:
- name : cpfile-account
copy : src=/root/.jenkins/workspace/yjk_master/haozhuo/haozhuo-account/target/haozhuo-account.war dest=/root/java_war/haozhuo-account.war
- name : restart
shell : /root/update/account.sh
async : 0
- name : shutdown
shell : /srv/tomcat/tomcat_account/bin/shutdown.sh
async : 0
- name : start
shell : chdir=/srv/tomcat/tomcat_account/bin nohup ./startup.sh &
async : 0

2016年6月份在ansible改进yml代码语法。去除了每台服务器新增发布脚本,这个过程太过于复杂,统一一台发布机处理即可。

这里我贴出yml代码 Jenkins直接调用相应模块发布,自然会去执行对应yml代码。每台服务器不需要放发布回滚脚本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
---
- hosts: all
environment:
LC_ALL: zh_CN.UTF-8
LANG : zh_CN.UTF-8
vars:
#jenkins-打包目录
TESTWAR: /root/java_war/haozhuo-family.war
#生产环境中项目的tomcat所在的位置
OLDHOME: /srv/tomcat/tomcat_family/webapps/ROOT
#生产环境中老版本项目所在webapps备份目录的位置
backupwebapps: /srv/tomcat/tomcat_family/warbackup
#从jenkins-打包环境获取的新版本war包所在的位置
NEWWAR: /root/java_war/
#生产环境中项目war包的名字
WARNAME: haozhuo-family.war
#kill服务type路径
DOWNFILE: /srv/tomcat/tomcat_family
tasks:
- name: copy-war-file
copy: src={{ TESTWAR }} dest={{ NEWWAR }}
- name: mkdir-bakwar-file
file: path={{ backupwebapps }} state=directory owner=tomcat group=tomcat mode=755
- name: bakwar-file
shell: "cp -r {{ OLDHOME }} {{ backupwebapps }}"
- name: unzip war.
unarchive: src={{ NEWWAR }}/{{ WARNAME }} dest={{ OLDHOME }}
- name: stop-tomcat-service
shell: "ps -ef |grep {{ DOWNFILE }} |grep -v grep |awk '{print $2}' |xargs kill -9"
ignore_errors: yes
async: 0
- name: start-tomcat-service-nohup
shell: chdir={{ DOWNFILE }}/bin nohup ./startup.sh &
3. 总结

在金融领域中,安全是最重要的考虑因素,在众多自动化运维工具种,Ansible的安全性能最好,是目前最适合金融领域的自动化运维工具。本文通过将Ansible微服务化,集成到自动化运维平台中,实现自动化运维平台高并发执行运维操作场景和实时收集执行结果。

2016年7月份Jenkins上面实现持续集成

这里Jenkins打通gitlab自动发布,审计代码。 这里结合openVPN+谷歌二次动态认证效果给予开发他们开放环境。
架构图 :

2016年9月份公司架构演变从传统架构更换dubbo架构。

公司应用服务架构图这里贴出来:Dubbo架构设计详解


系统架构图这里我后期在更新贴出来。

2017年3月份 公司服务器150台服务自动化发布。

后面运维开发开发了一套基于salt自动化一套web版的管理平台。对我们后面的做部署初始化的确减轻了很多。
现在开始公司用的是ansible基python开发出来一套自动化部署的。发布部署测试一体系:
刚开发出来的截了一张图:

个人总结:

系统标准化:

要想自动化,首先第一就是标准化。比如软件的安装位置、版本、脚本,注册到init.d下面,这些应该是标准的,所有服务器都统一的。或者说你使用salt就是为了达到这样的标准化做自动化运维要经历的标准化–>>自动化—->>服务化—->>数据化。

个人意见:

  1. 只有标准了,才能自动,至少你相同的业务都应该是一样的。
  2. 自动化,这个自动化讲的是工具,所有的操作是工具再做,不是人。也有小公司说我们半自动,的确是有的,就写写脚本然后靠工具去管理。
  3. 服务化,你平台搞的很牛逼了,直接给业务提供接口。DNS、负载均衡、分布式存储、你都封装好了,上层不需要关心,你相当于为上层服务提供服务。各种API都写好了。
  4. 数据化,或者说可视化,运维平台做的很牛逼,直接对业务负责,以业务为导向,今天订单量减少了,通过你的运维平台,直接定位问题,不需要各种查找,因为订单量的减少,肯定有相关的监控指标发生变化。

那么在工具自动化建设的开始,你需要有一个理论支持,比如ITIL。不能瞎搞。没有流程的自动化运维就是耍流氓如果上线没有走上线流程,动不动,开发自己登录服务器执行了git pull。那还自动化什么呢。

我个人的概念就是生产就是咱们运维的地盘。谁都不能动。开发想动,你可以提供接口,或者提供平台让开发点点鼠标就可以了。

题外话:

说个很蛋疼的事情,之前刚来这边负责美年大新的运维团队,技术团队开发人员都可以随便要权限,然后解决问题运维不用参与都是开发去操作。所以后来把公司运维整改:运维之间权限这些都是避免了。统一管理,统一分配,不同部门,不同岗位,不同权限。 这里我写过一篇文章:中小公司员工统一用户认证方案

这个是自动化里面最常见的部署自动化,对于ITIL的流程就是发布与部署管理。
构建---打包---测试---发布都需要是自动的;所以这块需要测试的支持。需要有自动化测试。没有就卡到测试了。
最简单的就是发布流程和开发流程分开。

自动化运维减轻了很多的事情,也让更多的运维小伙伴可以研究更多的知识。
这篇文章也是自己对这两年多运维的这一方面的自动化运维的总结。