GitLab
DevOps
DevOps 是 Development 和 Operations 的组合,也就是开发和运维的简写
什么是持续集成(CI-Continuous integration)
持续集成是指多名开发者在开发不同功能代码的过程当中,可以频繁的将代码行合并到一起并切相互不影响工作
什么是持续部署(CD-continuous deployment)
是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品,持续部署在某种程度上代表了一个开发团队的更新迭代速率
什么是持续交付(Continuous Delivery)
持续交付是在持续部署的基础之上,将产品交付到线上环境,因此持续交付是产品价值的一种交付,是产品价值的一种盈利的实现
GitLab
GitLab 和 GitHub 一样属于第三方基于 Git 开发的作品,免费且开源,与 Github 类似,可以注册用户,任意提交你的代码,添加 SSHKey 等等。不同的是,GitLab 是可以部署到自己的服务器上,简单来说可把 GitLab 看作个人版的 GitHub
Git 在每个用户都有一个完整的服务器,然后再有一个中央服务器,用户可以先将代码提交到本地,没有网络也可以先提交到本地,然后在有网络的时候再提交到中央服务器,这样就大大方便了开发者,而相比 CVS 和 SVN 都是集中式的版本控制系统,工作的时候需要先从中央服务器获 取最新的代码,改完之后需要提交,如果是一个比较大的文件则需要足够快的网络才能快速提交完成,而使用分布式的版本控制系统,每个用户都是一个完整的版本库,即使没有中央服务器也可以提交代码或者回滚,最终再把改好的代码提交至中央服务器进行合并即可
SVN
每次提交的文件都单独保存, 即按照文件的提交时间区分不同的版本, 保存至不同的逻辑存储区域,后期恢复时候直接基于之前版本恢复。
Git
Gitlab 与 SVN 的数据保存方式不一样,gitlab 虽然 也会在内部 对数据进行逻辑划分保存,但是当后期提交的数据如和之前交的数据没有变化,其就直接 快照之前的文件 ,而不是再将文件重新上传一份再保存一遍,这样既节省 了空间又加快了代码提交速度 。
git 缓存区与工作区等概念
- 工作区 :clone 的代码或者开发自己编写代码文件所在 的目录 ,通常是代码所在的一 个服务的目录名称
- 暂存区 :用于存储在工作区中对代码进行修改后的文件所保存的地方,使用
git add
添加 - 本地仓库: 用于提交存储在工作区和暂存区中改过的文件地方,使
git commit
提交 - 远程仓库 :多个开发人员共同协作提交代码的仓库,即 gitlab 服务器
Gitlab 部署与使用
测试环境:内存 4G 以上
生产环境:建议 CPU2C,内存 8G,磁盘 10G 以上配置,和用户数有关
清华源 centos7:https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
清华源 ubuntu18.04:https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu/pool/bionic/main/g/gitlab-ce/
安装
1 | [root@gitlab src]$dpkg -i gitlab-ce_13.8.4-ce.0_amd64.deb # 得等一会 |
配置
1 | # 需要配置gitlab服务器地址和邮件地址 |
gitlab 相关目录:
1 | /etc/gitlab #配置文件目录 |
初始化服务
修改完配置文件要执行此操作
1 | [root@gitlab src]$gitlab-ctl reconfigure |
常用命令:
1 | gitlab-rails #用于启动控制台进行特殊操作,如修改管理员密码、打开数据库控制台( gitlab-rails dbconsole)等 |
gitlab web 界面
username:root
注意,使用域名访问需要做 hosts
关闭账号注册
默认情况下可以直接注册账号,一般都关闭此功能,由管理员统一注册用户
修改邮箱地址
新添加的邮箱不是默认的通知邮箱,下面是设置新邮箱为默认邮箱
设置完后,需要重新登录才能生效,然后可以把之前的默认邮箱删除
创建 gitlab 账户
创建成功后,需要查看邮件,在邮件链接中重置密码
创建组
使用管理员 root 创建组,一个组里面可以有多个项目分支,可以将开发添加到组里,再进行设置权限,不同的组对应公司不同的开发项目或者服务模块,不同的组中添加不同的开发人员帐号,即可实现对开发设置权限的管理
管理员创建项目
有三种方式:创建空项目、使用模板、导入项目
将用户添加到组
更多权限:https://docs.gitlab.com/ee/user/permissions.html
gitlab 仓库 developer 权限无法 push
默认 develop 权限无法 merge 和 push 到 master 分支的,可以修改:
在这里,也可以设置也可以保护其他分支
在项目中新建测试页面
使用 陆东生 用户登录,新建分支,继承自 master:
git 客户端测试 clone 项目
ssh 认证
1
2ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub # 将公钥复制到给gitlabclone
1
git clone git@gitlab.ljk.local:testgroup/testproject.git
git 常用命令
运维常用:git pull
、git clone
、git reset
.gitignore
有些文件不需要上传,在 .gitignore 文件中设置忽略规则,示例:
1 | # 项目根目录下创建.gitignore,规则如下:忽略.vscode目录和.gitignore文件 |
修改完 .gitignore 文件后,更新缓存:
1 | git rm -r --cached . |
gitlab 数据备份恢复
备份前必须先停止 gitlab 两个服务
1
2[root@gitlab ~]$gitlab-ctl stop unicorn
[root@gitlab ~]$gitlab-ctl stop sidekiq备份数据
1
2
3
4
5
6
7
8
9[root@gitlab ~]$gitlab-rake gitlab:backup:create
...
Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.
# 以上warning表示gitlab.rb和gitlab-secrets.json两个文件包含敏感信息。未被备份到备份文件中。需要手动备份,这两个文件位于 /etc/gitlab
[root@gitlab ~]$gitlab-ctl start # 备份完成后启动gitlab备份数据位于
/var/opt/gitlab/backups/
1
2[root@gitlab ~]$ls /var/opt/gitlab/backups/
1614392268_2021_02_27_13.8.4_gitlab_backup.tar查看要恢复的文件
1
2
3/var/opt/gitlab/backups/ # Gitlab数据备份目录,需要使用命令备份的
/var/opt/gitlab/nginx/conf # nginx配置文件
/etc/gitlab/gitlab.rb # gitlab配置文件删除项目和用户信息
执行恢复
1
2
3
4
5# 恢复前先停止两个服务
[root@gitlab ~]$gitlab-ctl stop unicorn
[root@gitlab ~]$gitlab-ctl stop sidekiq
# 恢复时指定备份文件的时间部分,不需要指定文件的全名
[root@gitlab ~]$gitlab-rake gitlab:backup:restore BACKUP=备份文件名恢复后再将之前停止的两个服务启动
1
gitlab-ctl start
gitlab 汉化
虽然不推荐,但是有需求,基于第三方开发爱好者实现
汉化包地址: https://gitlab.com/xhang/gitlab
1 | git clone https://gitlab.com/xhang/gitlab.git |
常见的代码部署方式
蓝绿部署
不停老版本代码(不影响上一个版本访问),而是在另外一套环境部署新版本然后进行测试,测试通过后将用户流量切到新版本,其特点为业务无中断,升级风险相对较小
具体过程:
- 当前版本业务正常访问(V1)
- 在另外一套环境部署新代码(V2),代码可能是增加了功能或者是修复了某些 bug
- 测试通过之后将用户请求流量切到新版本环境
- 观察一段时间,如有异常直接切换旧版本,没有异常就删除老版本
- 下次升级,将旧版本升级到新版本(V3)
金丝雀发布
金丝雀发布也叫灰度发布,是指在黑与白之间,能够平滑过渡的一种发布方式,灰度发布是增量发布的一种类型,灰度发布是在原有版本可用的情况下,同时部署一个新版本应用作为“金丝雀”(小白鼠),测试新版本的性能和表现,以保障整体系统稳定的情况下,尽早发现、调整问题。因此,灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度
具体过程:
- 准备好部署各个阶段的工件,包括:构建组件,测试脚本,配置文件和部署清单文件。
- 从负载均衡列表中移除掉“金丝雀”服务器。
- 升级“金丝雀”应用(排掉原有流量并进行部署)。
- 对应用进行自动化测试。
- 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
- 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)
滚动发布
滚动发布,一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有的实例都更新成新版本,此方式可以防止同时升级,造成服务停止
A/B 测试
A/B 测试也是同时运行两个 APP 环境,但是和蓝绿部署完全是两码事,A/B 测试是用来测试应用功能表现的方法,例如可用性、受欢迎程度、可见性等等,蓝绿部署的目的是安全稳定地发布新版本应用,并在必要时回滚,即蓝绿部署是同一时间只有一套正式环境环境在线,而 A/B 测试是两套正式环境同时在线,一般用于多个产品竟争时使用