鸿 网 互 联 www.68idc.cn

【博客大赛】+ 生产环境自动化变更全纪录

来源:互联网 作者:佚名 时间:2022-07-19 11:06
特别申明:本文根据生产变更编写,所有ip、用户名、文件路径和文件名等敏感信息已做替换删除或打码处理。 服务器列表 ip主机名备注 172.16.5.111app011号机172.16.5.112app022号机172.16.5.11

特别申明:本文根据生产变更编写,所有ip、用户名、文件路径和文件名等敏感信息已做替换删除或打码处理。

服务器列表

ip 主机名 备注 172.16.5.111 app01 1号机 172.16.5.112 app02 2号机 172.16.5.113 app03 3号机 172.16.5.200 db01 数据库服务器 172.16.5.150 ansible spug自动变更服务器

执行生产变更时会登陆3台应用和一台数据库服务器,根据变更实施步骤,手动在每台服务器上敲命令执行,这是传统的变更方式。这样做有几个弊端:

  • 重复性工作多。生产变更少则十几步,多则几十步,很多步骤会在全部或部分服务器上执行。比如注释定时任务,4台服务器都要手敲注释命令;停应用操作会在3台应用服务器都执行。
  • 失误多。由于所有的步骤都是通过手敲命令方式执行,敲错命令在所难免。另外由于执行步骤多、执行的服务器也多,很容易发生漏执行或者重复执行的现象。
  • 文件传输不方便。生产环境一般通过堡垒机登陆,传文件也是通过堡垒机的ftp工具来执行。在变更时会多次涉及文件上传下载,这样就显得非常不便。
  • 耗时长。这点是前三点的延续。由于都是手动执行,执行步骤多,还涉及堡垒机的登陆,整个变更做下来想快都很难。

变更步骤抽象

变更手册大小步骤几十项,根据功能和关联性,抽象合并为16步,并分为实施准备、变更实施、变更收尾3类。

image-20210427112012224

模板

模板对应变更的16个步骤,相应的模板分为准备工作、变更实施和变更收尾3个大类。

image-20210427145012790

变更实施准备的模板

image-20210427144802449

变更实施的模板

image-20210427145139730

变更收尾

自动化变更流程

  • 1.将所有变更抽象为16个步骤;
  • 2.每个步骤对应1个或多个脚本;
  • 3.将脚本转化为spug平台的模板;
  • 4.每次执行变更步骤时选择对应的模板和执行主机;

登录系统

登陆堡垒机,搜索分发服务器172.16.5.150,通过浏览器方式登陆

image-20210427144005713

image-20210427144037210

在浏览器地址栏输入http://172.16.5.150/或者直接点击历史窗口

image-20210427144224405

输入用户名密码,登陆系统

一、变更前准备工作

第1步--注释定时任务

image-20210427150353707

在执行任务栏选择主机和执行模板

image-20210427150700001

选择主机,3台应用服务器和数据库服务器都执行

image-20210427150848532

选择模板

image-20210427150957429

执行命令

image-20210427151259820

数据库执行结果,有5个定时任务被注释,右上角的对号表示执行成功

image-20210427151534044

应用服务器有3个定时任务被注释

定时任务注释条数:1号机4条、2号机3条、3号机3条、数据库5条

第2步--停应用

3台应用执行该操作,停止后台进程和java程序

image-20210427151653202

执行反馈

image-20210427151827611

‘the process is killed’代表后台进程停止,‘the java is killed’表示java程序停止运行;若脚本正常执行,返回的界面右上角会有对号√

第3步--数据库跑批

跑批脚本:

image-20210427152617185

执行结果:

image-20210427152705463

第4步--数据库抽壳

数据库上执行抽壳操作

image-20210427152815765

执行结果:

image-20210427163821562

二、变更实施

第5步--应用程序替换

3台应用上执行

image-20210427153003059

执行结果:

image-20210427164119631

image-20210427153459306

依次检查执行结果,正常的返回如图

应用程序替换是一个关键的步骤,集成了scp文件获取、文件解压、文件上传和移动文件到指定目录、赋权以及执行sql等。

第6步--日初日终改为手动

备份响应的表,并将xx启动方式调整为手动

该操作数据库服务器上执行

image-20210427153901435

执行结果:

image-20210427154000551

第7步--修改发送步骤

变更前update所有发送步骤,致不用发送,测试完成后恢复,数据库机器执行

image-20210427154121769

执行结果:

image-20210427154146544

变更完恢复发送时注意比对sql执行结果的条数

第8步--执行sql

执行sql,在PL/SQL内根据变更手册执行对应sql

自动化平台spug内也可以直接通过数据库服务器的console执行sql,不过返回结果没有PL/SQL直观。

第9步--启动应用

3台应用服务器上执行应用启动脚本

image-20210427154652020

执行结果:

image-20210427154807860

应用启动会启动后台程序和java进程,也会重新装载共享内存映射

第10步--跑批

跑批有两种方式,一种是直接复制变更文档跑批命令在分发平台console上执行;一种是将跑批命令拷贝后上传自动执行。本文采用第一种方式,第二种方式适用于批次很多的情况。

进入console

image-20210427155047607

执行批次

image-20210427155303597

第11步--比对

可以三台一起比对,也可以单独比对:

image-20210427155338877

执行结果:

image-20210427155457008

获取结果:

image-20210427155636315

比对结果会上传到数据库服务器的/yssfgs/result目录,通过文件管理器可下载至本地电脑分析查看

比对这个也是关键步骤,之前跑批完每台服务器手敲命令执行比对,比对完然后登陆堡垒机通过ftp工具下载比对结果,劳时费力,而且批次越多花的时间越长,现在自动化了不受批次多少影响,所有的比对工作自动化完成。

三、变更收尾

第12步--日初验证

在1号机上通过执行日初批次验证变更有效性

开始执行:

image-20210427160029400

执行结果:

image-20210427160100469

第13步--查看是否有跳过步骤

查看跑批是否有Skipp步骤,正常结果为空,数据库上执行本步骤

image-20210427160136720

执行结果:

image-20210427160201973

如不为空需逐一排查原因

第14步--解注释

? 3台应用和数据库服务器都执行

image-20210427160313254

执行结果:

image-20210427160421349

image-20210427160547332

变更准备工作被注释的定时任务都被解开

第15步--恢复发送

恢复并修改发送,数据库上执行

image-20210427160638564

执行结果:

image-20210427160655985

第16步--日初日终改为自动

恢复有效并将启动方式调整为手动

数据库上执行本脚本

image-20210427160801554

变更执行完成

总结

自动化变更优势:

  • 执行效率高。传统变更大概需要2到3小时,如果遇到批次多的情况时间会更长。自动化后变更时长缩短到1个小时不到,并且不受批次影响,即无论批次多少都不影响变更时长。
  • 失误少。由于所有执行步骤都封装成了脚本做成了模板,杜绝了手动敲错命令的现象。
  • 界面友好。各步骤执行完后结果反馈的界面很直观,很容易判断执行结果。
  • 集成度高。通过spug自动化变更平台,可以方便的登陆各服务器并执行命令,轻松的进行文件的上传下载。

后记

运维自动化是每个运维人绕不开的话题,现在没有哪个公司不做自动化运维的。公司内也有很多工具和产品,之前也试用过很多开源的自动化平台。结合生产实际,无论是自研的还是开源,选哪个平台用什么产品不是问题,关键是如何切实的减轻工作量,提升工作效率。

目前私有云上的统一运维管理我选的是ansible,变更选择spug。这两个平台都很精准的解决了运维的痛点。一个简单的例子,之前生产环境改密码,100多台服务器至少需要两个小时才能改完,还出现过改错了的情况。每次改密码至少需要登录3次crt,一次是开着窗口防止密码改错了可以及时改回来,一个是修改密码用的,再一个是复核密码。光登录系统就让人崩溃,使用ansible一个yaml脚本统一执行,秒级完成且不会出错。

自动化运维平台不在乎高大上,好用是王道。

如果想了解spug自动化平台,请移步:自动化运维平台Spug测试 ? ?

image-20210427165655235

【本文来源:韩国服务器 http://www.558idc.com/kt.html欢迎留下您的宝贵建议】
上一篇:实测JumpServer2.1堡垒机单机部署2021
下一篇:没有了
网友评论
<