发表更新GitLab18 分钟读完 (大约2706个字)0次访问

GitLab 部署运维踩坑记

前言

   公司自建GitLab作为代码托管平台， 在自己接手之前，GitLab已经在当时很新，但现在看来很旧，BUG 很多，性能很慢的版本上已经运行了3年多，加上机房又是本地自建，缺乏专业机房的稳定性，自己一直想着升级和迁移，初来乍到，一腔热血，啥也不会， 不迁移、不升级，也能跑，也能用，1年，两年，N年，要一直这样吗？ 事总要去做，问题总要去解决，或许这就是存在的价值。
   迁移首先要保证数据不丢，因为这关系公司宝贵的数字资产， 登录管理员账号查看，400+ 项目，吓一跳，在经过一段时间踩坑折腾之后， 感觉也就那么回事，迁移了，升级了，之前没有的很多工作都做了，比如：容灾，写写文章记录下， 这里引用李宗盛歌曲《山丘》的一句歌词：就算终于忘了，也值了。

总览

部署方式

   首先要讲的就是如何安装部署，部署方式很多，走，去 官方瞅瞅 ，瞅到了嘛，很多， 其中官方推荐使用Linux 软件包方式，因为Linux 安装安装更快、升级更容易，并且包含其他方法所没有的增强可靠性的功能， 这里我只写我 目前 使用的方式，在阿里云托管的Kubernetes上部署Docker镜像整包。 可能大家会有疑问， 用了Kubernetes为什么不使用helm方式来部署？主要是组件太多， 虽然可以选择启用禁用，升级维护上还是有点麻烦，学习成本也挺高，不如整包来的方便，但后期肯定会使用Helm方式来部署。

  废话不多说，直接来部署文件吧，反正大家只要有Kubernetes 基础都能看懂，简单地很~

  • 首先需要创建 PersistentVolumeClaim 用于持久化数据。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    ---
    # 数据文件
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: gitlab
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 150Gi
      storageClassName: alicloud-nas-subpath-quota

    执行 kubectl carete -f pvc.yml -n <namespace>

  • 编写Deployment部署文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    ---
    # 部署k8s
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: gitlab
      labels:
        app: gitlab
    spec:
      replicas: 1
      strategy:
        type: RollingUpdate
      template:
        metadata:
          name: gitlab
          labels:
            app: gitlab
        spec:
          containers:
            - name: gitlab
              image: gitlab/gitlab-ce:14.0.5-ce.0
              imagePullPolicy: IfNotPresent
              # 卷挂载
              volumeMounts:
                # 数据文件
                - mountPath: /var/opt/gitlab
                  name: gitlab-volume
                  subPath: data
                # 备份文件
                - mountPath: /var/opt/gitlab/backups
                  name: gitlab-volume
                  subPath:  backups
                # 配置文件
                - mountPath: /etc/gitlab
                  name: gitlab-volume
                  subPath: config
                # 日志文件
                - mountPath: /var/log/gitlab
                  name: gitlab-volume
                  subPath: logs
                - mountPath: /etc/localtime
                  name: localtime
          restartPolicy: Always
          # 卷
          volumes:
            # data
            - name: gitlab-volume
              persistentVolumeClaim:
                claimName: gitlab
            - name: localtime
              hostPath:
                path: /etc/localtime

      selector:
        matchLabels:
          app: gitlab

    执行 kubectl carete -f deployment.yml -n <namespace>

  • 创建 Service服务，这里我创建的类型是ClusterIP ，并通过自建的APISIX 云原生网关将服务映射到了外部，大家可以创建适合自己的Service服务方式，比如LoadBalance 、NodePort这里就不多说了。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    ---
    # 创建service
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: gitlab
      name: gitlab
      namespace: gitlab
    spec:
      ports:
        - port: 80
          protocol: TCP
          targetPort: 80
      selector:
        app: gitlab
      sessionAffinity: None
      type: ClusterIP

    执行 kubectl carete -f service.yml -n <namespace>

  接下来就等待，容器运行起来后，内部需要执行漫长的操作，刷新浏览器页面等待就好了，安装成功之后，你将会看到登录页面，初始用户名为 root 密码需要进入容器内部的/etc/gitlab/initial_root_password文件中查找。 登录进去可以进行设置密码，配置语言，等个性化操作，没啥好写的，大家自己摸索即可。

完成安装之后，我们需要进行一些配置更改，比如设置电子邮件服务器，容器使用官方的 Omnibus GitLab 包，因此所有配置都在唯一的配置文件中完成/etc/gitlab/gitlab.rb，配置太多了，我把配置地址贴出来，大家有需要去里面寻找吧。

迁移之路

   迁移之路是个痛苦惊险，又刺激的过程，用了个很笨的办法，五一假期前一天下午，将公司gitalb容器停掉，找到数据持久化位置，通过SFTP上传到了新环境配置的对应数据位置，耗费了很久时间，数据当时大约在48G 左右，漫长痛苦的等待，在下班的时候，将新环境的gitalb启起来，过程漫长，数据未丢。

  通过SFTP方式比较笨，时间比较长，最简单的方式就是通过gitalb备份，然后在新位置进行相同版本还原。下面将讲备份和还原。

注意：新环境用的gitalb版本和老环境gitalb版本是一致的。不要想着将老版本数据放到新版本里面跑，这是一件很幼稚的事。

升级迭代

  版本升级，这个很刺激，坑很多，我当时是从10.1.3版本升级上的13的最新版本，目前最新的是14系列，公司gitalb版本始终紧紧跟随潮流，跟哥哥们吹牛逼说，只要我在一天，公司Gitlab就永远不会是老版本，没办法，谁让我太喜欢进步了呢。

  啥也别说了，直接上文档吧，看看官方文档的升级步骤和注意事项。如果你的版本幅度太大，啥也别说了，直接看特定版本升级和升级路径吧。

  在这里，感觉能给大家分享的，就是看我列出来的官方文档，毕竟我复制翻译一份放到这里意义不大，因为文章不能像官方文档一样实时更新，升级的时候别慌，先备份，再升级，下面来讲备份了。

防患未然

  防患未然，居安思危呗，就是备份恢复，又是简单地一批，贴官方文档了。

备份

  • 备份存档保存在文件中backup_path指定的位置，文件名是[TIMESTAMP]_gitlab_backup.tar，其中TIMESTAMP标识每个备份的创建时间，以及GitLab版本。如果您需要恢复GitLab并且有多个备份可用，则需要时间戳。例如，如果备份名称为1493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar，则时间戳为1493107454_2018_04_25_10.6.4-ce。

  • Gitalb备份包括以下数据

    • Database
    • Attachments
    • Git repositories data
    • CI/CD job output logs
    • CI/CD job artifacts
    • LFS objects
    • Container Registry images
    • GitLab Pages content
    • Snippets
    • Group wikis

  • 备份不包括以下数据

GitLab 不备份任何配置文件、SSL 证书或系统文件

  • 由于我是基于Docker镜像整包部署的，所以，我需要进入容器内部，执行命令sudo gitlab-backup create 命令，接下来就是等待了。数据量多时间就久了。

执行备份

  进入容器内部执行 gitlab-backup create 即可。

存储配置文件

  GitLab提供的备份 Rake 任务不会存储配置文件。需要手动进行备份，进入/etc/gitlab/config下目录，把数据备份一下即可。

备份上传远程云存储

  将备份上传到云厂商存储，这个功能很好了，具体文档。GitLab 为 AWS、Google、OpenStack Swift、Rackspace 和 Aliyun导入云驱动程序。本地驱动程序 也可用。

  我这里用的是fog-aliyun，将备份数据上传到阿里云OSS，修改/etc/gitlab/config/gitlab.rb配置，直接上配置内容吧。

1
2
3
4
5
6
7
8
9
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'aliyun',
  'aliyun_accesskey_id'     => <YOUR_ACCESS_KEY_ID>,
  'aliyun_accesskey_secret' => <YOUR_SECRET_ACCESS_KEY>,
  'aliyun_oss_bucket'       => <YOUR_OSS_BUCKET>,
  'aliyun_region_id'        => <YOUR_TARGET_REGION>,
  'aliyun_oss_endpoint'     => <YOUR_OSS_ENDPOINT>
}
gitlab_rails['backup_upload_remote_directory'] = ''

配置上以后，进入容器内部，执行gitlab-ctl reconfigure 重新配置即可，每次在执行备份任务结束后，都会自动进行上传操作。

备份文件生命周期

  为防止定期备份使用所有磁盘空间，我们需要为备份设置有限的生命周期。下次运行备份任务时，backup_keep_time会修剪早于 的备份。此配置选项仅管理本地文件。GitLab 不会修剪存储在第三方对象存储中的旧文件， 因为用户可能没有列出和删除文件的权限。建议为对象存储配置适当的保留策略。

  1. 编辑/etc/gitlab/gitlab.rb：

    1
    2
    ## Limit backup lifetime to 7 days - 604800 seconds
    gitlab_rails['backup_keep_time'] = 604800

  2. 进入容器内部执行 gitlab-ctl reconfigure 重新配置 GitLab 以使更改生效。

恢复

   恢复还是比较简单的，执行几个命令，先贴官方文档吧，恢复有很多种方式，不同安装方式恢复方式也有些出入，这里只写Docker方式的。

注意：只能将备份恢复到完全相同的GitLab版本和类型 (CE/EE)。

如果备份与当前安装的版本不同，则必须 在恢复备份之前 降级 GitLab 安装。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Stop the processes that are connected to the database
docker exec -it <name of container> gitlab-ctl stop puma
docker exec -it <name of container> gitlab-ctl stop sidekiq

# Verify that the processes are all down before continuing
docker exec -it <name of container> gitlab-ctl status

# Run the restore
docker exec -it <name of container> gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce

# Restart the GitLab container
docker restart <name of container>

# Check GitLab
docker exec -it <name of container> gitlab-rake gitlab:check SANITIZE=true

执行命令，经过漫长等待，恢复执行完毕后，将备份的配置文件还原到相应位置，重启即可。

GitLab 部署运维踩坑记

https://pingfangushi.com/posts/4023dc33/

作者

SanLi

发布于

2021-07-11

更新于

2021-07-11

许可协议

#

喜欢这篇文章？打赏一下作者吧

×