Home » Devops » Обновление Gitlab через несколько релизов

Обновление Gitlab через несколько релизов

С обновление Gitlab есть небольшие нюансы. Если вы не обновляетесь регулярно, то в какой-то момент спустя несколько релизов не сможете это сделать штатно через пакетный менеджер и репозиторий. Необходимо соблюдать определенную последовательность этапов обновления. Об этом я подробно расскажу далее.

Углубленный онлайн-курс по MikroTik.

Научиться настраивать 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"]]}

StandardError: An error has occurred, all later migrations canceled

В тексте ошибки представлено решение в виде завершения миграции вручную. Но это не сильно поможет, так как при следующем запуске будет эта же ошибка, только с другой миграцией. Я попробовал раза 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.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

13 комментариев

  1. Статья немного устарела. Есть официальная дорожная карта по обновлению через несколько версий: 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.

    • Статья писалась под обновление конкретных релизов как раз по документации. Для более свежих версий нужно смотреть актуальные рекомендации. А по старым релизам, если они ещё остались, должно работать, как описано.

  2. Аноним

    Вобщем если всегда дожидаться окончания фоновых процедур миграции, то ничего не ломается и фиксить не нужно. Это можно смотреть в дэшборде в мониторинге. Тоже самое и обновлением БД. Один раз только нужно ее ребутнуть было, чтобы применилась уже обновленная.

  3. А не пора ли катнуть обновление твоей 14.4 до 15.8

    и обновить эту статью?

  4. Андрей

    https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/?current=12.7.5&target=14.1.8&edition=ce на всякий ссыль чтобы корректно цепочку составить

  5. А подскажите, у меня на 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

      Вроде всё ок, при обновлении ошибок не было.

      • Сорри, ответил сам себе, а имя не указал и потому кажется, что ответил кто-то другой )

  6. крокодил

    Срочно обновляйте, там эксплойт в старых версиях. Словили майнер.

    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 требуется более свежий гит, но он сам обновился

  7. Сегодня обновился с 14.0.11 до 14.4.1. Уже никаких дополнительных действий не требуется. Обычным apt upgrade gitlab-ce все обновилось. Видать поправили они там что-то. До этого при прошлой попытке обновления тоже встречался с ошибками. Тогда откатился обратно на 14.0.11

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar