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キーの追加）"に貼り付けてください。
-
Click Add key and then click 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 アドレスの割り当てのどちらかを使用して、ユーザーのネットワークトラフィックを古いインスタンスから新しいインスタンスに切り替えます。
-
最新のパッチリリース 2.18 にアップグレードします。 詳細は「GitHub Enterprise Server をアップグレードする」を参照してください。