С обновление Gitlab есть небольшие нюансы. Если вы не обновляетесь регулярно, то в какой-то момент спустя несколько релизов не сможете это сделать штатно через пакетный менеджер и репозиторий. Необходимо соблюдать определенную последовательность этапов обновления. Об этом я подробно расскажу далее.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Некоторое время назад мне понадобилось обновить устаревшую версию Gitlab 12.7.5, установленную в Centos 7 из репозитория разработчиков. Для начала попробовал просто сделать yum update в надежде, что все произойдет само, но чуда не случилось. В репозитории последней версией уже была 14-я, а на нее так просто не перейти. Я получил ошибку:
gitlab preinstall: It seems you are upgrading from major version 12 to major version 14. gitlab preinstall: It is required to upgrade to the latest 13.0.x version first before proceeding. gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/README.html#upgrade-paths
Делать нечего, пошел читать документацию. Там четко прописана последовательность, по которой нужно обновляться, чтобы получить самую последнюю версию. В моем случае цепочка обновлений получалась следующая: 12.7.5 -> 12.9.2 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.10 -> 14.0.11 -> 14.1.6. Обязательно делаем бэкап и приступаем к обновлению gitlab до последней версии.
Для того, чтобы установить конкретную версию, используем следующую команду yum:
# yum install gitlab-ee-12.9.2-ee.0.el7.x86_64
И так далее для всех остальных релизов.
# yum install gitlab-ee-12.10.14-ee.0.el7.x86_64 # yum install gitlab-ee-13.0.14-ee.0.el7.x86_64 # yum install gitlab-ee-13.1.11-ee.0.el7.x86_64 # yum install gitlab-ee-13.8.8-ee.0.el7.x86_64 # yum install gitlab-ee-13.12.10-ee.0.el7.x86_64 # yum install gitlab-ee-14.0.11-ee.0.el7.x86_64
После этого на момент написания статьи до самой последней версии можно обновиться штатно:
# yum update gitlab-ee
Если после написания статьи выйдут следующие промежуточные версии, просто добавьте их в цепочку обновлений в соответствии с таблицей в документации. Сам принцип обновления gitlab будет такой же.
С ошибкой я столкнулся только при обновлении gitlab с версии 14.0 до 14.4. Ошибка связана с миграциями базы данных и описана в документации - Batched background migrations. Текст ошибки примерно такой:
StandardError: An error has occurred, all later migrations canceled: Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active': {:job_class_name=>"CopyColumnUsingBackg roundMigrationJob", :table_name=>"push_event_payloads", :column_name=>"event_id", :job_arguments=>[["event_id"], ["event_id_convert_to_bigint"]]}
В тексте ошибки представлено решение в виде завершения миграции вручную. Но это не сильно поможет, так как при следующем запуске будет эта же ошибка, только с другой миграцией. Я попробовал раза 3-4 проделать это вручную, но не помогло. Пошёл читать статью, там всё есть. Вам надо посмотреть, если у вас незавершённые миграции. Для этого выполните:
# gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
Если получите число больше нуля, значит какие-то миграции не завершены. Завершите их:
# gitlab-rails c > scheduled_queue = Sidekiq::ScheduledSet.new > pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq > pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }
Напоминаю, что это информация доступна по ссылке выше. Там всё подробно описано. После этого выполняем:
# gitlab-rake db:migrate # gitlab-ctl reconfigure # gitlab-ctl restart
После этого gitlab версии 14.4 нормально запустился.
Так же после обновления gitlab с более старых версий вы можете увидеть предупреждение о том, что можно обновить версию postgresql до 12 или выше. Автоматически база данных не обновляется. Инструкция по ее обновлению так же есть в документации. Для этого существует команда:
# gitlab-ctl pg-upgrade
Она все сделает сама, обновив postgresql до последней поддерживаемой версии. Результатом успешного обновления базы gitlab будет примерно следующее сообщение.
==== Upgrade has completed ==== Please verify everything is working and run the following if so sudo rm -rf /var/opt/gitlab/postgresql/data.11 sudo rm -f /var/opt/gitlab/postgresql-version.old
Вот и все. Мы полностью обновили gitlab через несколько релизов до самой последней версии. Удивительно, как такой масштабный и многокомпонентный продукт как gitlab так четко обновляется. Сколько с ним работаю, никогда не сталкивался с проблемами во время обновления. При этом постоянно опасаюсь, как бы что-нибудь не пошло не так. Так что бэкапы перед обновлением обязательно должны быть и желательно всей виртуалки.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Статья немного устарела. Есть официальная дорожная карта по обновлению через несколько версий: https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/
Простого `gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'` уже недостаточно. Надо ещё дёргать `gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigration::BatchedMigration.queued.count'` и ждать, когда оба выхлопа будут выплёвывать 0.
Статья писалась под обновление конкретных релизов как раз по документации. Для более свежих версий нужно смотреть актуальные рекомендации. А по старым релизам, если они ещё остались, должно работать, как описано.
Вобщем если всегда дожидаться окончания фоновых процедур миграции, то ничего не ломается и фиксить не нужно. Это можно смотреть в дэшборде в мониторинге. Тоже самое и обновлением БД. Один раз только нужно ее ребутнуть было, чтобы применилась уже обновленная.
А не пора ли катнуть обновление твоей 14.4 до 15.8
и обновить эту статью?
https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/?current=12.7.5&target=14.1.8&edition=ce на всякий ссыль чтобы корректно цепочку составить
А подскажите, у меня на Oracle Linux 7(Centos 7), gitlab-ce 11.4.3.
Моя цепочка обновлений тогда
1) 11.4.3 -> 11.5.0
2) 11.5.0 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.2.10
2) 13.10.2 -> 13.12.15 -> 14.0.12 -> 14.6.2
Верно?
Обновился
11.4.3 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15 -> 14.0.12 -> 14.8.3
Вроде всё ок, при обновлении ошибок не было.
Сорри, ответил сам себе, а имя не указал и потому кажется, что ответил кто-то другой )
Срочно обновляйте, там эксплойт в старых версиях. Словили майнер.
P.S. обновился, без особых проблем. но на версии 14.0.11 сначала подождал, пока завершатся миграции в вашдомен.ру/admin/background_migrations
потом через apt upgrade обновил до последней 14.4.2.
После каждого промежуточного обновления вводил gitlab-ctl reconfigure, затем проверял версию в вашдомен.ру/help.
Пару раз обновлял БД через gitlab-ctl pg-upgrade, установщик заранее оповещал об этом.
И ещё, требовалось обновить ключ репозитория:
# Download the new key
curl "https://gitlab-org.gitlab.io/omnibus-gitlab/gitlab_new_gpg.key" -o /tmp/omnibus_gitlab_gpg.key
# Import the key
## Debian/Ubuntu/Raspbian
sudo apt-key add /tmp/omnibus_gitlab_gpg.key
# CentOS/OpenSUSE/SLES
sudo rpm --import /tmp/omnibus_gitlab_gpg.key
И ещё бы добавил, для версии 14.4.0 требуется более свежий гит, но он сам обновился
(обновлялся с 12.7.х)
Сегодня обновился с 14.0.11 до 14.4.1. Уже никаких дополнительных действий не требуется. Обычным apt upgrade gitlab-ce все обновилось. Видать поправили они там что-то. До этого при прошлой попытке обновления тоже встречался с ошибками. Тогда откатился обратно на 14.0.11
А как штатная процедура отката выглядит? Никогда не пользовался. Обычно сразу виртуалку бэкаплю и откатываюсь, если нужно.
https://docs.gitlab.com/ee/update/package/downgrade.html