Казалось бы, что может будет проще сделай 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 и обратите внимание, что множество вложенных снимков может значительно деградировать производительность виртуальной машины!
Обновление GitLab
Проводим серию последовательных обновлений минорных версий. Обязательно минорных или вы получите ошибку, например в моем случае мы можем шагнуть с текущей версии до 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