目标：

使用168.61.113.220作为新服务器，把gitlab 8.10.4 数据迁移到新服务器中，并且升级到 12.4.2

升级思路：

准备一台新服务器168.61.113.220，安装gitlab8.10.4，然后备份生产环境gitlab数据，在新服务器恢复，最后、在进行升级。

因为gitlab升级不能跨大版本，所以必须升级到当前的最新版本，然后再升级到下一个大版本。

0、准备工作：

1、比较生产环境服务器与新服务器之间的差异(CPU、内存、磁盘空间)  ---------------------------------------------------------------------------dxd需要进行扩容

2、准备gitlab rpm升级包（已放在/app/tools目录下） ---------------------------------------------------------------------------------dxd提前放到/app/tools下面

http://svn.htzq.test.com.cn/test/docs/15 工具插件/05 Gitlab                                                  

【正式升级忽略】3、检查依赖包 policycoreutils-python是否已安装（中途升级过程成需要）

4、168.8.250.75对新服务器开通 25端口。用于gitlab调用邮件服务器发送邮件。

测试  telnet 168.8.250.75 25  端口是否开通。（已开通）------------------------------------------------------------dxd已走流程

【正式升级忽略】5、检查Python和Git客户端版本是否与原生产环境一致——陈兆康20200219

6、比较crontab是否一致（除了Python脚本，crontab 脚本已修改为一致。Python脚本需正式升级后修改）-----------------------------------------------------------------------------------------dxd正式升级前，需要提前改成一致

/home/appadmin/git_tool/git_start.py：Python代码统计，注意要拷贝整个Python项目而不是单独一个.py脚本文件

经检查 生产环境中并不存在影响其他服务器的定时脚本

【正式升级忽略】7、测试与Python代码统计脚本使用的数据库是否连通

telnet 168.61.1.120 3306 

测试结果：新服务器168.61.113.220  连接成功。   生产环境服务器168.61.1.107  连接成功

8、比较服务器公钥信息是否一致（见后面）--------------------------------------------------------------------------------------dxd不是放在准备工作里做，注意拷贝时间，后面有写

另外一台电脑，ssh -T git@服务器iP，查看know_hosts中，新服务器与生产环境服务器的公钥信息是否一致

如不一致，把生产环境服务器 /etc/ssh目录下的文件拷贝至新服务器中。

9、比较 root、appadmin、git用户下，~/.ssh是否一致（还差 git用户下的.ssh拷贝）------------------------------------如果8步骤不放在准备工作里面做，那么此步骤9就也不要放在这里做。也放在后面（徐文杰）

若gitlab服务器 通过ssh连接其他服务器，会保存信息到.ssh目录下，为保持一致，把生产环境中的.ssh拷贝至新服务器下

【正式升级忽略】10、全程使用root账户操作Gitlab服务器——陈兆康20200220

11、安装外部nginx的准备工作----------------------------------------------------------------------------------------------------------------dxd不是在这里做，注意操作时间，后面会写

•      依赖包     make zlib zlib-devel gcc-c++ libtool  openssl openssl-devel   pcre

   缺少依赖包 gcc-c++          yum  install gcc-c++

•   nginx安装包    安装包位置：D:\test\docs\15 工具插件\09 nginx

【正式升级忽略】12、生产环境 /etc/hosts中自定义了域名指向（此处暂不改动）

【正式升级忽略】13、拷贝 生产中的hosts.allow    hosts.deny文件(已拷贝)

14、测试前的准备工作：

• 把生产环境的系统设置截图 setting
• 把生产环境的数据面板截图  overviews-dashboard ,还原后，比较数据是否一致。
• 清除knows_host文件，再次在git客户端上，git clone 生产的仓库。

15、检查 新服务器的git客户端与生产环境的git客户端是否一致 （一致）

检查git客户端版本：git  --version

检查git安装地址：which git

1、卸载系统 （40minutes）

卸载步骤：

第一步：停止gitlab          gitlab-ctl stop

第二步：卸载gitlab（注意这里写的是gitlab-ce）                    rpm -e gitlab-ce

第三步：查看gitlab进程             ps aux | grep gitlab

第四步：杀掉第一个守护进程  kill -9   18777  (就是有带有 - - -的进程)

第五步：再次查看gitlab进程是否存在  ps aux|grep gitlab

第六步：删除所有gitlab文件     

cd /      ;

find  -name   gitlab;         

rm -rf /opt/gitlab

rm -rf /app/gitlab

rm  -rf /etc/gitlab

rm  -rf /var/opt/gitlab

rm -rf /var/log/gitlab

rm   -rf     /run/gitlab/

rm -rf /etc/sysctl.d/90-omnibus-gitlab-*
rm -rf /etc/systemd/system/multi-user.target.wants/gitlab-runsvdir.service
rm -rf /usr/lib/systemd/system/gitlab-runsvdir.service
rm -rf /tmp/gitlab*

第七步：查看gitlab文件是否删除完全   find   /   -name  gitlab

2、安装gitlab 8.10.4（20minutes）

1、检查服务器端口80是否被占用（在修改external_url 时，防止端口无法访问）

netstat -tnlp | grep  80         #  8080  80  8060  8082这些端口都不能被占用

2、rpm -ivh gitlab-ce-8.10.4-ce.0.el7.x86_64.rpm

      gitlab-ctl    reconfigure

      gitlab-ctl   restart

可能存在的问题：

在卸载gitlab然后再次安装执行sudo gitlab-ctl reconfigure的时候往往会出现：ruby_block[supervise_redis_sleep] action run，会一直卡无法往下进行！

解决方案 展开源码

3、检查gitlab http访问是否正常   http://168.61.113.220。

4、替换配置文件/etc/gitlab/gitlab.rb 

• 把原gitlab.rb 备份  cp   gitlab.rb   gitlab.rb.bak
• 替换新的gitlab.rb   

           注：拷贝gitlab.rb后注意权限，原gitlab的文件权限如下：[即最终的gitlab.rb权限如下图所示——陈兆康20200219]

5、替换完成后

•  修改external_url 地址。

•  修改LDAP的host地址

把   host  168.61.11.6   改为： host  addev.test.com.cn

重新加载配置文件，并重启

gitlab-ctl reconfigure
gitlab-ctl restart

6、替换hooks文件   ------------------------------------------------------------------------------dxd 这里的hook要重新改掉了，直接用gitlab2 的 168.63.66.139的 

• 把生产环境中的  /opt/gitlab/embedded/service/gitlab-shell/custom_hooks 拷贝至新服务器中。
• 把生产环境//opt/gitlab/embedded/service/gitlab-shell/hooks 拷贝至新服务器中。

            注：配置完成后并不需要 gitlab-ctl reconfigure

• gitlab-ctl   restart

7、测试http访问是否成功。

• 首次http访问gitlab，创建root mm
• gitlab是否可用，ldap账号是否可用
• 新建项目

3、数据迁移（ 3hours(备份) +85minutes(传输) +3hours(还原)=7.5hours ）

0、关闭生产环境gitlab的nginx,和sshd，防止备份过程中有数据写入

gitlab-ctl  stop  nginx    (防止用户通过http写入)

systemctl  stop  sshd   (防止用户通过ssh写入)

注

已验证，当nginx和sshd关闭后，用户无法通过http 和ssh访问gitlab

已验证，当nginx和sshd关闭后，gitlab可以正常备份

1、在生产环境服务器上，对整体项目进行打包备份

gitlab-rake gitlab:backup:create SKIP=artifacts,uploads,builds ---------------------------------------研究下这个命令这些skip有无影响？？？？？正式升级是否是这样------正式升级不skip，全量。

gitlab-rake gitlab:backup:create SKIP=artifacts

解释

完全备份包含以下：

db       数据库                         uploads 附件                                  repositories 代码库

builds  CI作业输出日志          artifacts CI工件                               lfs  LFS对象

registry  注册图片                  pages  页面内容

2 、在生产环境服务器上，把打包文件 拷贝至新服务器上/app/gitlab/backups上（是把/app/tools/下面的那个400多g的文件拷贝到backups文件夹）

scp 1581411722_gitlab_backup.tar appadmin@168.61.113.220:/app/gitlab/backups/

[服务器上只保留/app/gitlab/backups/目录下的生产数据备份包——陈兆康20200219]

scp时注意终端不要锁死了。-----------dxd

注意

为防止scp过程中，终端掉线导致scp失败。或者防止后期的升级过程中，因为终端掉线导致无标准输出，我们使用screen环境来进行操作。

screen 可以看做是窗口管理器的命令行界面版本，在Screen环境下，所有的会话都独立的运行，并拥有各自的编号、输入、输出和窗口缓存。即使终端窗口关闭了，也可以通过screen进行还原。

screen 安装 ：yum  install  screen

新建session：screen  

还原到session:  screen  -r  [session id]

关闭session :exit

3、在新服务器上停部分应用

gitlab-ctl stop unicorn

gitlab-ctl stop sidekiq
gitlab-ctl stop nginx

4、在新服务器上，修改备份文件的权限

chmod  777 1581411722_gitlab_backup.tar

5、在220服务器上，导入备份文件（注意：导入前检查剩余磁盘空间是否拥有 600G的容量）

gitlab-rake gitlab:backup:restore BACKUP=1581411722（这个数字改成安装包最后的数字，不要直接用这个数字）

还原会把sshkey还原回去的。

还原过程中，会弹出这两个提示，输入yes即可。

6、检查/etc/gitlab/gitlab.rb 中的url是否正确， 重载配置文件，并重启gitlab

gitlab-ctl reconfigure
gitlab-ctl restart、

7、gitlab hook的全局配置：-------------------------------------------------------------------------------------------------------------------20200414这条不做。dxd

• 把生产环境中的  /opt/gitlab/embedded/service/gitlab-shell/custom_hooks 拷贝至新服务器中。
• 把生产环境//opt/gitlab/embedded/service/gitlab-shell/hooks 拷贝至新服务器中。

            注：配置完成后并不需要 gitlab-ctl reconfigure

• gitlab-ctl   restart

7.1 修改新服务器中的hooks文件（并不需要把对应hook改为链接文件）

在还原过程中，有些仓库，在生产中hook是链接文件，但在新服务器缺不是，故需要修改对应的hooks文件。修改步骤：

第一步：在生产环境中，执行 /app/tools/check_hooks.sh  ,   文件107info 保存是内容是： hooks是链接文件的仓库

第二步：把107info 拷贝到新服务器的 /app/tools下，并对其授权  chmod 666 107info

第三步：切换git用户，执行 /app/tools/update_hooks.sh,  对仓库中非链接文件的hooks进行修改

第四步：执行/app/tools/check_hooks.sh，比较info 与 107info， 比较新服务器的链接文件hooks的仓库与生产是否一致。

第五步：检查 /opt/gitlab/embedded/service/gitlab-shell/hooks 目录是否存在，文件是否存在。

7.2 还原会把系统设置还原回去 把107的系统配置事先截好图，然后220导入后完全按着配。---------------------------------------------------------------------dxd20200414文杰回一下这条是不是导入数据后就已经变成和107一样了，如果是，这条直接忽略不做------已核实，导入数据后，测试环境的系统设置与生产环境一致。（徐文杰）

简单测试验证---------------------------------------------------dxd20200414正式升级不做

1、验证http访问，登录是否成功

1、验证git add、commit、push是否成功

4、升级

升级路径：8.10.4 ->8.12.0-> 8.17.8 ->9.5.10 ->10.8.7 ->11.11.8 →12.0.0 → 12.4.2

升级至 8.12.0    （不要升级到8.12.0，直接升级到8.17.8版本，升级到8.12.0版本出错-------徐文杰）
rpm -Uvh gitlab-ce-  ------------------------------------------------------------dxd命令补一下

报错：

解决办法：

尝试：chmod a+x /app/gitlab/git-data

          chmod 2770  /app/gitlab/git-data/repositories

/ data文件夹需要为777，重新配置会将/ data / GitLab文件夹更改为700，并由'git'用户拥有

gitlab-ctl restart

登一下网址看能不能登录进去

升级至 8.17.8
rpm -Uvh gitlab-ce-8.17.8-ce.0.el7.x86_64.rpm  （15minutes）

gitlab-ctl reconfigure
gitlab-ctl restart

登一下网址看能不能登录进去

升级至 9.5.10 
rpm -Uvh gitlab-ce-9.5.10-ce.0.el7.x86_64.rpm  （20minutes (升级) +10 minutes（reconfigure））
gitlab-ctl reconfigure
gitlab-ctl restart

登一下网址看能不能登录进去

vi /etc/gitlab/gitlab.rb --------------------------------------------------------------------------------写错了，9-10版本才需要改配置。这里不需要。
git_data_dirs({"default" => "/app/gitlab/git-data"})

修改为：

git_data_dirs({
"default" => {
"path" => "/app/gitlab/git-data"
}
})

gitlab-ctl reconfigure
gitlab-ctl restart

升级至 10.8.7

1、rpm -Uvh gitlab-ce-10.8.7-ce.0.el7.x86_64.rpm   1h

 此次升级过程会很久，当过了1个小时后，如果还卡在这，直接ctrl+c 

2、再次 rpm -Uvh gitlab-ce-10.8.7-ce.0.el7.x86_64.rpm  （因为已经升级完成了，再次执行这个并不会受影响，只是确保 确实升级到了10.8.7版本了）

3、gitlab-ctl restart   [在浏览器上，gitlab 并不能打开]

4、gitlab-ctl  reconfigure     30minutes

5、gitlab-ctl  restart

因为reconfigure 会time  out ,故修改此配置文件 /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/chef-14.13.11/lib/chef/provider/execute.rb ，把3600 改为 18000

8

升级至11.11.8  【30minutes】

rpm -Uvh gitlab-ce-11.11.8-ce.0.el7.x86_64.rpm

gitlab-ctl reconfigure

gitlab-ctl restart

登一下网址看能不能登录进去

升级至12.0.0  【30minutes】

rpm -Uvh gitlab-ce-12.0.0ce.0.el7.x86_64.rpm

gitlab-ctl restart

登一下网址看能不能登录进去

升级至12.4.2  [20minutes]

rpm -Uvh gitlab-ce-12.4.2-ce.0.el7.x86_64.rpm

gitlab-ctl reconfigure

gitlab-ctl restart

登一下网址看能不能登录进去

★ 关闭alertmanager     在gitlab.rb   添加：alertmanager['enable'] = false         ##在最后一行加

到此结束！！

5、简单验证-------------------------------------------------dxd新增

按照测试方案，进行重点操作。------（进行简单的测试add,push及浏览器访问。在步骤 9，进行全量、重点测试）

6、安装外部nginx -------------------------------------ssh key拷贝顺序调整为这个之后

1、停止gilab和内部nginx

• 停止gitlab    gitlab-ctl   stop
• 检查内部 nginx    ps  -ef | grep nginx
• 检查80端口是否没有被占用   netstat  -tnl | grep 80
• 检查gitlab 是否停止了。  通过浏览器访问不了gitlab

2、安装外部nginx

•  检查依赖包是否存在（详见 准备工作 11）  ----------------------------------------dxd准备工作11挪到这里做
• 检查nginx 用户，和组是否存在。  cat  /etc/passwd   |grep "nginx"         cat  /etc/group   |grep "nginx"   
• 把nginx安装包拷贝至/app目录下，解压 tar  -xvf  nginx.tar.gz
• 编译安装

           ./configure   --prefix=/usr --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx/nginx.pid --lock-path=/var/lock/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_gzip_static_module --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-http_stub_status_module --with-pcre   --with-stream

           make

           make  install 

• 启动nginx，并检查端口是否被监听

              nginx

             ps   -ef | grep nginx

            netstat  -tnl |grep 80

如果启动报错：

解决办法：https://blog.csdn.net/lzxlfly/article/details/80365817

•    gitlab中内部nginx ，与外部nginx的路径比较

3、修改sshd默认端口

把默认端口22 更改为 23

vi /etc/ssh/sshd_config

把22改为23. 以后通过ssh  登录nginx需要指定端口       ssh      ip  23

重新启动 sshd

service  sshd   restart

4、修改nginx 配置文件    

在/etc/nginx/nginx.conf 中,配置转发http模块，用于转发http 和 添加tcp模块配置，用于转发ssh.

分别编辑/etc/nginx/nginx.conf      和/etc/nginx/developll/gitlab.conf

已仿照 /etc/nginx/develop/gitlab.conf  进行配置----------------------------------------------------dxd nginx的模式能否改成/etc/nginx/develop/gitlab.conf 这种模式，其中nginx的基本配置模仿115的配置，便于今后统一迁移

具体配置文件如下：----------------------------------------dxd tcp模块和hhtp的IP地址记得到时候改掉

nginx.conf

gitlab.conf

5、重启NGINX

/usr/sbin/nginx -t     #检查配置是否正确

/usr/sbin/nginx  -s  stop        ##关闭nginx

/usr/sbin/nginx    #启动nginx

7、拷贝生产环境的那些ssh key-----------------------------dxd

把生产的/etc/ssh，各用户下的.ss拷贝至新服务器下

/etc/ssh :  

1、把生产的/etc/ssh拷贝到 新服务器的tools/etc_ssh目录下

scp –r   /etc/ssh   appadmin@IP:/app/tools/etc_ssh

2、把新服务器的/etc/ssh备份  cp -r /etc/ssh   /app/tools/etc_ssh.bak

3、覆盖/etc/ssh   cp  /app/tools/etc_ssh/ssh/*  /etc/ssh

(覆盖后，再修改/etc/ssh到原来的权限)  

/root/.ssh  和/etc/ssh的拷贝方法一致

/var/opt/gitlab/.ssh   和/etc/ssh的拷贝方法一致

/home/appadmin/.ssh   和/etc/ssh的拷贝方法一致

8、修改gitlab.rb  

1、修改gitlab配置文件

vi  /etc/gitlab/gitlab.rb

gitlab-ctl  reconfigure 

gitlab-ct restart

检查 /var/opt/gitlab/nginx/conf/gitlab-http.conf   中的server name是否为域名

5.3检查系统配置，结合之前107的系统配置截图，检查整体系统配置（如限制私有仓库等）---------------------------------dxd 系统配置重新检查一遍

5.4 禁用外部头像

现阶段头像是由外网http://www.gravatar.com/avatar/%{hash}?s=%{size}&d=identicon 自动生成的。

当linux服务器无法访问此网站，头像就无法生成。

解决方案一：禁用gravatar.

管理员登录-setting-gennral-Account and limit

5.5 禁用自动 pipeline

系统设置-CD    不勾选默认自动 pipeline

9、验证

参考兆康给的测试方案进行详细测试

详见：  Gitlab升级测试方案       

除了这个方案还有些额外的：-------------------------------------------------------------------------------------------------dxd

3、gitlab与fisheye集成（已完成）

fisheye通过无身份验证方式（no authentication）添加gitlab库。 

需要的操作：

   a、无身份验证方式，需要把fisheye的公钥添加至git服务器中。/var/opt/gitlab/.ssh/authorized_keys

      详情见：https://confluence.atlassian.com/fisheye/authentication-960155500.html

      因为gitlab还原时，会把此公钥信息还原至此文件中。故不需要再进行修改添加。

   b、fisheye需要ssh分别连接一次 nginx服务器，以及gitlab服务器。使know_hosts保存目标服务器信息。

     ssh   appadmin@gitlabIP

     ssh  appadmin@nginxIP

验证方式：

在fisheye上添加共有和私有仓库。

5、与其他服务器存在交互的定时任务（未解决）---可以解决

1、克隆的gitlab服务器存在与其他服务器交互的定时任务  git_start.py

2、新服务器中的 定时脚本git_start.py 不确定能否成功执行

解决方案：

1、在克隆前 把生产环境gitlab的  定时任务git_start.py  注释掉。克隆完成后再把生产环境的定时任务打开。

2、克隆的新服务器 测试能否telnet  成功。  

6、头像无图片（未解决）

现阶段头像是由外网http://www.gravatar.com/avatar/%{hash}?s=%{size}&d=identicon 自动生成的。

当linux服务器无法访问此网站，头像就无法生成。

解决方案一：禁用gravatar.

管理员登录-setting-gennral-Account and limit

解决方案二：网络管理员对gitlab服务器开通 访问http://www.gravatar.com/avatar

回滚方案

• 在生产环境中停止外部nginx   nginx -s  stop
• 把ssh端口改回为默认的22

                vi /etc/ssh/sshd_config

            重新启动 sshd

            service  sshd   restart

• 测试 git  clone  git@....git能否成功。    

 正式放弃升级后记得把220的ssh key还原回去---------------------------------------------------------------------dxd

************************************************************************************以下遗留问题应不会发生******************************************************************************************************

遗留问题：

1、gitlab与Jenkins集成，遇到的问题（遗留问题）

现象：在Jenkins中新建一个工程，源码连接新的gitlab系统。构建不成功。

原因：因为Jenkins的job是在各自的环境中运行，job的运行环境。ssh/known_hosts没有保存新gitlab的公钥，首次连接需要输入yes。

解决办法：

办法1：测试连接    ssh -T git@github.com     按提示输入yes

办法2：在job的运行环境中，连接新的gitlab，第一次连接时需要手动输入yes以确定连接。这样新gitlab的公钥就保存在 本地运行环境中。可以提前在各节点上修改known_hosts

在known_hosts文件中添加以下两行，

办法2：把生产/etc/ssh拷贝到 220中

2、gitlab与fisheye集成（已完成）

fisheye通过无身份验证方式（no authentication）添加gitlab库。 

需要的操作：

   a、无身份验证方式，需要把fisheye的公钥添加至git服务器中。/var/opt/gitlab/.ssh/authorized_keys

      详情见：https://confluence.atlassian.com/fisheye/authentication-960155500.html

      因为gitlab还原时，会把此公钥信息还原至此文件中。故不需要再进行修改添加。

   b、fisheye需要ssh分别连接一次 nginx服务器，以及gitlab服务器。使know_hosts保存目标服务器信息。

     ssh   appadmin@gitlabIP

     ssh  appadmin@nginxIP

验证方式：

在fisheye上添加共有和私有仓库。

3、gitlab server hook（待评估）-----待讨论                                                                                    ---------------------------------------------------直接用gitlab新的hook进行验证，一个是cust的一个是本地的

把生产环境中的  /opt/gitlab/embedded/service/gitlab-shell/custom_hooks 拷贝至新服务器中。

把生产环境//opt/gitlab/embedded/service/gitlab-shell/hooks 拷贝至新服务器中。

注：配置完成后并不需要 gitlab-ctl reconfigure

5、与其他服务器存在交互的定时任务（未解决）---可以解决

1、克隆的gitlab服务器存在与其他服务器交互的定时任务  git_start.py

2、新服务器中的 定时脚本git_start.py 不确定能否成功执行

解决方案：

1、在克隆前 把生产环境gitlab的  定时任务git_start.py  注释掉。克隆完成后再把生产环境的定时任务打开。

2、克隆的新服务器 测试能否telnet  成功。  

6、头像无图片（未解决）

现阶段头像是由外网http://www.gravatar.com/avatar/%{hash}?s=%{size}&d=identicon 自动生成的。

当linux服务器无法访问此网站，头像就无法生成。

解决方案一：禁用gravatar.

管理员登录-setting-gennral-Account and limit

解决方案二：网络管理员对gitlab服务器开通 访问http://www.gravatar.com/avatar

报错解决办法：

报错1：

需要依赖包 policycoreutils-python

解决方案：

依赖包安装：yum install   policycoreutils-python

打开网页提示：

译为：

已启用自动DevOps管道，如果找不到其他CI配置文件，将使用该管道。更多信息       设置|关闭

此GitLab实例上未启用容器。请让管理员启用它，以便AutoDevOps工作。

解决方案：

Gitlab Container registry介绍：

通过将GitLab Container Registry集成到GitLab中，每个项目都可以拥有自己的空间来存储其Docker镜像。

此为11的新特性，如果要不需要此新特性，直接 Dismss关闭即可。