Як самостійно розгорнути Stirling PDF у 2026 році: завантаження, OCR і безпека входу

Є дві версії «запустити Stirling PDF»: контейнер існує або сервіс виконує свою реальну роботу. Значення має лише другий варіант. Тут перевіркою є об’єднання двох PDF-файлів, розпізнавання відсканованої сторінки, стискання результату, а також перевірка завантаження та скачування через публічний proxy.

Stirling PDF призначений саме для цього: вебінтерфейс та API для поширених операцій із PDF. Розгортання має зберігати компоненти, від яких залежить така робота; порт, том і сертифікат — це вхідні дані, а не результат.

Налаштування контейнера, які варто перевірити

Перший контейнер має легко видалятися та створюватися заново. Зберігайте дані поза доступним для запису шаром, прив’язуйте порт 8080 лише там, де до нього може дістатися proxy, і передавайте конфігурацію під час запуску.

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

Після початкової перевірки зафіксуйте версію image. Читайте найпершу помилку запуску, а не фінальне повідомлення про перезапуск, перевіряйте кожне монтування за допомогою docker inspect і стежте за логами, поки об’єднуєте два PDF-файли, розпізнаєте відскановану сторінку, стискаєте результат і перевіряєте завантаження та скачування через публічний proxy. Така послідовність допомагає відрізнити помилку команди запуску image від проблеми із залежністю або дозволами.

Спочатку визначте критерії успіху для Stirling PDF

Розділіть чотири аспекти Stirling PDF: ingress, listener на порту 8080, постійний стан і допоміжні сервіси або локальні ресурси. Локальна вимога — це необов’язкові мовні дані для OCR і достатній обсяг тимчасового диска для великих завдань. Зафіксуйте її поруч з image і портом, щоб після заміни хост отримав ті самі локальні можливості.

Виконайте перевірену транзакцію — об’єднайте два PDF-файли, розпізнайте відскановану сторінку, стисніть результат і перевірте завантаження та скачування через публічний proxy — перш ніж вважати це розділення завершеним. Виміряйте обсяг тимчасового диска, мовні пакети OCR, споживання пам’яті JVM і кількість одночасних завдань конвертації та збережіть результат разом із записом про розгортання. Це забезпечує і критерій приймання, і першу базову оцінку місткості.

Захистіть Stirling PDF після bootstrap

Специфічний для застосунку ризик безпеці — залишити вимкненою автентифікацію на публічному сервісі обробки документів. Операційне рішення — увімкнути вхід для інстансу, доступного з інтернету, і не зберігати завантажені документи довше, ніж це потрібно для виконання завдання. Завершіть bootstrap через обмежений маршрут і відразу після цього видаліть тимчасовий доступ для налаштування.

SECURITY_ENABLELOGIN керує поведінкою, а не конфіденційністю; перевірте його тип і значення та зберігайте справжні облікові дані Stirling PDF окремо. Надайте процесу Stirling PDF лише задокументовані монтування та маршрути до залежностей; не надавайте доступу до root хоста й Docker socket. Записуйте невдалі спроби автентифікації та помилки конфігурації, але приховуйте токени, connection strings і вміст користувачів.

Задайте для Stirling PDF одну канонічну адресу

Браузер, API-клієнт і Stirling PDF мають використовувати один origin. Щоб цього досягти, задайте публічний HTTPS origin і ліміти proxy на завантаження. Зберігайте початкові host і protocol, водночас не допускаючи доступу до порту 8080 через альтернативну публічну адресу.

Посібник із діагностики недоступності сайту допомагає відрізнити недоступний маршрут від застосунку, який відповідає. Тут це розрізнення важливе: завантаження перевищують ліміт proxy або контейнер не може записати тимчасові файли. Лише першу проблему виправляють змінами ingress; друга потребує перевірки логів Stirling PDF, стану або навантаження.

Відокремте змінні контейнери від постійних даних

Набір даних для надійного відновлення — це конфігурація, власні файли та всі мовні дані OCR, які ви навмисно встановили. Змонтуйте /configs до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести, що цей шлях справді постійний. Том захищає дані від заміни контейнера, але не від втрати хоста, випадкового видалення чи пошкодження на рівні застосунку.

Створюйте резервні копії з урахуванням джерела даних: за потреби використовуйте logical dumps для активних баз даних, а файли копіюйте лише зі стабільного стану. Зберігайте одну зашифровану копію окремо від хоста Stirling PDF. Критерій приймання відновлення має бути конкретним — конфігурація й assets OCR повертаються, а фіксований тестовий документ дає прийнятний, читабельний результат. Посібник із резервного копіювання з перевіркою відновлення пояснює, чому одного успішного виконання завдання недостатньо.

Які докази зібрати до запуску Stirling PDF у production

Для Stirling PDF визначте перевірену транзакцію до запуску: об’єднайте два PDF-файли, розпізнайте відскановану сторінку, стисніть результат і перевірте завантаження та скачування через публічний proxy. Збережіть її prerequisites, очікувану відповідь і кроки очищення у version control без секретних значень. Зафіксуйте image, використаний для створення цього еталона.

Використовуйте транзакцію для перевірки заміни та незалежного відновлення. Відновлений сервіс можна вважати прийнятним лише тоді, коли конфігурація й assets OCR повертаються, а фіксований тестовий документ дає прийнятний, читабельний результат. Одночасно спостерігайте за тимчасовим диском, мовними пакетами OCR, пам’яттю JVM і кількістю одночасних завдань конвертації та перетворіть найповільнішу або найбільш обмежену ланку на service-level alert.

Gate також має містити негативний сценарій: подайте нешкідливі вхідні дані, близькі до обмеження ресурсу або формату, пов’язаного з цією межею: завантаження перевищують ліміт proxy або контейнер не може записати тимчасові файли. Переконайтеся, що Stirling PDF повертає зрозумілу помилку, зберігаючи дані, відновіть коректний стан і повторіть перевірену транзакцію. Збереження обох результатів не дає поверхневому health endpoint стати єдиним production-доказом.

Експлуатуйте Stirling PDF з урахуванням його реального bottleneck

Слідкуйте за роботою, яку виконує Stirling PDF: тимчасовим диском, мовними пакетами OCR, пам’яттю JVM і кількістю одночасних завдань конвертації. Встановлюйте ліміти із запасом для цієї роботи та не використовуйте liveness probe, яка конкурує з нею за ресурси. Перевірка оператора все одно має періодично виконувати об’єднання двох PDF-файлів, розпізнавання відсканованої сторінки, стискання результату, а також перевірку завантаження та скачування через публічний proxy.

Під час оновлень пам’ятайте, що встановлені дані OCR, власну конфігурацію та налаштування безпеки потрібно порівняти до оновлення image. Розгорніть кандидатну версію на відновленій копії та повторіть відомий тест. Якщо завантаження перевищують ліміт proxy або контейнер не може записати тимчасові файли, використовуйте runtime logs і фактичний network request, щоб з’ясувати, яке припущення змінилося.

Розгортайте Stirling PDF у Dockup, не втрачаючи меж відповідальності

Dockup усуває ручну роботу з reverse proxy та lifecycle навколо Stirling PDF. Сервіс отримує стабільний HTTPS-маршрут до порту 8080, інжектовану конфігурацію та постійне сховище під час заміни. Підключений сервер клієнта працює за тією самою моделлю, що й обчислювальні ресурси, розміщені в Dockup.

Після запуску виконайте контракт застосунку: задайте публічний HTTPS origin і ліміти proxy на завантаження, підтвердьте локальну вимогу — необов’язкові мовні дані OCR і достатній обсяг тимчасового диска для великих завдань — і запустіть цю перевірку: об’єднайте два PDF-файли, розпізнайте відскановану сторінку, стисніть результат і перевірте завантаження та скачування через публічний proxy. Це зберігає користь one-click досвіду, не нівелюючи деталей, завдяки яким Stirling PDF можна відновити й захистити.

Поширені запитання

Що потрібно Stirling PDF для production-розгортання?

Прокиньте контейнер Stirling PDF на порту 8080 через один HTTPS origin. Локальна вимога — це необов’язкові мовні дані OCR і достатній обсяг тимчасового диска для великих завдань. Не вважайте Stirling PDF готовим, доки не зможете об’єднати два PDF-файли, розпізнати відскановану сторінку, стиснути результат і перевірити завантаження та скачування через публічний proxy.

Які дані Stirling PDF потрібно включати до резервної копії?

Забезпечте збереження /configs і включіть конфігурацію, власні файли та всі мовні дані OCR, які ви навмисно встановили, до того самого recovery manifest. Чисте відновлення Stirling PDF вважається успішним лише тоді, коли конфігурація й assets OCR повертаються, а фіксований тестовий документ дає прийнятний, читабельний результат.

Чи потрібен Stirling PDF HTTPS за reverse proxy?

Використовуйте HTTPS для публічного origin Stirling PDF, а порт 8080 залиште у внутрішньому маршруті. Правильно застосуйте налаштування Stirling PDF: задайте публічний HTTPS origin і ліміти proxy на завантаження. Для Stirling PDF HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Stirling PDF?

Відновіть поточний стан Stirling PDF в ізольованому розгортанні, застосуйте кандидатну версію та повторіть acceptance transaction. Приділіть особливу увагу тому, що встановлені дані OCR, власну конфігурацію та налаштування безпеки потрібно порівняти до оновлення image. Зберігайте попередній image Stirling PDF, доки не буде зрозуміло межі міграції даних і rollback.