OpenBot Desktopは、ユーザーの既存の実行環境への干渉を抑え、更新中のデータ削除リスクを減らす新しい試験版を公開した。個人のパソコンでアプリを使うユーザーは、アプリ専用の実行空間と事前にダウンロードする更新を通じて、インストールと更新を管理することになる。
CopilotKitが11月11日に公開したバージョンは1.0.2-rc.3だ。中心となるのは、アプリの実行空間の分離、古い実行ツールの自動更新、新バージョンのインストール時のボットと会話の保持である。
1. OpenBot専用マシンで実行
Podmanマシンは、コンテナを動かす独立した実行空間だ。以下のコマンドで作成すると、マシン内で管理者権限なしに実行するrootless方式になる。従来のOpenBotは、管理者権限が必要なローカルバックエンド、つまりアプリの機能処理を担う構成要素をここで実行しようとして、設定変更画面で止まる問題があった。
podman machine init新バージョンは、マシン内で管理者権限で実行するrootful方式の専用マシンを使う。Windowsではユーザーマシンと並行して実行し、Macではユーザーマシンがrootlessの場合に専用マシンを使う。Macの既存のrootfulマシンやDockerは従来どおり使う。
専用マシンの名前はopenbotだ。Windowsでは、Dockerツールがエンジンに接続する既定の経路であるdocker_engineを占有しない。ユーザーの既定のPodman接続も変更しないため、アプリをインストールしても既存ツールの接続先は維持される。
2. 古いエンジンは実行前に更新
インストール時とアプリ起動時にエンジンのバージョンを確認し、実行基準を下回れば更新する。リリースノートではDocker Composeは2.27.2未満が対象で、これに対応するDocker Desktopの基準は4.32未満だ。
Podmanは6.1未満なら更新する。Docker Desktop 4.27では、設定が完了しても起動段階でComposeのエラーにより止まる事例があった。新バージョンは、コンテナの実行構成を読み込むComposeが動作する前にエンジンを検査し、この問題に対処する。
Docker DesktopはDockerの更新経路から取得する。ファイルの変更有無を判別する値であるチェックサムと、配布者やファイルの出所を証明する情報である署名を確認し、既存のインストールに上書き更新する。イメージとコンテナ、コンテナ外にデータを保持する領域であるボリュームは保持する。PodmanはOpenBotが固定したインストールファイルで更新し、それまで実行中だったユーザーマシンとコンテナも更新後に再起動する。
3. ダウンロードを前倒しし、アプリデータは残す
従来はインストールを押してから必要なファイルを順番に取得していた。新バージョンは最初の画面から、エンジンイメージとPodmanのインストールファイル、配布ファイル、アプリのインストールに必要なファイル群とアプリソフトウェアをまとめてダウンロードする。ログインや権限の承認中にも準備を進める方式だ。
会社発表によると、Macへの新規インストール例でエンジンイメージは937 MB、標準ボット用ソフトウェアは約1.1 GBだった。中断したダウンロードは次回の起動時に再開し、使用前にはファイルの整合性確認値をあらかじめ指定した値と照合する。
新バージョンが出ると、使用中のボットの構成要素と変更されたバックエンドもバックグラウンドで先に取得する。準備が整えばユーザーが更新を開始し、アプリは停止・バックアップ・新バージョンの適用・再起動の順で進める。自動の事前ダウンロードはディスクに空きがある場合に動作し、正式公開前の検証用バージョンである候補版と、外部公開前に内部で作成したバージョンである内部ビルドは対象外となる。
Windowsで既存バージョンに新しいインストールファイルを実行すると、旧アンインストーラーのデータ削除確認画面を経ずに更新する。設定のアプリ削除機能は、まずOpenBotが起動したサービスを止める。データ削除を選ぶとOpenBotマシンとバックエンド、インストールフォルダー内のOpenBotファイルを削除するが、そのフォルダーに置いたユーザーファイルは残す。削除を選ばなければ、関連項目は停止状態で残り、再インストールに使われる。
4. アップグレード前にデータベースを確認
今回のリリースでは、データベース構造を変更して既存データを新バージョンの構造に合わせるマイグレーションを追加で実行しない。1.0.1のデータベースをそのまま使い、データベースの項目と構造を定める枠組みであるスキーマも0088_approval_reviewer_guidanceの状態を維持する。
1.0.0や0.3.xから更新するユーザーは、この中間バージョンのマイグレーションを経る。そのためアップグレードの準備は、現在のデータベースのバージョンを確認し、更新前の状態のバックアップを確保することから始まる。
5. 環境分離と自動管理のトレードオフ
専用マシンはユーザー環境への干渉を減らし、エンジンの自動更新は起動エラーをインストール管理の段階で扱うようにする。更新ファイルの先行取得も、ユーザーが更新を押した後に待っていたダウンロードを、作業中に移すものだ。
その代わり、Macでは同意を得てrootlessのユーザーマシンを一時停止し、アプリ終了時にコンテナとともに再開する。Docker Desktopの更新時もコンテナが一時停止してから再起動する。既存のユーザーマシン上のインストール環境は専用マシンでは初期状態から始まり、以前のデータは元のマシンに残る。1.0.0・0.3.xから移行したデータベースを元に戻すには、アップグレード前のバックアップを復元する必要がある。
今回の版の要点は、既存の作業環境への干渉や更新時のミスを減らしながら、アプリの実行とデータの保持を一体で管理することにある。