OpenRun добавила встроенную поддержку Litestream для SQLite-приложений. В объявлении компания объясняет, как настроить репликацию и автоматическое восстановление в Docker, Podman и Kubernetes.

Интеграция непрерывно реплицирует базы в AWS S3 или S3-совместимые хранилища и восстанавливает их из реплики до запуска приложения, если том пуст или пересоздан. OpenRun управляет репликацией и восстановлением вне контейнера приложения, поэтому его образ остаётся неизменным.

В Docker и Podman Litestream работает в отдельном companion-контейнере для каждого приложения и делит с ним том данных. В Kubernetes OpenRun добавляет restore init container и нативный sidecar Litestream, при этом требуется Kubernetes 1.29 или новее.

Репликация работает асинхронно, поэтому при стандартном интервале синхронизации внезапный сбой может привести к потере примерно последней секунды записей. OpenRun проверяет сценарий полной потери узла end-to-end тестом в CI, включая автоматическое восстановление SQLite-данных приложения из объектного хранилища.

Проверка утверждений:

  • OpenRun опубликовала материал типа announcement о встроенной поддержке Litestream для SQLite-приложений; он объясняет читателю, как настроить репликацию и автоматическое восстановление на Docker, Podman и Kubernetes. (подтверждено первоисточником: доказательство; «OpenRun now has built-in Litestream support for SQLite apps. App databases are continuously replicated to AWS S3 or S3-compatible object storage such as Cloudflare R2, MinIO and SeaweedFS. Restore is automatic: when OpenRun detects an empty or recreated app volume, it restores the database from the replica before starting the app. The same setup works on a single node with Docker/Podman and on Kubernetes.»)
  • Интеграция непрерывно реплицирует базы приложений в AWS S3 либо S3-совместимые Cloudflare R2, MinIO и SeaweedFS и восстанавливает базу из реплики до запуска приложения, если том пуст или пересоздан. (подтверждено первоисточником: доказательство; «App databases are continuously replicated to AWS S3 or S3-compatible object storage such as Cloudflare R2, MinIO and SeaweedFS. Restore is automatic: when OpenRun detects an empty or recreated app volume, it restores the database from the replica before starting the app.»)
  • Разработчику не требуется устанавливать Litestream, настраивать объектное хранилище, менять образ контейнера или реализовывать логику восстановления в приложении. (подтверждено первоисточником: доказательство; «The result is that application developers use SQLite normally without having to install Litestream, configure object storage, modify their container image, or implement restore logic.»)
  • Настройки Litestream задаются один раз в серверной конфигурации OpenRun, а платформа управляет репликацией и восстановлением вне контейнера приложения, поэтому его образ остаётся неизменным. (подтверждено первоисточником: доказательство; «OpenRun moves that operational work into the platform. Litestream settings are defined once in the server configuration, while OpenRun manages replication and restoration outside the app container. The app image stays unchanged, and new SQLite apps can use replication without any Litestream-specific setup.»)
  • Приложение получает постоянный том в /data и переменные SQLITE_DB_PATH и SQLITE_DIR; все созданные там файлы *.db, включая появившиеся во время работы, реплицируются, обычно примерно за секунду при стандартных настройках. (подтверждено первоисточником: доказательство; «The app gets a persistent volume mounted at /data and finds its database through injected environment variables ( SQLITE_DB_PATH , SQLITE_DIR ). Every *.db file the app creates in that directory is replicated, including files created at runtime. Changes are typically replicated within about a second by default ( sync_interval is configurable)»)
  • На Docker и Podman Litestream работает в отдельном companion-контейнере для каждого приложения и делит с ним том данных; перед стартом приложения на пустом томе restore-контейнеры возвращают базы, а при scale-to-zero выполняется финальная синхронизация. (подтверждено первоисточником: доказательство; «On Docker and Podman, OpenRun runs Litestream in a per-app companion container that shares the app’s data volume. Before the app container starts on an empty volume, restore containers pull any replicated databases back. When the app scales down to zero on idle, the Litestream container performs a final sync and stops.»)
  • На Kubernetes привязка превращается в PersistentVolumeClaim, а OpenRun автоматически добавляет restore init container и нативный sidecar Litestream; требуется Kubernetes 1.29 или новее, а SQLite-приложения запускаются в одной реплике со стратегией Recreate. (подтверждено первоисточником: доказательство; «The binding’s volume becomes a PersistentVolumeClaim, and OpenRun adds a restore init container plus a native Litestream sidecar (Kubernetes 1.29 or newer) to the app pod automatically. The sidecar starts before the app container and is terminated after it, allowing Litestream to perform a final sync during orderly shutdown. Apps with a SQLite binding run as a single replica with the Recreate update strategy, preventing multiple app pods from writing to the same SQLite volume during an update.»)
  • После полной потери узла при включённой репликации метаданных достаточно установить OpenRun на новую машину и запустить его с прежней конфигурацией; метаданные, история аудита и данные приложений восстанавливаются из объектного хранилища. (подтверждено первоисточником: доказательство; «On startup, the server finds its metadata database missing, restores the metadata and audit databases from the replica, and comes up with all apps, bindings, services, versions and audit history intact. Each app then redeploys on first request, restoring its SQLite data from its own replica before the container starts. To recover the node, you only need the server config and its referenced secrets. OpenRun’s metadata and replicated app data are restored from object storage.»)
  • Репликация асинхронна: при стандартном интервале синхронизации в одну секунду внезапный сбой может привести к потере примерно последней секунды ещё не отправленных записей. (подтверждено первоисточником: доказательство; «Replication is asynchronous. Under normal conditions, with the default one-second sync_interval , a sudden crash can lose roughly the most recent second of writes that have not yet reached object storage.»)
  • Сценарий потери узла проверяется end-to-end тестом в CI: сервер принудительно завершают, удаляют контейнеры, тома и каталог установки, после чего проверяют автоматическое восстановление из объектного хранилища, включая SQLite-данные приложения. (подтверждено первоисточником: доказательство; «The node-loss scenario is exercised end-to-end in CI tests . The test hard-kills the server, deletes the containers, volumes, and the OpenRun installation directory, including the metadata databases. It then verifies that everything is rebuilt automatically from the object store, including the app SQLite data.»)

Первоисточники:

оценка 65.8 · тип announcement · ревизия 1 · истории st-ocm2vo