メモ
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コマンドを使って、現在のインスタンスの初期完全バックアップ スナップショットを作成します。 現在のインスタンスですでにスケジューリングされたバックアップを設定しているなら、インスタンスのスナップショットを取る必要はありません。ヒント
スナップショットの間、インスタンスはオンラインのままにして利用し続けられます。 移行作業のメンテナンスモードの間、別のスナップショットを取ることができます。 バックアップはインクリメンタルなので、この初期スナップショットは最終のスナップショットへのデータ転送量を減らしてくれます。それによって、メンテナンスウィンドウが短くなるかもしれません。
-
ユーザーネットワークトラフィックを新しいインスタンスに切り替える方法を決定します。 移行した後に、すべての HTTP と Git のネットワークトラフィックは新しいインスタンスに送信されます。
- DNS - この方法はシンプルであり、あるデータセンターから他のデータセンターへの移行であってもうまく働くことから、この方法はすべての環境でお勧めします。 移行を開始する前に、既存のDNSレコードのTTLを5分以下にして、変更が伝播するようにしてください。 移行が完了したら、DNSレコードを新しいインスタンスのIPアドレスを指すように更新してください。
- IP アドレスの割り当て - この方法を使用できるのは VMware から VMware への移行の場合のみであり、DNS の方法を使用できない場合を除き、お勧めできません。 移行を始める前に、古いインスタンスをシャットダウンしてそのIPアドレスを新しいインスタンスに割り当てる必要があります。
-
メンテナンスウィンドウをスケジューリングしてください。 メンテナンスウィンドウには、データをバックアップホストから新しいインスタンスに転送するのに十分な時間が含まれていなければならず、その長さはバックアップスナップショットのサイズと利用可能なネットワーク帯域に基づいて変化します。 この間、現在のインスタンスは利用できなくなり、新しいインスタンスへの移行の間はメンテナンスモードになります。
移行を実行する
-
新しい GitHub Enterprise 2.1 インスタンスをプロビジョニングします。 詳細については、ターゲット プラットフォーム用の「プロビジョニングとインストール」ガイドを参照してください。
-
ブラウザーで、新しいレプリカ アプライアンスの IP アドレスに移動し、 GitHub Enterprise ライセンスをアップロードします。
-
管理者パスワードを設定してください。
-
[移行] をクリックします。
-
[新しい SSH キーの追加] テキスト フィールドに、バックアップ ホストへのアクセス用の SSH キーを貼り付けます。
-
ghe-restoreコマンドをコピーします。これをバックアップ ホスト上で実行して、新しいインスタンスにデータを移行します。 -
古いインスタンスでメンテナンスモードを有効化し、すべてのアクティブなプロセスが完了するのを待ってください。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。
メモ
この時点から、インスタンスを通常のように使用できなくなります。
-
バックアップ ホストで
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. -
新しいインスタンスの復元ステータス画面に戻って、復元が完了したことを確認します。
-
Continue to settings をクリックして、前のインスタンスからインポートされた構成情報と設定を確認し、調整します。
-
Save settings をクリックします。
メモ
構成設定を適用してサーバーを再起動すると、新しいインスタンスを使用できます。
-
DNS または IP アドレスの割り当てのどちらかを使用して、ユーザーのネットワークトラフィックを古いインスタンスから新しいインスタンスに切り替えます。
-
GitHub Enterprise Serverの最新のパッチ リリースにアップグレードします。 詳しくは、「アップグレード プロセスの概要」をご覧ください。