注: GitHub Enterprise Server 11.10 は、2014 年からサポートされていないリリースです。 サポートされているリリースの一覧については、「GitHub Enterprise Server のリリース」をご覧ください。
GitHub Enterprise11.10.348以降からの移行がサポートされています。 GitHub Enterprise11.10.348以前からの移行はサポートされていません。 いくつかのアップグレードを経て、まず11.10.348にアップグレードしなければなりません。 詳細については、11.10.348 のアップグレード手順「最新リリースへのアップグレード」を参照してください。
最新バージョンの GitHub Enterprise にアップグレードするには、まず GitHub Enterprise Server 2.1 に移行する必要があります。その後、通常のアップグレードプロセスに従うことができます。 詳しくは、「アップグレード プロセスの概要」をご覧ください。
移行を準備する
-
プロビジョニング及びインストールガイドをレビューし、GitHub Enterprise2.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 Enterprise2.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 の最新パッチ リリースにアップグレードします。 詳しくは、「アップグレード プロセスの概要」を参照してください。