Содержание страницы
Обновление с 13.8.4 до N-2 (17.3.6). Уже вышел релиз 17.5.z, но его мы будем игнорировать до выхода 17.5.3.
Так же релиз 17.3.z является актуальным. Для избежание проблем как это было в некоторых версиях когда установив обновление, следующее обновление требует серьезного вмешательства, устанавливаем только те релизы, что уже 100% являются стабильными и более не обновляются, в данном случае это релиз 17.3.6 будет финальной целью нашего обновления. Если же вы уверены в стабильности более свежи релизов, то можете обновляться.
Процедура обновления выглядит безобидной, если она выполняется регулярно. Когда обновления выполняются крайне редко, то есть особенности, которые требуется выполнить.
Важно помнить, обновление Gitlab требуется выполнять в строгой последовательности. Есть несколько вариантов обновления с минимальными простоями (Zero downtime) и обновление с простоями.
Я буду комбинировать оба метода, в обновлении с простоями есть несколько оговорок касательно обновления 14.X, 15.X, 16.X о которых говорится в каждом документе для обновления. Документ обновления до версии 16.11.7
Необходимо соблюдать определенную последовательность этапов обновления. Об этом я подробно расскажу далее.
Карта обновления
GitLab 8: 8.11.Z > 8.12.0 > 8.17.7
GitLab 9: 9.0.13 > 9.5.10
GitLab 10: 10.0.7 > 10.8.7
GitLab 11: 11.0.6 > 11.11.8
GitLab 12: 12.0.12 > 12.1.17 > 12.10.14
GitLab 13: 13.0.14 > 13.1.11 > 13.8.8 > 13.12.15
GitLab 14: 14.0.12 > 14.3.6 > 14.9.5 > 14.10.5
GitLab 15: 15.0.5 > 15.1.6 > 15.4.6 > 15.11.13
GitLab 16: 16.0.8 > 16.1.6 > 16.2.9 > 16.3.7 > 16.7.7 > 16.10.9 > 16.11.10GitLab 17: 17.0.8 > 17.1.8 > 17.2.9 > 17.3.6
15.1.6 для экземпляров GitLab с несколькими веб-узлами
16.0.8 для экземпляров с большим количеством пользователей или большой историей переменных конвейера
16.1.6 для экземпляров для экземпляров
16.2.9 для экземпляров с большой историей переменных конвейера
Некоторые релизы требуют ручного вмешательства и достаточного времени ожидания для конвертации и обновления СуБД. Стоит учитывать, что после обновления для запуска некоторых служб требуется время, одной из таких служб является Sidekiq и Gitlab-shell.
Скачать резизы можно тут https://packages.gitlab.com/gitlab/gitlab-ce/
Немного о командах
gitlab-rake gitlab:env:info – команда собирает информацию о вашей установке GitLab и системе
gitlab-rake gitlab:check SANITIZE=true – проверяет, что каждый компонент был настроен в соответствии с руководством по установке, и предлагает исправления обнаруженных проблем. Используйте SANITIZE=true для исключения имен проектов из вывода
gitlab-rake db:migrate – запуск миграции базы данных
gitlab-ctl reconfigure – переконфигурирование GitLab, после изменения в конфигурации /etc/gitlab/gitlab.rb
gitlab-ctl restart – перезапустить GitLab и все связанные с ним службы
gitlab-ctl pg-upgrade – обновление сервера PostgreSQL до более поздней версии (если она включена в пакет). Команда в новых версиях выполняется автоматически если это не отключено специально
Для некоторых выпусков может потребоваться выполнение различных операций перед обновлением до более новой версии.
Пакетная миграция — это тип миграции, доступный в GitLab 14.0 и более поздних версиях. Фоновая миграция и пакетная миграция — это не одно и то же, поэтому перед обновлением следует убедиться, что обе миграции выполнены.
gitlab-rails runner -e production ‘puts Gitlab::BackgroundMigration.remaining’
gitlab-rails runner -e production ‘puts Gitlab::Database::BackgroundMigrationJob.pending.count’
Процедура обновления
Порядок обновления между большинством релизов будет примерно такой. Да некоторые команды будут избыточны, но далеко не всегда так. Ввиду того, что обновления выполняются на свежей ОС, то все пакеты будут устанавливаться вручную. В качестве примера используется первая версия, что требуется в моей цепочке обновления с версии 13.8.4.
gitlab-rake gitlab:env:info gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining' gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigrationJob.pending.count' cd /root/gitlab wget --content-disposition https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/bionic/gitlab-ce_13.8.8-ce.0_amd64.deb/download.deb apt install -f ./gitlab-ce_13.8.8-ce.0_amd64.deb gitlab-rake db:migrate gitlab-ctl pg-upgrade gitlab-ctl reconfigure gitlab-ctl restart gitlab-rake gitlab:check SANITIZE=true reboot
После обновления до 16.X или 17.X уже имеет смысл обновлять с официального репозитория, затем замораживать пакет во избежание авто обновления
apt install gitlab-ce=17.3.6-ce.0 apt-mark hold gitlab-ce=17.3.6-ce.0
Перезагрузка сервера не является обязательной мерой, но в данном случае используется для того, что бы убедиться в отсутствии проблем при старте ОС, а так же создания снапшота ВМ в консистентном состоянии.
Особенности обновления некоторых версий
Завершение фоновых миграций
Если при выполнении получаем значение больше нуля
gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining' gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigrationJob.pending.count'
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) }
14.3.6
При выполнении команды миграции СуБД, получаем ошибки, в которых четко описано что нужно сделать для ручного завершения миграции, в зависимости от конфигурации, размера СуБД и прочего у все могут потребоваться другие действия для завершения миграции
gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,ci_stages,id,'[["id"]\, ["id_convert_to_bigint"]]'] gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,ci_builds,id,'[["id"\, "stage_id"]\, ["id_convert_to_bigint"\, "stage_id_convert_to_bigint"]]'] gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,ci_builds_metadata,id,'[["id"]\, ["id_convert_to_bigint"]]']
15.0.5
В данном релизе обновляется PostgreSQL до 13 версии, после обновления и проверки работы сервисов требуется удалить старую базу данных
rm -rf /var/opt/gitlab/postgresql/data.12 rm -f /var/opt/gitlab/postgresql-version.old
16.7.7
В данном релизе обновляется PostgreSQL до 14 версии, после обновления и проверки работы сервисов требуется удалить старую базу данных
rm -rf /var/opt/gitlab/postgresql/data.13 rm -f /var/opt/gitlab/postgresql-version.old
В процессе обновления внимательно смотрите на отчет о состоянии после каждой команды.
17.1.0 и 17.1.1
Сбои миграции при обновлении с GitLab 16.x непосредственно до GitLab 17.1.0 или 17.1.1. Из-за ошибки в GitLab 17.1.0 и 17.1.1, из-за которой фоновое выполнение задания не применялось корректно, могут быть сбои при прямом обновлении до GitLab 17.1.0 и 17.1.1.
gitlab-rake gitlab:background_migrations:finalize[BackfillEpicBasicFieldsToWorkItemRecord,epics,id,'[null]']
Решение проблем
Ошибки 500
Первым делом выполняем проверку целостности секретов и подходят ли они
gitlab-rake gitlab:doctor:secrets
Если есть поврежденные/неподходящие, можно пытаться сбросить их. Не забудьте делать бекап, а потом уже сбрасывать секреты.
При сбросе секрета можно потерять данные где он используется. Особенно подвержены Pipeline, так же при обновлении с версию на верную нужно проверять целостность секретов
Определяем, какие секреты сломались/утеряны, DEBUG — : – Group[173]: runners_token
VERBOSE=true gitlab-rake gitlab:doctor:secrets #Group failures: 1 #DEBUG -- : - Group[173]: runners_token
Если нужного секрета нет, то выполняем сброс, сначала советую выполнять с ключем DRY_RUN=true, для определения что нужный секрет будет исправлен, затем измените флаг на DRY_RUN=false.
Group failures
Group failures: 1 Group[1]: runners_token
DRY_RUN=true VERBOSE=true MODEL_NAMES=Group TOKEN_NAMES=runners_token gitlab-rake gitlab:doctor:reset_encrypted_tokens
User failures
User failures: 1 User[1]: static_object_token
DRY_RUN=true VERBOSE=true MODEL_NAMES=User TOKEN_NAMES=static_object_token gitlab-rake gitlab:doctor:reset_encrypted_tokens
Integration failures
gitlab-rails console Integration.update_all(encrypted_properties: nil)
ApplicationSetting
ApplicationSetting[1]: customers_dot_jwt_signing_key, error_tracking_access_token
gitlab-psql UPDATE application_settings SET encrypted_customers_dot_jwt_signing_key = null, encrypted_customers_dot_jwt_signing_key_iv = null, error_tracking_access_token_encrypted = null;
Something went wrong for Group
Something went wrong for Group[1].runners_token: Validation failed: Visibility level private is not allowed since this group contains projects with higher visibility.
Исправить visibility для группы в админке, тк внутри содержатся проекты в большей видимостью. Обычно когда стоит Internal, а внутри есть проекты Public.