0x00.Предисловие

Эта статья представляет собой серию,Данная статья является четвёртой в серии статей.：Вспомните опыт 17-кратного обновления GitLab Community Edition на 6 основных версий за одну ночь.

Глава 1：на основе AlmaLinux 9 Установить GitLab Версия сообщества в действии

Часть 2：на основе AlmaLinux 9 Конфигурация GitLab Версия сообщества в действии

Часть третья：на основе AlmaLinux 9 резервное копирование GitLab Версия сообщества в действии

Эта статья по-прежнему основана на легком компьютере, купленном у Tencent Cloud. cn-tx-bj7-a9 начальство Установить,AlmaLinux 9.4 Версия, Конфигурация 4C4G60G

начальствостатьяна основе AlmaLinux 9 резервное копирование GitLab Версия сообщества в действииВведено во внутреннюю структуру компаниииспользоватьиз GitLab Как Конфигурация выполняет ежедневное резервное резервное копированиеиз

В конце я упомянул, что в следующей статье планируется представить реальный опыт обновления производственной среды до 6 основных версий. Да, в этой статье будет подробно рассмотрен весь процесс обновления.

Позвольте мне упомянуть здесь, что в производственной среде используется машина с версией CentOS 7, а в названии по-прежнему используется AlmaLinux 9 для унификации (название было изменено).

Но это не повлияет на общую идею обновления.

0x01. Обновление фона.

Сервис работает без сбоев, зачем нам его обновлять? Причина, естественно, GitLab Обнаружена новая уязвимость авторизации CVE-2024-45409 Надо вовремя исправлять

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

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

Итак, я начал читать официальные документы и проходить весь процесс обновления.

0x02. Резервное копирование перед обновлением.

Вначале все сложно,Ведь никто никогда этого не делал,Я думаю лучше начать с резервного восстановление Давайте сначала доделаем машину. копированиехорошо

1. Виртуальная машина работает на экземпляре vCenter. Открыв заявку на получение прав доступа, я обнаружил, что снимок не может быть выполнен. К счастью, другая сторона все же сделала снимок.
2. На всякий случай это было реализовано снова. gitlab-backup операцию, так что вы получите резервное копирования файла, конкретный метод был описан в предыдущей статье, вы можете secrets and configuration Файлы также добавлены

В резервном нет второго шага копирование файла на компьютер, но напрямую rsync Отправлено в другое удаленное место VM Да, это двойная страховка.

Вышеуказанные два уровня резервного копирование завершено, оно почти израсходовано 3+ часов, потому что это VM В Сан-Хосе... скорость интернета правда не высокая, но, к счастью, не падает.

Далее вы можете без опасений планировать обновление.

Обратитесь к официальной документации：https://docs.gitlab.com/ee/update/

0x03. Запланируйте обновление с помощью инструмента «Путь обновления».

Обратитесь к официальной документации：https://docs.gitlab.com/ee/update/plan_your_upgrade.html

Его нужно сначала сгенерировать Upgrade Path：https://gitlab-com.gitlab.io/support/toolbox/upgrade-path,То есть поэтапное обновление основных версий.

• Текущая версия: 11.4.14. На самом деле мы используем 11.4.X, поэтому в процессе обновления до 11.4.14 будет дополнительный шаг.
• Целевая версия: 16.3.9
• Версия: Издание сообщества
• Источник: Цент ОС
• Auto Установка: автоматическое обновление добавляется после команды существования. -да, сними галочку
• Нулевое время простоя: нулевое время простоя может быть реализовано в среде, требующей соглашения об уровне обслуживания. Цена заключается в том, что слишком много версий необходимо обновлять одну за другой, поэтому не проверяйте это.
• N-1: Считается, что предыдущая версия последней версии является последней версией, поэтому не проверяйте ее.

Посмотреть сводку

Дополнительное напоминание о том, что вам нужно обратить внимание на проблему совместимости glibc внизу.

Конкретный список обновленных версий выглядит следующим образом:

Всего необходимо 16 + 1 = 17 Второсортныйобновление,Всю ночь напролетсуществовать Нет выхода

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.3.6 => 14.9.5 => 14.10.5 => 15.0.5 => 15.4.6 => 15.11.13 => 16.3.9

0x04. Обновление по одному.

По соображениям стабильности не используется yum install существуют строки Установить, но перейти к загрузке rpm пакет, чтобы вы могли следить за ходом обновления в режиме реального времени.

Команда выполнения: rpm -Uvh xxx.rpm > version.log

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

Здесь есть еще одна проблема: пространство на жестком диске виртуальной машины находится под угрозой!

Чтобы оставить достаточно места для обновления, загрузите одно обновление RPM, а затем одно за другим загрузите следующее.

Но я не знал, пока не проснулся утром, что после выполнения определенной версии посреди ночи диск все еще был заполнен. После долгих возни он вернулся в нормальное состояние после удаления и переустановки. была бы дилемма.

Было измерено, что загрузка каждого пакета RPM сначала на ваш компьютер, а затем загрузка его на виртуальную машину происходит быстрее, чем загрузка его непосредственно на виртуальную машину.

А из-за медленной скорости интернета обновление было завершено с вечера первого дня до полудня второго дня: 11.4.X -> 16.3.9

Будучи администратором, я все еще видел, как на следующее утро мои коллеги использовали GitLab для слияния. Я действительно не боюсь отправлять записи и оставлять их в покое.

0x05. Проверьте фоновую миграцию.

Обратитесь к официальной документации：https://docs.gitlab.com/ee/update/background_migrations.html

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

0x06. Событие обновления еще раз.

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

16.7.10 => 16.11.10 => 17.X

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

0x07.Постскриптум

Я всегда хотел рассказать вам о своем опыте обновления, и во время мероприятия Double Eleven у меня это заняло почти 2 часа.

Невозможно не спать всю ночь в этой жизни. Если на кону жизнь собаки, она должна спать, когда следует.

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

Следующая статья знакомит с соответствующими практиками GitLab CI/CD и планирует начать с развертывания GitLab Runner.

Вы также можете купить легкую машину под руководством и опробовать ее.,В Double Eleven действуют скидки при групповой покупке.：https://cloud.tencent.com/act/pro/double11-2024?fromSource=gwzcw.8891816.8891816.8891816

Прыжок