DevOps 之 Jenkins+GitLab+SonarQube (一)

一、DevOps

  • DevOps 是 Development 和 Operations 的组合,也就是开发和运维的简写。
  • DevOps 是针对企业中的研发人员、运维人员和测试人员的工作理念,是他们在应用开发、代码部署和质量测试等整条生命周期中协作和沟通的最佳实践,强调整个组织的合作以及交付和基础设施变更的自动化、从而实现持续集成、持续部署和持续交付。
  • DevOps 四大平台:代码托管(gitlab/svn)、项目管理(jira)、运维平台(腾讯蓝鲸/开源平台)、持续交付(Jenkins/gitlab)

1.1 什么是 DevOps

1.2 为什么要推广 DevOps

  • DevOps 强调团队协作、相互协助、持续发展,然而传统的模式是开发人员只顾开发程序,运维只负责基础环境管理和代码部署及监控等,其并不是为了一个共同的目标而共同实现最终的目的,而 DevOps 则实现团队作战,即无论是开发、运维还是测试,都为了最终的代码发布、持续部署和业务稳定而付出各自的努力,从而实现产品设计、开发、测试和部署的良性循环,实现产品的最终持续交付。

1.3 什么是持续集成

  • 持续集成(CI-Continuous integration)
    • 持续集成是指多名开发者在开发不同功能代码的过程当中,可以频繁的将代码行合并到一起并且相互不影响工作。

1.4 什么是持续部署

  • 持续部署(CD-continuous deployment)
    • 是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品,持续部署在某种程度上代表了一个开发团队的更新迭代速率。

1.5 什么是持续交付

  • 持续交付(Continuous Delivery)
    • 持续交付是在持续部署的基础之上,将产品交付到线上环境,因此持续交付是产品价值的一种交付,是产品价值的一种盈利的实现。

1.6 常见的部署方式

  • 开发自己上传–最原始的方案
  • 开发给运维手动上传–运维自己手动部署
  • 运维使用脚本复制–半自动化
  • 结合 web 界面一键部署–自动化

1.7 常见的持续集成开源工具

  • 在公司的服务器安装某种程序,该程序用于按照特定格式和方式记录和保存公司多名开发人员不定期提交的源代码,且后期可以按照某种标记及方式对用户提交的数据进行还原。

1.7.1 CVS(Concurrent Version System)

  • 早期的集中式版本控制系统,现已基本淘汰,会出现数据提交后不完整的情况

1.7.2 SVN(Subversion)–集中式版本控制系统

  • 2000 年开始开发,目标就是替代 CVS 集中式管理,依赖于网络,一台服务器集中管理目前依然有部分公司在使用。

1.7.3 Gitlib—分布式版本控制系统

  • Linus 在 1991 年创建了开源的 Linux 内核,从此 Linux 便不断快速发展,不过 Linux 的壮大是离不开全世界的开发者的参与,这么多人在世界各地为 Linux 编写代码,那Linux 内核的代码是如何管理的呢?事实是,在 2002 年以前,世界各地的志愿者把源代码文件通过 diff 的方式发给 Linus,然后由 Linus 本人通过手工方式合并代码!你也许会想,为什么 Linus 不把 Linux 代码放到版本控制系统里呢?不是有 CVS、SVN 这些免费的版本控制系统吗?因为 Linus 坚定地反对 CVS 和 SVN,这些集中式的版本控制系统不但速度慢,且必须联网才能使用,但是也有一些商用的版本控制系统,虽然比CVS、SVN 好用,但那是付费的,和 Linux 的开源精神不符,不过,到了 2002 年,Linux系统已经发展了十年了,代码库之大让 Linus 很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是 Linus 选择了一个商业的版本控制系统BitKeeper,BitKeeper 的东家 BitMover 公司出于人道主义精神,授权 Linux 社区免费使用这个版本控制系统,但是安定团结的大好局面在 2005 年就被打破了,原因是 Linux社区牛人聚集,不免沾染了一些梁山好汉的江湖习气,开发 Samba 的 Andrew 试图破解 BitKeeper 的协议(这么干的其实也不只他一个),被 BitMover 公司发现了(监控工作做得不错!),于是 BitMover 公司怒了,要收回 Linux 社区的免费使用权,这时候其实 Linus 可以向 BitMover 公司道个歉,保证以后严格管教弟兄们,但这是不可能的,而且实际情况是 Linus 自己花了两周时间自己用 C 写了一个分布式版本控制系统,这就是 Git!一个月之内,Linux 内核的源码已经由 Git 管理了!牛是怎么定义的呢?大家可以体会一下,然后Git迅速成为最流行的分布式版本控制系统,尤其是2008年,GitHub网站上线了,它为开源项目免费提供Git存储,无数开源项目开始迁移至GitHub,包括 jQuery,PHP,Ruby 等等

1.8 版本控制系统分类

1.8.1 集中式版本控制系统

  • 任何的提交和回滚都依赖于连接服务器 SVN 服务器是单点

1.8.2 分布式版本控制系统

  • Git 在每个用户都有一个完整的服务器,然后在有一个中央服务器,用户可以先将代码提交到本地,没有网络也可以先提交到本地,然后在有网络的时候再提交到中央服务器,这样就大大方便了开发者的代码提交和回滚,而相比 CVS 和 SVN 都是集中式的版本控制系统,工作的时候需要先从中央服务器获取最新的代码,改完之后需要提交,如果是一个比较大的文件则需要足够快的网络才能快速提交完成,而使用分布式的版本控制系统,每个用户都是一个完整的版本库,即使没有中央服务器也可以提交代码或者回滚,最终再把改好的代码提交至中央服务器进行合并即可。

二、Gitlab部署与使用

  • https://about.gitlab.com/install/ # Gitlab 服务的安装文档
  • https://docs.gitlab.com/ce/install/requirements.html # 安装环境要求

2.1 下载并部署 gitlab

2.1.1 gitlab 安装

  • 安装包下载地址:https://packages.gitlab.com/gitlab/gitlab-ce
  • rpm 包国内下载地址:https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/
  • ubuntu 国内下载地址:https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu/pool/

dpkg -i gitlab-ce_11.11.8-ce.0_amd64.deb

2.1.2 gitlab 配置使用

grep "^[a-Z]" /etc/gitlab/gitlab.rb # 配置文件
external_url 'http://192.168.7.101'
# 可选邮件通知设置
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.qq.com"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_user_name'] = "123456789@qq.com"
gitlab_rails['smtp_password'] = "jbopxjjkfhxabeij"
gitlab_rails['smtp_domain'] = "qq.com"
gitlab_rails['smtp_authentication'] = :login
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = true
gitlab_rails['gitlab_email_from'] = "123456789@qq.com"
user["git_user_email"] = "123456789@qq.com"

# gitlab-rails console # 测试邮件
irb(main):001:0> Notify.test_email('123@163.com', 'Message Subject', 'Message Body').deliver_now

2.1.3 初始化服务

  • 执行配置并启动服务:gitlab-ctl reconfigure 修改完配置文件要执行此操作

gitlab 相关的目录有哪些

  • /etc/gitlab # 配置文件目录
  • /run/gitlab # 运行 pid 目录
  • /opt/gitlab # 安装目录
  • /var/opt/gitlab # 数据目录
  • /var/log/gitlab # 日志目录

2.1.4 gitlab常用命令

  • gitlab-rails
    用于启动控制台进行特殊操作,比如修改管理员密码、打开数据库控制台 (gitlab-rails dbconsole) 等

  • gitlab-psql # 数据库命令行
  • gitlab-rake # 数据备份恢复等数据操作
  • gitlab-ctl # 客户端命令行操作行
  • gitlab-ctl stop # 停止 gitlab
  • gitlab-ctl start # 启动 gitlab
  • gitlab-ctl restart # 重启 gitlab
  • gitlab-ctl status # 查看组件运行状态
  • gitlab-ctl tail nginx # 查看某个组件的日志
  • gitlab-ctl reconfigure # 重新配置gitlab

2.1.5 验证 gitlab 启动完成

2.1.6 验证端口及状态

  • 80 端口是在初始化 gitlib 的时候启动的,因此如果之前的有程序占用会导致初始化失败或无法访问!

2.2 登录 gitlab web

2.2.1 首次登录设置密码

  • 登录 web 页面并设置密码,最少 8 位

2.2.2 登录

  • 登录,默认用户为 root

2.2.3 默认首页

2.3 关闭 gitlab 账号注册

  • 默认情况下可以直接注册账号,因此一般都关闭此功能

2.4 创建 git 账户

2.4.1 创建账户

image-20210404223939494

2.4.2 在收件箱打开邮件设置密码

image-20210404233622805

2.4.3 设置密码

2.5 创建组

使用管理员 root 创建组,一个组里面可以有多个项目分支,可以将开发添加到组里面进行设置权限,不同的组就是公司不同的开发项目或者服务模块,不同的组添加不同的开发即可实现对开发设置权限的管理

2.6 使用管理员创建项目

  • 创建后的项目效果

2.7 将用户添加到组

  • https://docs.gitlab.com/ee/user/permissions.html # 更多权限介绍

image-20210404234827549

2.8 创建一个hlml文件

2.8.1 搜索项目

2.8.2 创建文件

添加内容

2.9 git 客户端测试 clone 项目

2.9.1 git clone到本地

git clone http://192.168.7.101/group-test1/project-test1.git

2.9.2 编辑文件并测试提交

cd project-test1/
git config --global user.name "jack"
git config --global user.email "11111111@163.com" 
cat index.html
<h1>111111111 v1</h1>
<h1>222222222 v2</h1>
git add index.html
git commit -m "v1"
git push

2.9.3 git web 端验证数据

2.9 gitlab 使用

2.9.1 数据保存方式

  • SVN 与 CVS
    每次提交的文件都单独保存,即按照文件的提交时间区分不同的版本,保存至不同 的逻辑存储区域,后期恢复的时候直接基于之前版本恢复。

  • Gitlab
    Gitlab 与 SVN 的数据保存方式不一样,gitlab 虽然也会在内部对数据进行逻辑划分保存,但是当后期提交的数据如果和之前提交过的数据没有变化,其就直接快照之前的 文件,而不是在将文件重新上传一份在保存一遍,这样既节省了空间又加快了代码提交速度。

2.9.2 常用 git 命令

  • 使用 git 命令下载代码与提交代码等操作。

git config --global user.name "name" # 设置全局用户名
git config --global user.email xxx@xx.com # 设置全局邮箱
git config --global --list # 列出用户全局设置
git add index.html / . # 添加指定文件、目录或当前目录下所有数据到暂存区
git commit -m "11" # 提交文件到工作区并添加备注
git status # 查看工作区的状态
git push # 提交代码到服务器
git pull # 获取代码到本地
git log # 查看操作日志
vim .gitignore # 定义忽略文件
git reset --hard HEAD^^ # git 版本回滚, HEAD 为当前版本,加一个^为上一个,^^为上上一个版本
git reflog  # 获取每次提交的 ID,可以使用--hard 根据提交的 ID 进行版本回退
git reset --hard 5ae4b06 # 回退到指定 id 的版本
git branch # 查看当前所处的分支
git checkout -b develop # 创建并切换到一个新分支
git checkout develop # 切换分支

2.9.3 git 缓存区与工作区等概念

  • 工作区:clone 的代码或者开发自己编写的代码文件所在的目录,通常是代码所在的一个服务的目录名称。
  • 暂存区:用于存储在工作区中对代码进行修改后的文件所保存的地方,使用 git add 添加。
  • 本地仓库:用于提交存储在工作区和暂存区中改过的文件地方,使用 git commit 提交。
  • 远程仓库:多个开发共同协作提交代码的仓库,即 gitlab 服务器。

2.9.4 gitlab 数据备份恢复

停止 gitlab 数据服务

<root@ubuntu181 project-test1>#gitlab-ctl stop unicorn
ok: down: unicorn: 0s, normally up
<root@ubuntu181 project-test1>#gitlab-ctl stop sidekiq
ok: down: sidekiq: 0s, normally up

手动备份数据

# gitlab-rake gitlab:backup:create # 在任意目录即可备份当前 gitlab 数据
# gitlab-ctl start # 备份完成后启动 gitlab

查看要恢复的文件

  • /var/opt/gitlab/backups/ # Gitlab 数据备份目录,需要使用命令备份的
  • /var/opt/gitlab/nginx/conf # nginx 配置文件
  • /etc/gitlab/gitlab.rb # gitlab 配置文件
  • /etc/gitlab/gitlab-secrets.json # key 文件
[root@cent711 /data/project-test1]#ll /var/opt/gitlab/backups/
total 100
-rw------- 1 git git 102400 Apr  4 23:54 1617551685_2021_04_04_11.11.8_gitlab_backup.tar

执行恢复

  • 删除一些数据,测试能否恢复。
# 恢复数据之前停止服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
# 恢复
gitlab-rake gitlab:backup:restore BACKUP=备份文件名

启动服务

gitlab-ctl start unicorn
gitlab-ctl start sidekiq

2.10 gitlab 汉化

  • 虽然不推荐,但是有需求,基于第三方开发爱好者实现。

2.10.1下载语言包替换

  • https://gitlab.com/xhang/gitlab
  • https://gitlab.com/xhang/gitlab/-/archive/v11.11.8/gitlab-v11.11.8.tar.gz

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION # 查看版本

2.10.2 替换文件

# 首次安装 gitlab 步骤
vim /etc/gitlab/gitlab.rb # 修改配置
gitlab-ctl reconfigure

# 已经安装 gitlab 步骤
wget https://gitlab.com/xhang/gitlab/-/archive/v11.11.8-zh/gitlab-v11.11.8-zh.tar.gz
gitlab-ctl stop
tar xvf gitlab-v11.11.8-zh.tar.gz
cp -rp /opt/gitlab/embedded/service/gitlab-rails /opt/gitlab-rails.bak # 备份源文件
cp -rf gitlab-v11.11.8-zh/* /opt/gitlab/embedded/service/gitlab-rails/ # 替换文件
gitlab-ctl reconfigure
gitlab-ctl start

2.10.3 Web 界面更改语言

  • 右上角的账户下拉框选 Settings 然后左侧 Preferences 设置项,然后语言选择中文

  • 保存后刷新界面

image-20210405001015079

2.10.4 补充:通过源码汉化(暂无)

2.11 常见的代码部署方式

2.11.1 蓝绿部署

  • 蓝绿部署指的是不停老版本代码(不影响上一个版本访问),而是在另外一套环境部署新版本然后进行测试,测试通过后将用户流量切到新版本,其特点为业务无中断,升级风险相对较小。

  • 具体过程:

1、当前版本业务正常访问(V1)
2、在另外一套环境部署新代码(V2),代码可能是增加了功能或者是修复了某些 bug
3、测试通过之后将用户请求流量切到新版本环境
4、观察一段时间,如有异常直接切换旧版本
5、下次升级,将旧版本升级到新版本(V3)

  • 蓝绿部署适用的场景:

1、不停止老版本,额外部署一套新版本,等测试发现新版本 OK 后,删除老版本。
2、蓝绿发布是一种用于升级与更新的发布策略,部署的最小维度是容器,而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持,但是对于涉及数据表结构变更等等不可逆转的升级, 并不完全合适用蓝绿发布来实现,需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。

2.11.2 金丝雀发布

  • 金丝雀发布也叫灰度发布,是指在黑与白之间,能够平滑过渡的一种发布方式,灰度发 布是增量发布的一种类型,灰度发布是在原有版本可用的情况下,同时部署一个新版本应用作为“金丝雀”(小白鼠),测试新版本的性能和表现,以保障整体系统稳定的情况下,尽早发现、调整问题。

“金丝雀”的由来:17 世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;而当瓦斯含量超过一定限度时,虽然鲁钝的人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”,以便在危险状况下紧急撤离。

  • 金丝雀发布、灰度发布步骤组成:

1、准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。
2、从负载均衡列表中移除掉“金丝雀”服务器。
3、升级“金丝雀”应用(排掉原有流量并进行部署)。
4、对应用进行自动化测试。
5、将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
6、如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)
灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。

  • 灰度发布/金丝雀部署适用的场景:

1、不停止老版本,额外搞一套新版本,不同版本应用共存。
2、灰度发布中,常常按照用户设置路由权重,例如 90% 的用户维持使用老版本,10%的用户尝鲜新版本。
3、经常与 A/B 测试一起使用,用于测试选择多种方案。

2.11.3 滚动发布

  • 滚动发布,一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用。 周而复始,直到集群中所有的实例都更新成新版本。

2.11.4 A/B 测试

  • A/B 测试也是同时运行两个 APP 环境,但是蓝绿部署完全是两码事,A/B 测试是用来测试应用功能表现的方法,例如可用性、受欢迎程度、可见性等等,蓝绿部署的目的是安全稳定地发布新版本应用,并在必要时回滚,即蓝绿部署是一套正式环境环境在线,而 A/B 测试是两套正式环境在线。

image-20210405001434790

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇