Gitlab扩展
Gitlab扩展即对官方的Gitlab源代码进行二次开发,在原有Gitlab的基础上定制属于自己的项目与代码管理的工具。Gitlab是开源项目,其源代码在官网上可以查阅,我们一般使用的是免费的Gitlab社区版,即Gitlab-CE。下面将从开发,打包,部署三个部分谈谈从源代码到部署成自己的应用是一个怎么样的流程,整个环境的搭建需要注意些什么。
开发
一般来说只要把Gitlab-CE的代码仓库clone到本地,就可以在上面修改代码了。这个是Gitlab-CE的地址:https://gitlab.com/gitlab-org/gitlab-ce/ 。但是,只有源代码是不能够直接在本地上跑起来的,整个开发环境还需要安装很多依赖,以及配置数据库。Gitlab为了方便开发者,提供了一个Gitlab开发工具Gitlab-Development-Kit,其地址是:https://gitlab.com/gitlab-org/gitlab-development-kit 。Gitlab-Development-Kit可以帮助开发者很方便地在本地搭建起开发环境,并且把Gitlab跑起来。它本身就有很详细的文档教你怎么使用,下面我就简单概括一下怎么利用Gitlab-Development-Kit搭建开发环境。
系统需求
理论上Gitlab-Development-Kit网站上列出的系统按照它的步骤都可以成功安装。但我试过在Centos 7下安装,官网上的例子只提供Centos 6.5,关于postgresql的一些下载地址都是有误的,需要自己修改一点目录,而且下下来的postgresql的库不全,导致后面安装Gitlab-Development-Kit时候有种种错误。再者它的依赖安装步骤除了列出的一些指令以外,还需要自己再装一些其他的依赖,感觉不够细致,很可能会产生环境错误。
相对而言,它对Ubuntu的支持就比较好了,首先安装指令简单,而且不需要额外操作。其他系统我没有试过。后面的步骤都是在Ubuntu 16.04上做的,我也推荐使用Ubuntu作为开发环境。
安装前的准备
就是跟着这篇guideline做:https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/prepare.md 。下面是我的步骤整理,对照着官网的看。
利用RVM安装Ruby
Gitlab的源代码是用Ruby on Rails写的,因此先要安装Ruby以及RubyGem。
|
|
上面这些就可以把Ruby版本管理工具RVM安装好了。
安装Ruby(Gitlab-Development-Kit要求2.3.1或更高版本):
|
|
使用Ruby:
|
|
验证是否安装成功:
|
|
安装Bundler
gem是Ruby的包管理工具,Rails框架就是一个gem包,Bundler是用于自动安装Rails项目所需要的gem包的一个工具,其本身也是一个gem包。
|
|
Ubuntu系统上的依赖安装
按照官网的指令一步步做就行,可能会在这一步有点问题:npm install phantomjs-prebuilt@2.1.12 -g ,提示你找不到npm指令。这时候只要手动安装npm就行:sudo apt-get install npm 。应该都没什么太大问题,这些步骤主要为了安装Gitlab项目用到的一些非gem依赖,大多是gem包要用到的系统软件依赖。
正式安装Gitlab-Development-Kit
跟着这篇文档做就行:https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/set-up-gdk.md 。需要注意是建议不要直接把官网的Gitlab-CE工程clone下来,而是先把源代码fork一份到自己的账户里,再把自己的这个项目clone下来。我觉得Gitlab-Development-Kit这个项目主要是帮助你管理Rails应用和数据库配置的,预先把Gitlab要用到的数据库配置好,并且把Gitlab项目依赖的一些其他Git项目clone下来,例如:Gitlab-Shell和Gitlab-workhorse。
安装成功后运行gdk run就可以把Gitlab启起来了,用本机浏览器可以访问localhost:3000。
源代码的update与push
我们在进行开发时候需要经常进行update与push。update是指从Gitlab-CE官网获取官方的更新,gdk update指令可以帮助我们从官方仓库里拉取更新,并运行数据库的迁移进行数据库修改。但这种方式是强制进行Fast-forward形式的merge,如果我们本地仓库做出了自己的修改,那么就会有冲突,gdk update会失败。这时候我们需要切换到gitlab-development-kit目录下的gitlab目录,手动运行git pull命令,然后自己解决了冲突以后再进行git pull。之后再切换到gitlab-development-kit目录,运行gdk update指令。
如果官方进行了数据库方面的更新,那么你在运行gdk update时候必须保证数据库已经运行起来,否则仍会失败。我们在运行gdk run之后数据库是启动起来的,如果某些数据库改动要求我们把gitlab下线操作的话(关于下线参照:https://docs.gitlab.com/ce/development/what_requires_downtime.html ),我们可以先把gitlab应用停止,然后单独运行gdk run db。
我们修改了源代码,就要把它push到远端仓库,方面后面的打包使用。直接切换到gitlab目录运行git push origin master就好。
打包
由于需要打出rpm包,打包环境选择Centos 7,要打deb包的话则要在Ubuntu下打包。
Gitlab官方是用omnibus-gitlab这个工程进行打包的,我们自己打包也得用这个工具,下面是Gitlab官方给开发者提供的自己打包的指导:https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/build/README.md 。下面是我的步骤整理。
打包环境配置
运行以下shell脚本:
|
|
官网说先要安装fakeroot这个库并且运行起来再运行上面的脚本,但我操作时候仍然在某步操作时候会报没有权限的错误,因此建议直接以root账户运行上面脚本。强烈建议翻墙运行脚本,因为某些依赖会下得特别慢,包括下面的打包过程,也应该翻墙了进行。
开始打包
按照官网的指示到运行bin/omnibus build gitlab这一步应该都没有问题。在运行这一步之前,我们先要修改clone下来的omnibus-gitlab下的.custom_sources.yml文件。仿照官网给出的模板:
|
|
其他都不需要改动,只需要把第一项gitlab-rails的地址改成我们自己fork下来的仓库地址就行,omnibus-gitlab在打包时候会自动从上面地址上拉取仓库。
还有一个很坑的问题,我在运行bin/omnibus build gitlab的时候有一个readline的库的下载地址貌似是无效的,一直下不下来,导致打包无法进行。我觉得这有可能是一个bug,我在omnibus-gitlab官网上提了一个issue,以后有可能官方会改掉。如果没有改,那么就自己修改本地omnibus-gitlab仓库config/software/readline.rb文件,把 “https://ftp.gnu.org/gnu/readline/“ 改成 “ftp://ftp.cwru.edu/pub/bash” 。
之后就可以运行bin/omnibus build gitlab了,应该就没有问题,可以成功打包了。
部署
部署环境是Centos 7。部署环境与打包环境必须分开,因为都会改动/opt/gitlab这个文件夹,会相互影响。
第一次安装Gitlab
如果部署机器以前没有装过Gitlab,那么非常方便,直接安装即可:rpm -i gitlab-ce.xx.rpm。其中xx是要安装的rpm包的版本号。安装成功运行sudo gitlab-ctl reconfigure即可。这时候Gitlab已经成功部署了。更多对Gitlab的配置,例如域名或者防火墙的设置,请参照Gitlab官网。
在已有Gitlab上update
这个才是我们一般的使用场景。运行rpm -Uvh gitlab-ce.xx.rpm。如果提示之前已经安装过或者有files confilct错误,那么运行rpm -Uvh –force gitlab-ce.xx.rpm,会强制安装rpm包。update不需要担心数据库会丢失。
有时候你如果修改了源代码的assets文件夹,修改了一些css或者js文件,或者添加了某些打包了assets的gem包,update以后有可能会不生效。这时候只需要把/opt/gitlab/embedded/service/gitlab-rails/public/assets文件夹删除,再重新运行rpm -Uvh –force gitlab-ce.xx.rpm命令,便会正常更新assets文件夹。
update命令成功后,我们便可以在部署的Gitlab上看到相应的更新了。