アップグレードとロールバック
アップグレードが置き換えるのはバイナリであり、別の製品へ移行するわけではありません。 データディレクトリ、監査署名鍵、TLS マテリアルはそのまま残り、新しいスキーマ マイグレーションはエンジンが起動時に適用します。このページは「このリリースを 適用すべきか」から「以前の版へ戻す必要がある」までの運用手順です。
どのアップグレード経路を使うか
Section titled “どのアップグレード経路を使うか”バイナリを新しくする方法は 2 つあり、どちらも同じ結果に到達します。
| インストール形態 | 経路 |
|---|---|
| ホスト上のバイナリ、systemd、Docker Compose | olivares upgrade — このページ |
| Kubernetes / Helm | イメージを設定し、operator にロールアウトさせます。Pod 内で olivares upgrade を実行しないでください。デプロイメントは宣言的であり、次の reconcile が変更を取り消します。 |
何より先に計画を確認する
Section titled “何より先に計画を確認する”--check はチャネルマニフェストをダウンロードして検証し、インストール済みの版と
比較して、何が行われるかを表示します。置き換えは行いません。
olivares upgrade --check応答にはインストール済みの版、利用可能な版、そして
up to date、upgrade available、
DOWNGRADE (blocked unless --force-rollback)、UNKNOWN のいずれかの
ステータス行が含まれます。2 つのバージョン番号を自分で比較するのではなく、
ステータス行を確認してください。
UNKNOWN は「おそらく問題ない」という意味ではありません。 クロスアーキテクチャの
ステージングディレクトリ、noexec マウント、ソースからのビルドなどが原因で、
インストール済みバージョンを測定できなかったという意味です。アンチロールバック
ガードと最低バージョンゲートはいずれもインストール済みバージョンについての判定で
あるため、どちらも評価できません。コマンドは推測せず拒否します。存在すると分かっている
バージョンを宣言すれば、ガードは有効なままです。
olivares upgrade --check --current-version 26.8.0リリースチャネル
Section titled “リリースチャネル”olivares upgrade はリリースチャネルに従います。チャネルは 3 つであり、
core/release/manifest.go に安定性が高くなる順で宣言されています。
--channel の値 | 宣言 |
|---|---|
stable | release.ChannelStable |
security | release.ChannelSecurity |
lts | release.ChannelLTS |
この表にない値は、何かをダウンロードする前に拒否されます
（release.ValidChannel）。
stable は一般提供のラインであり、デフォルトです。security は帯域外の
セキュリティ修正だけを運びます。そのチャネルを利用するデプロイメントは、
機能リリースを適用せずにセキュリティリリースを適用します。
運用方法に合うチャネルを選び、そのまま使い続けます。
olivares upgrade --channel securityセキュリティリリースはマニフェストでそのようにマークされ、--check は修正する
アドバイザリを表示します。security チャネルを使う場合、それらは GA ラインとは別に
配信されます。
アップグレードを適用する
Section titled “アップグレードを適用する”olivares upgradeコマンドが行う処理と、その順序の理由は次のとおりです。
- ビルドに埋め込まれた Ed25519 リリース鍵に対して、チャネルマニフェストを
ダウンロードし、その署名をオフラインで検証します。信頼の起点はトランスポート
ではなく署名です。鍵が埋め込まれていないビルドでは、
--pubkeyで鍵を 指定する必要があります。未検証の経路はありません。 - 古い版への移行を拒否します。 実行中の版より古いバージョンのインストールは、
--force-rollbackを指定しない限りブロックされます。この指定は監査エントリに 記録されます。 - バイトが実行される前に、アーティファクトをマニフェストの署名済み SHA-256 に 結び付けます。
- 候補をプローブしてからアトミックに置き換え、置き換えたバイナリの タイムスタンプ付きバックアップを残します。新しくインストールしたバイナリが 実行できなければ、自動的にそのバックアップへ戻します。
- 実行中のプロセスには触れません。 置き換えるのはディスク上のファイルです。 サービスを再起動した時点で新しいコードが引き継ぎます。
スクリプトから実行し、確認プロンプトに答える人がいない場合は --yes を
追加してください。
エアギャップ環境へのインストール
Section titled “エアギャップ環境へのインストール”エアギャップ環境のデプロイメントは更新ホストへ接続しません。すでに信頼している手段で バンドルを持ち込み、ローカルファイルからインストールします。信頼していたのは元から ネットワークではないため、検証は同じです。
バンドルからのインストールには、そのマシン上で有効なライセンスが必要です。
バイナリに埋め込まれたライセンス鍵に対してオフラインで検証されます。外部への呼び出しは
ないため、エアギャップ内でも動作します。そのマシンにまだライセンスをインストールして
いない場合は、ライセンスをインストールしてエンタープライズへ移行するに手順があります。
--check はゲートされないので、何かを
ステージングする前にバンドルを検証できます。
olivares upgrade --bundle ./olivares-release.tar.gz --check # verify only; no license readolivares upgrade --bundle ./olivares-release.tar.gz --yes # install; needs a live licenseビルドにリリース鍵が埋め込まれていない場合、または独自の署名鍵でリリースを ミラーリングする場合は、検証に使う鍵を指定します。
olivares upgrade --bundle ./olivares-release.tar.gz --pubkey @/etc/olivares/release.pubバンドルの作成方法と搬入方法は エアギャップ環境へのインストールを参照してください。
段階的ロールアウトと無人チェック
Section titled “段階的ロールアウトと無人チェック”マニフェストは段階的ロールアウトのコホートを指定できるため、最初は環境の一部だけに
リリースを届けられます。--if-eligible を指定すると、ノードはそのコホートに属する
場合だけ処理し、それ以外では何もしません。
olivares upgrade --if-eligible --yes組み込みタイマーはこの形式で実行します。メンテナンス時間内にこのコマンドを呼ぶ systemd タイマーとサービスを出力するには、次を実行します。
olivares upgrade --install-timer --timer-schedule 'Sun *-*-* 03:00:00'デフォルトでは unit を標準出力へ表示し、--timer-dir は指定された場所へ書き込みます。
これはオプトインであり、自動的にスケジュールされるものはありません。
コンソールには同じ情報の読み取り専用側があります。Settings → update status は
POST /v1/console/update-check を呼び出し、設定済みチャネルをオンデマンドで
チェックします。エアギャップ環境、またはチャネルが未設定のデプロイメントは
「更新なし」と報告するのではなく、理由を添えて 501 を返します。
アップグレードを検証する
Section titled “アップグレードを検証する”olivares versionolivares upgrade --check--check は up to date と報告するはずです。次にサービス自体が正常か確認します。
コンソールの Health 画面（/health）、または
Prometheus で監視するに記載されたエンジンの
readiness エンドポイントを使います。
ロールバック
Section titled “ロールバック”以前のバイナリは、それを置き換えたバイナリの隣に保存され、置き換え時にコマンドが パスを表示します。ロールバックは、そのファイルを復元してサービスを再起動する操作です。
ロールバックの安全性は偶然ではなく設計によるものです。すべてのスキーマ変更は最初に 追加的な expand として出荷され、破壊的な contract は後のリリースでのみ適用されます。 そのため、以前のリリースのバイナリはアップグレード済みスキーマでも引き続き動作します。 ロールバックが「データベースを逆向きに戻す」ではなく「古いバイナリを戻す」で済むのは このためです。
保存済みバックアップを戻すのではなく古いリリースをインストールする必要がある場合、 アンチロールバックガードは明示的な指定があるまでブロックします。
olivares upgrade --force-rollback --yesこのオーバーライドは監査ログに記録されます。最低バージョンゲートは、これでは オーバーライドできません。マニフェストが現在のインストール済みバージョンより高い 下限を宣言する場合、飛び越えようとせず、中間リリースを順に適用してください。
問題が発生した場合
Section titled “問題が発生した場合”| 症状 | 意味 | 対処 |
|---|---|---|
--check が UNKNOWN を表示する | インストール済みバージョンを測定できず、順序を判定できない | --current-version に、インストール済みと分かっているバージョンを指定する |
min_ver が古すぎると示す | 現在の版への直接インストールをリリースが拒否している | 指定された中間リリースへ先にアップグレードする |
| 新しいバイナリが起動しない | 置き換え後のプローブに失敗した | バックアップへすでに自動復元されている。ログを確認し、リリースを報告する |
--install-timer が動作したが何も起きない | ノードが段階的ロールアウトのコホートに属していない | --if-eligible では正常。ロールアウトの進行に伴ってコホートが拡大する |
| ”another olivares upgrade is already installing”, exit 5 | バイナリごとに一度に実行できるアップグレードは 1 つ。ロックはダウンロードから置き換えまで保持される | 実行中の処理を待って再実行する。何も動いていなければカーネルがロックを解放済みなので、そのまま再実行する |
| ”it CHANGED while this upgrade was downloading” | 計画後に別のもの（パッケージマネージャ、イメージロールアウト、構成管理）がバイナリを置き換えた | 再実行する。ガードは実際にインストールされたものに対して再評価される。繰り返す場合は 2 つの仕組みが同じバイナリを管理している |
バイナリごとに 1 つのアップグレードエージェント。 olivares upgrade は
準備・ダウンロード・置き換えの全シーケンスにわたり対象を排他ロックするため、2 つ目の
実行はインストールせず 5 で終了します。チャネルごとのタイマーを動かすのではなく、
1 つのタイマーをインストールして、その --channel を変更してください。以前は
同じ秒に完了した 2 つのインストールが互いのロールバック用バックアップを上書きし、
負けた側の自動ロールバックが別のバイナリを復元して成功と報告する可能性がありました。
コマンドは置き換えの直前にも対象のバイトを読み直し、計画対象と異なれば拒否します。
アンチロールバックと最低バージョンの判定は、特定のインストール済みファイルについての
判定だからです。
それ以外の問題はトラブルシューティングから確認できます。
コンソールの Logs 画面（/logs）では、エンジン自身のログをストリーム表示します。