OpenRun, Docker ve Kubernetes üzerindeki SQLite uygulamaları için Litestream replication'ı yerleşik hale getiriyor

OpenRun ne ekledi

Docker, Podman veya Kubernetes üzerinde web uygulamaları ve iç araçları dağıtmak için kullanılan açık kaynak, self-hosted bir GitOps platformu olan OpenRun, SQLite uygulamaları için yerleşik Litestream desteği ekledi. Hacker News ana sayfasında da görünen OpenRun duyurusuna göre, uygulama veritabanları AWS S3 veya herhangi bir S3 uyumlu object store'a — Cloudflare R2, MinIO ve SeaweedFS örnek veriliyor — sürekli olarak replicate ediliyor ve OpenRun boş veya yeniden oluşturulmuş bir uygulama volume'u algıladığında geri yükleme otomatik olarak gerçekleşiyor.

Amaç, uygulama geliştiricilerin SQLite'ı tam olarak eskisi gibi kullanmaya devam etmesi: Litestream kurmuyorlar, uygulamada object storage yapılandırmıyorlar, container imajını değiştirmiyorlar veya geri yükleme mantığı yazmıyorlar. Litestream sunucu yapılandırmasında bir kez tanımlanıyor ve replication ile geri yüklemeyi OpenRun, uygulama container'ının dışında yönetiyor.

Kurulum nasıl çalışıyor

Litestream backend'i sunucunun openrun.toml dosyasında bir kez tanımlanır; bir bucket, region ve environment secret'lardan çekilen credentials'a işaret eder. Bir SQLite servisi bu yapılandırmaya referans verir ve uygulamalar servise bağlanır:

openrun service create sqlite/main --is-default --config litestream_config=mainbackup openrun app create --bind sqlite --approve github.com/example/notes-app /notes

Aynı uygulama, Git'te tutulan bir apply dosyasında da tanımlanabilir ve openrun apply, Kubernetes apply gibi davranır: yeni uygulamalar oluşturur, yapılandırması değişen uygulamaları günceller ve gerisine dokunmaz; böylece SQLite binding tamamen GitOps üzerinden yönetilebilir.

Binding'e sahip uygulamalar /data yoluna mount edilmiş kalıcı bir volume alır ve veritabanlarını inject edilen environment variable'lar (SQLITE_DB_PATH ve SQLITE_DIR) üzerinden bulur. Uygulamanın o dizinde oluşturduğu her *.db dosyası, runtime'da oluşturulan dosyalar dahil, replicate edilir. Varsayılan ayarlarla değişiklikler genellikle yaklaşık bir saniye içinde object storage'a ulaşır ve sync aralığı yapılandırılabilir.

Tek node ile Kubernetes karşılaştırması

Docker ve Podman'da OpenRun, Litestream'i uygulamanın data volume'unu paylaşan, uygulama başına bir companion container içinde çalıştırır. Restore container'ları, volume boşken uygulama başlamadan önce çalışır ve boşta olan bir uygulama sıfıra ölçeklendiğinde Litestream container'ı son bir sync yapar ve durur.

Kubernetes'te binding'in volume'u bir PersistentVolumeClaim olur ve OpenRun, uygulama pod'una bir restore init container ve yerel bir Litestream sidecar (Kubernetes 1.29 veya daha yenisi) ekler. Sidecar, uygulama container'ından önce başlar ve ondan sonra sonlandırılır; bu da düzgün kapanma sırasında son bir sync yapılmasına olanak tanır. SQLite binding'ine sahip uygulamalar tek replica olarak Recreate update stratejisiyle çalışır; bu, bir güncelleme sırasında iki uygulama pod'unun aynı SQLite volume'una yazmasını engeller.

Litestream, OpenRun binary'sine bir Go kütüphanesi olarak gömülüdür; böylece platformun kendi metadata ve audit veritabanları da ekstra bir süreç çalıştırmadan, metadata.litestream_config ayarı üzerinden aynı şekilde replicate edilebilir.

Kurtarma ve izleme

Kaybolan bir uygulama volume'u operatör müdahalesi olmadan ele alınır: bir sonraki başlatılışta OpenRun boş volume'u görür, veritabanlarını replica'dan geri çeker ve uygulamayı geri yüklenmiş verilerle başlatır. Replica'lar binding'e göre anahtarlandığından, aynı binding'i yeni bir uygulamaya bağlamak verileri o uygulamanın yeni volume'una da geri yükler.

Tam node kaybı için belgelenen prosedür, OpenRun'ı yeni bir makineye kurmak ve sunucuyu aynı config dosyasıyla başlatmaktır; sunucu metadata'sını replica'dan geri yükler ve uygulamalar, binding'ler, sürümler ve audit geçmişi intact bir şekilde geri gelir; her uygulama ilk istekte yeniden dağıtılır ve kendi verisini geri yükler. OpenRun, bu senaryonun CI'da uçtan uca test edildiğini, testin sunucuyu hard-kill ettiğini ve her şeyin object storage'dan yeniden inşa edildiğini doğrulamadan önce container'ları, volume'ları ve kurulum dizinini sildiğini söylüyor.

İzleme, her replicate edilmiş veritabanının durumunu raporlayan openrun replication status ile yapılabilir. Durumlar, object storage'daki replica listesini replication container'ının durumuyla birleştirir; böylece object storage hâlâ güncel bir replica tutsa bile başarısız olan bir replication container'ı görünür olur.

Neden önemli

SQLite, işletilecek bir veritabanı sunucusu olmadığından iç araçlar ve küçük web uygulamaları için güçlü bir tercihtir; ancak tek node üzerinde dayanıklılık her zaman zayıf nokta olmuştur. Litestream replication sorununu çoktan çözdü, ancak şimdiye kadar bu altyapıyı kendiniz bir araya getirmeniz gerekiyordu: sidecar'lar, başlangıçta geri yükleme hook'ları, storage credentials ve imaj değişiklikleri. Bu işi platformun içine absorbe ederek — aynı uygulama yapılandırması tek bir Docker host'unda da Kubernetes'te de çalışarak — OpenRun, self-hosted SQLite uygulamalarını bir veritabanı servisi çalıştırmadan production'da kullanılabilir hale getiriyor. Ödünleşim açık ve belirtmeye değer: replication asenkron olduğundan ani bir çökme yaklaşık olarak en son bir saniyelik yazmaları kaybedebilir. OpenRun'ın uygulamalar için önerisi, bu pencereyi küçük tutmak için WAL modu, busy timeout'lar ve kısa yazma transaction'larına işaret ediyor.