Upgrade of Gitlab from 9.2.2 to 11.10.

1. Backup

For details on backup and recovery operations, please refer to my other blog: Gitlab Backup and Recovery.
Before starting the upgrade, be sure to make a backup and record the version number.
1. Check the current version number of Gitlab

[root@gitlab ~]# cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
9.2.2

2. Back up the current Gitlab

gitlab-rake gitlab:backup:create

A backup file will be generated under /var/opt/gitlab/backups such as: 1557218709_2019_05_07_9.2.2_gitlab_backup.tar, where 1557218709 is the version number of the backup.

Two, upgrade

Note: The upgrade of Gitlab cannot span the major version number, so you can only upgrade to the current major version number to the highest version before upgrading to the next major version number.
Since my current version number is 9.2.2, I want to upgrade to the latest version 11.10.4. The upgrade steps are as follows:
9.2.2—>9.5.9—>10.8.7—>11.10.4
1. Prepare the relevant rpm package

wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-9.5.9-ce.0.el7.x86_64.rpm
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-10.8.7-ce.0.el7.x86_64.rpm
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.10.4-ce.0.el7.x86_64.rpm

2. Follow the instructions below to upgrade step by step. After each step of the installation is successful, if you find the interface 500, this is because the redis and other programs have not been fully started, wait for a while to access it. (Be sure to ensure that the data can be accessed normally before executing the next upgrade instruction)

yum localinstall -y gitlab-ce-9.5.9-ce.0.el7.x86_64.rpm
yum localinstall -y gitlab-ce-10.8.7-ce.0.el7.x86_64.rpm
yum localinstall -y gitlab-ce-11.10.4-ce.0.el7.x86_64.rpm

After completion, check the current version:

[root@gitlab ~]# cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
11.10.4

At this point, the upgrade of Gitlab is complete, hurry up and experience the new version! !

 

Change the storage location of the gitlab warehouse

When changing the
default warehouse storage location , the GitLab warehouse storage location is "/var/opt/gitlab/git-data/repositories". In the actual production environment, obviously we will not store it in this location. Generally, we will divide a separate partition for storage. For warehouse data, I plan to store the data in the "/data/git-data" directory here.

root@test1:~/tools# mkdir -pv /data/git-data 
mkdir: created directory "/data"
mkdir: created directory "/data/git-data"
root@test1:~# chown -R git. git /data/git-data
#Modify the owner and group of the created directory to git user  root@test1:~/tools# cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak 
root@test1 :~/tools# vim /etc/gitlab/gitlab.rb #Enable the 
git_data_dirs parameter and modify it as follows: 
git_data_dirs path "/data/git-data"

git_data_dirs({
   "default" => {
     "path" => "/data/git-data",
     "failure_count_threshold" => 10,
     "failure_wait_time" => 30,
     "failure_reset_time" => 1800,
     "failure_timeout" => 30
    }
 })

#And modify the value of external_url to the planned access domain name 
external_url'http
://test.gitlab.net ' root@test1:~/tools# gitlab-ctl reconfigure #Recompile the gitlab.rb file and use the modifications to take effect 
again After editing, GitLab will automatically create a repositories file in the warehouse directory, as follows: 
root@test1:~# ls -ld /data/git-data/repositories/ 
drwxrws--- 2 git git 4096 January 4 14:15 /data /git-data/repositories/

 

Modify GITLAB default port

端口要用9090以后的最好，否则不生效
默认情况下：unicorn会占用8080端口，nginx会占用80端口。改完之后，就可以通过nginx[‘listen_port’] 在浏览器进行访问了。
内部8080端口也不再被占用了。

修改 /etc/gitlab/gitlab.rb 文件如下，然后执行重新配置，重启命令后完成。
gitlab-ctl reconfigure  //让配置生效，重新执行此命令时间也比较长
gitlab-ctl restart

 

Solve the problem that GITLAB cannot start runsv no running

You can try it first  

systemctl start gitlab-runsvdir.service

If it freezes, you need to check the system service items

systemctl -t target

If the system is normal, all tasks should be loaded active active. If there is an inactive dead option, it means that some services have gone wrong.

UNIT                   LOAD   ACTIVE SUB    DESCRIPTION
basic.target           loaded active active Basic System
cloud-config.target    loaded active active Cloud-config availability
cloud-init.target      loaded active active Cloud-init target
cryptsetup.target      loaded active active Encrypted Volumes
getty.target           loaded active active Login Prompts
graphical.target       loaded active active Graphical Interface
local-fs-pre.target    loaded active active Local File Systems (Pre)
local-fs.target        loaded active active Local File Systems
multi-user.target      loaded active active Multi-User System
network-online.target  loaded active active Network is Online
network-pre.target     loaded active active Network (Pre)
network.target         loaded active active Network
nss-user-lookup.target loaded active active User and Group Name Lookups
paths.target           loaded active active Paths
remote-fs-pre.target   loaded active active Remote File Systems (Pre)
remote-fs.target       loaded active active Remote File Systems
slices.target          loaded active active Slices
sockets.target         loaded active active Sockets
swap.target            loaded active active Swap
sysinit.target         loaded active active System Initialization
time-sync.target       loaded active active System Time Synchronized
timers.target          loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

22 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

multi-user.target      loaded inactive dead   start Multi-User System

 

Use this time

 systemctl list-jobs

If there is a task that is running, it is the task that blocks all other services. 

 1 graphical.target                     start waiting
107 plymouth-quit-wait.service           start running
  2 multi-user.target                    start waiting
169 ureadahead-stop.timer                start waiting
121 gitlab-runsvdir.service              start waiting
151 system-getty.slice                   start waiting
 31 setvtrgb.service                     start waiting
122 systemd-update-utmp-runlevel.service start waiting

 

At this point, you can use systemctl stop plymouth-quit-wait.service to end the task.

Then restart gitlab.

 

Uninstall GitLab

1. Stop gitlab

gitlab-ctl stop

• 1

1. Uninstall, see if your gitlab version is ce or ee

rpm -e gitlab-ce

1. Kill process

ps -ef|grep gitlab //查看进程

•  

Kill the process marked in the figure

kill -9 2287

1. Delete gitlab file

find / -name *gitlab*|xargs rm -rf 
find / -name gitlab |xargs rm -rf

1. Delete files backed up under root, first check

ls /root/gitlab*

If there is no need to delete, delete if there is

This is uninstalled!