Jak hostować Stirling PDF samodzielnie w 2026 roku: uploady, OCR i bezpieczeństwo logowania

Istnieją dwie wersje „uruchomienia Stirling PDF”: kontener istnieje albo usługa faktycznie wykonuje swoją pracę. Liczy się tylko ta druga. W tym przypadku dowodem jest połączenie dwóch plików PDF, wykonanie OCR na zeskanowanej stronie, skompresowanie wyniku oraz zweryfikowanie działania uploadu i downloadu przez publiczne proxy.

Stirling PDF służy właśnie do tego: udostępnia webowy interfejs i API do typowych operacji na plikach PDF. Deployment musi zachować elementy niezbędne do takiego działania; port, volume i certyfikat są danymi wejściowymi, a nie rezultatem.

Ustawienia kontenera, które warto sprawdzić

Pierwszy kontener powinien być łatwy do usunięcia i ponownego utworzenia. Przechowuj dane poza writable layer, mapuj port 8080 wyłącznie tam, skąd proxy może do niego dotrzeć, i przekazuj konfigurację w runtime.

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

Po pierwszym teście przypnij wersję obrazu. Odczytaj najwcześniejszy błąd startowy zamiast końcowego komunikatu o restarcie, zweryfikuj każdy mount za pomocą docker inspect i obserwuj logi podczas łączenia dwóch plików PDF, wykonywania OCR na zeskanowanej stronie, kompresowania wyniku oraz weryfikowania działania uploadu i downloadu przez publiczne proxy. Taka sekwencja pozwala odróżnić błędną komendę obrazu od problemu z zależnością lub uprawnieniami.

Najpierw zdefiniuj, kiedy Stirling PDF działa poprawnie

Rozdziel w przypadku Stirling PDF cztery kwestie: ingress, listener na porcie 8080, trwały stan oraz usługi wspierające lub lokalne zasoby. Lokalne wymagania runtime to opcjonalne dane językowe OCR oraz wystarczająca ilość tymczasowego miejsca na dysku dla dużych zadań. Zapisz je obok obrazu i portu, aby host zastępczy otrzymał takie same lokalne możliwości.

Przed uznaniem tego rozdzielenia za zakończone wykonaj sprawdzoną transakcję — połącz dwa pliki PDF, wykonaj OCR na zeskanowanej stronie, skompresuj wynik oraz zweryfikuj działanie uploadu i downloadu przez publiczne proxy. Zmierz tymczasowe miejsce na dysku, pakiety językowe OCR, pamięć JVM i liczbę jednoczesnych zadań konwersji, a następnie zachowaj wynik razem z dokumentacją deploymentu. Dostarcza on zarówno kryterium akceptacji, jak i pierwszy baseline pojemności.

Zabezpiecz Stirling PDF po bootstrapie

Specyficznym dla aplikacji ryzykiem bezpieczeństwa jest pozostawienie wyłączonych zabezpieczeń w publicznej usłudze przetwarzającej dokumenty. W przypadku instancji dostępnej z internetu należy włączyć logowanie i unikać przechowywania przesłanych dokumentów dłużej, niż wymaga tego zadanie. Zakończ bootstrap przez ograniczoną trasę i natychmiast potem usuń tymczasowy dostęp konfiguracyjny.

SECURITY_ENABLELOGIN steruje zachowaniem, a nie poufnością; zweryfikuj jego typ i wartość, a właściwe dane uwierzytelniające Stirling PDF przechowuj oddzielnie. Nadaj procesowi Stirling PDF wyłącznie udokumentowane mounty i trasy do zależności; unikaj dostępu do roota hosta i socketu Dockera. Rejestruj nieudane uwierzytelnienia oraz błędy konfiguracji, ale redaguj tokeny, connection stringi i treści użytkowników.

Nadaj Stirling PDF jeden kanoniczny adres

Przeglądarka, klient API i Stirling PDF muszą korzystać z tego samego originu. Aby to zapewnić, ustaw publiczny origin HTTPS oraz limity uploadu w proxy. Zachowaj oryginalny host i protokół, a jednocześnie nie udostępniaj portu 8080 jako konkurencyjnego publicznego adresu.

Poradnik rozwiązywania problemów z niedostępną stroną pomaga odróżnić nieosiągalną trasę od odpowiadającej aplikacji. To rozróżnienie ma tutaj znaczenie: uploady przekraczają limit proxy albo kontener nie może zapisywać plików tymczasowych. Tylko pierwszy problem można naprawić zmianami w ingressie; drugi wymaga analizy logów Stirling PDF, stanu lub obciążenia.

Oddziel kontenery, które można wymienić, od trwałych danych

Trwały zestaw do odtworzenia obejmuje konfigurację, pliki niestandardowe oraz wszelkie dane OCR zainstalowane celowo. Zamontuj /configs przed bootstrapem, zapisz nieszkodliwe przykładowe dane i wymień kontener, aby potwierdzić, że ta ścieżka faktycznie jest trwała. Volume chroni dane przed wymianą kontenera, ale nie przed utratą hosta, przypadkowym usunięciem ani uszkodzeniem na poziomie aplikacji.

Wykonuj backupy świadome źródła danych: w razie potrzeby używaj logical dumpów dla działających baz danych, a pliki kopiuj wyłącznie ze spójnego stanu. Jedną zaszyfrowaną kopię przechowuj poza hostem Stirling PDF. Kryterium akceptacji restore powinno być konkretne — konfiguracja i zasoby OCR muszą zostać przywrócone, a stały dokument testowy powinien dać akceptowalny, czytelny wynik. Poradnik dotyczący backupów przetestowanych przez restore wyjaśnia, dlaczego sam sukces zadania nie wystarcza.

Zbierz dowody przed uruchomieniem Stirling PDF na produkcji

W przypadku Stirling PDF zdefiniuj sprawdzoną transakcję przed uruchomieniem: połącz dwa pliki PDF, wykonaj OCR na zeskanowanej stronie, skompresuj wynik oraz zweryfikuj działanie uploadu i downloadu przez publiczne proxy. Umieść jej wymagania wstępne, oczekiwaną odpowiedź i kroki czyszczenia w kontroli wersji, bez wartości sekretów. Przypnij obraz użyty do ustanowienia tego punktu odniesienia.

Użyj transakcji do zweryfikowania wymiany kontenera i niezależnego restore. Przywrócona usługa jest akceptowalna tylko wtedy, gdy konfiguracja i zasoby OCR zostaną odtworzone, a stały dokument testowy da akceptowalny, czytelny wynik. Jednocześnie obserwuj tymczasowe miejsce na dysku, pakiety językowe OCR, pamięć JVM i liczbę jednoczesnych zadań konwersji, a następnie przekształć najwolniejszy lub najbardziej ograniczony element w alert na poziomie usługi.

Proces weryfikacji musi obejmować także przypadek negatywny: prześlij nieszkodliwy plik zbliżony do limitu zasobów lub formatu związanego z tą granicą: uploady przekraczają limit proxy albo kontener nie może zapisywać plików tymczasowych. Potwierdź, że Stirling PDF zwraca użyteczny komunikat błędu, zachowując dane, przywróć prawidłowy stan i ponownie wykonaj sprawdzoną transakcję. Przechowywanie obu wyników zapobiega sytuacji, w której powierzchowny health endpoint staje się jedynym dowodem działania na produkcji.

Obsługuj Stirling PDF z uwzględnieniem rzeczywistego wąskiego gardła

Obserwuj pracę wykonywaną przez Stirling PDF: tymczasowe miejsce na dysku, pakiety językowe OCR, pamięć JVM i liczbę jednoczesnych zadań konwersji. Ustaw limity z zapasem odpowiednim do tego obciążenia i unikaj liveness probe, który z nim konkuruje. Kontrola operatorska nadal powinna według harmonogramu próbować połączyć dwa pliki PDF, wykonać OCR na zeskanowanej stronie, skompresować wynik oraz zweryfikować działanie uploadu i downloadu przez publiczne proxy.

Przy aktualizacjach pamiętaj, że przed upgrade’em obrazu należy porównać zainstalowane dane OCR, niestandardową konfigurację i ustawienia bezpieczeństwa. Wdróż kandydata na podstawie odzyskanej kopii i ponownie wykonaj znany test. Jeśli uploady przekraczają limit proxy albo kontener nie może zapisywać plików tymczasowych, użyj logów runtime i rzeczywistego żądania sieciowego, aby ustalić, które założenie uległo zmianie.

Wdróż Stirling PDF na Dockup bez utraty jego granic

Dockup eliminuje ręczną obsługę reverse proxy i lifecycle wokół Stirling PDF. Usługa otrzymuje stabilną trasę HTTPS do portu 8080, wstrzykniętą konfigurację i trwały storage podczas wymiany kontenerów. Podłączony serwer klienta działa według tego samego modelu co compute hostowany przez Dockup.

Po uruchomieniu spełnij kontrakt aplikacji: ustaw publiczny origin HTTPS i limity uploadu w proxy, potwierdź lokalne wymaganie — opcjonalne dane językowe OCR i wystarczającą ilość tymczasowego miejsca na dysku dla dużych zadań — oraz wykonaj ten test: połącz dwa pliki PDF, wykonaj OCR na zeskanowanej stronie, skompresuj wynik i zweryfikuj działanie uploadu i downloadu przez publiczne proxy. Dzięki temu doświadczenie one-click pozostaje użyteczne, nie spłaszczając szczegółów, które decydują o możliwości odtworzenia i bezpieczeństwie Stirling PDF.

Najczęściej zadawane pytania

Czego Stirling PDF potrzebuje w deploymentcie produkcyjnym?

Przekieruj kontener Stirling PDF z portu 8080 przez jeden origin HTTPS. Lokalne wymagania runtime to opcjonalne dane językowe OCR oraz wystarczająca ilość tymczasowego miejsca na dysku dla dużych zadań. Nie uznawaj Stirling PDF za gotowy, dopóki nie możesz połączyć dwóch plików PDF, wykonać OCR na zeskanowanej stronie, skompresować wyniku oraz zweryfikować działania uploadu i downloadu przez publiczne proxy.

Które dane Stirling PDF powinny znaleźć się w backupie?

Utrwal /configs oraz uwzględnij konfigurację, pliki niestandardowe i wszelkie celowo zainstalowane dane OCR w tym samym recovery manifest. Czysty restore Stirling PDF kończy się powodzeniem tylko wtedy, gdy konfiguracja i zasoby OCR zostaną odtworzone, a stały dokument testowy da akceptowalny, czytelny wynik.

Czy Stirling PDF wymaga HTTPS za reverse proxy?

Użyj HTTPS dla publicznego originu Stirling PDF, a port 8080 pozostaw na trasie wewnętrznej. Poprawnie zastosuj ustawienie Stirling PDF: ustaw publiczny origin HTTPS i limity uploadu w proxy. W przypadku Stirling PDF HTTPS chroni dane uwierzytelniające lub treści użytkowników podczas transmisji i zapewnia spójność zachowania klienta zależnego od originu.

Jak testować aktualizację Stirling PDF?

Przywróć aktualny stan Stirling PDF do izolowanego deploymentu, zastosuj wersję kandydującą i ponownie wykonaj transakcję akceptacyjną. Zwróć szczególną uwagę na to, że przed upgrade’em obrazu należy porównać zainstalowane dane OCR, niestandardową konfigurację i ustawienia bezpieczeństwa. Zachowaj poprzedni obraz Stirling PDF do czasu zrozumienia granic migracji danych i rollbacku.