关于自动化的一点想法

Posted 2020-09-29 运维的自我修养

一、为什么要自动化?

        自动化（Automation）是指机器设备、系统或过程（生产、管理过程）在没有人或较少人的直接参与下，按照人的要求，经过自动检测、信息处理、分析判断、操纵控制，实现预期的目标的过程。自动化技术广泛用于工业、农业、军事、科学研究、交通运输、商业、医疗、服务和家庭等方面。采用自动化技术不仅可以把人从繁重的体力劳动、部分脑力劳动以及恶劣、危险的工作环境中解放出来，而且能扩展人的器官功能，极大地提高劳动生产率，增强人类认识世界和改造世界的能力。因此，自动化是工业、农业、国防和科学技术现代化的重要条件和显著标志。   ---摘自百度百科

          自动化最大的好处就是能减少人为的参与，所有的步骤都根据预先制定好的流程进行，从而减低人为导致的出错率，让人在枯燥重复的工作中解脱出来去做更有意义的事情。

二、自动化的前提

         此处将的自动化是运维系统的自动化，从运维工程师的角度出发，来制定一系列的规范标准，达到自动化的目的。

要想实现自动化，首先是要先实现各个系统的标准化，应用的标准化，部署目录标准化，主机命名标准化等等，无标准化是没有办法做自动化的，所有的自动化都是建立在标准化

的前提下。 这就好像汽车制造厂一样，比如我将汽车的车胎、发动机、车架拆分为不同的生产线来做，各个车型的车胎、车架都是标准的，这样各个零件都生产好之后再组装起来。

想想如果汽车的螺丝没有标准化、大小没有标准化那么肯定不能像现在这样的工业自动化的方式生产汽车了。

         标准化是建立一个统一的规范，大家来遵守并按照规范操作执行。

三、自动化的实现

          下面以java项目的持续集成的例子说明一个自动化项目的实现。

 组件说明：  

1.  源代码： Gitlab 是利用 Ruby on Rails 一个开源的版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。在线Demo.

2. 持续集成： Jenkins 是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。

3. 批量管理： 

SaltStack是一个服务器基础架构集中化管理平台，具备配置管理、远程执行、监控等功能，一般可以理解为简化版的puppet和加强版的func。SaltStack基于Python语言实现，结合轻量级消息队列（ZeroMQ）与Python第三方模块（Pyzmq、PyCrypto、Pyjinjia2、python-msgpack和PyYAML等）构建。

通过部署SaltStack环境，我们可以在成千上万台服务器上做到批量执行命令，根据不同业务特性进行配置集中化管理、分发文件、采集服务器数据、操作系统基础及软件包管理等，SaltStack是运维人员提高工作效率、规范业务配置与操作的利器。

 

      我们需要做的标准化工作包括：

         1. 项目的命名统一

         2. 使用相同的工具打包（maven工具）成war包.

         3. 使用gitlab的分支特性实现不同环境的代码隔离，线上分支使用master

         4. 统一软件的部署路径，例如tomcat规定部署在 /usrl/local/tomcat

         5. 使用pom.xml文件定义不同环境的环境变量，maven编译参数取值

以上我们就完成了java项目相关的标准化工作，将规范发给研发部门并推动执行，这样做的好处也非常的明显，可全部自动化，并且减少了运维和开发在部署上的沟通，

因为都标准化了嘛，大家也不用手动替换单个文件这么low的方式来进行项目的更新了。

 

一个项目的大概流程：   开发提交代码到gitlab ----->在 jenkins点击构建相应的job ---> job[1] 会更新本地的代码到最新------>job[2] 使用maven命令进行打包

-----> 使用salt工具批量分发到目标主机 -----> 使用salt批量重启目标主机上的服务.

        从上面的流程可以看出，需要人为操作的就是提交代码到gitlab后，在jenkins上面点击一下构建的操作就可以完成整个服务的更新了，是不是很方便？

如果不这样的话，你会不会是打好war包之后手动上传到服务目录，然后手动重启tomcat，这样的重复动作还是交给工具来做吧，人就应该做更有价值的事情。

四、总结

        自动化不是一天能够完成的，也不是一个人可以搞定的，这应当是一个团队的事情。如果你们的团队对这种理念比较认可，那你们可真是太幸福了。

标准规范是必须的，其次可以进行工具化，而后再web化，之后再服务化，最后智能化的一个过程。我们总是在说自动化，但是自动化要做到是有前提的，

我们先是鼎好标准规范之后才能谈自动化，因为如果你连标准都没有的话，那真的是毫无自动化构建可言。

        我理解的自动化就是将整个大的任务进行分解，拆分成n个单元，没个单元可独立运行，个单元之间进行解耦，然后在web页面上显示出相应的按钮，

可以对这一系列的动作进行整合操作。就好象是自动化部署那样，我们拆分为 提交代码、触发任务、构建代码、发布程序、重启服务的各个小单元，

而且每个小单元里面都有相应的规则，这样的话，相同的项目我们就可以服务化了。