树莓派上搭建GitLab教程

前言：

关键字：Raspberry Pi、GitLab、Git；

利用树莓派搭建GitLab私有代码仓库，可以说是一件非常简单的事，按照官方的安装教程操作，即可轻松搭建起GitLab服务。GitLab是在我见过的所有开源项目中，对树莓派支持最友好的一个项目了，其官方网站就提供了基于“ARM”架构设备的“DEB”安装包。

当然，GitLab在树莓派上运行，还是存在缺点的，就是GitLab的资源占用将会比较高；从GitLab的ARM包的资源库的命名方式来推断，GitLab应该是在树莓派2代开始提供对应的安装包服务的，也就是说，理论上来说，在低版本的树莓派上运行GitLab服务应该是不存在问题的，但事实是，当前的GitLab的ARM版本已经不能够在低版本的树莓派上正常运行了。博主首次安装测试是在“Raspberry Pi 3B”上操作的，但结果是以失败告终；后来博主在“Raspberry Pi 4B -- 4GB版”安装成功，分析此前失败的原因，原因大概能推断为系统资源的不足，GitLab正常无负载运行时，整个操作系统的RAM占用为1.6GB以上[含操作系统本身其它服务对内存的占用]，而“Raspberry Pi 3B”本身只具备1GB的RAM，连GitLab运行的基本要求也达不到；当然，以上说法并不严谨，因为还在存在“SWAP”虚拟内存这个东西，但树莓派的操作系统默认“SWAP”虚拟内存的大小为100MB，所以以上说法现实中基本是对的。

当然，也并不是说完全在低版本的树莓派上不能安装GitLab，但显然这样做要麻烦很多，比如说扩大“SWAP”虚拟内存的大小为“2GB-4GB”以满足GitLab对内存上的要求，但显然，博主严重不建议这么做~

另注：下文图片仅参考~

一、硬件与软件环境

本教程在以下环境下搭建测试通过！注：本处博主使用了一个较旧的安装包，主要是因为博主很早之前就下过GitLab基于ARM架构的安装包了，并且不想再去重新下载了，对于读者而言，博主认为，既然都是要下载GitLab的安装包，那就下载最新的，并不需要一定对应博主所使用的版本！之所以博主一反常态，建议读者使用与本示例不同的安装包，主要原因是GitLab项目在开源上实在是做得比较全面[个人感觉]，博主比较放心~[附：官方ARM架构安装包下载地址]；

• 硬       件 ：Raspberry Pi 4B -- 4GB版 

• 操作系统 ：Raspbian Buster Lite

• GitLab安装包 ：gitlab-ce_12.8.1-ce.0_armhf.deb

• 测试日期：2020年06月19日

二、配置及安装

假设以下为一个全新配置的树莓派操作系统，系统版本为“Raspbian Buster Lite”，首先，我们使用以下命令安装相关的依赖与必要软件；

在成功安装后将出现以下提示，如下图：

之后，我们按照相关提示进行最基本的配置操作[见上图提示框]，执行以下命令对“/etc/gitlab/gitlab.rb”文件进行配置；另注：此步建议加入“四、资源优化”中的配置，同时操作，如此操作能样整个服务搭建起来更加简单；

注：此处修改为定义GitLab的访问地址[域名或IP]，将以下原文内容：

修改为[请依据自身设备上的IP地址进行修改]；特别提示：关于“external_url”的修改，本处修改一定不要带上自定义的端口号，对GitLab服务的端口号修改，不应该在此配置项上定义；虽然说在本处带上自定义端口号也能使用服务生效，但日后若想再对本配置进行修改，则很有可能引起一些不可预期的错误；关于服务端口的配置，见“五、服务端口”；

在对配置文件进行修改后，执行以下命令使配置生效；

在整个“sudo gitlab-ctl reconfigure”命令执行完成后，你将极可能遇到“service[grafana]”的错误[见下图]；不需要管这一个错误，产生这一个错误的原因是因为，该部分操作命令均需要“grafana”组件在运行状态下才能执行成功，而GitLat首次部署时，“grafana”组件是不可能在运行状态下的。当然，出现警告信息，极具怀疑精神的博主有理由相信整个GitLab服务并没有完全正确配置，要解决这一个问题，我们只需要在GitLab服务能正常使用后，再一次执行“sudo gitlab-ctl reconfigure”命令即可，此处只是对该错误作说明，并没有执行任何操作；

至此，整个安装已经正式完成了，但要正常使用GitLab服务我们还需要等待一点时间……如果此时你急于启用服务并使用浏览器连接至GitLab，你极可能得到一个“502”的错误提示页面[见下图]；实际上，GitLab服务的启动较慢[包括任何有关的启动操作]，具体可以在服务刚启动时使用“top”命令查看系统的资源使用的情况，刚启用服务时，你将看到一个或若干个GitLab服务的进程占用了大量的CPU资源[几乎100%][多为“bundle”进程]，其正在部署一些不为博主所了解的操作，我们需要等待这个CPU资源的占用正常降下来后[CPU占用1%-20%]，GitLab服务才能正式进入可使用状态[见下图][注：此等待过程五分钟内]；

当GitLab服务的组件对CPU资源的占用正常后，GitLab服务才算是可以正常使用了；但还记得之前安装时遇到的“grafana”组的错误吗？此时，我们再执行一次“sudo gitlab-ctl reconfigure”命令，此时再执行本命令将不会收获到警告信息了[GitLab服务运行状态下]，并且配置的过程非常快[1分钟内]；当然，本处操作后，还需要使用“top”命令查看“bundle”命令进程CPU资源占用恢复至正常状态后，才能正常连接GitLab服务；

终于，整个GitLab服务可以正常使用了，并且不存在警告信息了；GitLab服务的WEB服务运行在默认“80”端口，只需在浏览器上输入对应的IP地址即可访问GitLab服务。在本示例中，对应的IP地址为“192.168.100.252”。在浏览器首次访问GitLab页面时，GitLab将要求设定管理员“root”的密码[见下图]，此时请自定义自己需要使用的密码，本示例使用密码为“12345678”。在密码设定完成后，在本示例下，即可通过用户名“root”及密码“12345678”，以管理员身份登录GitLab[见下图]；

至此，整个GitLab服务已经搭建完成了，剩下的就使用Git连接至GitLab了；关于Git的使用部分，不在本文讨论范围内，也就不作细说了~

三、基本命令

博主之所以说这个是我搭建过最方便的开源项目，在此处，你可以看到原因了，GitLab甚至连开机启动功能也已经为使用者定义好了，使用者甚至不需要关心开机启动的事。并且，其开机启动服务是基于“Systemd”守护进程的，使用者可以非常方便的定义GitLab服务的启用、禁用、重启操作。在树莓派上，其默认的守护进程配置文件为“/usr/lib/systemd/system/gitlab-runsvdir.service”，以下为一些对GitLab服务的基本操作，仅供参考：

四、资源优化

GitLab服务在系统资源的占用上还是比较大的，在作为个人服务器使用或只是几个团员成员之间使用，实际上GitLab并不需要占用如此多的系统资源。下面为参考网上一些其它网页上，对GitLab的资源优化配置。

关于GitLab的配置文件，我们现在应该已经知道了其配置文件为“/etc/gitlab/gitlab.rb”，要想知道当前的GitLab服务应用了那些配置项，可使用以下命令：

现执行以下命令修改“/etc/gitlab/gitlab.rb”文件并进行修改：

然后在文件内加入以下内容；注：因为本示例下“/etc/gitlab/gitlab.rb”只启用了“external_url 'http://192.168.100.252'”这一配置项，所以以下内容可以直接加入至配置文件内，如果你的GitLab服务并不是首次配置，请关于自身已启用的配置项，依据实际情况配置，以避免配置冲突；查询命令见之前述说；另外，若使用复制粘贴的方式复制配置至文件内，请务必手动替换掉配置项中的所有空格！！！在复制粘贴的方式下，配置项中的“空格”编码存在问题！！！！

在修改完成后，执行以下命令使配置生效；

五、服务端口

关于服务端口，我在网上看到太多具有误导性的配置教程，真的就是随便百度一下就有！对于修改服务端口，我们首先需要明白的是，我们是想通过修改服务端口实现一种什么样的效果！文章之前就已经提及，GitLab并不是一个单一的服务，而是一个系统，是由各种服务组合而成的，然后提供类拟GITHUB的服务，所以，实际上一个完整的GitLab服务占用着一系列的端口，这些端口应用于数据库、WEB服务器、代理等等……

对于服务端口的修改，一般有以下两种情况：

情况一：只是想自定义URL上的端口，即以“http://192.168.100.252:8088”此种方式访问GitLab服务；要实现以上效果，实际上非常简单，当然，我们首先要了解整个GitLab服务的基本构成，在整个GitLab服务的构成中，在接受外部访问连接的是NGINX组件，也就是说，实际上，所有的外部访问请求，首先到达的必定是NGINX组件，再由NGINX组件转发请求至真正的“GitLab服务器”[“unicorn”组件]；在这样的情况下，我们想实现URL上端口号的自定义，显然我们唯一需要关心的是NGINX组件的端口定义，而关于其它组件使用什么端口号，这根本不需要关心[还是需要关心的，至少不要与其它组件所占用的端口冲突]，因为，那是NGINX转发规则的事！在了解以上原理后，自定义访问URL上的端口，就非常简单了，操作如下：

修改NGINX组件的配置文件[“/var/opt/gitlab/nginx/conf/gitlab-http.conf”]：

找至以下原文内容

修改为想使用的端口，如“8088”；补充说明，不能使用了“8080”端口，因为“8080”端口已经被“unicorn”组件所占用；

在修改完成后，保存设置，并执行以下命令重新启用NGINX组件；

在重启NGINX组件成功后，你便可以以“http://192.168.100.252:8088”这种URL的方式从外部访问整个GitLab服务了；

情况二：另一种有端口修改需求的情况是，服务器上已启用的端口与GitLab服务默认所需要使用的端口产生冲突；比如说，原服务器上已经有服务在使用“8080”端口了，而GitLab服务的“unicorn”组件默认也是使用“8080”端口，于是，此时在此台服务器上安装GitLab服务，就会产生端口冲突的问题，要保证GitLab服务能正常运行，就必定需要进行端口修改；这种情况的端口修改，显然就复杂多了，因为，这是基于GitLab整个系统的定义；在这种情况下，就需要修改“/etc/gitlab/gitlab.rb”这份文件，然后运行“gitlab-ctl reconfigure”命令应用配置；关于这一情况，本文就说个原理并至此，不再作深入说明了。

六、结

原本博主认为写这篇博文并不会太花时间，原因是首先搭建时实在太顺手了，全程无障碍！！而原本也只是想写个安装的过程，可后来却加入了一些警告的解决与配置经验，结果，这篇博文的写作时间远超预想了……经验嘛，都写在上面了~END~