关于gitlab:gitlab远古版本备份还原升级

4次阅读

共计 11211 个字符，预计需要花费 29 分钟才能阅读完成。

gitlab 8.5.8版本. 参照：https://github.com/sameersbn/docker-gitlab.git. 太多年了也没有降级，当初筹备备份还原到一个新的服务器而后降级一下。gitlab 服务器开始是 docker-compose 搭建的前面迁徙到了 kubernetes 上（记得过后还是 1.14），前面 kubernetes 版本继续降级到了 1.21。根底环境如下：

kubectl get nodes
kubectl get pods -n gitlab

image 镜像的版本如下：

kubectl get deployment -n gitlab -o yaml|grep image:

降级的过程参考了：降级公司的 GitLab，根本版本是 8.5.8 -8.12.13-9.5.10-10.8.7-11.1.4（ 8 的小版本先降级到稳固的 8.12, 而后到 8 的最高版本，而后每个大版本进行降级）
注：我这里的 gitlab 的根底镜像并不是 sameersbn/gitlab 过后有汉化 twang2218/gitlab-ce-zh 镜像间接应用了汉化的镜像，间接应用了twang2218/gitlab-ce-zh 的镜像为例！存储间接挂载了 nfs 存储未应用 pv,pvc 形式, 如下：

登陆一台 CVM 节点, 当然了前提是能够 exec 进入 gitlab 容器控制台。也能够其余可视化 dashboard 进入，我这里间接在 k8s-master-01 节点操作了 VM-4-34-rockylinux 为操作还原降级节点，这里也备注强调一下：

kubectl exec -it gitlab-77d7878db-j8kqh bash -n gitlab
gitlab-rake gitlab:backup:create

确认一下数据的备份目录：

cat /etc/gitlab/gitlab.rb |grep back

默认的备份目录为：/var/opt/gitlab/backups目录

进入 /var/opt/gitlab/backups 失去生成的备份文件如下：

很漫长失去一个 20 多 G 的压缩包！

20g 的文件 copy 或者 mv 很慢很慢，尤其是在 copy 腾讯云 cfs 文件存储下面的文件。过后还找存储的小伙伴问过，过后他们举荐了应用 rclone 传输，体验了是很快！

装置 rclone, 参照：https://cloud.tencent.com/document/product/582/83114（还是在 kubernetes 管制节点操作的，当然了其实能够在任何一个局域网内节点装置，而后挂载10.0.0.24 的 nfs）

wget https://downloads.rclone.org/v1.53.4/rclone-v1.53.4-linux-amd64.zip --no-check-certificate
unzip rclone-v1.53.4-linux-amd64.zip
chmod 0755 ./rclone-*/rclone
cp ./rclone-*/rclone /usr/bin/
rm -rf ./rclone-*

源 nfs 10.0.0.24 目标 nfs 10.0.4.134 在 k8s 管制节点挂载。文件夹门路能够自定义。

sudo mount -t nfs -o vers=4.0,noresvport 10.0.0.24:/ /nfs5
sudo mount -t nfs -o vers=4.0,noresvport 10.0.4.134:/ /nfs10

rclone sync 同步文件到目标 nfs(也能够是其余文件系统)

rclone sync  /nfs5/data/github/gitlab/backups/1678096354_gitlab_backup.tar /nfs10/data/github/gitlab/backups/ -Pvv --transfers 32 --checkers 64 --copy-links --local-no-check-updated

4 分钟左右同步实现还是很快的，毕竟有 20 多 G 文件！
注：以上操作在 Kubernetes 管制节点上操作

一台新的 rocky 服务器, 主机名：VM-4-34-rockylinux

装置 docker docker-compose:

yum update -y ### 先 update 一下
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
sudo yum makecache fast
sudo yum -y install docker-ce
sudo service docker start
sudo docker -v

注：当然了能够配置一下镜像减速:

配置镜像减速后记得systemctl reload-daemon systemctl restart docker.
docker-compose 的装置：

docker_compose_version=v2.16.0 && curl -L "https://github.com/docker/compose/releases/download/${docker_compose_version}/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose && ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

装置一下 nfs 客户端（文件筹备同步过去，挂载 nfs 的！）

yum install nfs*
sudo mount -t nfs -o vers=4.0,noresvport 10.0.4.134:/ /data

/data 目录下创立 github 目录（与原来 nfs 实例保障目录构造统一），github 目录下创立 gitlab postgresql redis 目录(gitlab 目录曾经存在了其实，下面 reclone 同步的时候会主动创立目录)：

[root@VM-4-34-rockylinux github]# pwd
/data/data/github
[root@VM-4-34-rockylinux github]# mkdir gitlab postgresql redis

VM-4-34-rockylinux 主机操作
首先确认文件以及 rclone 到指定门路

登陆 github 仓库查找对应版本docker-compose.yml 文件放在 /data/data/github 目录下：

留神：我这里拿得 https://github.com/sameersbn/docker-gitlab/blob/v8.9.4/docker-compose.yml 的 yml 文件
批改docker-compose.yml 如下：

version: '2'

services:
  redis:
    restart: always
    image: sameersbn/redis:latest
    command:
    - --loglevel warning
    volumes:
    - /data/data/github/redis:/var/lib/redis:Z

  postgresql:
    restart: always
    image: sameersbn/postgresql:9.4-24
    volumes:
    - /data/data/github/postgresql:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlab
    - DB_PASS=passw0rd
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm

  gitlab:
    restart: always
    image: twang2218/gitlab-ce-zh:8.5.8
    depends_on:
    - redis
    - postgresql
    ports:
    - "80:80"
    - "10022:22"
    volumes:
    - /data/data/github/gitlab:/home/git/data:Z
    environment:
    - DEBUG=false

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Asia/Shanghai
    - GITLAB_TIMEZONE=Beijing

    - GITLAB_HTTPS=false
    - SSL_SELF_SIGNED=false

    - GITLAB_HOST=gitlab.zhangpeng.com
    - GITLAB_PORT=80
    - GITLAB_SSH_PORT=10022
    - GITLAB_RELATIVE_URL_ROOT=
    - GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alphanumeric-string

    - GITLAB_ROOT_PASSWORD=
    - GITLAB_ROOT_EMAIL=

    - GITLAB_NOTIFY_ON_BROKEN_BUILDS=true
    - GITLAB_NOTIFY_PUSHER=false

    - GITLAB_EMAIL=notifications@example.com
    - GITLAB_EMAIL_REPLY_TO=noreply@example.com
    - GITLAB_INCOMING_EMAIL_ADDRESS=reply@example.com

    - GITLAB_BACKUP_SCHEDULE=daily
    - GITLAB_BACKUP_TIME=01:00

    - SMTP_ENABLED=false
    - SMTP_DOMAIN=www.example.com
    - SMTP_HOST=smtp.gmail.com
    - SMTP_PORT=587
    - SMTP_USER=mailer@example.com
    - SMTP_PASS=password
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=login

    - IMAP_ENABLED=false
    - IMAP_HOST=imap.gmail.com
    - IMAP_PORT=993
    - IMAP_USER=mailer@example.com
    - IMAP_PASS=password
    - IMAP_SSL=true
    - IMAP_STARTTLS=false

    - OAUTH_ENABLED=false
    - OAUTH_AUTO_SIGN_IN_WITH_PROVIDER=
    - OAUTH_ALLOW_SSO=
    - OAUTH_BLOCK_AUTO_CREATED_USERS=true
    - OAUTH_AUTO_LINK_LDAP_USER=false
    - OAUTH_AUTO_LINK_SAML_USER=false
    - OAUTH_EXTERNAL_PROVIDERS=

    - OAUTH_CAS3_LABEL=cas3
    - OAUTH_CAS3_SERVER=
    - OAUTH_CAS3_DISABLE_SSL_VERIFICATION=false
    - OAUTH_CAS3_LOGIN_URL=/cas/login
    - OAUTH_CAS3_VALIDATE_URL=/cas/p3/serviceValidate
    - OAUTH_CAS3_LOGOUT_URL=/cas/logout

    - OAUTH_GOOGLE_API_KEY=
    - OAUTH_GOOGLE_APP_SECRET=
    - OAUTH_GOOGLE_RESTRICT_DOMAIN=

    - OAUTH_FACEBOOK_API_KEY=
    - OAUTH_FACEBOOK_APP_SECRET=

    - OAUTH_TWITTER_API_KEY=
    - OAUTH_TWITTER_APP_SECRET=

    - OAUTH_GITHUB_API_KEY=
    - OAUTH_GITHUB_APP_SECRET=
    - OAUTH_GITHUB_URL=
    - OAUTH_GITHUB_VERIFY_SSL=

    - OAUTH_GITLAB_API_KEY=
    - OAUTH_GITLAB_APP_SECRET=

    - OAUTH_BITBUCKET_API_KEY=
    - OAUTH_BITBUCKET_APP_SECRET=

    - OAUTH_SAML_ASSERTION_CONSUMER_SERVICE_URL=
    - OAUTH_SAML_IDP_CERT_FINGERPRINT=
    - OAUTH_SAML_IDP_SSO_TARGET_URL=
    - OAUTH_SAML_ISSUER=
    - OAUTH_SAML_LABEL="Our SAML Provider"
    - OAUTH_SAML_NAME_IDENTIFIER_FORMAT=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    - OAUTH_SAML_GROUPS_ATTRIBUTE=
    - OAUTH_SAML_EXTERNAL_GROUPS=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_EMAIL=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_NAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_FIRST_NAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_LAST_NAME=

    - OAUTH_CROWD_SERVER_URL=
    - OAUTH_CROWD_APP_NAME=
    - OAUTH_CROWD_APP_PASSWORD=

    - OAUTH_AUTH0_CLIENT_ID=
    - OAUTH_AUTH0_CLIENT_SECRET=
    - OAUTH_AUTH0_DOMAIN=

    - OAUTH_AZURE_API_KEY=
    - OAUTH_AZURE_API_SECRET=
    - OAUTH_AZURE_TENANT_ID=

只批改了几个 镜像的 tag与 kubernetes 搭建的 版本统一 (redis 版本其实没有太大要求)，还有 ssh 的 对外映射端口 （否则会与主机的 22 端口抵触，数据库明码也间接拿来 kubernetes 集群中的变量了 …….）：

为什么不必 8.5.8 的 docker-compose.yaml 文件呢？
https://github.com/sameersbn/docker-gitlab/blob/8.5.8/docker-compose.yml

docker-compose 的版本貌似是 V1 的起不来服务 ….. 这里就默认用 v2 的 yaml 了

cd /data/data/github
docker-compose up -d

期待容器 running……

进入 gitlab 容器，进入 backups 目录，执行 restore 命令还原仓库：

docker exec -it github-gitlab-1 bash
cd /var/opt/gitlab/backups/
gitlab-rake gitlab:backup:restore BACKUP:1678096354

注：BACKUP 后跟备份文件_后面的工夫辍格局. 除了 1678096354_gitlab_backup.tar 压缩包外其余文件是执行过程中解压产生的文件。这是在 CVM 主机挂载目录看到的！
两头会有

This will rebuild an authorized_keys file.
You will lose any data stored in authorized_keys file

yes 批准？期待还原实现

ip or host 绑定域名。或是 间接绑定域名 拜访 gitlab:

注：https 的操作能够创立负载平衡绑定端口的形式 or 参照 gitlab 15.8 on rocky 8 中证书配置设置一下？不晓得古老能不能实用，降级高版本了再去尝试！验证了一下仓库 and 用户权限都没有什么问题还原到一段落了，上面尝试一下降级！

我的项目搜寻这里，翻页貌似会 404…… 我尝试了线上的 github 利用也这样就疏忽了 …….

另外 ssh-key 的 clone 没有胜利，尝试了 http 的 clone 没有问题，先疏忽！

失常的更新流程看网上都是说

降级至以后大版本 (_major version_) 的最新小版本(_latest minor version_)
降级至指标大版本 (target major version) 的首个小版本(first minor version)
持续降级至更新的版本

依据 gitlab upgrading guide 的说法，版本低于 8.11.Z 时，先更新到 8.12.0 是比拟稳当的计划。第一部先降级到 8.12 吧！
注：我这里的 twang2218/gitlab-ce-zh 镜像很多都与官网的不太一样，还是持续应用 twang2218/gitlab-ce-zh 的镜像进行降级了！

降级 gitlab 的同时，postgresql 的版本也应该同时进行降级的，具体的版本对应关系可参考以下链接：
https://repository.prace-ri.eu/git/help/administration/package_information/postgresql_versions.md

筹备在降级 gitlab9 的时候降级一下 postgresql。8 版本就应用默认的 9.4.24 了！

dockerhub 仓库看了一眼：https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=8.12,8.12 的版本 tag 就棘手抉择了 8.12.13：

尝试批改 docker-compose.yml 中 gitlab image tag 为twang2218/gitlab-ce-zh:8.12.13

docker-compose down
docker-compose up -d

[root@VM-4-34-rockylinux github]# docker ps
CONTAINER ID   IMAGE                            COMMAND                  CREATED              STATUS              PORTS                                                                                 NAMES
dbb3e922065e   twang2218/gitlab-ce-zh:8.12.13   "/assets/wrapper"        About a minute ago   Up 1 second         0.0.0.0:80->80/tcp, :::80->80/tcp, 443/tcp, 0.0.0.0:10022->22/tcp, :::10022->22/tcp   github-gitlab-1
bbce8d9fcc7f   sameersbn/redis:latest           "/sbin/entrypoint.sh…"   About a minute ago   Up About a minute   6379/tcp                                                                              github-redis-1
da59ea5a2780   sameersbn/postgresql:9.4-24      "/sbin/entrypoint.sh"    About a minute ago   Up About a minute   5432/tcp                                                                              github-postgresql-1

docker logs -f github-gitlab-1

查看日志呈现如下报错：

尝试删除 secret 文件：

cd /data/data/github/gitlab/gitlab-rails/etc
rm -rf secret

综上，删除 secret 后，持续重启 gitlab 服务：

docker-compose down
docker-compose up -d
docker logs -f github-gitlab-1

恩 docker-compose.yml 少了两个参数，参照 gitlab on kubernetes 的配置：

    - GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alpha-numeric-string
    - GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alpha-numeric-strin

其实 kubernetes gitllab 中是有的，8.9.4 的 docker-compose.yml 中没有这两个参数，增加一下：

注：截图很多目录会是 /data/data/github1/gitlab/ 是第二次操作后截图，为了熟练练手，图中门路疏忽！
尝试持续重启 gitlab 服务：

cd /data/data/github/
docker-compose down
docker-compose up -d

查看 gitlab 服务日志：

docker logs -f github1-gitlab-1

呈现如下谬误，依照日志内容，根本确定是文件夹权限问题！

批改文件夹目录权限：

chmod 2770 -R gitlab/git-data/repositories

请留神文件目录门路，操作命令文件相对路径在 /data/data/github/ 目录
重启 gitlab 服务：

docker-compose down
docker-compose up -d

查看日志，期待服务失常启动！

docker logs -f github-gitlab-1

用原有 gitlab 账户登陆此 gitlab 服务器

点击治理区域查看 gitlab 版本，确认版本曾经降级到 8.12.13 版本。

第一步降级算是根本胜利！
注：docker-compose 命令都是在 /data/data/github 目录下执行（搁置 docker-compose.yml 文件目录下）。留神文件目录的切换！

dockerhub 查看 8 版本最初镜像 tag 为 8.17，https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=8.17。这里就抉择降级到 8.17.7 版本

批改 docker-compose.yml 文件中镜像 tag：

docker-compose down
docker-compose up -d
docker logs -f github-gitlab-1

用原有 gitlab 账户登陆此 gitlab 服务器，控制台查看 gitlab 服务器版本曾经降级到指定 8.17.7 版本

参照 postgresql 与 gitlab 对应关系 …..gitlab 降级到 9 版本，postgresql 也的降级到 9.6 版本以上：

参考：https://github.com/sameersbn/docker-gitlab/tree/9.5.5

还是应用 sameersbn 的 postgresql 镜像，批改 tag
https://hub.docker.com/r/sameersbn/postgresql/tags?page=1&name=9.6

筹备批改 postgresql 镜像 tag 为 9.6-3 gitlab 镜像 tag9.5.10 参照
https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=9.5

docker-compose down
docker-compose up -d
docker ps

docker logs -f github1-postgresql-1

恩 postgresql 版本升级会有问题！sameersbn/postgresql 中根底镜像中 9.4 的版本仓库应该没有了（毕竟太老了）怎么破？流氓一下，找到最新的 postgresql 的版本：

批改 docker-compose.yml postgresql 镜像为 sameersbn/postgresql:12-20200524

docker-compose down
docker-compose up -d 
docker logs -f github-postgresql-1

期待 postgresql 降级实现：

docker ps

查看 gitlab 容器日志：

docker logs -f github-gitlab-1

貌似会有点问题无奈登陆。个体重启一遍 docker-compose 服务：

docker-compose down
docker-compose up -d 
docker logs -f github-gitlab-1

期待 gitlab 容器失常运行：

用原有 gitlab 账户登陆此 gitlab 服务器，控制台查看 gitlab 服务器版本曾经降级到指定 9.5.10 版本：

另外对于 postgresql 的降级后文件目录的变动：

持续降级 gitlab 到 10 大版本. 到 dockerhub 参考一下镜像仓库版本：
https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=10.8

批改 gitlab 镜像 tag 为 10.8.7

docker-compose down
docker-compose up -d
docker ps -a

docker logs -f github-gitlab-1

期待的有些漫长

点击治理区域验证版本 10.8.7：

持续找到 11 大版本的最高版本 11.1.4
https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=11.1

docker-compose down
docker-compose up -d
docker ps -a

查看日志，期待服务降级：

docker logs -f github1-gitlab-1

点击治理区域：

确认版本升级到 11.1.4：

就先降级到这里后续用官网镜像 or sameersbn 镜像持续实现降级到更高版本！

postgresql 配置的时候第一次呈现过如下报错：

参照 csdn 的一篇文章：https://blog.csdn.net/weixin_42758299/article/details/117958407，批改了pg_hba.conf

而后重启了 postgresql 失常启动了：

正文完

gitlab

发表至： gitlab

2023-03-09

0

关于gitlab:第三方Gitlab库资源如何一键导入云效Codeup

关于gitlab:mac配置Gitlab

关于gitlab:细粒度的代码权限怎么做极狐GitLab-代码所有者来帮忙

关于gitlab:git-命令相关笔记

关于网络安全:企业上云如何高效破解挖矿攻击难题避免高价值数据泄露3月16日锁定直播get最优解

关于gitlab:gitlab远古版本备份还原升级

背景：

Kubernetes 下备份 gitlab

进入 gitlab 容器执行备份命令：

COPY 备份文件到新的存储门路

装置 rclone

挂载 nfs:

rclone 同步文件到新文件系统

还原 gitlab 到新环境

装置 docker docker-compose

装置 nfs 客户端，将 10.0.4.134 挂载到本地

docker-compose 启动 gitlab 相干利用

restore 还原 gitlab 仓库

拜访 gitlab 仓库验证

其余问题：

gitlab 降级之路

额定强调一下 gitlab 与 postgresql 版本的对应关系：

8.5.8 -8.12.13

批改镜像 tag

secret 文件问题

gitlab 参数 env 缺失

repositories 目录权限

登陆 web 并验证 gitlab 服务

8.12.13-8.17.7

确认并批改 docker-compose.yml 文件镜像 tag

重启 gitlab 服务

web 拜访并验证版本升级胜利

8.17.7-9.5.10

批改 gitlab postgresql 镜像版本

服务的启动与 postgresql 版本问题：

持续登陆验证 web 登陆仓库

9.5.10-10.8.7

持续批改 gitlab 镜像 tag

重启 gitlab 相干服务

web 登陆 gitlab 仓库

10.8.7-11.1.4

批改 gitlab 镜像 tag

重启降级 gitlab 服务

web 登陆 gitlab 控制台验证

过程中其余呈现过的问题：

站内搜索