背景：
gitlab 8.5.8版本.参照：https://github.com/sameersbn/docker-gitlab.git.太多年了也没有降级，当初筹备备份还原到一个新的服务器而后降级一下。gitlab服务器开始是docker-compose搭建的前面迁徙到了kubernetes上（记得过后还是1.14），前面kubernetes 版本继续降级到了1.21。根底环境如下：
kubectl get nodeskubectl 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形式,如下：
Kubernetes下备份gitlab
进入gitlab容器执行备份命令：
登陆一台CVM节点,当然了前提是能够exec进入gitlab容器控制台。也能够其余可视化dashboard进入，我这里间接在k8s-master-01节点操作了VM-4-34-rockylinux为操作还原降级节点，这里也备注强调一下：
kubectl exec -it gitlab-77d7878db-j8kqh bash -n gitlabgitlab-rake gitlab:backup:create
确认一下数据的备份目录：
cat /etc/gitlab/gitlab.rb |grep back默认的备份目录为：/var/opt/gitlab/backups目录
进入/var/opt/gitlab/backups失去生成的备份文件如下：
很漫长失去一个20多G的压缩包！
COPY备份文件到新的存储门路
20g的文件copy 或者mv很慢很慢，尤其是在copy腾讯云cfs文件存储下面的文件。过后还找存储的小伙伴问过，过后他们举荐了应用rclone传输，体验了是很快！
装置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-certificateunzip rclone-v1.53.4-linux-amd64.zipchmod 0755 ./rclone-*/rclonecp ./rclone-*/rclone /usr/bin/rm -rf ./rclone-*挂载nfs:
源nfs 10.0.0.24 目标nfs 10.0.4.134 在k8s管制节点挂载。文件夹门路能够自定义。
sudo mount -t nfs -o vers=4.0,noresvport 10.0.0.24:/ /nfs5sudo mount -t nfs -o vers=4.0,noresvport 10.0.4.134:/ /nfs10rclone同步文件到新文件系统
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管制节点上操作
还原gitlab到新环境
一台新的rocky服务器,主机名：VM-4-34-rockylinux
装置docker docker-compose
装置docker docker-compose:
yum update -y ###先update一下sudo yum install -y yum-utils device-mapper-persistent-data lvm2sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.reposudo yum makecache fastsudo yum -y install docker-cesudo service docker startsudo 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客户端，将10.0.4.134挂载到本地
装置一下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留神本人挂载的目录门路以及文件夹目录名.
docker-compose启动gitlab相干利用
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/githubdocker-compose up -d
期待容器running......
restore 还原gitlab仓库
进入gitlab容器，进入backups目录，执行restore命令还原仓库：
docker exec -it github-gitlab-1 bashcd /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 fileyes 批准？期待还原实现
拜访gitlab仓库验证
ip or host 绑定域名。或是间接绑定域名拜访gitlab:
注：https的操作能够创立负载平衡绑定端口的形式or参照gitlab 15.8 on rocky 8中证书配置设置一下？不晓得古老能不能实用，降级高版本了再去尝试！验证了一下仓库 and 用户权限都没有什么问题还原到一段落了，上面尝试一下降级！
其余问题：
我的项目搜寻这里，翻页貌似会404......我尝试了线上的github利用也这样就疏忽了.......
另外ssh-key 的clone没有胜利，尝试了http的clone没有问题，先疏忽！
gitlab降级之路
失常的更新流程看网上都是说
- 降级至以后大版本(_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版本的对应关系：
降级gitlab的同时，postgresql的版本也应该同时进行降级的，具体的版本对应关系可参考以下链接：
https://repository.prace-ri.eu/git/help/administration/package_information/postgresql_versions.md
筹备在降级gitlab9的时候降级一下postgresql 。8版本就应用默认的9.4.24了！
8.5.8 -8.12.13
dockerhub仓库看了一眼：https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=8.12,8.12的版本tag就棘手抉择了8.12.13：
批改镜像tag
尝试批改docker-compose.yml中gitlab image tag 为twang2218/gitlab-ce-zh:8.12.13
docker-compose downdocker-compose up -dsecret文件问题
[root@VM-4-34-rockylinux github]# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESdbb3e922065e 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-1bbce8d9fcc7f sameersbn/redis:latest "/sbin/entrypoint.sh…" About a minute ago Up About a minute 6379/tcp github-redis-1da59ea5a2780 sameersbn/postgresql:9.4-24 "/sbin/entrypoint.sh" About a minute ago Up About a minute 5432/tcp github-postgresql-1docker logs -f github-gitlab-1查看日志呈现如下报错：
尝试删除secret文件：
cd /data/data/github/gitlab/gitlab-rails/etcrm -rf secretgitlab 参数env缺失
综上，删除secret后，持续重启gitlab服务：
docker-compose downdocker-compose up -ddocker 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中没有这两个参数，增加一下：
repositories目录权限
注：截图很多目录会是/data/data/github1/gitlab/ 是第二次操作后截图，为了熟练练手，图中门路疏忽！
尝试持续重启gitlab服务：
cd /data/data/github/docker-compose downdocker-compose up -d
查看gitlab服务日志：
docker logs -f github1-gitlab-1呈现如下谬误，依照日志内容，根本确定是文件夹权限问题！
批改文件夹目录权限：
chmod 2770 -R gitlab/git-data/repositories
请留神文件目录门路，操作命令文件相对路径在/data/data/github/目录
重启gitlab服务：
docker-compose downdocker-compose up -d
查看日志，期待服务失常启动！
docker logs -f github-gitlab-1登陆web并验证gitlab服务
用原有gitlab账户登陆此gitlab服务器
点击治理区域查看gitlab版本，确认版本曾经降级到8.12.13版本。
第一步降级算是根本胜利！
注：docker-compose 命令都是在/data/data/github目录下执行（搁置docker-compose.yml文件目录下）。留神文件目录的切换！
8.12.13-8.17.7
确认并批改docker-compose.yml文件镜像tag
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：
重启gitlab服务
docker-compose downdocker-compose up -ddocker logs -f github-gitlab-1web拜访并验证版本升级胜利
用原有gitlab账户登陆此gitlab服务器，控制台查看gitlab 服务器版本曾经降级到指定8.17.7版本
8.17.7-9.5.10
批改gitlab postgresql镜像版本
参照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
服务的启动与postgresql版本问题：
docker-compose downdocker-compose up -ddocker psdocker logs -f github1-postgresql-1
恩 postgresql版本升级会有问题！sameersbn/postgresql中 根底镜像中9.4的版本仓库应该没有了（毕竟太老了）怎么破？流氓一下，找到最新的postgresql的版本：
批改docker-compose.yml postgresql镜像为sameersbn/postgresql:12-20200524
docker-compose downdocker-compose up -d docker logs -f github-postgresql-1
期待postgresql降级实现：
docker ps
查看gitlab容器日志：
docker logs -f github-gitlab-1
貌似会有点问题无奈登陆。个体重启一遍docker-compose服务：
docker-compose downdocker-compose up -d docker logs -f github-gitlab-1
期待gitlab 容器失常运行：
持续登陆验证web登陆仓库
用原有gitlab账户登陆此gitlab服务器，控制台查看gitlab 服务器版本曾经降级到指定9.5.10版本：
另外对于postgresql的降级后文件目录的变动：
9.5.10-10.8.7
持续批改gitlab镜像tag
持续降级gitlab到10大版本.到dockerhub参考一下镜像仓库版本：
https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=10.8
批改gitlab镜像tag为10.8.7
重启gitlab相干服务
docker-compose downdocker-compose up -ddocker ps -adocker logs -f github-gitlab-1
期待的有些漫长
web登陆gitlab仓库
点击治理区域验证版本10.8.7：
10.8.7-11.1.4
批改gitlab镜像tag
持续找到11大版本的最高版本11.1.4
https://hub.docker.com/r/twang2218/gitlab-ce-zh/tags?page=1&name=11.1
重启降级gitlab服务
docker-compose downdocker-compose up -ddocker ps -a
查看日志，期待服务降级：
docker logs -f github1-gitlab-1web登陆gitlab控制台验证
点击治理区域：
确认版本升级到11.1.4：
就先降级到这里后续用官网镜像or sameersbn镜像持续实现降级到更高版本！
过程中其余呈现过的问题：
postgresql配置的时候第一次呈现过如下报错：
参照csdn的一篇文章：https://blog.csdn.net/weixin_42758299/article/details/117958407，批改了pg_hba.conf
而后重启了postgresql失常启动了：