2026'da Wallabag'ı Kendi Sunucunda Barındırma: İçe Aktarmalar, Veritabanı ve Arka Plan İşleri

En kısa Wallabag demosu, bir process'in 80 portunu dinlediğini kanıtlar. Production için daha güçlü kanıt gerekir. Container değiştirildikten sonra bile şu senaryoyu başarıyla tamamlamalıdır: normal bir makaleyi ve sorunlu bir sayfayı kaydetmek, arka planda içerik çekmeyi çalıştırmak, bir mobil istemciyi senkronize etmek ve arşivlenmiş içerikte arama yapmak.

Wallabag net bir amaçla kullanıma alınıyor: sayfa karmaşasını ortadan kaldıran bir read-it-later arşivi. En yaygın deployment tuzağı, domain değişkeni yanlış olduğu için asset'lerin veya login redirect'lerinin HTTP kullanmasıdır. Bu nedenle public URL yönetimi ve kalıcı durum, image'ın başlatılması kadar dikkatle ele alınmalıdır.

Yerel komutu incelenebilir bir servise dönüştürme

Aşağıdaki komut, her external servisi provision ediyormuş gibi davranmadan container sınırını görünür hâle getirir.

docker run -d \
  --name wallabag \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallabag-data:/var/www/wallabag/data \
  -e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
  wallabag/wallabag:latest

Ingress'i açmadan önce çözümlenen environment'ı, mount'ları ve listener'ı inceleyin. Postgres veya MariaDB, Redis ve zamanlanmış import worker'ları için gözden geçirilmiş bağlantı ayarlarını ekleyin; private servisler için private isimler kullanın. Başarılı bir launch, docker ps çıktısında Up görülmesiyle değil; normal bir makaleyi ve sorunlu bir sayfayı kaydedebildiğiniz, arka planda içerik çekmeyi çalıştırabildiğiniz, bir mobil istemciyi senkronize edebildiğiniz ve arşivlenmiş içerikte arama yapabildiğiniz noktada tamamlanır.

Wallabag'ın bağımlılıkları

Wallabag'ın çevresine üç sınır çizin: 80 portuna ingress, kalıcı durum ve supporting requirements. Container değiştirilebilir, ancak diğer iki alanın açık sahipleri olmalıdır. Wallabag'ın network contract'ı Postgres veya MariaDB, Redis ve zamanlanmış import worker'larından oluşur. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Wallabag'a scope'u sınırlandırılmış bir service credential verin.

Temiz bir istemci normal bir makaleyi ve sorunlu bir sayfayı kaydedebildiğinde, arka planda içerik çekmeyi çalıştırabildiğinde, bir mobil istemciyi senkronize edebildiğinde ve arşivlenmiş içerikte arama yapabildiğinde diagram tamamlanmış olur. Page fetching, parser çalışması, image download'ları, queue'lar ve veritabanı büyümesi için timing ve resource verilerini toplayın. Transaction başarısız olursa, belgelenen şekilde davranmayan ilk sınır; routing, local capacity veya supporting service alanlarından hangisini incelemeniz gerektiğini gösterir.

Bootstrap sonrasında Wallabag'ı güvenli hâle getirme

Bir local tutorial'daki security varsayımlarını olduğu gibi almayın. Wallabag'a özgü endişe, default credential'ların korunması veya trusted proxy yapılandırmasının atlanmasıdır. Bu nedenle production ortamında default credential'lar kaldırılmalı, import token'ları korunmalı ve reader dışarıya açılmadan önce trusted proxy'ler yapılandırılmalıdır.

SYMFONY__ENV__DOMAIN_NAME bir configuration değeridir, secret değildir; değerini açıkça belirtirken Wallabag'ın kullandığı ayrı credential'ları koruyun. Filesystem ve network erişimini scope'landırın, setup endpoint'lerini koruyun ve page fetching, parser çalışması, image download'ları, queue'lar ve veritabanı büyümesi için upload, request veya execution limit'leri tanımlayın.

Public origin'i belirsizliği ortadan kaldıracak şekilde tanımlama

Wallabag için tek bir HTTPS hostname yayınlayın; raw 80 portunu private tutun. Domain name değerini son HTTPS URL'si olarak ayarlayın. Böylece browser'ların ve API client'larının birbiriyle yarışan iki farklı adres öğrenmesi önlenir.

Temiz bir istemciden bilinen iyi transaction'ı çalıştırın ve başarısız olan ilk request'i inceleyin. DNS veya TLS yanlışsa custom-domain rehberini kullanın. “Domain değişkeni yanlış olduğu için asset'ler veya login redirect'leri HTTP kullanıyor” durumunu, route doğrulandıktan sonra ayrı bir application diagnosis olarak ele alın.

Değiştirilebilir container'ları kalıcı verilerden ayırma

Kalıcı recovery set'i veritabanı, image'lar, içe aktarılan içerik ve configuration'dan oluşur. Bootstrap işleminden önce /var/www/wallabag/data yolunu mount edin, zararsız örnek veriler yazın ve bu yolun gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Bir volume verileri container değişiminden korur; ancak host kaybına, yanlışlıkla silinmeye veya application-level corruption'a karşı koruma sağlamaz.

Veri kaynağını anlayan yedeklemeler alın: gerektiğinde canlı veritabanları için logical dump kullanın ve dosyaları yalnızca tutarlı bir durumdan kopyalayın. Wallabag host'undan uzakta, encrypted bir kopya bulundurun. Restore için acceptance criterion nettir — makaleler, tag'ler, annotation'lar, kullanıcılar ve API token'ları geri gelmeli, mobil istemci senkronize olmalıdır. Restore ile test edilmiş yedekleme rehberi, yalnızca job başarısının neden yeterli olmadığını açıklar.

Wallabag production'a alınmadan önce toplanacak kanıtlar

Wallabag için launch öncesinde bilinen iyi bir transaction tanımlayın: normal bir makaleyi ve sorunlu bir sayfayı kaydetmek, arka planda içerik çekmeyi çalıştırmak, bir mobil istemciyi senkronize etmek ve arşivlenmiş içerikte arama yapmak. Ön koşullarını, beklenen response'u ve cleanup adımlarını secret değerler olmadan version control'e koyun. Bu referansı oluşturmak için kullanılan image'ı pin'leyin.

Bir replacement'ı ve bağımsız bir restore'u doğrulamak için transaction'ı kullanın. Restore edilen servis yalnızca makaleler, tag'ler, annotation'lar, kullanıcılar ve API token'ları geri geldiğinde ve mobil istemci senkronize olduğunda kabul edilebilir. Aynı zamanda page fetching, parser çalışması, image download'ları, queue'lar ve veritabanı büyümesini gözlemleyin; en yavaş veya en kısıtlı bölümü service-level alert'e dönüştürün.

Gate için bir negative case de gerekir: test identity'sinin Postgres veya MariaDB, Redis ve zamanlanmış import worker'larına erişimini geçici olarak engelleyin. Wallabag'ın verileri korurken actionable bir error ürettiğini doğrulayın, geçerli durumu geri yükleyin ve bilinen iyi transaction'ı tekrarlayın. Her iki sonucu da saklamak, yüzeysel bir health endpoint'inin production'daki tek kanıt hâline gelmesini önler.

Wallabag'ı gerçek darboğazı etrafında işletme

Dashboard'ları page fetching, parser çalışması, image download'ları, queue'lar ve veritabanı büyümesi etrafında oluşturun. Bu workload context'i olmadan CPU grafiği, Wallabag'ın neden yavaş olduğunu açıklayamaz. Zararsız test verileri kullanarak normal bir makaleyi ve sorunlu bir sayfayı kaydetmeyi, arka planda içerik çekmeyi çalıştırmayı, bir mobil istemciyi senkronize etmeyi ve arşivlenmiş içerikte arama yapmayı deneyen synthetic veya zamanlanmış bir check ekleyin.

Upgrade öncesinde şu application-specific riski hesaba katın: Wallabag migration'ları, parser davranışı ve worker configuration'ı, temsili kayıtlı sayfalarla test edilmelidir. Yakın tarihli bir yedeği isolated bir deployment'a restore edin, migration'ları orada çalıştırın ve davranışı karşılaştırın. Domain değişkeni yanlış olduğu için asset'ler veya login redirect'leri HTTP kullanıyorsa, ilgisiz ayarlara dokunmadan önce ilgili sınırı — public origin, storage veya dependency — inceleyin.

Platform katmanı için Dockup kullanma

Wallabag için Dockup route'u ve TLS certificate'ını oluşturabilir, mount'ları koruyabilir, secret'ları iletebilir ve Postgres veya MariaDB, Redis ve zamanlanmış import worker'larını private networking üzerinde konumlandırırken deployment'ı Dockup'a veya bağlı server'lara yapabilir.

Release gate yine somut Wallabag transaction'ıdır: normal bir makaleyi ve sorunlu bir sayfayı kaydetmek, arka planda içerik çekmeyi çalıştırmak, bir mobil istemciyi senkronize etmek ve arşivlenmiş içerikte arama yapmak. Restore durumunu da doğrulayın — makaleler, tag'ler, annotation'lar, kullanıcılar ve API token'ları geri gelmeli, mobil istemci senkronize olmalıdır. Bu iki kontrol, deployment'ın çalışıp çalışmadığını ve kurtarılabilir olup olmadığını gösterir.

Sık sorulan sorular

Production deployment'ı için Wallabag neye ihtiyaç duyar?

Wallabag container'ını 80 portunda tek bir HTTPS origin üzerinden route edin. Supporting network requirement; Postgres veya MariaDB, Redis ve zamanlanmış import worker'larıdır. Normal bir makaleyi ve sorunlu bir sayfayı kaydedemediğiniz, arka planda içerik çekmeyi çalıştıramadığınız, bir mobil istemciyi senkronize edemediğiniz ve arşivlenmiş içerikte arama yapamadığınız sürece Wallabag'ı hazır kabul etmeyin.

Wallabag'ın hangi verileri yedeklemeye dahil edilmelidir?

/var/www/wallabag/data yolunu kalıcı hâle getirin ve database, image'lar, içe aktarılan içerik ve configuration'ı aynı recovery manifest'ine dahil edin. Temiz bir Wallabag restore'u yalnızca makaleler, tag'ler, annotation'lar, kullanıcılar ve API token'ları geri geldiğinde ve mobil istemci senkronize olduğunda başarılı sayılır.

Wallabag reverse proxy arkasında HTTPS gerektirir mi?

Public Wallabag origin'i için HTTPS kullanın ve 80 portunu internal route üzerinde tutun. Wallabag ayarını doğru uygulayın: domain name değerini son HTTPS URL'si olarak ayarlayın. Wallabag için HTTPS, credentials veya kullanıcı içeriğinin aktarım sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Wallabag upgrade'i nasıl test edilmelidir?

Güncel Wallabag durumunu isolated bir deployment'a restore edin, aday sürümü uygulayın ve acceptance transaction'ını tekrarlayın. Özellikle dikkatli olun; Wallabag migration'ları, parser davranışı ve worker configuration'ı, temsili kayıtlı sayfalarla test edilmelidir. Data-migration ve rollback sınırları anlaşılana kadar önceki Wallabag image'ını saklayın.