Обновление с 13.8.4 до N-1 (16.11.7). Да уже вышел релиз 17.0.z, но его мы будем игнорировать до выхода 17.1.z. Так же релиз 16.11.z является актуальным. Для избежание проблем как это было в некоторых версиях когда установив обновление, следующее обновление требует серьезного вмешательства, устанавливаем только те релизы, что уже 100% являются стабильными и более не обновляются, в данном случае это релиз 16.11.7 будет финальной целью нашего обновления. Если же вы уверены в стабильности более свежи релизов, то можете обновляться.

Процедура обновления выглядит безобидной, если она выполняется регулярно. Когда обновления выполняются крайне редко, то есть особенности, которые требуется выполнить.

Важно помнить, обновление 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.7

GitLab 17: 17.0.z

 

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

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

Особенности обновления некоторых версий

Завершение фоновых миграций

Если при выполнении получаем значение больше нуля

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

В процессе обновления внимательно смотрите на отчет о состоянии после каждой команды.

Решение проблем

Ошибки 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.