アップグレードとロールバック
アップグレードが置き換えるのはバイナリであり、別の製品へ移行するわけではありません。 データディレクトリ、監査署名鍵、TLS マテリアルはそのまま残り、新しいスキーマ マイグレーションはエンジンが起動時に適用します。このページは「このリリースを 適用すべきか」から「以前の版へ戻す必要がある」までの運用手順です。
どのアップグレード経路を使うか
Section titled “どのアップグレード経路を使うか”バイナリを新しくする方法は 4 つあり、いずれも同じ結果に到達します。
| インストール形態 | 経路 |
|---|---|
| deb・rpm・apk・AUR パッケージ | パッケージマネージャ。パッケージからインストール |
| ホスト上のバイナリ、systemd（パッケージ由来ではない） | olivares upgrade — このページ |
| Docker または Podman コンテナ | docker compose exec olivares olivares upgrade を実行してから、コンテナを再作成します。イメージは変更できないため、リリースはデータボリューム（データディレクトリ配下の ota/）に保存され、イメージのバイナリは起動のたびに、そのリリースがイメージより新しい間、または同じバージョンを別にビルドしたものである間はそれを起動します。ota/ を削除すると、コンテナはイメージのバイナリに戻ります。コマンドは Docker と Compose にあります。 |
| 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 0.4リリースチャネル
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パッケージインストール（deb、rpm、apk、AUR）では、何かをダウンロードする前に終了コード 2 で拒否されます。
上の表のとおり、パッケージマネージャを使ってください。--check は引き続き計画を表示します。
コマンドが行う処理と、その順序の理由は次のとおりです。
- ビルドに埋め込まれた Ed25519 リリース鍵に対して、チャネルマニフェストを
ダウンロードし、その署名をオフラインで検証します。信頼の起点はトランスポート
ではなく署名です。鍵が埋め込まれていないビルドでは、
--pubkeyで鍵を 指定する必要があります。未検証の経路はありません。 - 古い版への移行を拒否します。 実行中の版より古いバージョンのインストールは、
--force-rollbackを指定しない限りブロックされます。この指定は監査エントリに 記録されます。 - バイトが実行される前に、アーティファクトをマニフェストの署名済み SHA-256 に 結び付けます。
- 候補をプローブしてからアトミックに置き換え、置き換えたバイナリの タイムスタンプ付きバックアップを残します。新しくインストールしたバイナリが 実行できなければ、自動的にそのバックアップへ戻します。
- 実行中のプロセスには触れません。 置き換えるのはディスク上のファイルです。 サービスを再起動した時点で新しいコードが引き継ぎます。
スクリプトから実行し、確認プロンプトに答える人がいない場合は --yes を
追加してください。
手順 4 の自動ロールバックが検査するのは version であり、サービス起動やデータベース互換性ではありません。
次の再起動でマイグレーションされたストアは復旧しません。
エアギャップ環境へのインストール
Section titled “エアギャップ環境へのインストール”エアギャップ環境のデプロイメントは更新ホストへ接続しません。すでに信頼している手段で バンドルを持ち込み、ローカルファイルからインストールします。信頼していたのは元から ネットワークではないため、検証は同じです。
オフラインのインストールには Enterprise が必要です。Community は --bundle --check でバンドルを検証し、ライセンスの読み取りやインストールは行いません。
olivares upgrade --bundle ./olivares-release.tar.gz --check段階的ロールアウトと無人チェック
Section titled “段階的ロールアウトと無人チェック”マニフェストは段階的ロールアウトのコホートを指定できるため、最初は環境の一部だけに
リリースを届けられます。--if-eligible を指定すると、ノードはそのコホートに属する
場合だけ処理し、それ以外では何もしません。
olivares upgrade --if-eligible --yes組み込みタイマーはこの形式で実行します。メンテナンス時間内にこのコマンドを呼ぶ systemd タイマーとサービスを出力するには、次を実行します。
olivares upgrade --install-timer --timer-schedule 'Sun *-*-* 03:00:00'デフォルトでは unit を標準出力へ表示し、--timer-dir は指定された場所へ書き込みます。
これはオプトインであり、自動的にスケジュールされるものはありません。
パッケージインストールでは、このコマンドは拒否されます。/usr/bin/olivares はパッケージ
マネージャーの管理下にあるため、終了コード 2 で終わり、unit を書き込まず、更新の経路を示します。
それはホストのパッケージマネージャーで、Olivares アプライアンスでは systemctl start olivares-appliance-update.service です。
--enterprise --connect のときは olivares license connect refresh も示します。判定はパスで行うため、
install.sh --bindir /usr/bin がそこに置いたバイナリも拒否されます。
コンソールには同じ情報の読み取り専用側があります。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 “ロールバック”以前の実行ファイルは新しいものの隣に保存され、コマンドがそのパスを表示します。 このコピーはデータの復旧ポイントではありません。
古いバイナリは、自身が対応するバージョンより新しい core スキーマを拒否します。 追加的なマイグレーションでも同じです。古いバイナリやイメージを再配置してもスキーマは戻りません。 マイグレーション履歴を編集したり、この拒否を回避したりしないでください。
- ストアを使うすべてのエンジンを停止し、アップグレード済みデータ、サービス設定、 TLS マテリアル、外部のシーラー鍵を保存します。
- 以前のリリースのバイナリで、アップグレード前の DR バンドルを復元します。
バックアップとリストアに従ってください。SQLite は新しい
データディレクトリ、または
dr restore --in-placeと--operator、--reasonを使用し、 復旧確認まで自動保存されたファイルを保持します。PostgreSQL はolivares db initで空の復元先を 作り、その--dsn、--owner-dsn、--admin-dsnと署名鍵用の新しいディレクトリを指定します。 - 台帳と監査鍵の検証成功を確認します。サービスのデータディレクトリ、ボリューム、PostgreSQL DSN を 復元済みストアと対応する署名鍵に向けてから、以前のリリースを起動します。
- サインインし、復元したデータとサービスの状態を確認します。
復旧は保存時点へ戻ります。バックアップ後の書き込みは復元済みストアにないため、照合用に アップグレード済みストアを保持してください。バンドルとパスフレーズまたは KEK がなければ、 実行ファイルの交換でこの復旧はできません。
--force-rollback は古い実行ファイルのインストールを許可し、監査ログに記録します。
core スキーマ検査や最低バージョンゲートを回避せず、データも復元しません。
最低バージョン未満の場合は、中間リリースを経由してください。
本番アップグレード前に復旧経路をテストする
Section titled “本番アップグレード前に復旧経路をテストする”検証済みの以前のリリースを一時的な SQLite データディレクトリで起動し、セットアップと
サインインを完了して停止します。その dr backup と dr verify でバンドルを作成・検証します。
同じストアで候補を起動し、サインインして停止します。スキーマが以前の版の上限を超えた場合、
以前の版は core schema version newer than this binary supports で失敗する必要があります。
以前の dr restore で新しいディレクトリに復元します。終了コード 0 と台帳検証成功を確認し、
そこで以前の版を起動して、サインイン、元の監査公開鍵、保存データを確認します。
復元やサインインが失敗した場合、復旧テストは失敗です。
SQLite 復旧の測定結果（2026-10-08）：公式 26.10.1 は core スキーマ 18 を作成し、
新しい候補が 27 に進めました。古い版は終了コード 1（database=27 binary=18）で拒否しました。
その版の dr backup、dr verify、dr restore は終了コード 0 でした。アップグレード前の
バンドルを新しいディレクトリに復元すると、元のアカウントでサインインでき、元の監査公開鍵を確認できました。
問題が発生した場合
Section titled “問題が発生した場合”| 症状 | 意味 | 対処 |
|---|---|---|
--check が UNKNOWN を表示する |
インストール済みバージョンを測定できず、順序を判定できない | --current-version に、インストール済みと分かっているバージョンを指定する |
min_ver が古すぎると示す |
現在の版への直接インストールをリリースが拒否している | 指定された中間リリースへ先にアップグレードする |
置き換え後の実行ファイルが version 検査に失敗 |
実行ファイル検査の失敗 | コマンドが保存済み実行ファイルを復元する。ログを確認する |
| 再起動後のサービスが失敗、または古い版が新しい core スキーマを拒否 | 実行ファイル検査の範囲外 | サービスを停止し、ロールバック手順でアップグレード前の DR バンドルを復元する |
--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）では、エンジン自身のログをストリーム表示します。