Как да хоствате LibreTranslate самостоятелно през 2026 г.: модели, API лимити и постоянни данни

Ако вече сте опитвали да хоствате LibreTranslate самостоятелно, вероятно ви е познато разочароващото състояние: интерфейсът се зарежда, но моделите не са изтеглени или желаната езикова двойка не е налична. Създаването на контейнера наново рядко отстранява несъответствие между URL адреси, състояние и зависимости.

Това ръководство използва един конкретен критерий за завършеност — извеждане на списъка с инсталирани езици, превод на фиксирано изречение и в двете посоки и проверка на квотата на API ключа и отговорите при грешки. Всяко решение за конфигурацията се оценява спрямо този критерий, а не спрямо зеления индикатор на контейнера.

Възстановяване на LibreTranslate на празен хост

Преди да създадете първия реален запис, изведете списък на състоянието: изтеглени модели, база данни с API ключове и персонализирана конфигурация. Монтирайте /home/libretranslate/.local преди bootstrap, запишете безопасни примерни данни и заменете контейнера, за да докажете, че пътят действително е persistent. Потвърдете монтирането, като запишете безопасни данни, замените LibreTranslate и ги прочетете отново.

Snapshot-ите са ценни за бързо връщане към предишно състояние, но е необходим независим backup, когато хостът или volume-ът изчезне. Възстановете в празна среда с фиксирания image и проверете дали моделите и състоянието на API ключовете са възстановени и regression corpus-ът завършва с приемлив резултат. Използвайте persistent volumes and snapshots, за да запазите тези два механизма за възстановяване отделни.

Портове, процеси и частни услуги

Не позволявайте image-ът на LibreTranslate случайно да определи production архитектурата. Image-ът предоставя процес на порт 5000; storage-ът, routing-ът и външните изисквания все пак се нуждаят от обмислени lifecycle-и. Локалното изискване за runtime е storage за изтегляне на модели и CPU или GPU, подходящи за съответните езикови двойки. Поддържайте неговия lifecycle изрично дефиниран, така че преместването на LibreTranslate между хостове да не променя поведението незабелязано.

Deployment-ът е готов за по-задълбочено тестване, когато може да изведе списъка с инсталирани езици, да преведе фиксирано изречение и в двете посоки и да провери квотата на API ключа и отговорите при грешки. Проследявайте транзакцията в log-овете и наблюдавайте заредените езикови модели, времето за inference на CPU, паралелните заявки и дисковото пространство, използвано от изтеглянето на моделите. Тези наблюдения показват дали текущата topology изолира правилния компонент.

Проверете LibreTranslate deployment-а от край до край

Production gate-ът за LibreTranslate трябва да може да бъде изпълнен от човек, който не е изградил deployment-а. Дайте на този човек фиксираната версия, несензитивен тестов акаунт и следната задача: да изведе списъка с инсталирани езици, да преведе фиксирано изречение и в двете посоки и да провери квотата на API ключа и отговорите при грешки. Ако инструкциите изискват shell достъп, който не е документиран, услугата все още не е готова за operational употреба.

Повторете gate-а, като замените само контейнера. След това възстановете изтеглените модели, базата данни с API ключове и персонализираната конфигурация в празна инфраструктура и докажете, че моделите и състоянието на API ключовете са възстановени и regression corpus-ът завършва с приемлив резултат. Измервайте заредените езикови модели, времето за inference на CPU, паралелните заявки и дисковото пространство, използвано от изтеглянето на моделите, и при двете успешни изпълнения; неочакваните разлики често разкриват липсващ cache, index, worker или data mount.

Добавете drill за отказ: изпратете безопасен input близо до resource или format лимита, свързан с тази граница: моделите не са изтеглени или желаната езикова двойка не е налична. LibreTranslate трябва да върне полезна грешка, да запази съществуващото състояние и да се възстанови, когато условието отново стане валидно. Запазете timestamp-ите и съответните редове от log-овете, като заличите secrets. Тези данни ще бъдат референтната точка при следващата промяна на image-а или конфигурацията.

Настройки на контейнера, които си струва да прегледате

Използвайте команда, която показва всеки важен избор. Тази базова конфигурация свързва LibreTranslate с loopback интерфейса на хоста, добавя известните data mount-ове и задава първата необходима настройка. Потвърдете локалното изискване, преди да го направите достъпен: storage за изтегляне на модели и CPU или GPU, подходящи за съответните езикови двойки.

docker run -d \
  --name libretranslate \
  --restart unless-stopped \
  -p 127.0.0.1:5000:5000 \
  -v libretranslate-data:/home/libretranslate/.local \
  -e LT_API_KEYS=true \
  libretranslate/libretranslate:latest

Заменете floating tag-овете с тествана версия или digest. След стартиране прегледайте docker logs --tail 200 libretranslate и потвърдете, че процесът слуша на порт 5000. След това изпълнете acceptance действието на LibreTranslate; отговорът от root страницата не може да докаже, че целият сценарий работи: изведете списъка с инсталирани езици, преведете фиксирано изречение и в двете посоки и проверете квотата на API ключа и отговорите при грешки.

Credentials, роли и изложени повърхности

Специфичният за приложението security риск е стартирането на неограничен публичен API, чийто ресурс други могат да изчерпят. Operational решението е да активирате API ключове или upstream authentication, да ограничите честотата на публичните заявки и да инсталирате само необходимите езикови двойки. Завършете bootstrap-а през ограничен route и незабавно премахнете временния setup достъп след това.

LT_API_KEYS управлява поведението, а не confidentiality; проверете типа и стойността му и съхранявайте реалните credentials на LibreTranslate отделно. Дайте на процеса на LibreTranslate само документираните mount-ове и dependency route-ове; избягвайте достъп до root на хоста и до Docker socket-а. Записвайте неуспешните authentication опити и грешките в конфигурацията, но заличавайте token-ите, connection string-овете и съдържанието на потребителите.

Поддържайте вътрешните и външните URL адреси правилно разграничени

Издаването на TLS е само половината от route-а на LibreTranslate. Предоставяйте API през HTTPS и документирайте правилния base path. Изпращайте трафика вътрешно към порт 5000 и препращайте външната scheme, така че генерираните URL адреси и secure cookie-тата да останат съгласувани.

Използвайте пълния сценарий на LibreTranslate от чиста мрежа, а не само root страницата. Грешка 502 или проблем със сертификата може да бъде изолиран с automatic domain and TLS setup. Ако трафикът достига до процеса, но моделите не са изтеглени или желаната езикова двойка не е налична, диагностицирайте състоянието там, където възниква, вместо да добавяте още redirects.

Drills за отказ на LibreTranslate

Capacity тестовете трябва да проверяват заредените езикови модели, времето за inference на CPU, паралелните заявки и дисковото пространство, използвано от изтеглянето на моделите, а не повтаряща се заявка към /. Изпълнете сценария „извеждане на списъка с инсталирани езици, превод на фиксирано изречение и в двете посоки и проверка на квотата на API ключа и отговорите при грешки“ при реалистична concurrency и запишете latency, error rate и ръста на storage-а.

Планирането на upgrade трябва да отчита следния риск: пакетите с модели и server release-ите могат да променят резултата от превода, затова поддържайте малък regression corpus. Тествайте новия release с представителен input, след което повторете acceptance транзакцията и сравнете резултата. Ако моделите не са изтеглени или желаната езикова двойка не е налична, запишете неуспешната транзакция и проверете първата засегната граница, вместо да приемате, че проблемът е в ingress-а.

Deployment на LibreTranslate в Dockup без загуба на границите му

Dockup template-ът трябва да кодира image-а, порт 5000, mount-овете, health timing-а, domain-а, TLS и доставянето на secret-ите. Dockup трябва да запази runtime настройките на LibreTranslate, докато операторът потвърди следното локално изискване: storage за изтегляне на модели и CPU или GPU, подходящи за съответните езикови двойки. Същият deployment може да бъде насочен към Dockup сървъри или към капацитет, прикачен от клиента.

След като route-ът е активен, приложете публичната настройка и опитайте да изведете списъка с инсталирани езици, да преведете фиксирано изречение и в двете посоки и да проверите квотата на API ключа и отговорите при грешки. Направете backup на изтеглените модели, базата данни с API ключове и персонализираната конфигурация и включете restore упражнението в operational плана; това са отговорности на LibreTranslate, които остават видими и след provision-а на инфраструктурата.

Често задавани въпроси

Какво е необходимо на LibreTranslate за production deployment?

Насочете контейнера на LibreTranslate през порт 5000 към един HTTPS origin. Локалното изискване за runtime е storage за изтегляне на модели и CPU или GPU, подходящи за съответните езикови двойки. Не обявявайте LibreTranslate за готов, преди да можете да изведете списъка с инсталирани езици, да преведете фиксирано изречение и в двете посоки и да проверите квотата на API ключа и отговорите при грешки.

Кои данни на LibreTranslate трябва да бъдат включени в backup?

Направете /home/libretranslate/.local persistent и включете изтеглените модели, базата данни с API ключове и персонализираната конфигурация в един и същ recovery manifest. Чистото restore на LibreTranslate е успешно само когато моделите и състоянието на API ключовете са възстановени и regression corpus-ът завършва с приемлив резултат.

Необходим ли е HTTPS на LibreTranslate зад reverse proxy?

Използвайте HTTPS за публичния origin на LibreTranslate и запазете порт 5000 във вътрешния route. Приложете правилно настройката на LibreTranslate: предоставяйте API през HTTPS и документирайте правилния base path. При LibreTranslate HTTPS защитава credentials или потребителско съдържание при пренос и поддържа съгласувано поведение на клиента, чувствително към origin-а.

Как трябва да се тества upgrade на LibreTranslate?

Възстановете текущото състояние на LibreTranslate в изолиран deployment, приложете кандидат-версията и повторете acceptance транзакцията. Обърнете особено внимание, защото пакетите с модели и server release-ите могат да променят резултата от превода, затова поддържайте малък regression corpus. Запазете предишния image на LibreTranslate, докато не изясните границите на data migration-а и rollback-а.