本文是我在一个技术分享群里面,对于任务调度和开源软件opencron的分享和使用体会,现在整理成文字,供大家参考。

        大家好,下面我来分享一下 部署和使用 opencron 任务调度工具的一些经验和体会
        我计划从五个方面来进行分享


1 任务调度需求与要素分析
        任务调度,平时在大家的工作中应该会遇到比较多的,对于运维来说,操作系统的重要文件的每天定时备份,操作系统时间同步,各种数据库的备份,日志和监控信息的抓取等,都需要配置各种定时任务
        对于开发和业务来说,一般也会定时运行一些操作或作业,实现一定的开发需求和业务需求
        任务调度的需求,在各个地方都会有很多,如果想要建设自动化运维平台,任务调度,也是一个非常重要和基础的模块
        一般来说,少量的任务调度,都会使用操作系统本身的  crontab 来实现,把想要执行的任务封装成shell脚本,或者python脚本,添加到 crontab中进行定时运行,任务运行的结果写入null中,或者记录到一个日志文件中
        这种方式,比较稳定,简单,在定时任务数量很少,需求也比较简单的时候,是一种很常见的解决方案; 但当需要执行的任务数量很多,需求更复杂,需要能调度、可视化展示、结果分析等功能时,这种方式就不太能适合需求了
        以我现在的实际工作而言,每天需要调度几十个计算任务、同步任务,在用crontab之后,会有一些痛点,让我不得不考虑更合适的任务调度策略

        我大致梳理了一下,任务调度需要满足的几个基本要素:
  1.         通信便捷性:调度server端与agent执行端可以方便通信;
  2.         作业配置性:所有的作业都可以方便进行配置和修改;
  3.         执行控制性:可以一般情况下定时调度,也可以异常情况处理;
  4.         日志展示性:每个任务执行的结果可以方便看到,不用登陆每个机器翻日志来获取结果;
  5.         结果概览性:可以概览知道一共配置了多少作业,今天是否正常,是否异常;

        这几个任务调度平台的要素,是我现在实际工作中一些痛点,和自己想要任务调度可以达到的目标
        在对调度需求和要素进行梳理了,我和同事也进行了调研和思考,目前调研和使用的就是 opencron 任务调度程序


2 opencron特点和部署
        这里首先感谢一些 opencron作者的无私分享@B e n-opencron
        对于opencron,该项目的特点和解决的问题如下:

opencron01_.png

        通过对这些特点进行了解后,觉得和我需要的几个方面的任务调度需求,还是比较契合的
        于是和同事一起,首先在测试环境进行测试,然后在生产环境逐步进行一些测试脚本的定时调度,逐步添加个别生产任务,最后大规模添加生产任务,按照这样的思路和过程,逐步确认和使用
        对于 opencron 的部署,从架构上讲,是采用的 C/S 的架构, 需要有Server端和agent端,整体开发是用Java语言, 需要JDK 1.7 以上的版本; server端的web是用 Tomcat进行支持,需要 Tomcat server 1.8 以上的版本支持
        server端的 执行器信息,JOB作业信息,日志信息,用户访问控制信息,都是存储在MySQL数据库表中,所以还需要一个MySQL数据库作为后台

        部署opecron系统的顺序一般是:

  1.         准备MySQL数据库;
  2.         确认server端的jdk和Tomcat环境,用jar包的方式,或者 执行 server.sh 的方式部署好 server端,并在浏览器进行界面登陆和确认;
  3.         部署agent端,确认好agent所需的jdk环境,安装agent包,执行 startup.sh 启动agent服务,并确认agent和server之间的主机防火墙等可以开通;
  4.         在server图形界面,添加agent主机作为执行器;
  5.         在server图形界面,添加job作业,指定执行器,调度时间,执行脚本内容等;
  6.         手工,或自动定时执行作业后,在server图形界面查看作业执行情况,日志细节等

        我在一开始部署的时候,是直接拷贝同事编译好的包,到server端,然后启动Tomcat服务,就可以在浏览器里面查看了
        现在作业已经把整个部署过程,简化成是三个shell脚本,内置 Tomcat等环境,下载了github相关程序后,直接执行 server.sh 就可以完成服务端的部署和启动; 直接执行 agent.sh 就可以完成 agent端的部署和启动
        这样使整个opencron的安装部署过程,变得比较简便了

        我现在生产环境中的 opencron界面为:

02_.png

        一个具体配置作业的显示为

03_.png


3 opencron注意点与使用经验
        opencron部署和使用后,可以对于一开始设想的任务调度要素,与opencron的实际情况进行一个对比


        通信便捷性
        opencron 的server端,和agent端之间的通信,不需要新创建操作系统用户,配置ssh互信, 两者之间的通信是通过 server和agent本身的socket通信来实现的,在网络可以连通的情况下,只要server端和agent端进程可以启动,状态正常,就可以相互通信,完成作业的分发和调度,通信非常便捷


        作业配置性



04_.png       

05_.png

可以看到 opencron的任务配置,最核心的是必须要指定的 执行器主机,作业时间规则,命令内容,作业的名称和备注
        其他附加的还有,运行身份,失败重跑,超时时间,失败报警,流程作业设置等功能
        整体上配置一个作业是比较简单的,与原本在crontab中添加一个作业需要填写的内容,没有太多区别
        @朱红亮_稠州_运维   我先按照思路分享,一会分享后,我们再探讨和交流一下这个问题吧


        执行控制性
06.png        执行可控性,可以从 执行前,执行中,执行后三个角度来看待
        执行前,每一个作业,可以按照确定的时间,定时执行,也可以点击执行按钮手工执行,手工执行,在确认作业任务,或者异常情况需要手工执行时,非常有用
        新版本opencron中,每个作业,还添加了  “禁用/启用”功能,对于一个定时任务,可以 用“禁用”将这个任务暂定调度执行,或者用 “启用”恢复任务的调度执行
        这样在任务执行前,就更加可控了
        执行中的作业,可以“调度记录”-“正在运行”的界面中看到,可以对任务直接执行暂定,或者关闭后重新运行
        执行后的作业,主要就是 “调度记录”-“已完成”界面中,可以获取该调度任务的具体信息包括最主要的 开始时间,执行时间,是否成功,任务类型等
        可以方便地获知任务执行后的各种状态结果


        日志展示性
07.png        这个在前面的截图中,已经可以看到,每个任务执行的记录,可以不写入到日志文件,而是直接存储在日志表中,在作业执行后结果中显示
        这样一方面不用登陆到每个机器分别查询日志文件来获取状态,直接在图形界面中看到结果内容
        另一方面,对于作业执行结果,除了我自己关心,很多相关业务人员也非常关系各自的业务任务,每天的执行情况
        有了这样一个日志统一收集和展示的方式,再结合 完善的权限设置,给需要的业务方开放只读账号,让他们可以根据自己的需求,查看任务配置和任务执行情况
        这样就可以使 opencron不仅仅是自己使用的一个 作业调度工具,更成为各相关方进行信息共享与展示的 任务平台了


        结果概览性
08.png        在图形界面中,通过对 执行器,作业,作业日志的控制,就可以清楚地知道相关的配置情况
        在一开始的界面中,有仪表盘方式的显示,对成功任务,失败任务,有很清晰地展示,就可以很方便地控制和获知 整体任务执行情况
        获知任务状态的效率非常高

        首页下方,也还有一个监控概况,可以选择已经添加的任一一个 执行器 主机,以图形化的方式实时显示系统的 cpu,内存,进程,磁盘空间等信息
        这样发起一个作业后,对于客户端主机的资源消耗情况,进行一个实时的监控,对系统状态,就可以有更好的把控了
        通过对比,目前opencron的功能,与我需要的任务调度诉求,还是比较契合的,所以整体上也在线上运行了一段时间,状态比较良好

       
        Opencron使用时的注意点
        当然在使用opencron时,还有一些地方也需要注意下:
        a. 部署软件包规划
        由于部署opencron对Java jdk 和Tomcat都有一定要求,如果部署的系统中,已经有不同版本的jdk或Tomcat,建议不要替换整个系统中的环境版本,只需要安装一个新目录,然后在opencron中指定对应位置
        这样既可以满足opencron部署需求,又可以不影响原有线上环境


        b. 基础环境规划
        基础环境,比如网络环境,主机资源环境等,一定要估算和确认好,避免基础环境影响任务调度
        比如把opencron底层的mysql实例,server启动命令,agent启动命令,都添加到 /etc/rc.lcal 中开机自动启动,避免实例重启,agent进程不在,就无法调度任务了;
        另外如果网络环境不好,也可能出现在执行器界面,显示server与agent失联的情况;
        我的环境中,有时就会出现 agent由于网络条件不好,显示为失联状态,但实际所有任务都会调度成功


        c. 平台权限完善
        权限控制的完善, 目前opencron中只有 superadmin 和 admin两种角色,这两种角色都是读写权限,可以查看和修改作业;
        但如果想给不了解调度,只需要知道结果的业务人员来说,就只能给他们分配 只读权限,这样就即可以实现信息共享,又能避免作业被随意修改的问题;
        我目前采用的折中方案,是对opencron底层的MySQL数据库,开放了一个select只读用户,并提供了查看作业执行结果的sql语句,发给业务方,让他们能够通        过只读用户访问底层表,来获知作业相关信息


4 opencron与其他常见任务调度方案的引申
        通过对opencron的说明和对比,可以看底层的信息
        opencron底层在MySQL数据库中,创建了一个 opencron_db 库,里面建了10张MySQL表
        其中改变比较多的,就是 T_AGENT 执行器信息, T_JOB 作业流程信息, T_RECORD 作业执行日志信息 这几个表

09.png

        opencron底层在MySQL数据库中,创建了一个 opencron_db 库,里面建了10张MySQL表
        其中改变比较多的,就是 T_AGENT 执行器信息, T_JOB 作业流程信息, T_RECORD 作业执行日志信息 这几个表
        把这些主要的表再抽象一下,就可以知道满足任务调度的五个基本需求,进行对比,实际上就是 以“任务”为维度,在执行前保证好 “执行器和作业”的配置,         在执行过程中,保证“正在执行的任务”可用,在执行后可以将“作业调度的详细结果和整体结果”展示
        这样,配置“执行器任务”信息,监测时间调度作业,最后图形展示作业结果,这就形成了一个闭环,也抽象出了任务调度核心三各本质点
        再加上平台都需要的 权限管理,邮件发送,报警通知,界面展示等,就可以完成一个不错的任务调度平台
        反过来说,把每个部分用不同的技术对待,或者细化,深化,就形成了新的任务调度体系
        比如 从作业元信息获取命令和参数,用worker通讯和执行;  在调度阶段用 beat 一直监视是否到时间,调用的多个命令,不是直接发起,而是引入消息队列,实现各种不同的并行或串行;  最后的结果,用redis存储,用flower展示
        通用的权限,邮件,报警,界面 这些用Django框架实现
        这样就是目前 Django + celery 的任务调度实现思路
        所用方法和技术不同,但任务调度的要素和本质都是相同的
        当然,我所知道的,直接用python语言,Python常用和自带的各种包,来实现各个过程,成为一个任务调度平台,也是有的

5 opencron的展望和建议
        最后在回到opencron本身,通过刚才的思考和讨论,从整体上看待opencron后,又对opencron的一些细节,进行了对比
        从opencron这个具体的,能够很好解决问题工具,延伸出一种平台和实现思路
        可以使opencron本身的功能,获得更多的完善和增进
        作者把好的项目开源出来,大家通过使用,反馈,建议,再回馈给作者
        这样就可以使 opencron 和社区都不断变好
        甚至有人从这种框架和实现思路中,得到启发和借鉴,在有时间和精力的前提下,也不断深化和完善某个模块,产生出新的开源项目
        opencron 是一个很好的,能够解决实际的问题的“鱼”,任务调度和编排是一种相对通用的“渔”,具体的实现技术和方式,可以有很多种
        能够用“鱼”来解决问题,且能够从中思考“渔”,两者皆受,会收获更多!


        我今天的分享就到这里了
        谢谢大家!