Note
GitHub Enterprise Server 11.10 — неподдерживаемый выпуск 2014 года. Список поддерживаемых выпусков см. в разделе Выпуски GitHub Enterprise Server.
Поддерживается переход из GitHub Enterprise версии 11.10.348 и более поздних версий. Переход из GitHub Enterprise версии 11.10.348 и более ранних версий не поддерживается. Сначала необходимо выполнить обновление до версии 11.10.348 в нескольких обновлениях. Дополнительные сведения см. в процедуре обновления 11.10.348, обновлении до последнего выпуска.
Чтобы выполнить обновление до последней версии GitHub Enterprise, необходимо сначала перейти на GitHub Enterprise Server версии 2.1, а затем выполнить обычное обновление. Дополнительные сведения см. в разделе Обзор процесса обновления.
Подготовка к миграции
-
Еще раз изучите руководство по подготовке и установке и убедитесь, что выполнены все условия для подготовки и настройки GitHub Enterprise версии 2.1.23 в вашей среде. Дополнительные сведения см. в разделе "Подготовка и установка".
-
Убедитесь, что текущий экземпляр выполняет поддерживаемую версию обновления.
-
Настройте последнюю версию GitHub Enterprise Server Backup Utilities. Дополнительные сведения см. в GitHub Enterprise Server Backup Utilities.
- Если вы уже настроили запланированные резервные копии с помощью GitHub Enterprise Server Backup Utilities, убедитесь, что выполнено обновление до последней версии.
- Если сейчас вы не выполняете запланированные резервные копии, настройте GitHub Enterprise Server Backup Utilities.
-
Создайте моментальный снимок полной резервной копии текущего экземпляра с помощью команды
ghe-backup. Если вы уже настроили запланированные резервные копии для текущего экземпляра, моментальный снимок экземпляра создавать не нужно.Tip
Экземпляр можно оставить в сети и активно использовать во время моментального снимка. Во время обслуживания миграции вы создадите еще один моментальный снимок. Так как резервные копии являются добавочными, этот исходный моментальный снимок уменьшает объем данных, передаваемых в окончательном моментальном снимке, что может сократить период обслуживания.
-
Определите метод переключения трафика пользователя на новый экземпляр. После миграции весь трафик HTTP и Git направляется в новый экземпляр.
- DNS. Мы рекомендуем этот метод для всех сред, так как он прост в использовании и хорошо работает даже при миграции из одного центра обработки данных в другой. Перед началом миграции сократите срок жизни существующей записи DNS до пяти минут или меньше и разрешите распространение изменений. После завершения миграции обновите записи DNS, чтобы указать IP-адрес нового экземпляра.
- Назначение IP-адресов. Этот метод доступен только при миграции VMware в VMware и не рекомендуется к использованию, если метод DNS недоступен. Перед началом миграции необходимо завершить работу старого экземпляра и назначить его IP-адрес новому экземпляру.
-
Запланируйте период обслуживания. Период обслуживания должен включать достаточно времени для передачи данных из узла резервной копии в новый экземпляр и будет зависеть от размера моментального снимка резервной копии и доступной пропускной способности сети. В течение этого времени текущий экземпляр будет недоступен, а во время миграции на новый экземпляр будет находиться в режиме обслуживания.
Выполнение миграции
-
Подготовьте новый экземпляр GitHub Enterprise версии 2.1. Дополнительные сведения см. в руководстве по подготовке и установке целевой платформы.
-
В браузере перейдите к IP-адресу нового устройства реплики и отправьте лицензию GitHub Enterprise.
-
Установите пароль администратора.
-
Нажмите Мигрировать.
-
В текстовом поле "Добавление нового ключа SSH" вставьте ключ SSH для узла резервного копирования.
-
Нажмите Добавить ключ, а затем — Продолжить.
-
Скопируйте команду
ghe-restore, которую вы будете выполнять на узле резервной копии, чтобы перенести данные в новый экземпляр. -
Включите режим обслуживания на старом экземпляре и дождитесь завершения всех активных процессов. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
Note
Экземпляр будет недоступен для обычного использования с этого момента.
-
На узле резервной копии выполните команду
ghe-backup, чтобы создать окончательный моментальный снимок резервной копии. Это гарантирует, что все данные из старого экземпляра будут записаны. -
На узле резервной копии выполните команду
ghe-restore, скопированную на экране состояния восстановления нового экземпляра, чтобы восстановить последний моментальный снимок.$ ghe-restore 169.254.1.1 The authenticity of host '169.254.1.1:122' can't be established. RSA key fingerprint is fe:96:9e:ac:d0:22:7c:cf:22:68:f2:c3:c9:81:53:d1. Are you sure you want to continue connecting (yes/no)? yes Connect 169.254.1.1:122 OK (v2.0.0) Starting restore of 169.254.1.1:122 from snapshot 20141014T141425 Restoring Git repositories ... Restoring GitHub Pages ... Restoring asset attachments ... Restoring hook deliveries ... Restoring MySQL database ... Restoring Redis database ... Restoring SSH authorized keys ... Restoring Elasticsearch indices ... Restoring SSH host keys ... Completed restore of 169.254.1.1:122 from snapshot 20141014T141425 Visit https://169.254.1.1/setup/settings to review appliance configuration. -
Вернитесь на экран состояния восстановления нового экземпляра, чтобы проверить, завершено ли восстановление.
-
Щелкните Перейти к параметрам, чтобы проверить и настроить сведения о конфигурации и параметры, импортированные из предыдущего экземпляра.
-
Нажмите кнопку Сохранить параметры.
Note
Новый экземпляр можно использовать после применения параметров конфигурации и перезапуска сервера.
-
Переключите трафик пользователя из старого экземпляра на новый с помощью назначения DNS или IP-адреса.
-
Выполните обновление до последнего выпуска исправлений GitHub Enterprise Server. Дополнительные сведения см. в разделе Обзор процесса обновления.