关于GitLab

GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。安装方法是参考GitLab在GitHub上的Wiki页面。

2022年2月消息，极狐（GitLab）正式宣布推出极狐GitLab SaaS （JihuLab.com），为中国用户提供从源代码托管到开发运维的全栈式一体化DevOps SaaS平台与企业级专家咨询服务。

GitLab除作为代码仓库外，还可以集成CI/CD工作流程，天然的DevOps体系似的项目开发在持续集成和持续交付方面可以完全摆脱其他工具。

搭建GitLab本地服务

GitLab官方版有很多种，其中主流的就是国际版和国产的极狐GitLab，国产版本的极狐免费版限制较多，所以更推荐直接使用官方版的GitLab。

本文以容器化部署为核心，着重介绍Docker搭建GitLab的详细步骤，国产版本的本地搭建暂时没有遇到比较棘手的问题，但作者搭建官方版的Docker镜像时发现可能会在搭建过程中遭遇仓库无法正常使用的情况。

1.搭建准备

搭建本地GitLab前首先要确保电脑或服务器主机上已经安装docker工具，并启动docker服务。除docker工具外，还需要安装docker compose管理工具，更加方便的管理镜像和容器。

2.docker-compose.yml编写

在开发工具或文件系统中准备gitlab管理目录，如图所示。

在gitlab目录中创建docker-compose.yml文件，代码如下（先使用官方的配置）：

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab.example.com'
    container_name: 'gitlab'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224 
    ports:
      - '8888:80'
      - '2224:22'
    volumes:
      #映射配置目录
      - './config:/etc/gitlab'
      #映射日志目录
      - './logs:/var/log/gitlab'
      #映射数据目录
      - './data:/var/opt/gitlab'
    shm_size: '256m'

配置后在gitlab中创建data、config、logs三个目录如图所示。

4. 下载镜像启动容器

由于docker compose可以自动寻找镜像安装并启动容器，所以下一步可以直接通过命令行处理，使用命令行工具打开gitlab目录并输入运行容器的指令：

docker compose up -d

执行后控制台会输出如下内容(下载镜像部分已省略)：

zhangyunpeng@zhangyunpengdeMacBook-Pro gitlab % docker compose up -d
[+] Running 1/1
 ⠿ Container gitlab  Started         

启动后可以通过docker指令查看容器运行状态

docker ps #docker查看容器运行数据

docker compose ps #docker compose查看容器运行数据

5.启动的注意事项

gitlab体系庞大，所以启动时间较长并大量占用内存，所以执行启动命令后若访问http://localhost:8888可能优先出现无法访问界面。

在程序内存占用超过1G时可能会提示502错误，如图所示。

启动的过程中，三个映射文件夹内部会陆续出现相应的配置文件和日志，如图所示。

要等待内存占用超过2G左右时才可以正常访问首页，内存占用数据可以使用图形化的docker工具查看，如图所示。

注意：这里的yml文件夹路径中不可以包含中文，否则会导致项目无法成功启动

首页的效果图为

6.默认账号密码

gitlab的默认账号为：root。默认密码保存在config目录中的initial_root_password文件中，如下：

# WARNING: This value is valid only in the following conditions
#          1. If provided manually (either via `GITLAB_ROOT_PASSWORD` environment variable or via `gitlab_rails['initial_root_password']` setting in `gitlab.rb`, it was provided before database was seeded for the first time (usually, the first reconfigure run).
#          2. Password hasn't been changed manually, either via UI or via command line.
#
#          If the password shown here doesn't work, you must reset the admin password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.

Password: JwZiv7gqL9zhtKXyw37jxwO0EHjb8JWII240Of1YrN0=

# NOTE: This file will be automatically deleted in the first reconfigure run after 24 hours.

该密码只能在24小时内有效，使用后请重新修改密码。登录后会在首页发现存在默认仓库，如图第二个仓库，按照官方标配默认启动无问题。

一旦打开或创建新仓库时会出现500异常如图所示。

7.解决异常问题

作者遇到该问题后，查阅了gitlab的运行日志发现如下错误信息：

{"level":"info","msg":"finding gitaly","pid":305,"pid_file":"/var/opt/gitlab/gitaly/gitaly.pid","time":"2022-06-01T07:05:09.852Z","wrapper":305}
{"level":"info","msg":"spawning a process","pid":305,"time":"2022-06-01T07:05:09.855Z","wrapper":305}
{"gitaly":311,"level":"info","msg":"monitoring gitaly","pid":305,"time":"2022-06-01T07:05:09.856Z","wrapper":305}
time="2022-06-01T07:05:10Z" level=info msg="Starting GitalyversionGitaly, version 14.6.1"
time="2022-06-01T07:05:10Z" level=warning msg="git path not configured. Using default path resolution" resolvedPath=/opt/gitlab/embedded/bin/git
time="2022-06-01T07:05:10Z" level=fatal msg="load config: config_path \"/var/opt/gitlab/gitaly/config.toml\": invalid config: internal_socket_dir: try create socket: socket could not be created in /var/opt/gitlab/gitaly/internal_sockets: listen unix /var/opt/gitlab/gitaly/internal_sockets/test-9f073a3e.sock: bind: invalid argument"
{"gitaly":311,"level":"warning","msg":"forwarding signal","pid":305,"signal":17,"time":"2022-06-01T07:05:10.178Z","wrapper":305}
{"error":"os: process already finished","gitaly":311,"level":"error","msg":"can't forward the signal","pid":305,"signal":17,"time":"2022-06-01T07:05:10.178Z","wrapper":305}
{"gitaly":311,"level":"error","msg":"wrapper for gitaly shutting down","pid":305,"time":"2022-06-01T07:05:10.868Z","wrapper":305}

该异常信息代表gitaly服务下由于一些原因找不到/var/opt/gitlab/gitaly/gitaly.pid文件，可以通过

docker exec -it ...

进入镜像内部查看，不过由于/var/opt文件夹已经被映射到外部，所以可以直接在data文件夹中刚找到gitaly文件夹会发现下面的确不存在该pid文件，如图所示。

这就是官方gitlab镜像可能会出现的问题，目前作者使用的是MacOS系统下的docker镜像，并没有去其他平台测试，所以不能保证该问题是普遍问题。

查看gitlab管理界面也可以从http://localhost:8888/admin/gitaly_servers路径下发现gitaly服务确实宕机了，如图所示。

根据该错误信息，作者安装了极狐gitlab最新个人版本地镜像，发现该镜像进入代码仓库完全没有问题，于是作者对比了gitaly文件夹发现，目录下存在pid文件并且生成的文件夹名称叫做run，如图所示。

根据该文件作者对比了两个镜像gitaly文件夹下的配置文件发现不同之处，如下：

# Gitaly configuration file
# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run:
# sudo gitlab-ctl reconfigure

socket_path = '/var/opt/gitlab/gitaly/gitaly.socket'
#极狐镜像下的配置文件是runtime_dir属性
runtime_dir = '/var/opt/gitlab/gitaly/run'
#官方镜像下的配置文件是internal_socket_dir属性
internal_socket_dir = '/var/opt/gitlab/gitaly/internal_sockets'

bin_dir = '/opt/gitlab/embedded/bin'

# Optional: export metrics via Prometheus
prometheus_listen_addr = 'localhost:9236'


[[storage]]
name = 'default'
path = '/var/opt/gitlab/git-data/repositories'

[logging]
format = 'json'
dir = '/var/log/gitlab/gitaly'


[auth]

[git]
bin_path = '/opt/gitlab/embedded/bin/git'
use_bundled_binaries = true

[gitaly-ruby]
dir = "/opt/gitlab/embedded/service/gitaly-ruby"
rugged_git_config_search_path = "/opt/gitlab/embedded/etc"

[gitlab-shell]
dir = "/opt/gitlab/embedded/service/gitlab-shell"

[gitlab]
url = 'http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsockets%2Fsocket'
relative_url_root = ''

[hooks]
[daily_maintenance]

对比两个文件后发现存在属性差异，顺着该配置文件的指引，找到/confit/gitlab.rb文件，并找到gitaly部分的配置信息发现确实不同，如下

#官方下的配置
# gitaly['internal_socket_dir'] = "/var/opt/gitlab/gitaly"
#极狐下的配置
# gitaly['runtime_dir'] = "/var/opt/gitlab/gitaly/run"

由此作者便产生了灵感，可以在docker-compose.yml文件夹下提前对官方镜像注入极狐的配置信息，不过这里值得注意的是官方版配置必须使用internal_socket_dir属性，而不是runtime_dir属性，最终实验结果是在官方的配置文件下加入如下信息。

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab.example.com'
    container_name: 'gitlab'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
        //若存在runtime_dir则使用它的配置
        gitaly['runtime_dir'] = "/var/opt/gitlab/gitaly/run"
        //若需要使用internal_socket_dir属性则使用下列配置
        gitaly['internal_socket_dir'] = "/var/opt/gitlab/gitaly/run"
    ports:
      - '8888:80'
      - '2224:22'
    volumes:
      - './config:/etc/gitlab'
      - './logs:/var/log/gitlab'
      - './data:/var/opt/gitlab'
    shm_size: '256m'

只需要在容器启动时将官方的internal_socket_dir属性路径指向run文件夹即可解决该问题。

接下来的操作便是删除停止并删除原容器：

docker stop gitlab
docker rm gitlab

最后重新加载docker-compose.yml启动容器

docker compose up -d

启动过程中可以观察gitaly文件夹，会发现run文件夹和pid文件出现了，如图所示。

接下来通过root账号登录后，会发现可以进入代码仓库并自己创建代码仓库，进入后的效果如图所示。

总结

到此为止，本地gitlab搭建部分已经完毕，作者还没有测试其他方面有没有问题，后续会抽时间上线基于GitLab的CI/CD处理教程，本次文章为记录一次百度搜索不到的bug和解决方案，若有读者遇到同样的问题可以按照文章的步骤解决，感谢观看，喜欢作者文章的同学可以点赞关注。