Миграция GitLab с RHEL 6 на RHEL 7 / CentOS 7

Миграция GitLab с RHEL 6 на RHEL 7 / CentOS 7

Миграция GitLab с RHEL 6 на RHEL 7 / CentOS 7

Недавно мы были на перекрестке. Мы не знали, можем ли мы оставить старый сервер GitLab версии 10.2.1-ee работающим на RHEL 6 и начать заново на новом сервере GitLab, или мы могли бы перенести все репозитории в новый экземпляр. Изучив статьи и документацию, мы обнаружили, что у GitLab есть собственные инструменты CLI, которые могут создавать резервные копии и восстанавливать контент прямо из коробки, и это было большим облегчением. Добившись успеха, мы сочли целесообразным задокументировать это здесь, чтобы все желающие могли следить за ним.

В первую очередь для того, чтобы произошла миграция, версии GitLab должны совпадать на обоих серверах, поэтому мы решили обновить старую версию GitLab версии 10.2.1-ee в RHEL 6 шаг за шагом до версии 13.5.4-ee , последней доступен для RHEL 6 в репозиториях GitLab. Спасибо команде GitLab за поддержку репозиториев после EOL RHEL 6. Процесс обновления был болезненным, но хорошо то, что они работали. Вот несколько проблем, особенно скачок с версии 12 на 13.

Во всем опыте следует отметить изменение одной из основных программ GitLab с версии 12 на 13, как было упомянуто выше. Предыдущий веб-сервер GitLab, известный как « единорог », заменяется новым, известным как Puma . Это привело к нескольким ошибкам, потому что Puma не включается во время процесса обновления, который будет обсуждаться.

Шаг 1. Пошаговое обновление

На первом этапе мы решили обновить GitLab с версии 10.2.1-ee до версии 13.5.4-ee . Это дорожная карта версий, которые мы прошли в RHEL 6. Вы можете выбрать другой маршрут.

10.2.1-> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.5.4

Ниже приведены примеры команд, которые мы использовали для пошагового обновления, вплоть до gitlab-ee-13.5.4-ee.0.el6.x86_64.

sudo yum install gitlab-ee-10.2.1-ee.0.el6.x86_64 -y
sudo yum install gitlab-ee-10.8.7-ee.0.el6.x86_64 -y
sudo yum install gitlab-ee-11.11.8-ee.0.el6.x86_64 -y
sudo yum install gitlab-ee-12.0.12-ee.0.el6.x86_64 -y

При обновлении с 12.10.14-ee до 13.0.14-ee веб-сервер GitLab « unicorn » меняется на « Puma », что вызывает множество ошибок после завершения обновления. Что мы сделали, так это включили « puma » и отключили « unicorn » в GitLab следующим образом:

$ sudo vim /etc/gitlab/gitlab.rb
puma['enable'] = true #Enable puma
unicorn['enable'] = false #Look for this setting or add if it is no there

В случае, если проблемы не исчезнут позже, проверьте, работает ли « единорог », посмотрев на приложение, прослушивающее порт 8080. Если на нем работает единорог, убейте его.

sudo kill -9 PID of unicorn

Позже перезапустите все службы таким образом:

sudo gitlab-ctl restart

Когда мы закончили обновления, пришло время перенести сервер на новую CentOS 7 с установленным сервером GitLab версии 13.5.4-ee . Помните, мы упоминали, что для миграции версии GitLab должны быть одинаковыми. Итак, теперь у нас есть версия 13.5.4-ee в RHEL 6 и такая же версия в RHEL 7 / CentOS 7.

Шаг 2. Резервное копирование содержимого GitLab

Поскольку это сервер RHEL 6, мы не могли ничего обновить или обновить после версии 13.5.4 . Поэтому нам просто нужно было сделать резервную копию этой версии GitLab следующим образом:

sudo gitlab-rake gitlab:backup:create

Был засвидетельствован результат, аналогичный приведенному ниже.

Dumping database ... 
Dumping PostgreSQL database gitlabhq_production ... [DONE]
done
Dumping repositories ...
 * jkibet/peoject-Social-Lending ... [DONE]
 * jkibet/project-Social-Lending.wiki ...  [SKIPPED]
 * jkibet/peoject-Broom ... [DONE]
 * jkibet/peoject-Broom.wiki ...  [SKIPPED]
 * jkibet/QmicaCS-Qmicash ... [DONE]
 * jkibet/QmicaCS-Qmicash.wiki ...  [SKIPPED]
 * jkibet/Qmica-phoneloan ... [DONE]

.......

Creating backup archive: 1628175183_2021_08_05_13.5.4-ee_gitlab_backup.tar ... done
Uploading backup archive to remote storage  ... skipped
Deleting tmp directories ... done

Как только процесс резервного копирования будет завершен, посмотрите каталог « / var / opt / gitlab / backups / », где, мы надеемся, вы найдете свой файл резервной копии в tar-архиве. Как вы уже догадались, этот файл нужно скопировать в новый экземпляр GitLab следующим

Шаг 3. Скопируйте резервный архив и файлы на новый сервер.

В зависимости от ваших потребностей или предпочтений существует несколько способов скопировать файл на новый сервер. Вы можете использовать rsync, scp или другие инструменты на основе графического интерфейса. В этом примере мы сохраним простоту и воспользуемся инструментом, который вы уже установили в Linux. И это scp (Secure Copy). Выполните команду следующим образом. Не забудьте заменить « user » на пользователя вашего сервера.

sudo scp /var/opt/gitlab/backups/1628175183_2021_08_05_13.5.4-ee_gitlab_backup.tar [email protected]:/home/user

Другие файлы, которые нам нужно скопировать на новый сервер, включают следующие: « /etc/gitlab/gitlab.rb » и « /etc/gitlab/gitlab-secrets.json ». Эти файлы содержат конфиденциальные данные, и GitLab позволяет создавать их резервные копии вручную.

sudo scp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json [email protected]:/home/user

Шаг 4. Подготовьте новый сервер к восстановлению

Мы предполагаем, что у вас уже установлен новый сервер GitLab с той же версией, что и ваш старый сервер RHEL 6. В противном случае следующие руководства будут для вас весьма полезны. Когда вы будете готовы, выполните приведенные ниже команды для новой установки в CentOS 7.

curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
sudo yum update -y
sudo yum install pygpgme yum-utils policycoreutils-python openssh-server perl postfix -y
sudo systemctl enable postfix
sudo systemctl start postfix
sudo EXTERNAL_URL="//gitlab.computingforgeeks.com" yum install -y gitlab-ee-13.5.4-ee.0.el7.x86_64

Дайте ему время для установки. Позже вы сможете узнать, все ли службы работают нормально, следующим образом:

sudo gitlab-ctl status

После успешного запуска GitLab остановите следующие службы, прежде чем мы сможем восстановить файлы, которые мы скопировали в них.

sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

Вы можете снова проверить, запущены ли службы, запустив так:

sudo gitlab-ctl status

И вы можете запускать и перезапускать компоненты следующим образом:

# Start all GitLab components
sudo gitlab-ctl start

# Stop all GitLab components
sudo gitlab-ctl stop

Шаг 5: Скопируйте и восстановите резервную копию

Теперь на этом этапе мы собираемся переместить резервную копию, которую мы скопировали на этом новом сервере, в папку резервных копий по умолчанию, откуда GitLab будет читать.

sudo mv /home/user/1628175183_2021_08_05_13.5.4-ee_gitlab_backup.tar /var/opt/gitlab/backups/

Затем предоставьте « git » пользователю и группе права на каталог /var/opt/gitlab/backups/.

sudo chown git:git /var/opt/gitlab/backups/ -R

Если вы помните, мы скопировали некоторые файлы на этот новый сервер, это « gitlab.rb » и « gitlab-secrets.json ». Мы должны заменить те, которые пришли с установкой, на эти. Сделайте резервную копию исходных файлов, а затем замените их теми, которые мы скопировали со старого сервера.

cd /etc/gitlab
#Back up the original files
sudo mv gitlab.rb gitlab.rb-backup
sudo mv gitlab-secrets.json gitlab-secrets.json-backup
#Copy the ones from the old server
sudo cp /home/user/gitlab.rb /home/user/gitlab-secrets.json /etc/gitlab

Как только это будет сделано, мы готовы восстановить наш GitLab. Скрестив пальцы, давайте теперь все восстановим и надеемся, что все работает без проблем. Выполните команду ниже, чтобы восстановить ваши репозитории и базу данных. Обратите внимание, что файл резервной копии был усечен следующим образом. Это было « 1628175183_2021_08_05_13.5.4-ee_gitlab_backup.tar », но в команде его отметка времени — « 1628175183_2021_08_05_13.5.4-ee ». По сути, удалите конечную часть « _gitlab_backup.tar », а затем запустите команду только с отметкой времени.

sudo gitlab-rake gitlab:backup:restore BACKUP=1628175183_2021_08_05_13.5.4-ee

Unpacking backup ...

Во время процесса восстановления вы увидите сообщение ниже в виде подсказки. Просто подтвердите, набрав « да », и пусть GitLab сделает свое дело.

Be sure to stop Puma, Sidekiq, and any other process that
connects to the database before proceeding. For Omnibus
installs, see the following link for more information:
https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-gitlab-installations

Before restoring the database, we will remove all existing
tables to avoid future upgrade problems. Be aware that if you have
custom tables in the GitLab database these tables and all data will be
removed.

Do you want to continue (yes/no)? yes

В конце резервного копирования появится другое приглашение, как показано ниже. Просто введите да, и восстановление должно завершиться успешно.

This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes

После этого запустите команду reconfigure, а затем перезапустите службы GitLab.

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

ok: run: alertmanager: (pid 8132) 0s
ok: run: gitaly: (pid 8143) 1s
ok: run: gitlab-exporter: (pid 8164) 1s
ok: run: gitlab-workhorse: (pid 8168) 0s
ok: run: grafana: (pid 8177) 0s
ok: run: logrotate: (pid 8188) 0s
ok: run: nginx: (pid 8195) 0s
ok: run: node-exporter: (pid 8206) 1s
ok: run: postgres-exporter: (pid 8216) 0s
ok: run: postgresql: (pid 8228) 0s
ok: run: prometheus: (pid 8232) 0s
ok: run: puma: (pid 8247) 0s
ok: run: redis: (pid 8255) 0s
ok: run: redis-exporter: (pid 8261) 0s
ok: run: sidekiq: (pid 8268) 1s

Позже, после того, как все будет успешно восстановлено и заработает, остается только обновить GitLab с 13.5.4-ee до последней версии на момент написания, то есть 14.1.2-ee . Ниже представлена ​​дорожная карта, которую мы использовали. Имейте в виду, что команды запускались не сразу, они выполнялись шаг за шагом, проверяя, что GitLab в порядке при каждом обновлении.

13.9.2 -> 13.12.6 -> 14.0.5 -> 14.1.2

Примеры команд, которые мы выполнили, включают следующее. Как и раньше, мы не запускали команды сразу, а пошагово проверяли, работают ли службы GitLab при каждом обновлении, которое мы сделали.

sudo yum install gitlab-ee-13.9.2-ee.0.el6.x86_64 -y
sudo yum install gitlab-ee-13.12.6-ee.0.el6.x86_64 -y
sudo yum install gitlab-ee-14.0.5-ee.0.el6.x86_64 -y
sudo yum install gitlab-ee-14.1.2-ee.0.el6.x86_64 -y
sudo gitlab-ctl status

Если все работает, войдите в систему с учетной записью администратора, затем нажмите « Меню »> « Админ ». Вы должны увидеть, что ваш GitLab обновлен до последней версии, как показано ниже:

Миграция GitLab с RHEL 6 на RHEL 7

Заключительные счастливые размышления

Долгое путешествие наконец закончилось полностью работающим GitLab вместе с предыдущими пользователями, их учетные данные и проекты остались нетронутыми. Мы надеемся, что у вас был такой же опыт, если вы полностью переходили со старого устаревшего сервера. Вы можете столкнуться с другими ошибками, и, возможно, они не будут рассмотрены здесь. Так что не стесняйтесь делиться ими.

В противном случае мы благодарим вас за то, что вы оставались до конца, и мы ценим огромную поддержку и комментарии, которые мы получаем. Вы заставляете все это случиться.

 

Оставить ответ

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

семнадцать − шестнадцать =