Gitlab Pipeline+Supervisor 實戰Python項目CI/CD

一.背景

談到到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 <

安裝

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.rb 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 在沒有數據的情況下 [root@gitlab ~]# gitlab-ctl stop [root@gitlab ~]# gitlab-ctl reconfigure //使修改生效 2.如果 /var/opt/gitlab/git-data 目錄已經存在Git倉庫數據， 你可以用下面的命令把數據遷移到新的位置: # 準備遷移之前要停止GitLab服務，防止用戶寫入數據。 [root@gitlab ~]# gitlab-ctl stop # 注意 'repositories'后面不帶斜杠，而 # '/home/gitlab-data'后面是有斜杠的。 [root@gitlab ~]# rsync -av /var/opt/gitlab/git-data/repositories /data/gitlabdata/ # 如果需要修復權限設置， # 可運行下面的命令進行修復。 [root@gitlab ~]# 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

可參考:https://www.imooc.com/article/276994

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 服務器列表

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的作業。

3.4.2 .gitlab-ci.yml 編寫

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 root@172.16.100.2 pkill supervisord || true - ssh -o stricthostkeychecking=no root@172.16.100.2 killall /data/miniconda3/bin/python || true - ssh -o stricthostkeychecking=no root@172.16.100.2 killall /data/miniconda3/envs/go2cloud_platform/bin/python || true - ssh -o stricthostkeychecking=no root@172.16.100.2 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}* root@172.16.100.2:/project${BASE_DIR} - ssh -o stricthostkeychecking=no root@172.16.100.2 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 root@172.16.100.2 /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 root@172.16.100.2 sleep 7 - ssh -o stricthostkeychecking=no root@172.16.100.2 supervisord -c /etc/supervisord.conf - ssh -o stricthostkeychecking=no root@172.16.100.2 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 root@172.16.100.2 sleep 7 - ssh -o stricthostkeychecking=no root@172.16.100.2 ps -ef|grep "8088" tags: - 51common-runner only: - dev when: always

在此我們部署服務分為五個步驟

清理環境：可以配置為全部刪除目標源代碼或這rsync/scp增量覆蓋到目標服務器，如果增量部署，需要考慮遷移數據庫到重復執行。

部署源碼：將gitlab-runner服務器pull下來到代碼scp到目標服務器到目標部署目錄，

安裝依賴：此處有可能后期更新requirements，配置為manual手動去執行更新，如果有更新，手動去安裝。

重啟服務：此時啟動為supervisord服務，啟動后可以自動啟動配置到項目服務。

檢測進程：由于此項目為平臺為寫單元測試，部署上去存在可能代碼有異常進程為能正常啟動，檢測進程是否正常啟動可方便為們知道部署是否成功。

項目中到配置指標和變量可以參考：https://docs.gitlab.com/ee/ci/yaml/README.html

查看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。

五.參考資料

https://docs.gitlab.com/ce/ci/yaml/README.html

https://docs.gitlab.com/ce/ci/README.html

http://supervisord.org/

Git GitHub Python

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。