您的位置:主页 > 营销知识 > 建站资讯 > GitLab 搭建以及配置
服务器:阿里云主机
操作系统:Centos7.0 64位
已装软件:Nginx(80端口)、Apache(8080端口)、PHP-FPM(9000端口)
GitLab分为社区版(GitLab Community Edition)和企业版(GitLab Enterprise Edition)。社区版免费,企业版收费,但是功能比社区版多。根据目前的需求,选择安装社区版(GitLab-CE)。
版本号:8.5.4
以前试过源码安装,过程痛苦无比。此次选择官方提供的GitLab-CE Omnibus安装包。GitLab官网上有详细的安装说明,根据自己的操作系统选择相应的版本,按步骤操作即可。
https://about.gitlab.com/downloads
由于国内阿里云主机无法连接国外的GitLab Yum源,所以只能从GitLab中文社区直接下载rpm包进行安装。
curl -LJO https://mirror.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-8.5.4-ce.0.el7.x86_64.rpmrpm -i gitlab-ce-8.5.4-ce.0.el7.x86_64.rpm
GitLab中文社区:http://www.gitlab.cc
GitLab由以下服务构成:
nginx
:静态Web服务器
gitlab-shell
:用于处理Git命令和修改authorized keys列表
gitlab-workhorse
:轻量级的反向代理服务器
logrotate
:日志文件管理工具
postgresql
:数据库
redis
:缓存数据库
sidekiq
:用于在后台执行队列任务(异步执行)
unicorn
:An HTTP server for Rack applications,GitLab Rails应用是托管在这个服务器上面的。
重点讲一下gitlab-shell和gitlab-workhorse。
GitLab Shell有两个作用:为GitLab处理Git命令、修改authorized keys列表。
当通过SSH访问GitLab Server时,GitLab Shell会:
限制执行预定义好的Git命令(git push, git pull, git annex)
调用GitLab Rails API 检查权限
执行pre-receive钩子(在GitLab企业版中叫做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动作
也许你会奇怪在通过http(s)推送(push)代码的情况下,GitLab Rails应用为什么不在GitLab Shell之前进行鉴权。这是因为GitLab Rails应用没有解析git push
命令的逻辑。好的方法是将这些解析代码放在一个地方,这个地方就是GitLab Shell,这样我们就可以在通过SSH进行访问时重用这段代码。实际上,GitLabShell在执行git push
命令时根本不会进行权限检查,它是依赖于pre-receive钩子进行权限检查的。而当你执行git pull
命令时,权限检查是在命令执行之前的。对git pull
命令的权限检查要简单得多,因为你只需要检查一个用户是否可以访问这个仓库就可以了(不需要检查分支权限)。
好吧,GitLab Shell这段话都是翻译官网的。链接在这里
https://gitlab.com/gitlab-org/gitlab-shell/blob/master/README.md
最后一段话有点拗口,我对此还是有一点问题的:既然你把
git push
的逻辑都放在GitLab Shell里面了,为什么不把git pull
的逻辑也都放在里面提供重用呢?
猜想:git pull
这段逻辑无法重用,因为通过http(s)方式访问时,要读取仓库的数据并且把这些数据封装成http包返回给客户端;而通过ssh方式访问时,仓库代码数据是通过ssh数据包返回的。两种访问方式返回数据的封装方式不一样,所以也没有必要提供重用。但是我觉得读取仓库数据这段逻辑应该还是重用了的。
GitLab Workhorse是一个敏捷的反向代理。它会处理一些大的HTTP请求,比如文件上传、文件下载、Git push/pull和Git包下载。其它请求会反向代理到GitLab Rails应用,即反向代理给后端的unicorn。官网对GitLab Workhorse的介绍在这里:https://gitlab.com/gitlab-org/gitlab-workhorse/
要求能通过子域名git.domain.com
访问GitLab站点并且站点内的仓库地址也要用子域名显示。
要求使用腾讯企业邮箱的SMTP服务器发送邮件。
要求使用HTTP请求方式。
要求能使用SSH连接方式。
要求避免与已装软件的端口冲突
要求使用系统已安装的Nginx服务器
修改GitLab配置文件,停用GitLab内置Nginxnginx[domain'enabledomain'] = false
使用系统已经安装的Nginx给gitlab-workhorse作反向代理
因为unicorn的默认端口是8080,与系统已存在的Apache端口冲突,修改Apache端口为8000(也可以修改unicorn的端口)
修改GitLab配置文件中的external_urlexternal_url domain'http://git.domain.comdomain'
修改这个配置会影响GitLab里面显示的仓库链接
修改GitLab邮件服务配置,使用腾讯企业邮箱的SMTP服务器
gitlab_rails[domain'smtp_enabledomain'] = truegitlab_rails[domain'smtp_addressdomain'] = "smtp.exmail.qq.com"gitlab_rails[domain'smtp_portdomain'] = 25gitlab_rails[domain'smtp_user_namedomain'] = "xxx"gitlab_rails[domain'smtp_passworddomain'] = "xxx"gitlab_rails[domain'smtp_domaindomain'] = "smtp.qq.com"gitlab_rails[domain'smtp_authenticationdomain'] = domain'plaindomain'gitlab_rails[domain'smtp_enable_starttls_autodomain'] = true
GitLab-CE 8.0以上的版本已经将GitLab-CI集成进了GitLab里面,并且是默认开启的。所以不需要像以前一样再单独安装GitLab-CI并且为GitLab-CI开启单独的Server。如下图所示:
上海云轩网络版权所有 Copyright©2008-2018 http://www.lvon8.com All Rights Reserved 备案号:沪ICP备14049216号