Як самостійно розгорнути ConvertX у 2026 році: завантаження, JWT-секрети та обмеження ресурсів

Є дві версії «запустити ConvertX»: контейнер існує або сервіс виконує свою реальну роботу. Важлива лише друга. Перевірка полягає в тому, щоб завантажити кілька типових форматів, конвертувати кожен із них, завантажити результати та порівняти хеші або властивості медіафайлів там, де результат має бути детермінованим.

ConvertX призначений саме для цього: це браузерний сервіс конвертації файлів. Розгортання має зберігати всі компоненти, що забезпечують таку поведінку; порт, том і сертифікат — це вхідні параметри, а не результат.

Оберіть найменшу працездатну топологію ConvertX

Почніть із мережевого простору імен ConvertX: його web listener працює на порту 3000, а не на host port, скопійованому з інструкції для ноутбука. Локальна вимога до runtime — це CPU, пам’ять і тимчасовий диск, достатні для вибраних конвертерів. Задокументуйте очікувану ємність, права власності та сценарій відмови, а не залишайте налаштування за замовчуванням образу.

Після виконання вимоги запустіть повний сценарій — завантажте кілька типових форматів, конвертуйте кожен із них, завантажте результати та порівняйте хеші або властивості медіафайлів там, де результат має бути детермінованим. Зафіксуйте логи та показники CPU, пам’яті, тимчасового диска, розміру файлів і бінарних файлів конвертерів, викликаних для кожної пари форматів. Ці докази стануть першою відомою працездатною архітектурою та дадуть змогу тестувати подальші переміщення між обчислювальними ресурсами Dockup і під’єднаним сервером.

Розрізняйте внутрішні та зовнішні URL

Не використовуйте для ConvertX тимчасові й постійні публічні origin-адреси. Натомість опублікуйте UI через HTTPS із навмисно заданими лімітами завантаження, спрямуйте вибране DNS-ім’я на route платформи та проксуюйте запити лише на порт 3000.

Виконайте цю дію з-поза хоста: завантажте кілька типових форматів, конвертуйте кожен із них, завантажте результати та порівняйте хеші або властивості медіафайлів там, де результат має бути детермінованим. Якщо ingress не працює, у посібнику з усунення проблеми 502 описано помилки з портом і listener. Якщо ConvertX отримує запит, але бінарний файл конвертера відсутній або proxy відхиляє велике завантаження, тепер докази вказують не на proxy.

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

Запустіть ConvertX так, щоб route залишався приватним до завершення bootstrap.

docker run -d \
  --name convertx \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v convertx-data:/app/data \
  -e JWT_SECRET=replace-with-a-long-random-value \
  ghcr.io/c4illin/convertx:latest

Якщо процес зациклюється, порівняйте очікуваного користувача образу з власником кожного змонтованого шляху. Якщо процес працює, перевірте порт 3000 локально, а потім одразу переходьте до workflow: завантажте кілька типових форматів, конвертуйте кожен із них, завантажте результати та порівняйте хеші або властивості медіафайлів там, де результат має бути детермінованим. Зафіксуйте версію образу лише після успішної end-to-end перевірки та збережіть точну конфігурацію поруч із сервісом.

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

Неактивна health check мало що говорить про ConvertX. Відстежуйте CPU, пам’ять, тимчасовий диск, розмір файлів і бінарні файли конвертерів, викликаних для кожної пари форматів, а сповіщення налаштуйте на симптом, який бачать користувачі: помилку під час дії «завантажити кілька типових форматів, конвертувати кожен із них, завантажити результати та порівняти хеші або властивості медіафайлів там, де результат має бути детермінованим». Залиште liveness локальною та недорогою; readiness має повідомляти про міграції або ініціалізацію, не спричиняючи storm перезапусків.

Ризикова зона під час оновлення полягає в тому, що релізи образу можуть додавати або видаляти конвертери, тому тестуйте точну матрицю форматів, від якої залежать користувачі. Прочитайте release notes, створіть snapshot стану, розгорніть цільову версію на відновленій копії та повторіть acceptance action. Якщо бінарний файл конвертера відсутній або proxy відхиляє велике завантаження, зіставте клієнтський запит із першим відповідним application log, а не видаляйте стан і не додавайте redirects навмання.

П’ять перевірок, надійніших за health контейнера

Не робіть трафік першого користувача acceptance test для ConvertX. Підготуйте безпечний тестовий стан і виконайте повну дію «завантажити кілька типових форматів, конвертувати кожен із них, завантажити результати та порівняти хеші або властивості медіафайлів там, де результат має бути детермінованим». Занотуйте точний публічний URL, результат, посилання на образ і інтервал логування, пов’язані з цим запуском.

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

Одна фінальна перевірка має навмисно завершитися помилкою: надішліть безпечні вхідні дані, розмір або формат яких близький до межі ресурсу чи формату, пов’язаної з цим обмеженням: бінарний файл конвертера відсутній або proxy відхиляє велике завантаження. Перевірте, що отримане повідомлення ConvertX визначає відповідну межу, а не запускає видалення даних або нескінченний цикл перезапусків. Відновіть коректний стан і переконайтеся, що та сама тестова транзакція успішно виконується. Додайте цю коротку вправу до checklist релізу.

Знайдіть кожен довговічний байт у ConvertX

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

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

Зменште повноваження, якими володіє ConvertX

Після першого входу перевірте, що можуть робити анонімний відвідувач, звичайний користувач і адміністратор. Помилка ConvertX, якої слід уникати, — використання прикладного JWT-секрету або надання необмеженої можливості публічної конвертації. Цільова політика — використовувати справжній JWT-секрет, вимагати вхід і обмежити завантаження до приймання неперевірених файлів з інтернету.

Згенеруйте JWT_SECRET як довге випадкове значення; його ротація зазвичай робить сесії або токени недійсними, тому заздалегідь сплануйте вплив на користувачів, а не називайте це міграцією шифрування. Розділяйте облікові записи залежностей і облікові записи людей, де це практично, забороняйте невикористовуваний egress і обмежуйте роботу, на яку впливають CPU, пам’ять, тимчасовий диск, розмір файлів і бінарні файли конвертерів, викликаних для кожної пари форматів.

Розгорніть ConvertX у Dockup, не втрачаючи його обмежень

Dockup усуває ручну роботу з reverse proxy та lifecycle навколо ConvertX. Під час замін сервіс отримує стабільний HTTPS route до порту 3000, інжектовану конфігурацію та постійне сховище. Під’єднаний сервер клієнта працює за тією самою моделлю, що й обчислювальні ресурси, розміщені в Dockup.

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

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

Що потрібно ConvertX для production deployment?

Спрямуйте контейнер ConvertX на порт 3000 через один HTTPS origin. Локальна вимога до runtime — це CPU, пам’ять і тимчасовий диск, достатні для вибраних конвертерів. Не вважайте ConvertX готовим, доки не зможете завантажити кілька типових форматів, конвертувати кожен із них, завантажити результати та порівняти хеші або властивості медіафайлів там, де результат має бути детермінованим.

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

Збережіть /app/data і включіть дані застосунку, облікові записи та всі збережені налаштування конвертації до одного recovery manifest. Чисте відновлення ConvertX вважається успішним лише тоді, коли облікові записи й налаштування повернулися, а фіксована матриця форматів і надалі виконується в межах вибраних лімітів.

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

Використовуйте HTTPS для публічного origin ConvertX, а порт 3000 залиште у внутрішньому route. Застосуйте налаштування ConvertX правильно: опублікуйте UI через HTTPS із навмисно заданими лімітами завантаження. Для ConvertX HTTPS захищає облікові дані та вміст користувачів під час передавання й забезпечує узгоджену поведінку клієнта, чутливу до origin.

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

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