一.背景
談到到CI/CD，我們不禁會想到Gitlab + Jenkins + Docker等一些列優秀的工具，Jenkins以其豐富的插件及靈活配置已經非常好的滿足我們日常工作中的CI/CD需求，通常的做法為Gitlab配置webhook，開發人員通過push代碼或merge request可以觸發執行一些列的測試部署上線工作，打通了開發到部署到整個生命周期，完成持續內建持續建構。
在Gitlab 也是具有一套CI/CD到架構，通過簡單的注冊Gitlab Runner，根據業務測試部署需求撰寫 .gitlab-ci.yml檔案，即可輕松的實作CI/CD，無需多餘的工具介入，友善快捷。
本文對記錄下利用Gitlab pipeline+supervisor來實戰部署Python對tornado項目。
二.基礎必備
2.1 Gitlab
2.1.1 Gitlab 簡介
Gitlab為一套開源代碼倉庫管理系統，有CE(社群版)和EE(企業版)，相較與共有的代碼管理平台Githab，Gitlab常用與私有化部署在企業内網，友善對代碼倉庫及人員的分組及權限管控，輕松友善管理團隊開發流程及多人合作開發規範，通過注冊Runner，編寫.gitlab-ci.yml實作快速項目CI/CD。
2.1.2 搭建部署
更新yum源
cat > /etc/yum.repos.d/gitlab-ce.repo <
[gitlab-ce]
name=Gitlab CE Repository
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el\$releasever/
gpgcheck=0
enabled=1
EOF
安裝
yum clean all && yum makecache
sudo yum install gitlab-ce #自動安裝最新版
sudo yum install gitlab-ce-x.x.x #安裝指定版本
配置啟動
1.修改gitlab配置檔案指定為安裝gitlab伺服器ip和自定義端口： vim /etc/gitlab/gitlab.r
2.重置并啟動GitLab
執行：
gitlab-ctl reconfigure
gitlab-ctl restart
初始賬戶: root 密碼: 5iveL!fe
自定義密碼：
gitlab-rails console production #開始初始化密碼
u=User.where(id:1).first 來查找與切換賬号(User.all 可以檢視所有使用者)
u.password=12345678 設定密碼
u.password_confirmation=12345678
u.save!
exit
修改預設存儲路徑
更改倉庫存儲位置 預設時GitLab的倉庫存儲位置在“/var/opt/gitlab/git-data/repositories”，在實際生産環境中我們會建立資料盤，将重要資料存儲在單獨的資料盤分區中，我這裡規劃把資料存放在“/data/gitlabdata”目錄下。
mkdir -pv /data/gitlabdata
vim /etc/gitlab/gitlab.rb
git_data_dirs({ "default" => { "path" => "/data/gitlabdata" } })
1 在沒有資料的情況下
[[email protected] ~]# gitlab-ctl stop
[[email protected] ~]# gitlab-ctl reconfigure //使修改生效
2.如果 /var/opt/gitlab/git-data 目錄已經存在Git倉庫資料， 你可以用下面的指令把資料遷移到新的位置:
# 準備遷移之前要停止GitLab服務，防止使用者寫入資料。
[[email protected] ~]# gitlab-ctl stop
# 注意 'repositories'後面不帶斜杠，而
# '/home/gitlab-data'後面是有斜杠的。
[[email protected] ~]# rsync -av /var/opt/gitlab/git-data/repositories /data/gitlabdata/
# 如果需要修複權限設定，
# 可運作下面的指令進行修複。
[[email protected] ~]# gitlab-ctl reconfigure
# 再次檢查下 /data/gitlabdata 的目錄. 正常情況應該有下面這個子目錄:
# repositories
備份還原
備份
確定/var/opt/gitlab/backups 目錄存在并且gitlab有權限寫入檔案
gitlab-rake gitlab:backup:create
還原
将備份檔案拷貝到/var/opt/gitlab/backups下
停止相關資料連接配接服務
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
1. 制定時間戳恢複
從備份恢複
從指定時間戳的備份恢複(backups目錄下有多個備份檔案時)：
sudo gitlab-rake gitlab:backup:restore BACKUP=1500809139
2.從預設備份恢複(backups目錄下隻有一個備份檔案時)：
sudo gitlab-rake gitlab:backup:restore
啟動Gitlab
sudo gitlab-ctl start
sudo gitlab-ctl reconfigure
修改預設備份目錄【可選】
你也可以通過修改/etc/gitlab/gitlab.rb來修改預設存放備份檔案的目錄：
gitlab_rails['backup_path'] = '/data/gitlabbackup'
/data/gitlabbackup修改為你想存放備份的目錄即可, 修改完成之後使用gitlab-ctl reconfigure指令重載配置檔案即可
可配合定時任務或上傳到對象存儲，實作異地代碼備份。
2.1.3 Gitlab CI/CD概念
CI/CD的優勢：
盡可能快地檢測錯誤：在開發人員的腦海中解決問題
減少內建問題：更小的問題更容易消化
避免複合問題：讓團隊更快，更自信地發展
確定每個更改都是可釋放的：在調用之前測試所有内容，包括部署
降低每次釋出的風險：使釋出“無聊”
更頻繁地提供價值：可靠的部署意味着更多的版本
嚴密的客戶回報循環：客戶對變更的快速和頻繁回報
Gitlab runner
Gitlab ci/cd是由獨立的runner程式完成，runner采用go語言編寫，是以可以很好的進行跨平台，通常可以将runner部署到任何gitlab server之外的伺服器，進而避免對gitlab server的影響，gitlab runner相當于一個agent安裝在目标伺服器，或這多個項目公用一個runner，runner伺服器單獨來執行建構任務。
runner類型：
GitLab-Runner可以分類兩種類型：Shared Runner(共享型)和Specific Runner(指定型)。
Shared Runner：這種Runner(勞工)是所有工程都能夠用的。隻有系統管理者能夠建立Shared Runner。
Specific Runner：這種Runner(勞工)隻能為指定的工程服務。擁有該工程通路權限的人都能夠為該工程建立Shared Runner。
根據上圖可以看出，gitlab-runner可以安裝到最終項目部署當伺服器上，一個伺服器可以部署多個runner，也可以單獨一台伺服器專用與common-runner來負責多個項目當部署。
Pipeline
Pipeline相當于一次整體的建構任務，其中包含有多個流程步驟(Stages)，例如檢測程序，清理環境，安裝依賴，測試，編譯，部署到dev/prod環境，程序檢查等，可以對比jenkins建構工作流來了解。任何送出代碼或者 Merge Request 的合并都可以觸發 一條Pipeline。
Stages
Stages為一條Pipeline的基本構成步驟，一條pipeline的所有stages構成來一條完整的CI/CD工作流。
Stages特征：
順序執行，第一個stage執行完畢，第二個stage開始
stage串行執行，前面的一個stage執行失敗，後面的所有stage不會執行
所有的stage執行都成功，該pipeline任務為成功。
Jobs
Jobs為單個stage中的具體執行工作
Jobs特征：
同一個stage的jobs會并行執行
同一個stage中的所有jobs都執行成功，該stage為成功
一個stage中的任意一個jobs執行失敗，該stage為失敗，該stage所在的pipline執行失敗
2.2 YAML
2.3 Supervisor
背景
在部署Python項目中，啟動Django項目或Tornado項目，如果将程序放在前台或是利用nohup &放在背景，gitlab pipeline無法進行退出，可以通過編寫腳本部署，但是耗時耗力且需要做單獨對程序監控，不便于我們管理維護，是以利用Superviosr來實作對部署項目start/stop/restart/reload服務管理，通過fork/exec的方式把這些被管理的程序，當supervisor的子程序來啟動，完美解決來項目部署對難題。
簡介
Superviosr為用Python語言開發對一套通用程序管理系統，可利用pip或yum進行安裝，其能将一個普通對指令行程序變為daemon，并監控其程序狀态，可通過配置如果監控程序異常退出則自動對其進行重新開機，同時也擁有web管理界面友善管理檢視。
配置部署
yum install supervisor # 安裝
安裝完成後配置檔案會在/etc/supervisord.conf,對此可自行修改
[unix_http_server]
file=/tmp/supervisor.sock ;UNIX socket 檔案，supervisorctl 會使用
;chmod=0700 ;socket檔案的mode，預設是0700
;chown=nobody:nogroup ;socket檔案的owner，格式：uid:gid
;[inet_http_server] ;HTTP伺服器，提供web管理界面
;port=127.0.0.1:9001 ;Web管理背景運作的IP和端口，如果開放到公網，需要注意安全性
;username=user ;登入管理背景的使用者名
;password=123 ;登入管理背景的密碼
[supervisord]
logfile=/tmp/supervisord.log ;日志檔案，預設是 $CWD/supervisord.log
logfile_maxbytes=50MB ;日志檔案大小，超出會rotate，預設 50MB，如果設成0，表示不限制大小
logfile_backups=10 ;日志檔案保留備份數量預設10，設為0表示不備份
loglevel=info ;日志級别，預設info，其它: debug,warn,trace
pidfile=/tmp/supervisord.pid ;pid 檔案
nodaemon=false ;是否在前台啟動，預設是false，即以 daemon 的方式啟動
minfds=1024 ;可以打開的檔案描述符的最小值，預設 1024
minprocs=200 ;可以打開的程序數的最小值，預設 200
[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ;通過UNIX socket連接配接supervisord，路徑與unix_http_server部分的file一緻
;serverurl=http://127.0.0.1:9001 ; 通過HTTP的方式連接配接supervisord
; [program:xx]是被管理的程序配置參數，xx是程序的名稱
[program:xx]
command=/opt/apache-tomcat-8.0.35/bin/catalina.sh run ; 程式啟動指令
autostart=true ; 在supervisord啟動的時候也自動啟動
startsecs=10 ; 啟動10秒後沒有異常退出，就表示程序正常啟動了，預設為1秒
autorestart=true ; 程式退出後自動重新開機,可選值：[unexpected,true,false]，預設為unexpected，表示程序意外殺死後才重新開機
startretries=3 ; 啟動失敗自動重試次數，預設是3
user=tomcat ; 用哪個使用者啟動程序，預設是root
priority=999 ; 程序啟動優先級，預設999，值小的優先啟動
redirect_stderr=true ; 把stderr重定向到stdout，預設false
stdout_logfile_maxbytes=20MB ; stdout 日志檔案大小，預設50MB
stdout_logfile_backups = 20 ; stdout 日志檔案備份數，預設是10
; stdout 日志檔案，需要注意當指定目錄不存在時無法正常啟動，是以需要手動建立目錄(supervisord 會自動建立日志檔案)
stdout_logfile=/opt/apache-tomcat-8.0.35/logs/catalina.out
stopasgroup=false ;預設為false,程序被殺死時，是否向這個程序組發送stop信号，包括子程序
killasgroup=false ;預設為false，向程序組發送kill信号，包括子程序
;包含其它配置檔案
[include]
files = supervisord.d/*.conf ;可以指定一個或多個以.conf結束的配置檔案
通常我們修改include 中的擴充名為.conf來在其下目錄中配置為們自定義的項目。
在supervisord.d中配置我們對具體項目，例如：
[program:myproject]
command=/data/miniconda3/envs/go2cloud_api_env/bin/python /project/myproject/server.py 8011
user=root
stdout_logfile=/project/go2cloud_api/run.log
autostart=true
autorestart=true
startsecs=60
stopasgroup=true
ikillasgroup=true
startretries=1
redirect_stderr=true
啟動程式
supervisord -c /etc/supervisord.conf
用戶端指令
supervisorctl 是 supervisord的指令行用戶端工具
supervisorctl status：檢視所有程序的狀态
supervisorctl stop myproject：停止es
supervisorctl start myproject：啟動myproject
supervisorctl restart myproject: 重新開機myproject
supervisorctl update ：配置檔案修改後可以使用該指令加載新的配置
supervisorctl reload: 重新啟動配置中的所有程式
...
把myproject 換成all 可以管理配置中的所有程序
注意事項
supervisor不能監控背景程序，command 不能為背景運作指令。
三.實戰部署
3.1 伺服器清單
名稱
IP
軟體
備注gitlab-server
10.57.61.138
gitlab-server
Gitlab 伺服器
gitlab-common-runner
10.57.61.11
gitlab-runner
公用runner伺服器
Des-server
172.21.0.10
miniconda/supervisor
項目部署伺服器
3.2 架構圖
根據上圖，我們可以清晰當看清楚兩種部署模式，多個項目公用一個gitlab-runner，和将gitlab-runner部署到目标伺服器上。由于存在多個項目，友善後期多項目管理，本次我們利用到為公用gitlab-runner。
3.3 前期準備
Gitlab-runner服務區的gitlab-runner使用者可以免密鑰登入des-server伺服器
Gitlab伺服器安裝配置
在目标伺服器安裝配置conda虛拟環境
supervisor部署配置
[program:go2cloud_platform]
command=/data/miniconda3/envs/go2cloud_platform/bin/python /project/go2cloud_platform/runserver start all
user=root
stdout_logfile=/var/log/go2cloud_platform.log
autostart=true
autorestart=true
startsecs=60
stopasgroup=true
ikillasgroup=true
startretries=1
redirect_stderr=true
3.4 配置部署
3.4.1 Gitalb Runner配置
Gitlab runner安裝注冊
gitlab-runner安裝
# 配置yum源
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
# 安裝runner
sudo yum install -y gitlab-ci-multi-runner
開啟項目Pipelines
有的項目為開啟pipeline，需要手動開啟
settings->General->Visibility, project features, permissions->Pipelines
可以配置所有人或此項目到Members可以配置管理Pipeline
記錄注冊資訊
settings->CI/CD>Runners
記錄注冊url和token
在gitlabrunner伺服器進行注冊
# gitlab runner注冊到平台
sudo gitlab-ci-multi-runner register
此處我們選擇的為單機shell執行，如果為docker可以選擇docker，注冊完成後可以傳回gitlab web管理界面檢視已經注冊的runner。
也可以對runner進行配置。
配置runner
可以勾選Active，runner為公用對時候，暫停Runner不接受新的jobs
如果沒有制定tag，可以運作在未指定tag的作業。
stages:
- clean_env # 清理環境及殺死程序
- deploy_src # 部署源碼
- install_dependency # 更新依賴
- restart_server # 重新開機服務
- check_server # 檢測服務
variables:
BASE_DIR: "/go2cloud_platform/"
job clean_env_job:
stage: clean_env
script:
- ssh -o stricthostkeychecking=no [email protected] pkill supervisord || true
- ssh -o stricthostkeychecking=no [email protected] killall /data/miniconda3/bin/python || true
- ssh -o stricthostkeychecking=no [email protected] killall /data/miniconda3/envs/go2cloud_platform/bin/python || true
- ssh -o stricthostkeychecking=no [email protected] rm -rf /project${BASE_DIR}*
tags:
- 51common-runner
only:
- dev
when: always
job deploy_src_job:
stage: deploy_src
script:
- scp -r /home/gitlab-runner/builds/QFafrHEq/0/devops/${BASE_DIR}* [email protected]:/project${BASE_DIR}
- ssh -o stricthostkeychecking=no roo[email protected] cp /project/config/config.yml /project${BASE_DIR}
tags:
- 51common-runner
only:
- dev
when: always
job install_dependency_job:
stage: install_dependency
script:
- ssh -o stricthostkeychecking=no [email protected] /data/miniconda3/envs/go2cloud_platform/bin/python -m pip install -r /project${BASE_DIR}requirements/requirements.txt
tags:
- 51common-runner
only:
- dev
when: manual
job restart_server_job:
stage: restart_server
script:
- ssh -o stricthostkeychecking=no [email protected] sleep 7
- ssh -o stricthostkeychecking=no [email protected] supervisord -c /etc/supervisord.conf
- ssh -o stricthostkeychecking=no [email protected] ps -ef |grep supervisord |grep -v grep
tags:
- 51common-runner
only:
- dev
when: always
job check_server_job:
stage: check_server
script:
- ssh -o stricthostkeychecking=no [email protected] sleep 7
- ssh -o stricthostkeychecking=no [email protected] ps -ef|grep "8088"
tags:
- 51common-runner
only:
- dev
when: always
在此我們部署服務分為五個步驟
清理環境：可以配置為全部删除目标源代碼或這rsync/scp增量覆寫到目标伺服器，如果增量部署，需要考慮遷移資料庫到重複執行。
部署源碼：将gitlab-runner伺服器pull下來到代碼scp到目标伺服器到目标部署目錄，
安裝依賴：此處有可能後期更新requirements，配置為manual手動去執行更新，如果有更新，手動去安裝。
重新開機服務：此時啟動為supervisord服務，啟動後可以自動啟動配置到項目服務。
檢測程序：由于此項目為平台為寫單元測試，部署上去存在可能代碼有異常程序為能正常啟動，檢測程序是否正常啟動可友善為們知道部署是否成功。
檢視pipeline
檢視具體jobs資訊
如果那個jobs執行失敗可以進行手動retry。
檢視CI/CD charts
charts直覺的展示來建構到成功及失敗圖表。
檢視建構郵件
在des-server檢視項目
通過web界面檢視
至此一個完整到Gitlab runner就配置完成。
四.總結反思
gitlab-runner配置簡單,與gitlab內建友好，無需單獨搭建建構平台，告警有gitalb發送。當建立一個項目的時候，不需要配置webhook回調位址，将部署繼承在代碼的.gitlab-ci.yml 中易于維護管理。
gitlab-ci/cd沒有代碼審計，需要單獨配置，随着業務增加，團隊擴充需要單獨建構代碼審計平台。
如果小型Devops團隊建議利用Gitlab CI/CD友善管理維護，如果大型gitlab ci/cd無法滿足可以結合jenkins來實作CI/CD。
五.參考資料