- 延迟发表
- 本文早先已经创作完成，因若干原因延迟发表，可能已无时效。上方标注者为创作日期，实际发表于 2021 年 04 月 04 日。
近期有多个项目正在进行，涉及到很多份程序代码，大多数由师兄提供。
学习过程中：
- 一方面，需要对代码做不同程度的修改，以完成新的任务；
- 另一方面，也需要在代码中写上注释、创建 README 等，作为研读程序过程中的记录；
- 若能够将程序的改动记录下来，也将会是一件很有帮助的事情；
- 现在有两台工作用的电脑，加上自己的笔记本，总共有三台电脑，需要更方便地在它们之间传递最新版本的代码。
显然，用 Git 结合云托管平台来维护这些代码是一种自然的需求。然而，教研室的这些代码并不适合放在公有云上；考虑到这一方面的问题，以及未来教研室可能的需求，我决定尝试自己搭建一个 GitLab 平台，用来存放这些代码。
现在我手头没有公网 IP 的电脑，用来建个人网站的云服务器的带宽、硬盘也受限。因此，决定先在自己宿舍的旧笔记本上搭一个 GitLab，然后通过 Sakura Frp 内网穿透映射到公网上。
配置情况
旧笔记本（服务器）的配置：
- 型号：ThinkPad E555（20DHA01QCD）;;
- CPU 为 AMD A10-7300；
- 显卡为 AMD Radeon R7；
- 4G（实际为 3.2G）内存；
- 系统为 Cent OS 7.8；
- 近 500G 的机械硬盘；
- 接入宿舍的 50M 宽带。
配置很差，但基本能达到运行 GitLab 服务的要求。
此外，笔记本上已经运行了一个 Seafile 服务，80、443、8080 等端口已经被占用了。
解决方案
个人安装，当然选社区版本（gitlab-ce）。首先，按 GitLab 官方的要求检查依赖项是否安装：
sudo yum install -y curl policycoreutils-python openssh-server postfix
一般来说，Cent OS 上这些服务都是安装了的。
然后，通过 GitLab 的 yum 软件源安装 gitlab-ce；为加快速度，采用清华的镜像，具体配置请直接参考这里。这一过程可能会耗费一点时间。
安装完成之后，立即去改配置，需要调整下面几项。配置文件一般是：
/etc/gitlab/gitlab.rb
配置文件较长，下面仅展示需要修改的内容，你可以在编辑器中查找对应的部分在哪里。
配置 URL 及 SSL 证书
NATFrp 的国内隧道现在不允许做 HTTP 映射，只能用 HTTPS。假设采用的域名为 gitlab.example.com，则需在配置文件的头部中做如下设置：
external_url 'https://gitlab.example.com'
根据默认设置，若在 URL 中采用 HTTPS 协议头，则 GitLab 将自动通过 acme 工具来获取并更新 Let’s Encrypted 的免费 SSL 证书。在大多数场景下，这是最方便的一种策略，但在当前情景（内网穿透）中：
- 经过多次尝试，发现很难通过宿舍网接通 Let’s Encrypted 的验证站点，经常获取不到 IP；
- 即使能够联通，也会因为笔记本处于内网之中而无法完成验证。
因此，只好手动配置证书。首先到配置文件 gitlab.rb 中（路径已述）找以下内容，取消注释，关闭 Let’s Encrypted：
################################################################################
# Let's Encrypt integration
################################################################################
letsencrypt['enable'] = false
...
然后，自己通过 Let’s Encrypted 或其他平台（如 freessl.cn）手动为当前站点生成 SSL 证书。将：
- 获取到的证书文件命名为
<domain>.crt，如gitlab.example.com.crt； - 获取到的私钥文件命名为
<domain>.key，如gitlab.example.com.key； - 将这两个文件拷贝到服务器的
/etc/gitlab/ssl目录下即可。
以上是根据默认配置设置的，在配置文件中的对应内容为：
# nginx['ssl_certificate'] = "/etc/gitlab/ssl/#{node['fqdn']}.crt"
# nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/#{node['fqdn']}.key"
这里的 #{node['fqdn']} 就对应着网站的域名。当然，你可以根据你的需要修改上面的默认配置，然后再按对应的配置来放置文件。
修改冲突端口
在需求中已言及，常用的几个 WEB 端口在安装 GitLab 之前都已经被占用了。新版本（13.x）中 GitLab 的应用服务器（Puma / Unicorn 及 GitLab Workhorse）已经默认采用 Unix Domain Socket 通信（之前通过 TCP 方式通信，占用 8080 端口），这一方面无需再做调整；但 GitLab 内置的 Nginx 仍然会占用 80 端口（无论是否启用 HTTPS）。为此需要解决这一方面的冲突，例如将其改为 81 端口：
nginx['listen_port'] = 81
在之后采用内网穿透时，也就需要将这里的 81 端口映射出去。（完整的端口分配列表可参考：GitLab 默认端口列表。）
内网穿透情景下配置 SSH 通道
在内网穿透的情景下，还有一个问题需要注意：需要采用正确的方式将 GitLab 所用的 SSH 端口映射出来。默认情况下 SSH 会使用 22 端口，但是：
在使用像 Sakura Frp 及花生壳这样的内网穿透服务时，分配的外网端口通常都是随机分配的五位数，不可能是 22 端口。
当然，内网端口仍然可以设置为 22，但这时就需要自己手工修改 GitLab 上生成的 SSH 访问地址了。GitLab 的网页端事实上可以为每个仓库自动生成的 SSH 访问地址附加自定义的端口号，前提是需要修改 Gitlab 所采用的 SSH 通道端口；思索一番便会发现，最简单易行的方法就是：把 SSH 服务对应的内网与外网端口都改为一个 22 以外的统一值（最好以外网端口为准，因为可用的外网端口通常是在限定的范围内随机分配的，并且需要与其他使用同一内网穿透的用户分享，很难调整）。
假设内网穿透服务自动分配（或由你人工选取）的 SSH 通道端口为 23333，首先在 GitLab 的配置文件中修改 GitLab Shell 的 SSH 服务端口号：
gitlab_rails['gitlab_shell_ssh_port'] = 23333
然后，去修改服务器的 OpenSSH 服务配置文件（/etc/ssh/sshd_config），在其中添加 23333 端口为 SSH 服务端口
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# ...
Port 22
Port 23333 # add this
注意到上面的写法中保留了 22 端口，这意味着你仍然可以在内网通过 22 端口（具体来说就是直接 ssh xxx@IP）连接服务器。
Sakura Frp 配置内网穿透通道
这一步，直接按 Sakura Frp 官网上的指南来做即可。不再赘述，只需记得内网穿透设置中的内部端口为 23333 即可。启动为系统服务，保证每次服务器重启后都能正常工作。
启动
完成以上配置之后，需要让 GitLab 重载以上配置，并重新启动（以下命令都需要管理员权限）：
gitlab-ctl reconfigure
gitlab-ctl restart
可能会花费一点时间。由于我的旧笔记本性能较差，在启动大概 3 分钟后才能正常工作；在此之前，网站会显示 502 错误。
试试在外网用你设置的域名（如 gitlab.example.com）访问一下（第一次登录的时候会要求设定 root 账户的密码）：
完成，收工！
补充
若服务器条件尚可，宜用 Docker 安装 GitLab，如此可规避上面曾碰到过的不少问题。不过，对 GitLab 来说，需要认真配置其持久化储存的方式，并做好备份。
写本篇时，尚不知有 Gogs、Gitea 等轻量级的 Git 托管平台；如今若再要配置，宁则此诸小型服务，更方便。