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 <<EOF
[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
  • 备份还原

a.备份

确保/var/opt/gitlab/backups 目录存在并且gitlab有权限写入文件

gitlab-rake gitlab:backup:create

b.还原

将备份文件拷贝到/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类型：
a.GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。
b.Shared Runner：这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
c.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特征：
a.顺序执行，第一个stage执行完毕，第二个stage开始
b.stage串行执行，前面的一个stage执行失败，后面的所有stage不会执行
c.所有的stage执行都成功，该pipeline任务为成功。

  • Jobs

Jobs为单个stage中的具体执行工作
Jobs特征：
a.同一个stage的jobs会并行执行
b.同一个stage中的所有jobs都执行成功，该stage为成功
c.一个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 服务器列表

名称 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安装注册
# 配置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 [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 [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服务，启动后可以自动启动配置到项目服务。
  • 检测进程：由于此项目为平台为写单元测试，部署上去存在可能代码有异常进程为能正常启动，检测进程是否正常启动可方便为们知道部署是否成功。

项目中到配置指标和变量可以参考：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/

原文地址：https://blog.51cto.com/kaliarch/2388901

时间： 2024-11-06 17:44:44

Gitlab Pipeline+Supervisor 实战Python项目CI/CD的相关文章

jinkens+gitlab针对k8s集群实现CI/CD

一.环境准备 k8s集群环境(我这里是三台的K8s集群): 单独一台docker服务器,主要用于向私有仓库上传镜像,Jenkins和gitlab也部署在这台服务器: 上述环境共计服务器4台,均指向同一个私有仓库,以便共享docker镜像: 服务器IP依次为192.168.20.2.20.3.20.4.20.5(前三个IP为K8s集群中的节点) Jenkins采用war包的方式部署,需要用到tomcat环境,自行参考博文,进行部署:其他环境部署可以参考以下博文:Tomcat安装及优化配置:Dock

【Kubernetes系列】第7篇 CI/CD之组件部署

前言 应对敏捷开发的需求,对CI(持续集成))/CD(持续交付)的提出了更高的标准,今天来讨论下,如何基于开源组件(gitlab/jenkins/harbor/kubernetes)使用CI/CD,赋能团队的开发.运维. 核心组件 组件名称 版本 备注 kubernetes v1.15.3 10.0.0.182:6443 jenkins 2.176.2 集群内部署/ namespace: devops gitlab 11.8 主机部署 harbor v1.7.4 docker-compose部署

Jenkins部署Python项目实战

一.背景 我们工作中常用Jenkins部署Java代码,因其灵活的插件特性,例如jdk,maven,ant等使得java项目编译后上线部署一气呵成,同样对于脚本语言类型如Python上线部署,利用Jenkins强大的插件功能,轻松实现CI/CD,但如果部署多项目到同一台服务器涉及环境一致性问题,对此可以利用容器技术Docker解决,也可以利用Python虚拟环境例如virutalenv或conda等优秀等工具解决,在此由于后期根据requirements来安装依赖包比较慢,且后期需要将Pytho

Jenkins与Docker的自动化CI/CD流水线实战

Jenkins与Docker的自动化CI/CD流水线实战 标签(空格分隔): docker的部分 一:什么是CI/CD 二: 发布流程设计 三:部署Git仓库并上传测试代码 一:什么是CI/CD 持续集成(Continuous Integration,CI):代码合并.构建.部署.测试都在一起,不断地执行这个过程,并对结果反馈. 持续部署(Continuous Deployment,CD):部署到测试环境.预生产环境.生产环境. 持续交付(Continuous Delivery,CD):将最终产

如何使用GitLab和Rancher构建CI/CD流水线 – Part 2

这是我们使用GitLab和Rancher构建CI/CD流水线系列教程的第二部分.第一部分的内容介绍了如何部署.配置和确保GitLab在Rancher的运行.这一部分中,我们将介绍如何使用GitLab CI Multi-Runner构建容器,以及如何使用GitLab容器registry配置项目.除此之外,我们还将涉及如何用GitLab CI建立容器并部署到Rancher上. 使用GitLab CI Multi-Runner构建容器 GitLab CI是用于持续集成和持续交付的强大工具.它需要和Ra

centos7下使用gitlab+shell实现CI/CD持续集成持续部署

centos7下使用gitlab+shell实现CI/CD持续集成持续部署 流程解释:第一步ci客户端向gitlab服务器注册自己,建立通信,第二步,当项目分支代码收到变化时,自动触发yml脚本,yml脚本根据注册时带入的runner通知客户端deploy脚本更新代码,同时执行编译和部署过程,deploy脚本写代码集成相关操作,具体见下面的讲解 CI部分 第一步:准备三台虚拟机S,C1,C2,我这里的三台机子都是全新的,除了系统文件没有其他文件 S:内存是4G用于装gitlab服务器 IP:19

docker与jenkins的自动化CI/CD流水线实战

docker与jenkins的自动化CI/CD流水线实战 在互联网时代,对于每一家公司,软件开发和发布的重要性不言而喻,目前已经形成一套标准的流程,最重要的组成部分就是持续集成(CI)及持续部署.交付(CD).本文基于Jenkins+Docker+Git实现一套CI自动化发布流程. 高效的CI/CD环境可以获得: ? 及时发现问题 ? 大幅度减少故障率 ? 加快迭代速度 ? 减少时间成本 一.发布流程设计 总结:开发===>提交代码到Git/Svn===>推送到Jenkins====>通

Jenkins 结合 Docker 为 .NET Core 项目实现低配版的 CI&amp;CD

随着项目的不断增多,最开始单体项目手动执行 docker build 命令,手动发布项目就不再适用了.一两个项目可能还吃得消,10 多个项目每天让你构建一次还是够呛.即便你的项目少,每次花费在发布上面的时间累计起来都够你改几个 BUG 了. 所以我们需要自动化这个流程,让项目的发布和测试不再这么繁琐.在这里我使用了 Jenkins 作为基础的 CI/CD Pipeline 工具,关于 Jenkins 的具体介绍这里就不再赘述.在版本管理.构建项目.单元测试.集成测试.环境部署我分别使用到了 Go

手把手教导实战Python Web项目

手把手教导实战Python Web项目 一.前言 Django是一个开放源代码的Web应用框架,由Python写成.采用了MVC的框架模式,即模型M,视图V和控制器C.Django的主要目的是简便.快速的开发数据库驱动的网站.它强调代码复用,多个组件可以很方便的以"插件"形式服务于整个框架,Django有许多功能强大的第三方插件,你甚至可以很方便的开发出自己的工具包.这使得Django具有很强的可扩展性. 二.开发环境 Python3.7.4 Django2.0 Django安装 安装