- GitLab 12.9 へのアップデート
- GitLab 12.7 へのアップデート
- GitLab 12.2 へのアップデート
- GitLab 12.1 へのアップデート
- GitLab 12.0 へのアップデート
- GitLab 11.11 へのアップデート
- GitLab 10.8 へのアップデート
- GitLab 10.6 へのアップデート
- GitLab 10.5へのアップデート
- GitLab 10.3 へのアップデート
- GitLab 10.2 へのアップデート
- GitLab 10.1 へのアップデート
- GitLab 10.0へのアップデート
- GitLab 9.3 以前からのアップデート
- GitLab 9.0 へのアップデート
バージョン別のアップデート手順
アップデートするバージョンに対応する手順が記載されている場合は、このドキュメントを確認してください。 これらの手順は、Geo ノードをアップデートする一般的な手順と同じです。
GitLab 12.9 へのアップデート
GitLab 12.7 へのアップデート
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 へのアップデート
GitLab 11.11 へのアップデート
GitLab 10.8 へのアップデート
10.8以前では、セカンダリノードでキャッシュをフラッシュしないとブロードキャストメッセージが伝播しませんでした。 これは10.8で修正されましたが、各セカンダリノードで最後のキャッシュフラッシュが必要です:
sudo gitlab-rake cache:clear
GitLab 10.6 へのアップデート
10.4では、データベース・ユーザー(gitlab
)にパスワードを定義することを推奨するようになりました。
Geo Tracking Databaseを最適化する方法として、Foreign Data Wrapperを有効にするためにこのパスワードを使用するため、この変更を要求しています。 また、信頼認証方法の使用を無効にすることで、セキュリティを向上させています。
-
(プライマリ) プライマリノードにログインして実行します:
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
-
(プライマリ)再設定して再起動します:
sudo gitlab-ctl reconfigure sudo gitlab-ctl restart
-
(セカンダリ)すべてのセカンダリノードにログインし、
/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
-
(セカンダリ)再設定して再起動します:
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レプリケーションを使用して作成する必要があります。
セカンダリノードが プライマリノードに昇格した場合に問題が発生する可能性があります:
-
(セカンダリ) すべての セカンダリノードにログインして実行します:
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でこれを行う最も簡単な方法は次のとおりです:
- プライマリサーバーにOmnibus GitLabがあることを確認してください。
-
gitlab-ctl reconfigure
とgitlab-ctl restart postgresql
を実行します。 これで、プライマリ・データベースのレプリケーション・スロットが有効になります。 -
postgresql['sql_user_password']
,gitlab_rails['db_password']
を定義する手順を確認してください。 -
postgresql['max_replication_slots']
がセカンダリGeo ノードのロケーション数と一致していることを確認してください。 - セカンダリサーバにGitLab をインストールします。
- データベースのレプリケーション処理を再実行します。
GitLab 9.0 へのアップデート
重要:GitLab 9.0では、PostgreSQLのバージョンが9.6にアップデートされ、セカンダリノードをアップデートしてストリーミングレプリケーションを動作させ続けるためには、手動での手順が必要です。 ダウンタイムが必要なので、前もって計画を立ててください。
以下の手順は、GitLab 8.17から9.0+にアップデートする場合にのみ適用されます。 それ以前のバージョンの場合は、9.0+にアップデートする前にまずGitLab 8.17にアップデートしてください。
各ステップは、より分かりやすくするために、関連するノードを先頭につけています:
-
(セカンダリ) すべての セカンダリノードにログインし、すべてのサービスを停止します:
sudo gitlab-ctl stop
-
(セカンダリ)PostgreSQLの認証情報を保持するために、すべてのセカンダリノードで
recovery.conf
ファイルのバックアップを作成してください:sudo cp /var/opt/gitlab/postgresql/data/recovery.conf /var/opt/gitlab/
-
(プライマリ)通常のアップデートのドキュメントに従って、プライマリノードをGitLab 9.0 にアップデートします。 アップデートが終了すると、プライマリノードはPostgreSQL 9.6 で動作するようになります。
-
(プライマリ)リポジトリのレプリケーションの同期解除を防ぐため、セカンダリノードのデータベースを再初期化するために使用する
postgresql
以外のすべてのサービスを停止します:sudo gitlab-ctl stop sudo gitlab-ctl start postgresql
-
(セカンダリ) 各セカンダリ・ノードで以下の手順を実行します:
-
(セカンダリ)すべてのサービスを停止します:
sudo gitlab-ctl stop
-
(セカンダリ)データベースのマイグレーションを実行しないようにします:
sudo touch /etc/gitlab/skip-auto-migrations
-
(セカンダリ)古いデータベースを別のディレクトリに移動します:
sudo mv /var/opt/gitlab/postgresql{,.bak}
-
(secondary)GitLab 9.0にアップデートします。 アップデートが終了すると、ノードはPostgreSQL 9.6で動作するようになります。
-
(二次)すべてのサービスが立ち上がっていることを確認します:
sudo gitlab-ctl start
-
(2つ目)GitLabを再設定します:
sudo gitlab-ctl reconfigure
-
(二次)PostgreSQLのアップグレードコマンドを実行します:
sudo gitlab-ctl pg-upgrade
-
(セカンダリ)レプリケーションの再初期化に必要なデータベースの保存された認証情報を参照してください:
sudo grep -s primary_conninfo /var/opt/gitlab/recovery.conf
-
(二次)以下のスニペットをファイルに保存します。
/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
-
(セカンダリ)前のステップの認証情報を使用して、リカバリスクリプトを実行します:
sudo bash /tmp/replica.sh
-
(2つ目)GitLabを再設定します:
sudo gitlab-ctl reconfigure
-
(二次)すべてのサービスを開始します:
sudo gitlab-ctl start
-
(セカンダリ)残りのセカンダリノードについても手順を繰り返します。
-
-
(プライマリ)すべてのセカンダリノードが更新された後、プライマリノードですべてのサービスを開始します:
sudo gitlab-ctl start
セカンダリノードのトラッキングデータベースの更新
セカンダリノードをアップデートした後、トラッキングデータベースのマイグレーションを実行する必要があるかもしれません。 トラッキングデータベースはGitLab 9.1で追加され、10.0からは必須です。
-
トラッキングデータベースのデータベースマイグレーションを実行します:
sudo gitlab-rake geo:db:migrate
-
各セカンダリノードについてこの手順を繰り返します。