本文是我在一個技術分享群里面，對於任務調度和開源軟件opencron的分享和使用體會，現在整理成文字，供大家參考。
大家好，下面我來分享一下 部署和使用 opencron 任務調度工具的一些經驗和體會
我計划從五個方面來進行分享
1 任務調度需求與要素分析
任務調度，平時在大家的工作中應該會遇到比較多的，對於運維來說，操作系統的重要文件的每天定時備份，操作系統時間同步，各種數據庫的備份，日志和監控信息的抓取等，都需要配置各種定時任務
對於開發和業務來說，一般也會定時運行一些操作或作業，實現一定的開發需求和業務需求
任務調度的需求，在各個地方都會有很多，如果想要建設自動化運維平台，任務調度，也是一個非常重要和基礎的模塊
一般來說，少量的任務調度，都會使用操作系統本身的 crontab 來實現，把想要執行的任務封裝成shell腳本，或者python腳本，添加到 crontab中進行定時運行，任務運行的結果寫入null中，或者記錄到一個日志文件中
這種方式，比較穩定，簡單，在定時任務數量很少，需求也比較簡單的時候，是一種很常見的解決方案； 但當需要執行的任務數量很多，需求更復雜，需要能調度、可視化展示、結果分析等功能時，這種方式就不太能適合需求了
以我現在的實際工作而言，每天需要調度幾十個計算任務、同步任務，在用crontab之后，會有一些痛點，讓我不得不考慮更合適的任務調度策略
我大致梳理了一下，任務調度需要滿足的幾個基本要素：
-
- 通信便捷性：調度server端與agent執行端可以方便通信；
- 作業配置性：所有的作業都可以方便進行配置和修改；
- 執行控制性：可以一般情況下定時調度，也可以異常情況處理；
- 日志展示性：每個任務執行的結果可以方便看到，不用登陸每個機器翻日志來獲取結果；
- 結果概覽性：可以概覽知道一共配置了多少作業，今天是否正常，是否異常；
這幾個任務調度平台的要素，是我現在實際工作中一些痛點，和自己想要任務調度可以達到的目標
在對調度需求和要素進行梳理了，我和同事也進行了調研和思考，目前調研和使用的就是 opencron 任務調度程序
2 opencron特點和部署
這里首先感謝一些 opencron作者的無私分享@B e n-opencron
對於opencron，該項目的特點和解決的問題如下：
通過對這些特點進行了解后，覺得和我需要的幾個方面的任務調度需求，還是比較契合的
於是和同事一起，首先在測試環境進行測試，然后在生產環境逐步進行一些測試腳本的定時調度，逐步添加個別生產任務，最后大規模添加生產任務，按照這樣的思路和過程，逐步確認和使用
對於 opencron 的部署，從架構上講，是采用的 C/S 的架構， 需要有Server端和agent端，整體開發是用Java語言， 需要JDK 1.7 以上的版本； server端的web是用 Tomcat進行支持，需要 Tomcat server 1.8 以上的版本支持
server端的 執行器信息，JOB作業信息，日志信息，用戶訪問控制信息，都是存儲在MySQL數據庫表中，所以還需要一個MySQL數據庫作為后台
部署opecron系統的順序一般是：
-
- 准備MySQL數據庫；
- 確認server端的jdk和Tomcat環境，用jar包的方式，或者 執行 server.sh 的方式部署好 server端，並在瀏覽器進行界面登陸和確認；
- 部署agent端，確認好agent所需的jdk環境，安裝agent包，執行 startup.sh 啟動agent服務，並確認agent和server之間的主機防火牆等可以開通；
- 在server圖形界面，添加agent主機作為執行器；
- 在server圖形界面，添加job作業，指定執行器，調度時間，執行腳本內容等；
- 手工，或自動定時執行作業后，在server圖形界面查看作業執行情況，日志細節等
我在一開始部署的時候，是直接拷貝同事編譯好的包，到server端，然后啟動Tomcat服務，就可以在瀏覽器里面查看了
現在作業已經把整個部署過程，簡化成是三個shell腳本，內置 Tomcat等環境，下載了github相關程序后，直接執行 server.sh 就可以完成服務端的部署和啟動； 直接執行 agent.sh 就可以完成 agent端的部署和啟動
這樣使整個opencron的安裝部署過程，變得比較簡便了
我現在生產環境中的 opencron界面為：
一個具體配置作業的顯示為
3 opencron注意點與使用經驗
opencron部署和使用后，可以對於一開始設想的任務調度要素，與opencron的實際情況進行一個對比
通信便捷性
opencron 的server端，和agent端之間的通信，不需要新創建操作系統用戶，配置ssh互信， 兩者之間的通信是通過 server和agent本身的socket通信來實現的，在網絡可以連通的情況下，只要server端和agent端進程可以啟動，狀態正常，就可以相互通信，完成作業的分發和調度,通信非常便捷
作業配置性
可以看到 opencron的任務配置，最核心的是必須要指定的 執行器主機，作業時間規則，命令內容，作業的名稱和備注
其他附加的還有，運行身份，失敗重跑，超時時間，失敗報警，流程作業設置等功能
整體上配置一個作業是比較簡單的，與原本在crontab中添加一個作業需要填寫的內容，沒有太多區別
@朱紅亮_稠州_運維 我先按照思路分享，一會分享后，我們再探討和交流一下這個問題吧
執行控制性
執行可控性，可以從 執行前，執行中，執行后三個角度來看待
執行前，每一個作業，可以按照確定的時間，定時執行，也可以點擊執行按鈕手工執行，手工執行，在確認作業任務，或者異常情況需要手工執行時，非常有用
新版本opencron中，每個作業，還添加了 “禁用/啟用”功能，對於一個定時任務，可以 用“禁用”將這個任務暫定調度執行，或者用 “啟用”恢復任務的調度執行
這樣在任務執行前，就更加可控了
執行中的作業，可以“調度記錄”-“正在運行”的界面中看到，可以對任務直接執行暫定，或者關閉后重新運行
執行后的作業，主要就是 “調度記錄”-“已完成”界面中，可以獲取該調度任務的具體信息包括最主要的 開始時間，執行時間，是否成功，任務類型等
可以方便地獲知任務執行后的各種狀態結果
日志展示性
這個在前面的截圖中，已經可以看到，每個任務執行的記錄，可以不寫入到日志文件，而是直接存儲在日志表中，在作業執行后結果中顯示
這樣一方面不用登陸到每個機器分別查詢日志文件來獲取狀態，直接在圖形界面中看到結果內容
另一方面，對於作業執行結果，除了我自己關心，很多相關業務人員也非常關系各自的業務任務，每天的執行情況
有了這樣一個日志統一收集和展示的方式，再結合 完善的權限設置，給需要的業務方開放只讀賬號，讓他們可以根據自己的需求，查看任務配置和任務執行情況
這樣就可以使 opencron不僅僅是自己使用的一個 作業調度工具，更成為各相關方進行信息共享與展示的 任務平台了
結果概覽性
在圖形界面中，通過對 執行器，作業，作業日志的控制，就可以清楚地知道相關的配置情況
在一開始的界面中，有儀表盤方式的顯示，對成功任務，失敗任務，有很清晰地展示，就可以很方便地控制和獲知 整體任務執行情況
獲知任務狀態的效率非常高
首頁下方，也還有一個監控概況，可以選擇已經添加的任一一個 執行器 主機，以圖形化的方式實時顯示系統的 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 作業執行日志信息 這幾個表
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 是一個很好的，能夠解決實際的問題的“魚”，任務調度和編排是一種相對通用的“漁”，具體的實現技術和方式，可以有很多種
能夠用“魚”來解決問題，且能夠從中思考“漁”，兩者皆受，會收獲更多！
我今天的分享就到這里了
謝謝大家！