LitestreamでDockerとKubernetes上でSQLiteアプリを実行する

ブログ Litestream組み込みのSQLiteを本番環境で利用する Litestreamレプリケーションによる本番環境でのSQLite コピーページ コピー（Markdown形式） Markdown形式で表示 2026年8月25日 OpenRunは、Docker、Podman、またはKubernetes上でWebアプリや内部ツールをデプロイするためのオープンソースのセルフホスト型GitOpsプラットフォームです。アプリケーションの変更を必要とせずに、認証、認可、監査、RBACを提供します。 OpenRunは、SQLiteアプリ向けのLitestreamサポートを組み込みました。アプリのデータベースは、AWS S3またはCloudflare R2、MinIO、SeaweedFSなどのS3互換オブジェクトストレージに継続的にレプリケートされます。復元は自動で行われます。OpenRunは、空のアプリボリュームまたは再作成されたアプリボリュームを検出すると、アプリを起動する前にレプリカからデータベースを復元します。この同じセットアップは、Docker/Podmanを使用する単一ノードでも、Kubernetes上でも機能します。 その結果、アプリケーション開発者は、Litestreamのインストール、オブジェクトストレージの設定、コンテナイメージの変更、または復元ロジックの実装を行う必要なしに、SQLiteを通常通り使用できます。 背景 SQLiteは、内部ツールや小規模なWebアプリに最適です。データベースはファイルベースで、読み込みは高速であり、個別のデータベースサーバーを運用する必要がありません。LitestreamはSQLiteの変更をオブジェクトストレージに継続的にレプリケートし、ノード外での耐久性のあるバックアップとポイントインタイムリカバリを提供します。 しかし、プラットフォーム統合がない場合、アプリと並行してLitestreamをデプロイし、レプリカを設定し、起動時のデータベース復元を処理する必要があります。 OpenRunは、その運用作業をプラットフォームに移行させます。Litestreamの設定はサーバー構成で一度定義され、OpenRunはアプリコンテナの外側でレプリケーションと復元を管理します。アプリイメージは変更されず、新しいSQLiteアプリはLitestream固有の設定なしでレプリケーションを使用できます。 SQLiteアプリのデプロイ OpenRunサーバー構成でLitestreamを一度定義します。 openrun.toml [litestream.mainbackup] bucket = "openrun-backups" region = "us-east-1" access_key_id = '{{secret_from "env" "LITESTREAM_KEY_ID"}}' secret_access_key = '{{secret_from "env" "LITESTREAM_KEY"}}' 次に、それを参照するSQLiteサービスを作成し、アプリをそのサービスにバインドします。 openrun service create sqlite/main --is-default --config litestream_config=mainbackup openrun app create --bind sqlite --approve github.com/example/notes-app / 同じアプリを宣言的に定義することもできます。Git内の他の構成ファイルと一緒に、定義をapplyファイルに配置します。 apps.star app("/notes", "github.com/example/notes-app", bindings=["sqlite"]) openrun apply --promote github.com/example/config/apps.star openrun apply はKubernetesのapplyと同様に機能します。新しいアプリを作成し、構成が変更されたアプリを更新し、残りはそのままにします。SQLiteバインディングを含むすべてのアプリ管理は、GitOpsを通じて行うことができます。 これが全体のセットアップです。アプリは/dataにマウントされた永続ボリュームを取得し、注入された環境変数（SQLITE_DB_PATH、SQLITE_DIR）を通じてデータベースを見つけます。そのディレクトリ内でアプリが作成するすべての*.dbファイルは、実行時に作成されたファイルも含めてレプリケートされます。 変更は通常、デフォルトの1秒間隔でレプリケートされます（sync_intervalは設定可能）。 単一ノード（DockerおよびPodman） DockerおよびPodmanでは、OpenRunはアプリごとのコンパニオンコンテナでLitestreamを実行し、アプリのデータボリュームを共有します。アプリコンテナが空のボリューム上で起動する前に、復元コンテナがレプリケートされたデータベースをプルバックします。アプリがアイドル状態のためゼロにスケールダウンすると、Litestreamコンテナは最終同期を実行して停止します。 サーバー自身のメタデータも同様にレプリケートできます。LitestreamはGoライブラリとしてOpenRunバイナリに組み込まれているため、サーバー構成でmetadata.litestream_configを設定すると、追加のLitestreamプロセスなしでメタデータと監査データベースがレプリケートされます。 Kubernetes 同じアプリ構成は、OpenRunがKubernetesクラスタにデプロイされる場合にも機能します。バインディングのボリュームはPersistentVolumeClaimになり、OpenRunはアプリポッドに復元initコンテナとネイティブLitestreamサイドカー（Kubernetes 1.29以降）を自動的に追加します。サイドカーはアプリコンテナの前に起動し、その後終了するため、Litestreamは秩序あるシャットダウン中に最終同期を実行できます。SQLiteバインディングを持つアプリは、Recreateアップデート戦略を持つ単一レプリカとして実行され、アップデート中に複数のアプリポッドが同じSQLiteボリュームに書き込むことを防ぎます。 ボリュームまたはノードの損失が発生した場合 失われたアプリボリュームの場合、アプリの観点からはリカバリは自動です。アプリが次に起動すると、OpenRunは空のボリュームを認識し、復元コンテナを実行してレプリカからデータベースをプルバックし、復元されたデータに対してアプリコンテナを起動します。レプリカはバインディングによってキー付けされるため、同じバインディングを新しいアプリにアタッチすると、そのアプリの新しいボリュームにデータが復元されます。 ノード全体の損失の場合、メタデータレプリケーションが有効になっていると、リカバリ手順は次のようになります。 新しいマシンにOpenRunをインストールします。 同じ構成ファイルでサーバーを起動します。 起動時に、サーバーはメタデータデータベースが見つからないことを認識し、レプリカからメタデータと監査データベースを復元し、すべてのアプリ、バインディング、サービス、バージョン、監査履歴がそのままの状態ですべて復旧します。その後、各アプリは初回リクエスト時に再デプロイされ、コンテナが起動する前に独自のレプリカからSQLiteデータを復元します。ノードを復旧するには、サーバー構成とその参照されているシークレットのみが必要です。OpenRunのメタデータとレプリケートされたアプリデータはオブジェクトストレージから復元されます。 したがって、アプリケーションデータとOpenRun自身のメタデータは、同じオブジェクトストレージバックエンドから復旧できます。レプリケーションは非同期です。通常の条件下では、デフォルトの1秒のsync_intervalで、突然のクラッシュは、まだオブジェクトストレージに到達していない書き込みの約1秒分を失う可能性があります。 ノード損失シナリオは、CIテストでエンドツーエンドで実行されます。テストでは、サーバーをハードキルし、コンテナ、ボリューム、およびメタデータデータベースを含むOpenRunインストールディレクトリを削除します。その後、オブジェクトストアからすべてが自動的に再構築されることを検証します。これには、アプリのSQLiteデータも含まれます。 監視 openrun replication status は、すべてのレプリケートされたデータベースの状態を表示します。 $ openrun replication status -f table Kind Target Config State LastSync Files Apps metadata metadata mainbackup healthy 2026-08-25 16:31:42 - metadata audit mainbackup healthy 2026-08-25 16:31:42 - app /auto/app_prd_.../sqlite (prod) mainbackup healthy 2026-08-25 23:31:30 data.db / notes app /auto/app_prd_.../sqlite (staged) mainbackup pending - - stage.localhost:/notes アプリの状態は、オブジェクトストレージのレプリカリストとレプリケーションコンテナの状態を組み合わせるため、オブジェクトストレージに最新のレプリカが含まれている場合でも、レプリケーションコンテナの失敗は表示されます。 完全な設定オプションについてはLitestreamリファレンスを、アプリのベストプラクティスについてはSQLiteホスティングユースケース（WALモード、ビジータイムアウト、短い書き込みトランザクション）を参照してください。 レプリケーションステータスはコンソールアプリでも確認できます。ライブデモをご覧ください。 Webアプリ向けのPostgreSQLおよびMySQLサービスバインディング