Обновление GitLab

Оцените статью

Казалось бы, что может будет проще сделай yum update и все будет замечательно, но как всегда есть нюансы и большую продовую систему можно довольно легко сломать и вас за это точно не похвалят. Поэтому, вам нужен пошаговый план который включает в себя все моменты где что-то пойдет не так, а оно по законам Мерфи так и случится.

Если вы получили сообщение Important notice — Critical patch release, стоит к этому совету прислушаться и обновиться в самое ближайшее время.

Начинаем с обновления списка пакетов в CentOS.

# yum makecache

Есть ли у вас план Мистер Фикс?

План у меня конечно же есть и главное он максимально простой:

Делаем резевную копию средствами гитлаба
Делаем снэпшот виртуальной машины для быстрого отката
Проводим серию последовательных обновлений, на минорные сборки

План простой и казалось бы безотказыный и мы сможем спокойно и последовательно (в моем случае) обновиться, ф текущую установленную версию пакета вы можете посмотреть командой:

# yum --showduplicate list gitlab-ce

Или в случае использования Ubuntu/Debian:

# apt-cache policy gitlab-ce

Теперь думаю, что хватит разговоров и давайте займемся делом.

Резервное копирование и восстановление средствами GitLab

Бэкап средствами гитлаба мы делаем на самый крайний случай, так-как резервные копии создаются автоматически при обновлении пакета гитлаб.

Создаем резервную копию:

# gitlab-backup create STRATEGY=copy

Аналогично, но без артифактов и докер-реджестри:

# gitlab-backup create STRATEGY=copy SKIP=registry,artifacts,lfs

Восстановление из резервной копии выполняется следующей последовательностью команд.

Смена прав доступа к скопированному бэкапу:

# chown git:git /var/opt/gitlab/backups/1630905848_2021_09_06_13.12.3_gitlab_backup.tar

Остановка сервисов использующих базу данных:

# gitlab-ctl stop puma
# gitlab-ctl stop sidekiq

Восстанавливаем архив:

# gitlab-backup restore BACKUP=1630905848_2021_09_06_13.12.3

Реконфигурация, перезапуск тестирование:

# gitlab-ctl reconfigure
# gitlab-ctl restart
# gitlab-rake gitlab:check SANITIZE=true

Создание снимка виртуальной машины

Снимок выртуально машины мы содаем на случай когда мне понадобится быстро откатить нашу VM если обновление пошло не по плану и не заниматься восстановлением из резервной копии которое занимает достаточно много времени.

Снимок создаем средствами VmWare Cloud и обратите внимание, что множество вложенных снимков может значительно деградировать производительность виртуальной машины!

Проводим серию последовательных обновлений минорных версий. Обязательно минорных или вы получите ошибку, например в моем случае мы можем шагнуть с текущей версии до 17.1.8.

Останавливаем сервисы работающие с базой данных:

# gitlab-ctl stop puma
# gitlab-ctl stop sidekiq

Такими итерациями обновляемся до последней стабильной версии. Последовательность обновления:

# yum install gitlab-ce-17.1.8-ce.0.el7
# yum install gitlab-ce-17.2.9-ce.0.el7
# yum install gitlab-ce-17.3.5-ce.0.el7
# yum install gitlab-ce-17.4.2-ce.0.el7

Потенциальные проблемы

Ошибка «Cannot communicate securely with peer: no common encryption algorithm(s).»

В моем случае была связана с тем, что репозитарий GitLab заблокирован на доступ из России в связи с недавними событиями и пришлось использовать прокси в Америке. Для этого в файле /etc/yum.conf прописываем используемый прокси-сервер (в моем случае это Squid на моем VPS).

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
proxy=http://prod-srv-02.bds.su:3128

Проверяем работу через прокси-сервер:

# curl -I -x "http://45.138.27.6:3128" https://packages.gitlab.com/gitlab/gitlab-ce/el/7/x86_64/repodata/repomd.xml

При обновлении до версии 14.10.5 получаем ошибку: Error executing action `run` on resource ‘bash[migrate gitlab-rails database]’

Последовательность действий для устранения ошибки:

# gitlab-rake gitlab:background_migrations:finalize[ProjectNamespaces::BackfillProjectNamespaces,projects,id,'[null\,"up"]']
# gitlab-rake db:migrate
# gitlab-ctl reconfigure