Word中win10打不开表格的处理方法
1006
2022-05-29
一.背景
谈到到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小时内删除侵权内容。