流漓 · 客

Appearance

Gitlab ​

安装 ​

Linux安装包方式 ​

安装建议:

使用https而不是http：部分内置功能需要https，如：容器镜像服务、KubernetesAgent 使用授信证书而不是自签证书：自签证书会造成部分内置功能以及与第三方工具的集成出现问题；

GitLab下载安装

安装依赖 ​

在 CentOS 7 上，下面的命令会在系统防火墙中打开 HTTP、HTTPS 和 SSH 访问。这是一个可选步骤，如果打算仅从本地网络访问极狐 GitLab，则可以跳过它。

bash
$ yum install -y curl policycoreutils-python openssh-server perl

$ systemctl enable sshd
$ systemctl start sshd
$ firewall-cmd --permanent --add-service=http
$ firewall-cmd --permanent --add-service=https
$ systemctl reload firewalld

（可选）如果要使用 Postfix 来发送电子邮件通知，执行以下安装命令。

bash
$ yum install postfix
$ systemctl enable postfix
$ systemctl start postfix

在安装Postfix的过程中可能会出现一个配置界面，在该界面中选择"Internet Site并按下回车。把"mail name设置为您服务器的外部DNS域名并按下回车。如果还有其它配置界面出现，继续按下回车以接受默认配置

下载安装 ​

Gitlab · Nexus

下载安装包

bash
# 查找合适的版本后
$ wget https://packages.gitlab.cn/repository/el/7/gitlab-jh-17.2.1-jh.0.el7.x86_64.rpm

确保已正确设置您的DNS解析，并修改https://gitlab.example.com为访问极狐Gitlab的实际URL。安装包将自动配置该URL和启动极狐GitLab。 建议将极狐GitLab实例的域名以环境变量的形式注入（将命令中URL替换为要访问极狐GitLab实例的实际URL）

bash
$ EXTERNAL_URL="https://gitlab.example.com:8080"

对于https站点，极狐GitLab将使用Let's Encrypt自动请求SSL证书，这需要有效的主机名和入站HTTP访问，也可以使用自己的证书或仅使用http://(不带s)。

安装

bash
$ rpm -Uvh gitlab-jh-17.2.1-jh.0.el7.x86_64.rpm

登录极狐 GitLab 实例

使用前面的 EXTERNAL_URL 中配置的地址来访问安装成功的极狐 GitLab 实例。用户名默认为 root 。

如果在安装过程中指定了初始密码，则用初始密码登录;

如果未指定密码，则系统会随机生成一个密码并存储在 /etc/gitlab/initial_root_password 文件中， 查看随机密码并使用 root 用户名登录

bash
$ cat /etc/gitlab/initial_root_password

建议登录后马上修改密码，因为默认的初始化密码文件，24h后会被删除，或者第一次 gitlab-ctl reconfigure 自动删除

使用命令重置密码

bash
$ gitlab-rake "gitlab:password:reset[root]"

Helm Chart安装 ​

极狐GitLab Helm chart

Docker安装 ​

Docker Engine ​

bash
$ docker run --detach \
  --hostname gitlab.example.com \
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.example.com'" \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume $(pwd)/config:/etc/gitlab \
  --volume $(pwd)/logs:/var/log/gitlab \
  --volume $(pwd)/data:/var/opt/gitlab \
  --shm-size 256m \
  registry.gitlab.cn/omnibus/gitlab-jh:17.2.1

访问 GitLab URL，并使用以下命令中的用户名和密码登录：root

bash
$ docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password

密码文件将在 24 小时后的第一次容器重启时自动删除

external_url配置的是客户机访问gitlab的ip或域名、端口。而通过防火墙映射的时候，实际是防火墙在访问它，而不是外网终端访问它。所以，external_url针对的应该是防火墙访问它时的IP、域名或者端口，因此，视情况设置外外网IP+端口或者外网域名 或 防火墙访问它时的IP、域名或者端口

可以指定gitlab ssh的端口：

bash
 --env GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.example.com'; gitlab_rails['gitlab_shell_ssh_port'] = 2424"

Docker Compose ​

yaml
version: '3.6'
services:
  gitlab:
    image: registry.gitlab.cn/omnibus/gitlab-jh:17.2.1
    container_name: gitlab
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # Add any other gitlab.rb configuration here, each on its own line
        external_url 'https://gitlab.example.com'
    ports:
      - '80:80'
      - '443:443'
      - '22:22'
    volumes:
      - '/data/gitlab/config:/etc/gitlab'
      - '/data/gitlab/logs:/var/log/gitlab'
      - '/data/gitlab/data:/var/opt/gitlab'
    shm_size: '256m'
bash
$ docker-compose up -d
$ docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password

源代码安装 ​

bash
源代码方式支持Debian/Ubuntu
极狐GitLab的源代码地址：https://jihulab.com/gitlab-cn/gitlab
依赖软件：
    Ruby 2.7
    Go 1.16
    Git 2.33.x
    Node.js 14.15.0

自编译安装 · GitLab

参考架构方式 ​

参考架构 · GitLab

用户少于1000：单台部署即可

用户多于1000：多节点、集群安装

主要参考架构：1k、2k、3k、5k、10k、25k、50k

3k及以上架构支持HA高可用

3K架构节点

  • 外部负载均衡器：处理应用程序服务节点的负载均衡；
  • 内部负载均衡器：处理应用程序内部连接的负载均衡；
  • Redis：缓存服务；
  • Consul和Sentinel：提供高可用；
  • PostgreSQL：数据库服务；
  • PgBouncer：数据库连接池服务；
  • Gitaly：Git 存储服务；
  • Sidekiq：执行后台任务；
  • GitLabRails：提供前端服务，包括UI、API和基于HTTP/SSH的Git；
  • Prometheus：系统监控
  • 对象存储：共享数据；
  • NFS（可选、不推荐）：共享存储；
  • Elasticsearch（可选）：提供更快、更高级的代码搜索；

备份恢复 ​

备份极狐GitLab

备份 ​

配置备份 ​

配置备份包含/etc/gitlab目录下的所有文件，存放于此目录下的任何文件都将被备份。因此建议不要将无关紧要的文件存放于此目录下。

目录下主要包含：

  • 参数文件：/etc/gitlab/gitlab.rb
  • 密钥文件：/etc/gitlab/gitlab-secrets.json
  • 证书文件：/etc/gitlab/ssl
  • 自签根证书文件：/etc/gitlab/trusted-certs

备份命令：

bash
$ gitlab-ctl backup-etc
# 可以通过-p，--backup-path 指定备份存放位置，默认存放在 /etc/gitlab/config_backup

应用程序备份 ​

应用程序备份包含GitLab所有资料数据，具体如下： 数据库、附件、Git存储库、CI/CD作业日志、CI/CD作业工件、LFS对象、Terraform State、容器注册表、Pages、包、代码片段、群组Wiki 备份命令：

bash
$ gitlab-backup create
# 备份默认存放在/var/opt/gitlab/backups目录下，位置以参数形式定义在gitlab.rb中

应用程序备份有多种选项，常用的主要有以下：

bash
$ gitlab-backup create STRATEGY=copy

默认备份策略本质上使用的是Linux的tar和gzip，这适用于大多数情况，但是当数据库变化过快时，会导致备份命令报错，提示file changed as we read it. copy策略可以很好的解决这个问题，通过先复制再打包的方式避免备份失败，副作用是会额外占用一倍的空间(8.17引入）。

bash
$ gitlab-backup create SKIP=db,uploads

跳过备份部分对象，可跳过的对象主要有 db/uploads/builds/artifacts/lfs/terraform_state/registry/pages/repositories/packages

bash
$ gitlab-backup create SKIP=tar

创建tar文件是备份的最后一步，打包会消耗额外的时间，在某些情况下采用不打包的方式会更加方便备份和恢复。

bash
$ gitlab-backup create REPOSITORIES_PATHS=group-a,group-b/project-c

备份特定存储库，在某些特殊情况下，例如上一次的完整备份部分仓库有问题，可以采用备份部分仓库的方式重新对这部分仓库进行备份。

bash
0 2 *** /opt/gitlab/bin/gitlab-backup create CRON=1

gitlab默认没有定时备份的机制，需要借助Linux计划任务配置定时备份。 其他参考：https://gitlab.cn/docs/omnibus/settings/backups.md

主机密钥备份 ​

如果要执行完整的机器恢复，就需要备份主机密钥，这些密钥会在客户端连接主机时进行验证，用以识别主机身份。 如果你不想在用户通过SSH方式克隆代码时提示警告：WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

使用备份的迁移是IP和域名保持不变。

备份命令：

bash
$ tar -cvf ssh.tar /etc/ssh/ssh_host_*

配置备份策略 ​

为了保证备份的安全性和完整性，需要注意以下事项：

bash
gitlab_rails['backup_path']="/var/opt/gitlab/backups"    # 定义默认的备份文件存放位置，默认/var/opt/gitlab/backups
gitlab_rails['backup_archive_permissions']               # 定义备份文件的权限，默认0600
gitlab_rails['backup_keep_time']                         # 定义备份保留期策略，默认7天
gitlab_rails['backup_upload_connection']                 # 定义对象存储连接
gitlab_rails['backup_upload_remote_directory']='my.s3.bucket’ # 定义上传到对象堆存的存储桶

避免冲突的配置

不要将以下配置键设置为相同路径：

bash
- gitlab_rails['backup_path']                        （私有化部署安装的 backup.path）
- gitlab_rails['backup_upload_connection'].local_root（私有化部署安装的 backup.upload.connection.local_root）

backup_path 配置键设置备份文件的本地位置。upload 配置键用于备份文件上传到单独的服务器时，可能用于归档目的。

如果这些配置键设置为相同位置，则上传功能将失败，因为上传位置已经存在备份。这种失败会导致上传功能删除备份，因为它假设这是上传失败后剩余的文件。

备份注意事项 ​

为了保证备份的安全性和完整性，需要注意以下事项：

  1. 备份时需要停止 puma 和 sidekiq 组件或者开启维护模式，否则尽量找数据量变化少的时段进行备份，以免造成数据不一致。

    bash
    # 在备份存储库之前停止所有 Gitaly 服务以创建明确的停机时间
gitlab-ctl stop gitaly
gitlab-ctl start gitaly

  2. 配置备份和应用程序备份尽量不要放在同一个位置，gitlab-secrets.json文件中存储了保护数据库数据的加密密钥，这些密钥用来解密数据库中的加密数据。如果发生备份泄漏，会造成不可挽回的损失。

  3. 采用copy策略进行备份时会占用额外的一倍空间，因此采用此方式进行备份时需要保证磁盘剩余的空间是已经占用空间的2倍及以上。

  4. 空的 Wiki 仓库会跳过备份。

  5. 默认使用 git用户 进行备份和恢复。

  6. 备份命令运行在rails节点，k8s环境中运行在toolbox pod中。

恢复 ​

配置恢复 ​

恢复配置前如果有必要需要备份好恢复环境的配置文件。因为恢复都是采取的覆盖策略。会直接覆盖掉现有的配置文件。

bash
恢复命令：
$ mv /etc/gitlab /etc/gitlab.$(date+%s)
$ tar-xf gitlab_c0nfig_1487687824_2017_02_21.tar -C /

应用程序恢复 ​

先决条件：

  • 恢复的版本和类型需要和备份的一致，可以通过文件backup_information.yml查看到创建备份的版本和类型。
  • 恢复的环境需要先安装好并做好初始化。
  • 确认GitLab处于启动状态，并且停掉 sidekiq 和 puma

恢复配置前如果有必要需要备份好恢复环境的配置文件。 因为恢复都是采取的覆盖策略。会直接覆盖掉现有的配置文件。

恢复命令：

bash
备份文件名： <backup_timestamp>_gitlab_backup.tar
$ gitlab-backup restore BACKUP=1657707659_2022_07_13_15.1.1-jh

当恢复完成后需要执行以下操作：

  1. 确认 gitlab-secrets.json 文件

  2. gitlab-ctl reconfigure # 重新配置

  3. gitlab-ctl restart # 重启

  4. 其他非必要检查

    bash
    $ gitlab-rake gitlab:doctor:secrets
$ gitlab-rake gitlab:artifacts:check
$ gitlab-rake gitlab:lfs:check
$ gitlab-rake gitlab:uploads:check

注意事项：

  • 恢复前需要保证备份文件的权限是git.git
  • 如果使用了pgboucner，需要使用参数 GITLAB_BACKUP_PGHOST、GITLAB_BACKUP_PGPORT 跳过 pgboucner 连接
  • gitlab-secrets.json文件必须恢复，否则会造成众多加密数据无法使用，默认随配置一起恢复

恢复主机密钥 ​

如果想用户在升级后不用对客户端的known_hosts做出修改，则需要恢复主机密钥以及原服务器IP地址

恢复命令：

bash
$ find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
$ tar -xvf ssh.tar -C /etc/ssh/

升级 ​

升级通常是一个相对简单的过程，但是升级的复杂性会根据使用安装方法、GitLab版本等的不同而增加。

极狐GitLab采用语义版本控制的方式，即(Major).(Minor).(Patch) 例如：14.10.5 14代表主要版本，即主要版本是14.0.0，发布时间：每年5月28日 10代表次要版本，即次要版本是14.10.0，发布时间：每月28日 5代表补丁号，即补丁版本是14.10.5，发布时间：不固定

注：补丁版本中不会增加新功能

通常会同时维护三个次要版本的更新： -14.10.5 -15.0.4 -15.1.1

制定极狐GitLab升级计划 ​

在正式升级之前建议在测试环境中进行升级测试，应尽量规避生产环境升级可能遇到的问题。测试环境尽量贴进生产环境，如果是云服务器可以通过镜像服务器的方式创建测试服务器、虚拟机可以采用克隆的方式、docker可以采用import的方式进行创建，物理机可以采用备份恢复方式。

  1. 升级前检查，实例健康状态检查

    bash
    $ gitlab-rake gitlab:check

  2. 确认密钥文件的可用性

    bash
    $ gitlab-rake gitlab:doctor:secrets

  3. 基本操作检查 用户登录、项目列表可见、访问issue和mr、克隆存储库、推送提交

  4. 验证流水线是否可以正常运行 手动运行流水线、在镜像仓库中拉取和推送镜像

  5. 如果配置Geo，检查geo 状态

    bash
    $ gitlab-rake gitlab:geo:check

确认回滚计划 ​

回滚通常采用备份恢复的方式，如果服务器资源足够，我们更加建议采用异机升级的方式进行升级，升级后切换域名（和IP，如果需要），这样可以极大保证原生产环境的可用和快速回滚。

确认升级路径 ​

https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/ 8.11.Z -> 8.12.0 -> 8.17.7 -> 9.5.10 -> 10.8.7 -> 11.11.8 ->12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11->13.8.8->13.12.15->14.0.12->14.3.6->14.9.5->14.10.Z->15.0.Z->latest 15.Y.Z

按照升级路径进行升级是非常有必要的，不然可能会遇到各种不可预知的问题。 一般升级中我们建议采用停机的方式进行升级，零停机升级的方式会有一个较长的升级时长，因为这意味着我们需要安装更多的版本，每个minor版本都需要更新。

curl -fsSL "https://jihulab.com/cs_public/upgrade-paths/-/raw/main/get-upgrade-paths.sh?inline=false" | /bin/bash

如果是离线升级需要提前下载好所需的软件包：https://packages.gitlab.cn

升级路径计算：Upgrade Path

后台任务检查 ​

未运行完成的情况下升级到下一个版本会导致升级出错，后台任务主要是对gitlab元数据结构做出性能优化或者新特性支持方面的调整。

  • Background Jobs
    • Pending jobs/Failed jobs
  • Batched Background Migrations

处理正在运行的CI/CD流水线和作业 ​

正在运行流水线并不会导致升级出现任何的问题，相反的升级可能会导致流水线运行失败。因此在升级前建议操作如下：

  1. 开启维护模式
  2. 阻止新的流水线调度
  3. 配置生效后等待旧流水线完成

检查挂起的高级搜索迁移 如果集成了ElasticSearch，需要检查相关维护任务是否有挂起

备份实例 ​

维护模式开启后，备份GitLab

开始升级 ​

touch /etc/gitlab/skip-auto-backup        跳过自动备份
touch /etc/gitlab/skip-auto-reconfigure   跳过重新配置（一般不会使用）
omnibus        - 安装新版本的升级包
docker         - 替换新版本的镜像
helm           - helm upgrade newhelm chart

升级包安装完成后注意输出的提示，有时可能需要重启数据库

依据此流程依次升级每个版本，这里面备份只在升级之前做一次就可以

数据迁移 ​

迁移方式

bash
备份恢复
导出导入
pull mirror/repo by url
Rsync
自定义迁移程序

备份恢复 ​

备份升级的方式适合所有同版本之间进行数据迁移。 严格限制版本：

CE--> CE
EE --> EE
JH--> JH

优点：

  1. 操作简单
  2. 迁移资料完整，恢复后基本不需要额外配置

缺点：

  1. 备份的各部分数据之前依赖性强，不建议做部分恢复(和元数据强关联）
  2. 缺乏灵活性

导出导入 ​

导出导入适合对部分项目操作，默认没有批量导出功能，需要自己通过调用API程序编写脚本才能实现批量导出。 优点：

  1. 灵活，可导出单个项目
  2. 可以保留issues 和 mr等众多对象
  3. 操作简单
  4. 自定义导入位置
  5. 可以跨版本

缺点：

  1. 不支持批量导出
  2. 如果有对象引用的文件缺失则项目无法导出

pull mirror/repo by url ​

pull mirror 可以将分支、标签和提交从上游存储库复制到您的存储库，定时定期从上游仓库拉取更新。 push mirror 通过提交和管理员强制更新触发，推送到下游仓库的更改会在5min之内加载。 repo by url 通过url导入仓库，不可指定特定分支进行导入。 优势：

  1. 可以保持单个仓库的定期更新
  2. 可以只镜像保护分支

劣势：

  1. 需要保证网络连通
  2. 不可推送更新到下游仓库，容易导致镜像出错

Rsync ​

rsync一般不建议使用，但是如果您的仓库比较大（例如TB 级别的数据量），大体量的数据量在迁移时会面临巨大的挑战，如果使用备份恢复，这将需要一个较长的维护窗口，rsync可以在正常使用的情况下保证数据的定时复制，在停机窗口时保证数据的一致。 rsync主要用来迁移/var/opt/gitlab目录（数据存放目录），目录中包含了数据库目录，一般建议排除掉，数据库采用流复制或者在停机窗口导出导入的方式进行迁移。

优势：

  1. 可以大大减少停机窗口
  2. 可以实现全量数据复制

劣势：

  1. 配置稍微繁琐
  2. 停机窗口需要做数据校验

自定义迁移程序 ​

如果对项目的issue，mr等数据要求不高，可直接舍弃保留仓库数据即可的情况下，可以通过自行编写程序批量拉取推送裸仓库的方式进行迁移。此种方式可以保证仓库数据的完整，但是不保证其他数据，例如项目成员，issue，mr等。 主要实现：

  • git clone --bare
  • git push --mirror