Stirling PDF’yi 2026’da Kendi Sunucunuzda Çalıştırma: Yüklemeler, OCR ve Oturum Açma Güvenliği

“Stirling PDF’yi çalıştırmanın” iki farklı anlamı vardır: Bir container’ın mevcut olması veya servisin gerçek işini tamamlaması. Önemli olan yalnızca ikincisidir. Buradaki kanıt; iki PDF’yi birleştirmek, taranmış bir sayfaya OCR uygulamak, sonucu sıkıştırmak ve public proxy üzerinden yükleme ve indirme davranışını doğrulamaktır.

Stirling PDF bu amaç için kullanılır: Yaygın PDF işlemleri için web arayüzü ve API. Deployment, bu davranışın arkasındaki parçaları korumalıdır; bir port, bir volume ve bir sertifika girdidir, sonuç değildir.

İncelenmeye değer container ayarları

İlk container’ın silinip yeniden oluşturulması kolay olmalıdır. Verileri writable layer’ın dışında tutun, 8080 portunu yalnızca proxy’nin erişebileceği şekilde bind edin ve configuration’ı runtime sırasında aktarın.

docker run -d \
  --name stirling-pdf \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v stirling-pdf-data:/configs \
  -e SECURITY_ENABLELOGIN=true \
  stirlingtools/stirling-pdf:latest

İlk testten sonra image’ı sabitleyin. Son restart mesajı yerine en erken startup error mesajını okuyun, her mount’u docker inspect ile doğrulayın ve iki PDF’yi birleştirirken, taranmış bir sayfaya OCR uygularken, sonucu sıkıştırırken ve public proxy üzerinden yükleme ve indirme davranışını doğrularken log’ları takip edin. Bu sıra, hatalı bir image komutunu dependency veya permission sorunundan ayırır.

Önce Stirling PDF için başarı kriterini tanımlayın

Stirling PDF için dört konuyu birbirinden ayırın: ingress, 8080 portunu dinleyen listener, kalıcı state ve supporting service’ler ya da yerel kapasite. Yerel runtime gereksinimi, isteğe bağlı OCR language data ile büyük işler için yeterli temporary disk alanıdır. Bir replacement host’un aynı yerel kapasiteye sahip olması için bunu image ve port bilgilerinin yanında kaydedin.

Bu ayrımı tamamlanmış kabul etmeden önce bilinen ve doğru çalışan işlemi gerçekleştirin — iki PDF’yi birleştirin, taranmış bir sayfaya OCR uygulayın, sonucu sıkıştırın ve public proxy üzerinden yükleme ve indirme davranışını doğrulayın. Temporary disk alanını, OCR language pack’lerini, JVM memory kullanımını ve eş zamanlı conversion job’larını ölçün; sonucu deployment kaydıyla birlikte saklayın. Bu kayıt hem bir kabul kriteri hem de ilk kapasite baseline’ı sağlar.

Bootstrap sonrasında Stirling PDF’yi güvenli hâle getirin

Uygulamaya özgü güvenlik riski, public document-processing service üzerinde security’nin devre dışı bırakılmış olarak bırakılmasıdır. Internet’e açık bir instance için operasyonel çözüm, login’i etkinleştirmek ve yüklenen belgeleri job’ın gerektirdiğinden daha uzun süre saklamamaktır. Bootstrap işlemini kısıtlı bir route üzerinden tamamlayın ve geçici setup erişimini hemen ardından kaldırın.

SECURITY_ENABLELOGIN, gizlilikten çok davranışı kontrol eder; türünü ve değerini doğrulayın, gerçek Stirling PDF credential’larını ayrı saklayın. Stirling PDF process’ine yalnızca belgelenmiş mount’larını ve dependency route’larını verin; host root erişiminden ve Docker socket erişiminden kaçının. Başarısız authentication denemelerini ve configuration error’larını log’layın; ancak token’ları, connection string’leri ve kullanıcı içeriğini redact edin.

Stirling PDF’ye tek bir canonical address verin

Browser, API client ve Stirling PDF tek bir origin üzerinde anlaşmalıdır. Bunu sağlamak için public HTTPS origin’i ve proxy upload limit’lerini ayarlayın. 8080 portunu rakip bir public address olarak erişilemez tutarken original host ve protocol bilgilerini koruyun.

Site erişilemiyor sorun giderme kılavuzu, erişilemeyen bir route ile yanıt veren bir application’ı ayırt etmeye yardımcı olur. Bu ayrım burada önemlidir: Yüklemeler proxy limit’ini aşıyor olabilir veya container temporary file’lara yazamıyor olabilir. Yalnızca ilk durum ingress değişiklikleriyle çözülür; ikinci durum için Stirling PDF log’larını, state’i veya workload’u incelemek gerekir.

Değiştirilebilir container’ları kalıcı verilerden ayırın

Kalıcı recovery set’i configuration, custom file’lar ve özellikle yüklediğiniz OCR data’sından oluşur. Bootstrap işleminden önce /configs’i mount edin, zararsız örnek veriler yazın ve bu path’in gerçekten kalıcı olduğunu kanıtlamak için container’ı değiştirin. Bir volume, verileri container replacement işlemine karşı korur; ancak host kaybına, yanlışlıkla silinmeye veya application-level corruption’a karşı koruma sağlamaz.

Data source’u dikkate alan yedekler alın: Gerektiğinde çalışan database’ler için logical dump kullanın ve dosyaları yalnızca consistent bir state’ten kopyalayın. Şifrelenmiş bir kopyayı Stirling PDF host’undan ayrı bir yerde saklayın. Restore için kabul kriteri net olmalıdır — configuration ve OCR asset’leri geri gelmeli, sabit bir test belgesi kabul edilebilir ve okunabilir bir sonuç üretmelidir. Restore testi yapılmış yedekleme kılavuzu, yalnızca job success bilgisinin neden yeterli olmadığını açıklar.

Stirling PDF canlıya alınmadan önce toplanacak kanıtlar

Stirling PDF için launch öncesinde bilinen ve doğru çalışan bir işlem tanımlayın: iki PDF’yi birleştirin, taranmış bir sayfaya OCR uygulayın, sonucu sıkıştırın ve public proxy üzerinden yükleme ve indirme davranışını doğrulayın. Ön koşulları, beklenen response’u ve cleanup adımlarını secret değerleri içermeden version control altında saklayın. Bu referansı oluşturmak için kullanılan image’ı sabitleyin.

Bir replacement ve bağımsız bir restore işlemini doğrulamak için bu işlemi kullanın. Restore edilen service ancak configuration ve OCR asset’leri geri geldiğinde, ayrıca sabit bir test belgesi kabul edilebilir ve okunabilir bir sonuç ürettiğinde kabul edilebilir. Aynı zamanda temporary disk alanını, OCR language pack’lerini, JVM memory kullanımını ve eş zamanlı conversion job’larını gözlemleyin; en yavaş veya en kısıtlı bileşeni service-level alert’a dönüştürün.

Bu gate’in bir negative case’i de olmalıdır: Bu sınırla ilişkili resource veya format limitine yakın, zararsız bir input gönderin: yüklemeler proxy limit’ini aşıyor veya container temporary file’lara yazamıyor. Stirling PDF’nin actionable bir error ürettiğini ve verileri koruduğunu doğrulayın, geçerli durumu geri yükleyin ve bilinen doğru işlemi tekrarlayın. Her iki sonucu da saklamak, yüzeysel bir health endpoint’inin production’daki tek kanıt hâline gelmesini önler.

Stirling PDF’yi gerçek darboğazı etrafında işletin

Stirling PDF’nin gerçekleştirdiği işi gözlemleyin: temporary disk alanı, OCR language pack’leri, JVM memory kullanımı ve eş zamanlı conversion job’ları. Bu iş için headroom bırakarak limit’ler belirleyin ve onunla rekabet eden bir liveness probe kullanmaktan kaçının. Operator check, yine de belirli bir aralıkla iki PDF’yi birleştirmeyi, taranmış bir sayfaya OCR uygulamayı, sonucu sıkıştırmayı ve public proxy üzerinden yükleme ve indirme davranışını doğrulamayı denemelidir.

Güncellemeler için, kurulu OCR data’sının, custom configuration’ın ve security ayarlarının image upgrade öncesinde karşılaştırılması gerektiğini unutmayın. Aday sürümü recovered copy üzerinde deploy edin ve bilinen testi tekrarlayın. Yüklemeler proxy limit’ini aşıyorsa veya container temporary file’lara yazamıyorsa hangi varsayımın değiştiğini bulmak için runtime log’larını ve gerçek network request’ini kullanın.

Sınırlarını kaybetmeden Stirling PDF’yi Dockup üzerinde deploy edin

Dockup, Stirling PDF etrafındaki manuel reverse-proxy ve lifecycle işlerini ortadan kaldırır. Service, 8080 portuna yönlenen sabit bir HTTPS route, inject edilmiş configuration ve replacement işlemleri sırasında persistent storage alır. Bağlı bir customer server da Dockup-hosted compute ile aynı modeli izler.

Launch sonrasında application contract’ını karşılayın: public HTTPS origin’i ve proxy upload limit’lerini ayarlayın, yerel gereksinimi — isteğe bağlı OCR language data ve büyük işler için yeterli temporary disk alanı — doğrulayın ve şu testi çalıştırın: iki PDF’yi birleştirin, taranmış bir sayfaya OCR uygulayın, sonucu sıkıştırın ve public proxy üzerinden yükleme ve indirme davranışını doğrulayın. Bu yaklaşım, Stirling PDF’yi recoverable ve güvenli kılan ayrıntıları göz ardı etmeden one-click deneyimini kullanışlı tutar.

Sık sorulan sorular

Production deployment için Stirling PDF’nin neye ihtiyacı vardır?

Stirling PDF container’ını 8080 portu üzerinden tek bir HTTPS origin’e yönlendirin. Yerel runtime gereksinimi, isteğe bağlı OCR language data ve büyük işler için yeterli temporary disk alanıdır. İki PDF’yi birleştirip taranmış bir sayfaya OCR uygulayamadığınız, sonucu sıkıştıramadığınız ve public proxy üzerinden yükleme ve indirme davranışını doğrulayamadığınız sürece Stirling PDF’yi hazır kabul etmeyin.

Stirling PDF’ye ait hangi veriler yedeğe dahil edilmelidir?

/configs’i kalıcı hâle getirin ve configuration’ı, custom file’ları ve özellikle yüklediğiniz OCR data’sını aynı recovery manifest’ine dahil edin. Temiz bir Stirling PDF restore işlemi yalnızca configuration ve OCR asset’leri geri geldiğinde, ayrıca sabit bir test belgesi kabul edilebilir ve okunabilir bir sonuç ürettiğinde başarılı sayılır.

Stirling PDF, reverse proxy arkasında HTTPS gerektirir mi?

Public Stirling PDF origin’i için HTTPS kullanın ve 8080 portunu internal route üzerinde tutun. Stirling PDF ayarını doğru uygulayın: public HTTPS origin’i ve proxy upload limit’lerini ayarlayın. Stirling PDF için HTTPS, credential’ları veya kullanıcı içeriğini transit sırasında korur ve origin’e duyarlı client davranışının tutarlı kalmasını sağlar.

Stirling PDF yükseltmesi nasıl test edilmelidir?

Mevcut Stirling PDF state’ini izole bir deployment’a restore edin, aday sürümü uygulayın ve kabul işlemini tekrarlayın. Özellikle dikkatli olun; çünkü kurulu OCR data’sı, custom configuration ve security ayarları image upgrade öncesinde karşılaştırılmalıdır. Data migration ve rollback sınırları anlaşılana kadar önceki Stirling PDF image’ını saklayın.