Как да хоствате Whoogle самостоятелно през 2026 г.: поверителност, ограничения на честотата и proxy настройки

Контейнерът на Whoogle може да е в зелено, докато реалната функционалност, от която потребителите се нуждаят, е повредена. При Whoogle този скрит проблем обикновено означава, че upstream блокира IP адреса или че proxy environment variables са зададени неправилно. Този наръчник приема като acceptance test „изпращане на търсения с обичайни и поверителни настройки, проверка на връзките към резултатите, тестване на upstream proxy и задействане на избраното ограничение на честотата“ и изгражда deployment-а обратно от този резултат.

Whoogle има конкретна роля в stack-а: резултати от търсене в Google без реклами, tracking или client-side JavaScript. Следователно production въпросът не е дали порт 5000 ще отговори веднъж, а дали state-ът, зависимостите и публичният адрес ще продължат да съвпадат след restart, update и restore.

Първо дефинирайте успеха за Whoogle

Полезната диаграма на Whoogle показва публичния маршрут, частния порт 5000, границата на state-а и всяко поддържащо изискване. Отбележете кои стрелки пренасят credentials и кои представляват обикновен user traffic. Външното изискване за Whoogle е outbound HTTPS достъп и стабилен server IP, който доставчиците на търсене приемат. Тествайте outbound DNS, TLS и поведението на доставчика, без да публикувате друга inbound услуга.

Докажете диаграмата с едно реално действие: изпратете търсения с обичайни и поверителни настройки, проверете връзките към резултатите, тествайте upstream proxy и задействайте избраното ограничение на честотата. Най-вероятният натиск идва от блокиране от upstream search, репутацията на server IP, едновременните заявки и latency на proxy-то; наблюдавайте този път, вместо да третирате всички HTTP заявки като еднакви.

Насочете Whoogle правилно, без да подвеждате за HTTPS

Избягвайте временни и постоянни публични origins за Whoogle. Вместо това публикувайте search UI през HTTPS с измерени rate limits, насочете избраното DNS име към platform route и проксирайте само към порт 5000.

Изпълнете това действие извън хоста: изпратете търсения с обичайни и поверителни настройки, проверете връзките към резултатите, тествайте upstream proxy и задействайте избраното ограничение на честотата. Ако ingress не работи, наръчникът за отстраняване на проблеми с 502 обхваща грешки в порта и listener-а. Ако Whoogle получава заявката, но upstream блокира IP адреса или proxy environment variables са зададени неправилно, доказателствата вече насочват отвъд proxy-то.

Направете стартирането на Whoogle възпроизводимо

Първият контейнер трябва да може лесно да бъде изтрит и създаден отново. Дръжте данните извън writable layer-а, bind-нете порт 5000 само там, където proxy-то може да достигне до него, и подайте конфигурацията по време на runtime.

docker run -d \
  --name whoogle \
  --restart unless-stopped \
  -p 127.0.0.1:5000:5000 \
  -v whoogle-data:/config \
  -e WHOOGLE_CONFIG_PASSWORD=replace-with-a-long-random-value \
  benbusby/whoogle-search:latest

Фиксирайте image-а след първоначалния тест. Прочетете най-ранната startup грешка, а не финалното съобщение за restart, проверете всеки mount с docker inspect и следете logs, докато изпращате търсения с обичайни и поверителни настройки, проверявате връзките към резултатите, тествате upstream proxy и задействате избраното ограничение на честотата. Тази последователност разграничава неправилна команда за image от проблем със зависимост или permissions.

Logs, които отговарят на следващия въпрос

При Whoogle наблюдавайте транзакция, а не процес: изпращайте търсения с обичайни и поверителни настройки, проверявайте връзките към резултатите, тествайте upstream proxy и задействайте избраното ограничение на честотата. Съчетайте latency и error rate с блокирането от upstream search, репутацията на server IP, едновременните заявки и latency на proxy-то, така че alert-ът да идентифицира ограничения компонент.

Upgrade rehearsal-ът трябва да обхваща факта, че markup-ът на upstream и release-ите на Whoogle могат да повредят parsing-а, без контейнерът да стане unhealthy. Направете restore, изпълнете migration и стартирайте транзакцията преди production replacement. Ако upstream блокира IP адреса или proxy environment variables са зададени неправилно, не изтривайте данни, за да стане startup-ът зелен; сравнете version, variables, mounts и достижимостта на зависимостите в този ред.

Превърнете smoke test-а на Whoogle в release check

Създайте малък, disposable Whoogle fixture и го запазете за всеки release. Fixture-ът трябва да изпълнява реалния workflow: изпращане на търсения с обичайни и поверителни настройки, проверка на връзките към резултатите, тестване на upstream proxy и задействане на избраното ограничение на честотата. Запишете image digest-а, external hostname-а, dependency address-а и очаквания резултат, така че по-късен оператор да може да повтори теста, без да интерпретира този наръчник.

Стартирайте fixture-а три пъти. Първо използвайте новия deployment. Второ, заменете контейнера, без да засягате durable state-а. Трето, възстановете backup-а в празна среда. Третият run е успешен само когато конфигурацията и preferences се възстановят и фиксиран набор от заявки продължи да връща използваеми връзки към резултатите. По време на всеки run събирайте latency и resource usage около блокирането от upstream search, репутацията на server IP, едновременните заявки и latency на proxy-то; това става baseline за alerts, вместо произволен процент CPU.

Накрая тествайте умишлено negative path-а: временно блокирайте test path-а, използван за outbound HTTPS достъпа и стабилния server IP, който доставчиците на търсене приемат. Потвърдете, че Whoogle се проваля видимо, без да поврежда state-а, възстановете правилното условие и повторете успешната транзакция. Release record с тези четири резултата е по-силно доказателство от screenshots на dashboard или еднократен curl отговор.

Открийте всеки durable byte в Whoogle

Направете inventory на всеки durable artifact: конфигурацията и всички user preferences, съхранявани на диска. Mount-нете /config преди bootstrap, запишете безвредни примерни данни и заменете контейнера, за да докажете, че този path действително е persistent. Включете и конфигурацията, която променя начина на интерпретиране на съхранените данни, а не само най-голямата директория.

Задайте retention, копирайте backups извън хоста и изпълнете clean-room restore. Drill-ът на Whoogle е завършен, когато конфигурацията и preferences се възстановят и фиксиран набор от заявки продължи да връща използваеми връзки към резултатите. Ако snapshots са част от плана, използвайте насоките за PITR спрямо snapshot, за да документирате какво може да възстанови всеки механизъм.

Защитете ценната част на Whoogle

Сигурният deployment на Whoogle започва с премахване на излишните права. Избягвайте open public proxy без abuse controls; вместо това защитете всеки публичен instance с authentication или rate controls и не съхранявайте proxy credentials в image-а.

Сменете примерния WHOOGLE_CONFIG_PASSWORD незабавно, съхранявайте го извън image-а и го ротирайте като administrator credential, ако бъде разкрит. Ограничете administrative routes, използвайте private DNS за зависимостите и прегледайте всеки bind mount. Когато logs се изпращат към централизирана система, филтрирайте secrets и private content, преди да напуснат сървъра.

Какво трябва да автоматизира Dockup за Whoogle

Dockup премахва ръчната работа по reverse proxy и lifecycle около Whoogle. Услугата получава стабилен HTTPS route към 5000, инжектирана конфигурация и persistent storage при replacements. Свързаният customer server следва същия модел като compute, хостван от Dockup.

След launch изпълнете application contract-а: публикувайте search UI през HTTPS с измерени rate limits, разрешете и проверете outbound HTTPS достъпа и стабилния server IP, който доставчиците на търсене приемат, и изпълнете следното доказателство: изпратете търсения с обичайни и поверителни настройки, проверете връзките към резултатите, тествайте upstream proxy и задействайте избраното ограничение на честотата. Така one-click изживяването остава полезно, без да се заличават детайлите, които правят Whoogle възстановим и сигурен.

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

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

Насочете контейнера на Whoogle през порт 5000 към един HTTPS origin. Външното delivery изискване е outbound HTTPS достъп и стабилен server IP, който доставчиците на търсене приемат. Не обявявайте Whoogle за готов, преди да можете да изпращате търсения с обичайни и поверителни настройки, да проверявате връзките към резултатите, да тествате upstream proxy и да задействате избраното ограничение на честотата.

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

Направете /config persistent и включете конфигурацията и всички user preferences, съхранявани на диска, в същия recovery manifest. Clean Whoogle restore е успешен само когато конфигурацията и preferences се възстановят и фиксиран набор от заявки продължи да връща използваеми връзки към резултатите.

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

Използвайте HTTPS за публичния Whoogle origin и оставете порт 5000 във вътрешния маршрут. Приложете настройката на Whoogle правилно: публикувайте search UI през HTTPS с измерени rate limits. При Whoogle HTTPS защитава credentials или user content при преноса и поддържа последователно client behavior, зависимо от origin-а.

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

Възстановете текущия state на Whoogle в изолиран deployment, приложете candidate version и повторете acceptance транзакцията. Обърнете специално внимание, защото markup-ът на upstream и release-ите на Whoogle могат да повредят parsing-а, без контейнерът да стане unhealthy. Запазете предишния Whoogle image, докато не изясните границите на data migration и rollback.