GitHub Enterprise11.10.348以降からの移行がサポートされています。 GitHub Enterprise11.10.348以前からの移行はサポートされていません。 いくつかのアップグレードを経て、まず11.10.348にアップグレードしなければなりません。 詳細については、11.10.348 のアップグレード手� �「最新リリースへのアップグレード」を参照してく� さい。
最新バージョンの GitHub Enterprise にアップグレードするには、まず GitHub Enterprise Server 2.1 に移行する必要があります。その後、通常のアップグレードプロセスに従うことができます。 詳細については、「GitHub Enterprise のアップグレード」を参照してく� さい。
移行を準備する
-
プロビジョニング及びインストールガイドをレビューし、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キーを"Add new SSH key（新しいSSHキーの追� ）"に貼り付けてく� さい。
-
[Add key](キーの追� ) 、 [Continue](続行) の� �にクリックします。
-
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 の最新パッチ リリースにアップグレードします。 詳細については、「GitHub Enterprise Server をアップグレードする」を参照してく� さい。