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バックアップユーティリティ をセットアップします。 詳細は GitHub Enterprise Serverバックアップユーティリティ を参照してく� さい。
- GitHub Enterprise Serverバックアップユーティリティを使ってすでにスケジューリングされたバックアップを設定しているなら、最新バージョンにアップデートしたことを確認してく� さい。
- 現時点でスケジューリングされたバックアップを動作させていないなら、GitHub Enterprise Serverバックアップユーティリティをセットアップしてく� さい。
-
ghe-backupコマンドを使って、現在のインスタンスの初めてのフルバックアップスナップショットを取ってく� さい。 現在のインスタンスですでにスケジューリングされたバックアップを設定しているなら、インスタンスのスナップショットを取る必要はありません。Tip:スナップショットを取る間は、インスタンスをオンラインのままにして利用し続けられます。 移行作業のメンテナンスモードの間、別のスナップショットを取ることができます。 バックアップはインクリメンタルなので、この初期スナップショットは最終のスナップショットへのデータ転送量を減らしてくれます。それによって、メンテナンスウィンドウが短くなるかもしれません。
-
ユーザーネットワークトラフィックを新しいインスタンスに切り替える方法を決定します。 移行した後に、すべての HTTP と Git のネットワークトラフィックは新しいインスタンスに送信されます。
- DNS - この方法はシンプルであり、あるデータセンターから他のデータセンターへの移行であってもうまく働くことから、この方法はすべての環境でおすすめします。 移行を開始する前に、既存のDNSレコードのTTLを5分以下にして、変更が伝播するようにしてく� さい。 移行が完了したら、DNSレコードを新しいインスタンスのIPアドレスを指すように更新してく� さい。
- IPアドレスの割り当て - この方法が利用できるのはVMWareからVMWareへの移行の� �合のみであり、DNSを使う方法が利用できない� �合以外にはおすすめできません。 移行を始める前に、古いインスタンスをシャットダウンしてそのIPアドレスを新しいインスタンスに割り当てる必要があります。
-
メンテナンスウィンドウをスケジューリングしてく� さい。 メンテナンスウィンドウには、データをバックアップホストから新しいインスタンスに転送するのに十分な時間が含まれていなければならず、その長さはバックアップスナップショットのサイズと利用可能なネットワーク帯域に基づいて変化します。 この間、現在のインスタンスは利用できなくなり、新しいインスタンスへの移行の間はメンテナンスモードになります。
移行の実施
-
新しいGitHub Enterprise2.1インスタンスをプロビジョニングしてく� さい。 詳しい情� �については、ターゲットのプラットフォー� の"プロビジョニングとインストール"ガイドを参照してく� さい。
-
ブラウザで新しいレプリカアプライアンスのIPアドレスにアクセスして、所有するGitHub Enterpriseのライセンスをアップロードしてく� さい。
-
管理者パスワードを設定してく� さい。
-
Migrate（移行）をクリックしてく� さい。
-
バックアップホストへのアクセス用の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 アドレスの割り当てのどちらかを使用して、ユーザーのネットワークトラフィックを古いインスタンスから新しいインスタンスに切り替えます。
-
Upgrade to the latest patch release of GitHub Enterprise Server. 詳細は「GitHub Enterprise Server をアップグレードする」を参照してく� さい。