GitLab CI 之 Scheduling Pipelines
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10224845）
延續昨天的內容，對於 CI Service 我們開始有了一些不同的想法，其實它就是一個 Worker，可以利用它來幫我們代勞執行許多的任務，既然如此是不是也能同樣利用 CI Service 來幫我們執行一些需要排程定時執行的工作呢？
答案是當然可以，而 GitLab CI 也針對這樣的需求提供了 Scheduling Pipelines 的功能。
Scheduling Pipelines
在 project 的 CI/CD 中，即可找到 Scheduling Pipelines。就如功能名稱所描述的，這就是一個讓你可以設定排程自動定時執行 CI Job 的功能。
因此，你不仿就將它當成是一個「自動排程任務中心」，可以利用它來執行各式各樣的工作，這邊就舉兩個範例。
爬蟲程式
為了隨時關注網際網路上的最新資訊，讓自己能在第一時間搶得先機，很多工程師都會撰寫爬蟲程式，鎖定特定網站是否有更新資料，例如就有工程師會透過爬蟲定期關注 Apple 官方的認證整修品是否有上架了自己有興趣的產品。
像這樣的爬蟲程式就很適合設定在 Scheduling Pipelines，讓它自動定期定時執行。
在新增 Scheduling Pipelines 時，可以用工程師實現的 Cron Job 的方式設置排程時間，接著告知 GitLab CI 要排程執行的是哪一個 branch 的 CI/CD Pipeline。另外也可以為 Scheduling Pipelines 預先設定特別的 Variables，因此以下圖為例，即是假設這隻 crawler 可以爬取不同 url 的內容，那麼我就可以重複利用它建立多個 Scheduling Pipelines，只要設定不同的 variables 即可。
在 Scheduling Pipelines 可以看到上次執行的結果，以及下一次何時會執行。
（User 也可以按下「按鈕」，直接執行該 Pipeline。）
服務監控
需要定期監控公司的網站是否正常在線上嗎？除了利用坊間的各種監控工具之外，其實也可以透過 CI Service 來代勞。畢竟只要你會善用 curl，其實就可以利用它去定期戳一下網站，根據回傳的 Response 是否正確來判斷網站是否運作正常。
所以只要透過簡單的 CI Job 與自動化腳本，再搭配上 Scheduling Pipelines 即可打造出一個簡易的服務監控。例如你可以規劃類似下面的 CI Job 交給 Scheduling Pipelines 排定每 15 分鐘執行一次，定期檢查網站回傳的 Response，然後根據 Response 判斷要不要送出 Alert，並且最後將結果記錄為 log 存放在某個 Storage 內留存。
stages:
- monitoring
website:
stage: monitoring
tags:
- "ansible"
script:
- ansible-playbook monitoring_website.yml -e url="https://mysite.tw"
- ansible-playbook alerting.yml
- ansible-playbook store_log.yml
小結
今天延續昨天的內容，介紹了另一種利用 CI Service 的方式，將它當成是你的小幫手，將需要定期重複執行的工作都交給它。希望大家都能善用 CI Service，一起當一個又懶又有生產力的工程師！