本文是我在一個技術分享羣裏面，對於任務調度和開源軟件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，該項目的特點和解決的問題如下：
通過對這些特點進行了解後，覺得和我需要的幾個方面的任務調度需求，還是比較契合的
於是和同事一起，首先在測試環境進行測試，然後在生產環境逐步進行一些測試腳本的定時調度，逐步添加個別生產任務，最後大規模添加生產任務，按照這樣的思路和過程，逐步確認和使用
對於 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界面爲：
一個具體配置作業的顯示爲
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 是一個很好的，能夠解決實際的問題的“魚”，任務調度和編排是一種相對通用的“漁”，具體的實現技術和方式，可以有很多種
能夠用“魚”來解決問題，且能夠從中思考“漁”，兩者皆受，會收穫更多！
我今天的分享就到這裏了
謝謝大家！