1. Gitlab概述
1.1 GitLab介绍
GitLab是利用Ruby on Rails一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。
GitLab能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。
它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找
1.2 Gitlab服务构成
Nginx:静态web服务器。
gitlab-shell:用于处理Git命令和修改authorized keys列表。
gitlab-workhorse: 轻量级的反向代理服务器。
logrotate:日志文件管理工具。
postgresql:数据库。
redis:缓存数据库。
sidekiq:用于在后台执行队列任务(异步执行)。
unicorn:An HTTP server for Rack applications,GitLab Rails应用是托管在这个服务器上面的。
1.3 Gitlab工作流程
1.4 GitLab Shell
GitLab Shell有两个作用:为GitLab处理Git命令、修改authorized keys列表
当通过SSH访问GitLab Server时,GitLab Shell会:
- 限制执行预定义好的Git命令(git push,git pull,git annex)
- 调用GitLab Rails API检查权限
- 执行pre-receive钩子(在企业版中叫做Git钩子)
- 执行用户请求的动作,处理GitLab的post-receive动作
- 处理自定义的post-receive动作
当通过http(s)访问GitLab Server时,工作流程取决于你是从Git仓库拉取(pull)代码还是向git仓库推送(push)代码:
如果是从Git仓库拉取(pull)代码,GitLab Rails应用会全权负责处理用户鉴权和执行Git命令的工作
如果是向Git仓库推送(push)代码,GitLab Rails应用既不会进行用户鉴权也不会执行Git命令,它会把以下工作交由GitLab Shell进行处理:
- 调用GitLab Rails API 检查权限
- 执行pre-receive钩子(在GitLab企业版中叫做Git钩子)
- 执行你请求的动作
- 处理GitLab的post-receive动作
- 处理自定义的post-receive动作
1.5 GitLab Workhorse
GitLab Workhorse是一个敏捷的反向代理。它会处理一些大的HTTP请求,比如文件上传、文件下载、Git push/pull和Git包下载。其它请求会反向代理到GitLab Rails应用,即反向代理给后端的unicorn。
2. Gitlab的安装部署
2.1 方式一:下载gitlab-ce的rpm包
将对应版本的gitlab-ce下载到本地后,直接yum安装即可
2.2 方式二:配置yum源
在 /etc/yum.repos.d/ 下新建 gitlab-ce.repo,写入如下内容:
然后创建cache,再直接安装gitlab-ce
2.2.1. 单服务启动模式
2.2.1. Compose服务编排模式(推荐方式)
2.3 gitlab的配置
配置文件位置 /etc/gitlab/gitlab.rb
修改好配置文件后,要使用 gitlab-ctl reconfigure 命令重载一下配置文件,否则不生效。
测试邮件服务器
配置gitlab代理
也可以使用单独模块代理
应用生效 gitlab-ctl reconfigure
2.4 Gitlab常用命令
2.5 gitlab-ctl常用命令介绍
命令 | 说明 |
---|
check-config | 检查在gitlab中是否有任何配置。在指定版本中删除的rb |
deploy-page | 安装部署页面 |
diff-config | 将用户配置与包可用配置进行比较 |
remove-accounts | 删除所有用户和组 |
upgrade | 升级 |
service-list | 查看所有服务 |
once | 如果GitLab服务停止了就启动服务,如果已启动就不做任何操作 |
restart | 重启GitLab服务 |
start | 如果GitLab服务停止了就启动服务,如果已启动就重启服务 |
stop | 停止GitLab服务 |
status | 查看GitLab服务状态 |
reconfigure | 重新配置GitLab并启动 |
3. Gitlab的使用
- Gitlab安装好后,设置密码,管理账户为root
3.1 创建Group
3.2 创建User
- 创建四个User:pm、dev1、dev2、dev3
3.3 添加User到Group中并授权
3.4 创建Project并配置SSH
3.5 在项目中添加成员
3.6 将本地文件推送到Gitlab
4. 制定开发计划
4.1 创建开发计划
4.2 创建里程碑Milestones
- 用pm账号登录gitlab后操作(先要在admin中设置pm账号的密码)
- 要根据开发计划来创建Milestones
4.3 根据开发计划创建issue
- 创建4个issue,分派给dev1和dev2这两个开发人员
**4.4 开发者登录账号查看分派的任务 **
- 然后开发dev1登录gitlab,就能看到任务已经分配过来了
4.5 开发流程
4.6 合并分支
1)开发dev1发送合并分支请求给pm
2)pm收到开发的Merge请求后进行处理
- 使用pm登录,就可以看到pm已经收到了合并请求merge request
3)开发dev1确认任务完成
- 或者点进去后,在侧边栏进行标识Done,然后已经完成的issue,可以将其Close
- 这个时候Milestones的进度已经往前进了一些了:
4.7 开发其他功能
- 然后其他开发者或者自己再次进行开发时,先要把刚刚更新后的内容(master主干)拉回来,然后再进行开发
git checkout master # 切换到master
git pull # 从远端仓库拉取数据
# 然后再进行其他操作
5. Gitlab备份恢复
5.1 备份gitlab
1)修改配置文件
2)设置定时任务
3)备份时间的识别
5.2 恢复gitlab
1)停止停止相关数据连接,数据写入服务
2)进行数据恢复并重启
6. gitlab邮件通知配置
- vim /etc/gitlab/gitlab.rb
启用邮件功能
Gitlab 的 Compose 配置 GITLAB_OMNIBUS_CONFIG
节点下增加如下几行:
7. 使用SourceTree进行项目开发
7.1 项目拉取
- 如果ssh的方式克隆失败,可能是因为SSH Key没找到,可以在这里添加
7.2 创建分支进行功能开发
1)新建立一个叫“pay”的分支
2)进行功能开发
7.3 提交项目
1)开发pay功能完成后进行提交
- 可以看到SourceTree中已经有“未提交的更改”
2)添加“用户信息”
** 3)进行提交**
- 注释也可以写成 close #3 ,作用是提交完成后关闭3号issue
7.4 推送到仓库
- 然后就可以在gitlab上进行发送merge请求了,后面就可以进行其他操作了
7.5 项目上线
1)当所有工作完成之后,就可以进行上线了
2)打标签
** 3)删除无用分支**
- 然后删除已经合并到主干中的不必要的分支,如index、pay等
- 最后一定要注意时间一定要同步,不然会错乱
8. Gitlab调优
gitlab对内存资源的消耗比较厉害
其中尤以 sidekiq队列 及 unicorn服务 两个组件对内存消耗最多
可以再容器启动时对相关参数进行微调:
配置调整后需要重载一下
9. Gitlab 启用 ContainerRegistry
ContainerRegistry
是Gitlab
内置的Docker Registry
集成组件- 集成后每个项目可获得私有的
Docker
镜像存储空间 ContainerRegistry
可以复用 Gitlab
域名 或者 独立域名- 这里配置为复用域名(此时
ContainerRegistry
将复用 Gitlab
的 TLS
证书)
docker-compose.yaml
中Gitlab服务的 GITLAB_OMNIBUS_CONFIG
节点下增加如下配置:
- 端口开放增加
- 4567:4567
- 服务重启
docker-compose restart Gitlab
ContainerRegistry
集成后可以通过 Gitlab
账户登录: docker login gitlab.example.com:4567
日常维护命令
Import Repository(Repo By Url)
10. GitLab重置用户名密码
打开终端,访问:
输入:
然后退出命令行即可。
11. HTTPS SSL 支持
nginx反向代理方式
- 注意docker 内部没有ca支持, 需要手动添加
域名提供商提供的免费证书
- 这种证书直接用,如果是自签名证书,需要添加自己的ca root证书到服务器
12. Gitlab恢复数据出现must be owner of解决方法
按正常Gitlab备份数据gitlab-rake gitlab:backup:create
解决方法:
**1. 修改postgresql配置 **
找到listen_addresses = ” 改为listen_addresses = ‘*’
修改 /var/opt/gitlab/postgresql/data/pg_hba.conf
在这个文件最后面加入
2. 重启gitlab生效
3. 修改gitlab账号为超级用户
进入postgresql命令行
查看账户权限
执行修改gitlab用户为超级权限
退出
4. 从1462989681编号备份中恢复
这样Gitlab恢复数据就不会再报must be owner of extension plpgsql错误。
4. 重启gitlab
13. Gitlab Pages
官方文档:https://docs.gitlab.com/ee/user/project/pages/ 。
Gitlab Pages 使用 GitLab Pages daemon 服务,它是用 GO 语言实现的简单 HTTP 服务,并且可以监听外部 IP 地址以及为自定义域名和自定义证书提供支持。它通过 SNI 支持动态证书并且默认通过 HTTP2 协议发送页面。最后推荐你去看官方文档 README 以便全面了解它的工作原理。
启用 Pages
打开 gitlab.rb
:
修改 Pages
配置:
让 Gitlab
使用当前配置:
如果没有域名怎么办呢?可以参考 Linux智能DNS服务搭建之Bind服务。
使用 Pages
官方的案例库:https://gitlab.com/pages
用户文档
一般有两种类型的Pages可以创建
在GitLab中,usernames或groupnames是唯一的,我们经常把他们称为namespaces。在一个GitLab实例中只能有一个namespace。
下面是Gitlab Pages类型、Project Name和 website URL对照表:
GitLab Pages前提条件:
简而言之,这是上传web站点到GitLab Pages需要的:
- Gitlab Pages使用的域名(向管理员询问)。
- 创建一个Project。
- 仓库的根目录放一个.gitlab-ci.yml,其中有个叫做pages的job。
- 设置一个GitLab Runner构建web站点。
部署简单的 html 项目
- 我们在自己的
gitlab
上面创建一个测试项目:plain-html
- 把项目拉取到本地:
- 在项目中新建
public
目录,然后添加 index.html
、 style.css
文件:
- 在项目根目录添加
.gitlab-ci.yml
文件:
- 提交代码:
最后我们回到 gitlab 服务,在 plain-html
仓库中的 Settings / pages
页面可以看到已经有对应的服务地址了:
gitlab 服务的域名跟 pages 的不要使用同一个,防止 XSS 攻击。
Container Registry
官方文档:https://docs.gitlab.com/ee/user/packages/container_registry/
本节修改中
开启 Container Registry
修改gitlab配置文件: vim /etc/gitlab/gitlab.rb
这里需要注意的是,registry_external_url是外部访问的url,如docker需要pull和push,都是访问该路径。然后,刷新配置,重启:
访问Docker
默认需要SSL,请使用反向代理
官方文档有说明,如果启用了双重验证(Two-Factor Authentication)则不应该输入密码,而是token:
CI
GitLab Continuous Integration (GitLab CI/CD)
- CI: Continuous Integration:持续集成。
- CD: Coninuous delivery and deployment:持续交付和部署。
Gitlab CI/CD 是以可持续方法论进行软件开发的内建工具(continuous integration service )。
在使用 Gitlab CI 之前,我们需要先了解几个概念:
Stage
阶段:通俗的讲就是步骤(把一件事分解成多个步骤来完成)。 从最上面的图中可以看到在 CI
中可能会有:Build
、Unit Test
、Integration Tests
等多个阶段。
Job
任务:就是我们在每个阶段具体要做的事情,而一个阶段可能会有多个任务。
Pipelines
一条流水线 ( pipeline
)就是 一组 在各个阶段执行的任务。在同一阶段的多个任务是可以并行的(如果 Runner
足够多的话),当全部的任务都执行成功之后流水线将会进入下一个阶段。反之,如果其中有一个任务失败,流水线的下一个阶段将不再执行。
Runners
在 Gitlab CI 中,Runner
负责运行定义在 .gitlab-ci.yml
中的代码。Runner
为三种:Shared Runners
、Group Runners
、Specific Runners
,分别表示全局共用 Runner、组共用 Runner、单个项目指定的 Runner。
.gitlab-ci.yml
Gitlab CI 的配置文件,该文件声明了流水线的结构和顺序,以任务为最小单元。
文件中允许定义的元素:
image
:docker 镜像,当 Gitlab-Runner 的类型为 docker 时,会根据该属性指定的镜像为脚本执行容器。services
: 指定另一个 docker 镜像,主要用于提供服务层的能力,比如 mysql
。before_script
:任务执行前的钩子事件,比如一个 node 项目,我们可以在这里安装依赖。after_script
:任务执行后的钩子事件,当所有的任务都执行完毕之后被调用,不管任务是否执行成功。stages
:定义流水线中的阶段,默认的为 build
、test
、deploy
。如果我们要在任务中指定其他的 stage
,则需要使用该属性先申明。cache
:需要缓存的文件,比如 node 项目可以把 node_modules 缓存起来。提示:可以定义在 .gitlab-ci.yml
顶级表示项目级别的,也可以申明在单个任务中。variables
:变量,同样可以在顶级或者单个任务中申明。pages
:内置的一个任务,用于上传任务执行的结果到 Gitlab Pages。include
:合并其他的 .gitlab-ci.yml
文件配置。- 在单个任务中申明的元素:
script
:需要执行的脚本。stage
:标识该任务所属的阶段。tags
:为任务打上标签,用于选择特定的 Runner
。only
:用于表明何时创建该任务。except
:用于表明何时不创建该任务。when
:用于表明何时运行该任务。allow_failure
:允许失败,该任务失败时不会影响整个流水线的结果。artifacts
:任务执行的结果,比如执行 打包任务
后的产出资源。dependencies
:依赖的其他任务。retry
:当任务失败时最多重试的次数。coverage
:指定如何从任务结果中提取代码覆盖率。parallel
:允许并行的任务实例个数。
请注意版本问题,每个属性对版本的要求并不一致,具体的可以点击属性查看官方文档。
使用 Gitlab CI
使用 Gitlab CI 服务的两种方式: 1. Auto DevOps 2. 手动配置 CI/CD
Auto DevOps 是 Gitlab 11.0 推出的新功能,它提供了预定义的 CI/CD 配置,允许我们自动检测、构建、测试、发布以及监控应用。
暂未使用,待补充。
手动配置 CI/CD
手动配置主要就 2 个步骤,配置 .gitlab-ci.yml
文件,添加 Gitlab Runner 运行该文件。
下面,我们看看如何配置 Gitlab Runner:
Gitlab Runner
Gitlab Runner 是一个开源项目,用来运行 .gitlab-ci.yml
中定义的任务并把结果返给 Gitlab。
安装
官方文档:https://docs.gitlab.com/runner/install/linux-repository.html
首先,添加离线仓库:
然后,安装最新版本:
注册
官方文档:https://docs.gitlab.com/runner/register/index.html
首先,我们进入要配置 Runner 的 Gitlab 仓库,在 Settings -> CI / CD
页面展开 Runners
配置面板可以看到已经分配的 Runner 以及注册 Runner 需要的参数:
然后,我们使用 Gitlab-Runner 命名开始注册:
执行完会该命令,终端会有交互,要求我们输入以下参数:
- gitlab-ci coordinator url :gitlab 服务地址
- gitlab-ci token:上图中的 token
- description:描述信息
- tags:标签,对应
.gitlab-ci.yml
任务中配置的 tags,只有 tags 匹配的任务才会被该 Runner 执行。 - executor:执行器,即任务脚本执行的环境
如果使用 docker 执行,则需要事先安装 Docker 环境。
参数填写完毕之后,一个 Runner 便被注册成功了:
我们回到 gitlab 仓库页面,然后刷新便可以看到 _fzBq4PN
这个 Runner 已经被注册到该项目:
我们可以点击 编辑图标
对该 Runner 进行修改。我比较喜欢把 Run untagged jobs
选项勾上,这样就不用每个任务都添加对应的 tags 了(因为现在涉及到的都是一些简单的流程)。
总结
首先,CI/CD 是一种软件开发流程,Gitlab CI/CD 是 Gitlab 为实现该流程而提供的一个内置工具(服务)。 其次,我们有 Auto DevOps 与 手动配置
两种方式使用,本文讲解的主要是 手动配置
方式。
加速Gitlab Runner
gitlab runner构建镜像每次RUN 安装依赖包,都远程下载?可以缓存加速吗? 可以的!
在将GitLab Runner注册到GitLab page上,让GitLab page可以和你的Runner通信时,有一步是填写使用的executor
如果你选择Docker作为Runner的executor,你还要选择默认的docker image来运行job(当然,你也可以在.gitlab-ci.yml里指明你需要用的image),这句话就跟文章使用gitlab-runner往k8s上发送curl命令实现pod中容器使用的镜像版本更新,地址: 开头讲述的那样,不过.gitlab-ci.yml里指明的image优先级高。
注册完成后你可以在/etc/gitlab-runner里发现 config.toml文件,该文件是Runner的配置文件
接下来就牵涉到一个重要的话题 —— Executor
- Shell Executor
以宿主机作为Runner的所有jobs的执行器。Runner将会从远程仓库pull你的工程,工程的目录为:/builds。如果你使用了cache,那么cache将会存在/cache/。
但是,它需要将构建所需的所有依赖手动安装到安装了Runner的同一台计算机上,比如使用到的git,jdk,maven,docekr等 - Docker Executor
所有jobs的执行环境为指定的docker image所生成的container,每个job都会生成一个container并且在job结束后立即销毁。这个说的就是config.toml文件和.gitlab-ci.yml中指定的image
Docker executor默认将所有的builds存储在/builds/(这里的路径是container里的路径,Runner配置文件config.toml里的build_dir字段可以重新指明build的目录,默认对应于宿主机的目录是在宿主机的docker volume下:/var/lib/docker/volumes//_data/),默认将所有的caches存储在container里的/cache目录(config.toml里的cache_dir字段可以重新指明cache的目录),注意build_dir和cache_dir指向的均是container里的目录,要想将container里的数据持久化,需要用到volumes字段,这个字段的使用和docker volume的使用是类似的,只需在config.toml的[runner.docker]部分添加volumes = [“/cache”, “:rw”]即可实现container里/cache目录数据的永久保存以及将host目录挂载到相应的container目录并具有读写的功能。
比如:
当你使用docker 或 docker+machine executors时,你可以通过设置pull_policy来决定Runner如何pull docker image。pull_policy有三种值:
注意:这一步就是本文开头提到的,使用本地镜像,不用再从dockerhub上拉取了
当你使用docker, docker+machine 或 kubernetes作为executor时,GitLab Runner将会使用特定的container来处理Git、artifacts 和cache 操作。
权限管理
以管理员的身份登入gitlab,点击Settings,然后选择Members,可以通过输入名字选择要分配权限的小组成员,然后分配角色,选择权限有效时间,点击Add to Project就把人员拉近到项目中。
GitLab的角色有以下四种:
- Guest:可以创建issue、发表评论,不能读写版本库
- Reporter:可以克隆代码,不能提交,可以赋予测试、产品经理此权限
- Developer:可以克隆代码、开发、提交、push,可以赋予开发人员此权限
- MainMaster:可以创建项目、添加tag、保护分支、添加项目成员、编辑项目,一般GitLab管理员或者CTO才有此权限
访问权限 - Visibility Level:
这个是在建立项目时就需要选定的,主要用于决定哪些人可以访问此项目,包含3种
- Private - 私有,只有属于该项目成员才有原先查看
- Internal - 内部,用个Gitlab账号的人都可以clone
- Public - 公开,任何人可以clone
本文作者:夜法之书 写作不易,转载请注明来源地址!
参考链接:
- https://www.cnblogs.com/hgzero/p/14088215.html
- http://www.51blogs.net/2017/11/10/1110113243.html
- https://my.oschina.net/u/2400083/blog/808097
系列教程
全部文章RSS订阅
Gitlab 使用系列
Gitlab RSS 分类订阅
Devops系列
Devops 分类 RSS 订阅
项目管理系列介绍锦集
快速全面的介绍现代企业中项目管理相关知识!
如何做一个完整的硬件项目的项目管理之简明教程
以一个硬件项目开发为例,介绍现代公司项目管理的一些基本工具和方法,给行业内外朋友一个初步印象,为广大从业者入门相关管理打下一个初步的,全局的基础!最后给出一个IPD端到端管理项目示例
几种常用管理模型和方法
几种常用管理模型和方法:PDCA, 5W2H, SMART, SWOT, GROW, OKR, WBS 等,职场人员需要了解的知识。
PMBOK指南(第6版)
PMBOK 只是一套悬在空中的方法论,要想具体落地还需要具体的行业知识。两条腿,缺一不可!PMBOK 是基础中的基础知识,了解总是没有坏处的。是常识,不懂就没法做,但要做项目管理,光靠PMBOK远远不够。
如何做好竞品分析
竞品分析可以帮助我们更好地找准自身产品定位,发现自己产品的优劣所在,进而推动产品的优化迭代。
一大堆寓意深刻的管理故事锦集
几十个关于管理,经营的故事。寓教于乐,寓意深刻,在自己遗忘之前,记录保存下来。包括 扁鹊三兄弟,曲突徒薪,猎人与狗等等
人格类型分类总结归纳
本文介绍了什么是人格特质,怎么分类,并介绍了主流分析方法。后面着重介绍了敏感型人格和内向人格的优势,最后介绍了人格缺陷的一些分类和特点。与人打交道,这些了解不可或缺