バージョン別のアップデート手順

アップデートするバージョンに対応する手順が記載されている場合は、このドキュメントを確認してください。 これらの手順は、Geo ノードをアップデートする一般的な手順と同じです。

GitLab 12.9 へのアップデート

警告:GitLab 12.9.0からGitLab 12.9.3はリポジトリの検証を停止するバグの影響を受けます。 このイシューはGitLab 12.9.4で修正されています。GitLab 12.9.4以降にアップグレードしてください。

GitLab 12.7 へのアップデート

危険:GitLab 12.7.5以降にアップグレードしてください。 バージョン12.7.0から12.7.4まではアップグレードしないでください。初期化順序のバグがあり、Geoセカンダリが不正なデータベース接続プールサイズを設定する原因となります。この修正は12.7.5で配布されました。

GitLab 12.2 へのアップデート

GitLab 12.2には以下のPostgreSQLのマイナーアップデートが含まれています：

  • PostgreSQL 9.6を使用している場合は、9.6.14 。
  • PostgreSQL 10を使用している場合は、10.9 。

このアップデートは、PostgreSQLのメジャーアップデートが無効になっていても行われます。

Geoアップグレード中にForeign Data Wrapperをリフレッシュする前に、Geoトラッキング・データベースを再起動してください： 

sudo gitlab-ctl restart geo-postgresql

再起動することで、PostgreSQLがFDW拡張をロードしようとした時のバージョンの不一致を回避できます。

GitLab 12.1 へのアップデート

デフォルトでは、GitLab 12.1は組み込みPostgreSQLサーバーを9.6から10.7に自動的にアップデートしようとします。推奨される手順については、オムニバスのドキュメントを参照してください。

これは、アップデートの前に以下を実行することで、一時的に無効にすることができます： 

sudo touch /etc/gitlab/disable-postgresql-upgrade

GitLab 12.0 へのアップデート

警告:このバージョンには、新しいLFSオブジェクトがGeoセカンダリノードにレプリケートされないというバグがあります。 このイシューはGitLab 12.1で修正されています。GitLab 12.1以降にアップグレードしてください。

GitLab 11.11 へのアップデート

警告:このバージョンには、新しいLFSオブジェクトがGeoセカンダリノードにレプリケートされないというバグがあります。 このイシューはGitLab 12.1で修正されています。GitLab 12.1以降にアップグレードしてください。

GitLab 10.8 へのアップデート

10.8以前では、セカンダリノードでキャッシュをフラッシュしないとブロードキャストメッセージが伝播しませんでした。 これは10.8で修正されましたが、各セカンダリノードで最後のキャッシュフラッシュが必要です： 

sudo gitlab-rake cache:clear

GitLab 10.6 へのアップデート

10.4では、データベース・ユーザー(gitlab)にパスワードを定義することを推奨するようになりました。

Geo Tracking Databaseを最適化する方法として、Foreign Data Wrapperを有効にするためにこのパスワードを使用するため、この変更を要求しています。 また、信頼認証方法の使用を無効にすることで、セキュリティを向上させています。

  1. (プライマリ） プライマリノードにログインして実行します： 

    gitlab-ctl pg-password-md5 gitlab
# Enter password: <your_password_here>
# Confirm password: <your_password_here>
# fca0b89a972d69f00eb3ec98a5838484

    生成されたハッシュをコピーし、/etc/gitlab/gitlab.rbを編集します： 

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
postgresql['sql_user_password'] = '<md5_hash_of_your_password>'

# Every node that runs Unicorn or Sidekiq needs to have the database
# password specified as below.
# This must be present in all application nodes.
gitlab_rails['db_password'] = '<your_password_here>'

    コンフィギュレーション・ファイルで、trust_auth_cidr_addressを見つけて削除します： 

    postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/32','1.2.3.4/32'] # <- Remove this

  2. (プライマリ）再設定して再起動します： 

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

  3. (セカンダリ）すべてのセカンダリノードにログインし、/etc/gitlab/gitlab.rbを編集します： 

    # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
postgresql['sql_user_password'] = '<md5_hash_of_your_password>'

# Every node that runs Unicorn or Sidekiq needs to have the database
# password specified as below.
# This must be present in all application nodes.
gitlab_rails['db_password'] = '<your_password_here>'

# Enable Foreign Data Wrapper
geo_secondary['db_fdw'] = true

# Secondary address in CIDR format, for example '5.6.7.8/32'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_node_ip>/32']

    コンフィギュレーション・ファイルで、trust_auth_cidr_addressを見つけて削除します： 

    postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/32','5.6.7.8/32'] # <- Remove this

  4. (セカンダリ）再設定して再起動します： 

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

GitLab 10.5へのアップデート

Geo Disaster Recovery を最小限のダウンタイムで動作させるには、セカンダリノードで プライマリノードと同じシークレットセットを使用する必要があります。 ただし、10.5 リリース以前のセットアップ手順では、db_key_base シークレットのみを同期していました。

既存のインストールでこのエラーを修正するには、/etc/gitlab/gitlab-secrets.json 各セカンダリ・ノードで /etc/gitlab/gitlab-secrets.json プライマリ・ノードの内容を上書きし、各セカンダリ・ノードで以下のコマンドを実行します： 

sudo gitlab-ctl reconfigure

この手順を実行しないと、DR後に2要素認証が解除されることがあります。

プライマリノード・ドメインのDNSレコードを更新する際に、SSHホストキーの不一致が原因で新しく昇格したプライマリノードへのSSHリクエストが失敗するのを防ぐには、各セカンダリノードで プライマリSSHホストキーを手動で複製するステップを実行する必要があります。

GitLab 10.3 へのアップデート

SSH リポジトリ同期のサポートが削除されました。

GitLab 10.2では、SSH経由でのセカンダリの同期は非推奨となりました。 10.3では、サポートは完全に削除されました。 すべてのインストールは、代わりにHTTP/HTTPSクローニング方法に切り替わります。 アップデートする前に、すべてのGeoノードがこの方法を使うように設定されていて、あなたのインストールで動作することを確認してください。 特に、HTTP/HTTPS経由でのGitアクセスが有効になっていることを確認してください。

公開インターネット上で HTTP を使用してリポジトリを同期することは安全ではないため、更新する前に HTTPS が設定されていることを確認する必要があります。 このような場合、ファイルの同期も安全ではないことに注意してください！

GitLab 10.2 へのアップデート

セキュアなPostgreSQLレプリケーション

TLSセキュリティで保護されたPostgreSQLレプリケーションのサポートが追加されました。 接続を保護する外部手段（サイト間VPNなど）を使用せずにオープンインターネット上でPostgreSQLレプリケーションを使用している場合は、更新された指示に従ってプライマリと セカンダリのPostgreSQLインスタンスを直ちに再構成してください。

接続を外部でセキュリティしており、今後もそうしたい場合は、gitlab-ctl replicate-geo-databaseの今後の呼び出しに新しいオプション--sslmode=prefer を含めるようにしてください。

HTTPSリポジトリ同期

HTTP/HTTPS 経由でのリポジトリと Wiki のレプリケーションのサポートが追加されました。 SSH 経由でのレプリケーションは非推奨となり、このオプションのサポートは将来のリリースで削除される予定です。

HTTP/HTTPSレプリケーションに切り替えるには、管理者としてプライマリノードにログインし、 Admin Area > Geo(/admin/geo/nodes) にアクセスします。リストされた各セカンダリノードについて、「Edit」ボタンを押し、「Repository cloning」設定を「SSH (deprecated)」から「HTTP/HTTPS」に変更し、「Save changes」を押します。 これはすぐに有効になります。

新しいセカンダリは、HTTP/HTTPSレプリケーションを使用して作成する必要があります。

セカンダリノードが プライマリノードに昇格した場合に問題が発生する可能性があります：

  1. (セカンダリ） すべての セカンダリノードにログインして実行します： 

    sudo -u git -H rm ~git/.ssh/id_rsa ~git/.ssh/id_rsa.pub

ハッシュドストレージ

警告:ハッシュド・ストレージはアルファ版です。 実験的なものであり、本番用ではありません。 詳細はハッシュド・ストレージを参照してください。

以前にHashed Storageを有効にして、既存のプロジェクトをすべてHashed Storageに移行した場合、Hashed Storageを無効にしても、プロジェクトは以前のプロジェクトベースのストレージ・パスに移行されません。 そのため、一度有効にして移行した後は、Hashed Storageを有効のままにしておくことをお勧めします。

GitLab 10.1 へのアップデート

警告:ハッシュド・ストレージはアルファ版です。 実験的なものであり、本番用ではありません。 詳細はハッシュド・ストレージを参照してください。

GitLab 10.0でハッシュストレージが導入され、GitLab 10.1で既存リポジトリの移行パスが追加されました。

GitLab 10.0へのアップデート

GitLab 10.0以降では、SSHアクセス用のauthorized_keys ファイルの一貫性を維持する必要がないように、すべてのGeoシステムでデータベース経由でSSHキーのルックアップを使用するよう求めています。これを怠ると、ユーザーはSSH経由でクローンを作成できなくなります。

Geo の古いバージョンでは、セカンダリノードでダウンロードされた添付ファイルが間違ったディレクトリに保存されることがありました。 これをクリーンアップするには、次のようにすることをお勧めします。

セカンダリGeo ノード上で、root として実行します： 

mv /var/opt/gitlab/gitlab-rails/working /var/opt/gitlab/gitlab-rails/working.old
mkdir /var/opt/gitlab/gitlab-rails/working
chmod 700 /var/opt/gitlab/gitlab-rails/working
chown git:git /var/opt/gitlab/gitlab-rails/working

/var/opt/gitlab/gitlab-rails/working.old はいつでも削除できます。

これが完了したら、新しい作業ディレクトリを使用するためにセカンダリノードでGitLabを再起動することをお勧めします： 

sudo gitlab-ctl restart

GitLab 9.3 以前からのアップデート

GeoをGitLab 9.3またはそれ以前のバージョンで使い始めた場合は、セカンダリのPostgreSQLデータベースをレプリケーションスロットを使うように再同期することをお勧めします。 GeoをGitLab 9.4または10.xで使い始めた場合は、デフォルトでレプリケーションスロットが使われているため、これ以上のアクションは必要ありません。 しかし、GitLab 9.3で使い始め、それ以降にアップデートした場合でも、以下の手順に従ってください。

Omnibusでこれを行う最も簡単な方法は次のとおりです：

  1. プライマリサーバーにOmnibus GitLabがあることを確認してください。
  2. gitlab-ctl reconfigure とgitlab-ctl restart postgresqlを実行します。 これで、プライマリ・データベースのレプリケーション・スロットが有効になります。
  3. postgresql['sql_user_password'],gitlab_rails['db_password']を定義する手順を確認してください。
  4. postgresql['max_replication_slots'] がセカンダリGeo ノードのロケーション数と一致していることを確認してください。
  5. セカンダリサーバにGitLab をインストールします。
  6. データベースのレプリケーション処理を再実行します。

GitLab 9.0 へのアップデート

重要：GitLab 9.0では、PostgreSQLのバージョンが9.6にアップデートされ、セカンダリノードをアップデートしてストリーミングレプリケーションを動作させ続けるためには、手動での手順が必要です。 ダウンタイムが必要なので、前もって計画を立ててください。

以下の手順は、GitLab 8.17から9.0+にアップデートする場合にのみ適用されます。 それ以前のバージョンの場合は、9.0+にアップデートする前にまずGitLab 8.17にアップデートしてください。

各ステップは、より分かりやすくするために、関連するノードを先頭につけています：

  1. (セカンダリ） すべての セカンダリノードにログインし、すべてのサービスを停止します： 

    sudo gitlab-ctl stop

  2. (セカンダリ）PostgreSQLの認証情報を保持するために、すべてのセカンダリノードで recovery.conf ファイルのバックアップを作成してください： 

    sudo cp /var/opt/gitlab/postgresql/data/recovery.conf /var/opt/gitlab/

  3. (プライマリ)通常のアップデートのドキュメントに従って、プライマリノードをGitLab 9.0 にアップデートします。 アップデートが終了すると、プライマリノードはPostgreSQL 9.6 で動作するようになります。

  4. (プライマリ）リポジトリのレプリケーションの同期解除を防ぐため、セカンダリノードのデータベースを再初期化するために使用するpostgresql 以外のすべてのサービスを停止します： 

    sudo gitlab-ctl stop
sudo gitlab-ctl start postgresql

  5. (セカンダリ） 各セカンダリ・ノードで以下の手順を実行します：

    1. (セカンダリ)すべてのサービスを停止します： 

      sudo gitlab-ctl stop

    2. (セカンダリ)データベースのマイグレーションを実行しないようにします： 

      sudo touch /etc/gitlab/skip-auto-migrations

    3. (セカンダリ)古いデータベースを別のディレクトリに移動します： 

      sudo mv /var/opt/gitlab/postgresql{,.bak}

    4. (secondary)GitLab 9.0にアップデートします。 アップデートが終了すると、ノードはPostgreSQL 9.6で動作するようになります。

    5. (二次)すべてのサービスが立ち上がっていることを確認します： 

      sudo gitlab-ctl start

    6. (2つ目)GitLabを再設定します： 

      sudo gitlab-ctl reconfigure

    7. (二次)PostgreSQLのアップグレードコマンドを実行します： 

      sudo gitlab-ctl pg-upgrade

    8. (セカンダリ）レプリケーションの再初期化に必要なデータベースの保存された認証情報を参照してください： 

      sudo grep -s primary_conninfo /var/opt/gitlab/recovery.conf

    9. (二次)以下のスニペットをファイルに保存します。/tmp/replica.shとします。 必要であれば、埋め込みパスを修正してください： 

      #!/bin/bash

PORT="5432"
USER="gitlab_replicator"
echo ---------------------------------------------------------------
echo WARNING: Make sure this script is run from the secondary server
echo ---------------------------------------------------------------
echo
echo Enter the IP or FQDN of the primary PostgreSQL server
read HOST
echo Enter the password for $USER@$HOST
read -s PASSWORD
echo Enter the required sslmode
read SSLMODE

echo Stopping PostgreSQL and all GitLab services
sudo service gitlab stop
sudo service postgresql stop

echo Backing up postgresql.conf
sudo -u postgres mv /var/opt/gitlab/postgresql/data/postgresql.conf /var/opt/gitlab/postgresql/

echo Cleaning up old cluster directory
sudo -u postgres rm -rf /var/opt/gitlab/postgresql/data

echo Starting base backup as the replicator user
echo Enter the password for $USER@$HOST
sudo -u postgres /opt/gitlab/embedded/bin/pg_basebackup -h $HOST -D /var/opt/gitlab/postgresql/data -U gitlab_replicator -v -x -P

echo Writing recovery.conf file
sudo -u postgres bash -c "cat > /var/opt/gitlab/postgresql/data/recovery.conf <<- _EOF1_
  standby_mode = 'on'
  primary_conninfo = 'host=$HOST port=$PORT user=$USER password=$PASSWORD sslmode=$SSLMODE'
_EOF1_
"

echo Restoring postgresql.conf
sudo -u postgres mv /var/opt/gitlab/postgresql/postgresql.conf /var/opt/gitlab/postgresql/data/

echo Starting PostgreSQL
sudo service postgresql start

    10. (セカンダリ)前のステップの認証情報を使用して、リカバリスクリプトを実行します： 

      sudo bash /tmp/replica.sh

    11. (2つ目)GitLabを再設定します： 

      sudo gitlab-ctl reconfigure

    12. (二次)すべてのサービスを開始します： 

      sudo gitlab-ctl start

    13. (セカンダリ）残りのセカンダリノードについても手順を繰り返します。

  6. (プライマリ）すべてのセカンダリノードが更新された後、プライマリノードですべてのサービスを開始します： 

    sudo gitlab-ctl start

セカンダリノードのトラッキングデータベースの更新

セカンダリノードをアップデートした後、トラッキングデータベースのマイグレーションを実行する必要があるかもしれません。 トラッキングデータベースはGitLab 9.1で追加され、10.0からは必須です。

  1. トラッキングデータベースのデータベースマイグレーションを実行します： 

    sudo gitlab-rake geo:db:migrate

  2. 各セカンダリノードについてこの手順を繰り返します。