Як розгорнути Whoogle на власному сервері у 2026 році: приватність, обмеження частоти запитів і налаштування proxy

Контейнер Whoogle може бути в стані green, хоча потрібна користувачам функція не працює. Для Whoogle прихована причина збою зазвичай полягає в тому, що upstream блокує IP-адресу або змінні середовища proxy налаштовано неправильно. У цьому посібнику критерієм приймання є такий сценарій: виконати пошук у звичайному та приватному режимах, перевірити посилання в результатах, протестувати upstream proxy і спровокувати вибране обмеження частоти запитів. Розгортання будується у зворотному напрямку — від цього результату.

Whoogle виконує в стеку конкретну роль: надає результати пошуку Google без реклами, трекінгу та клієнтського JavaScript. Тому у production важливо не те, чи відповідає порт 5000 один раз, а те, чи продовжують стан, залежності та публічна адреса узгоджено працювати після перезапуску, оновлення й відновлення.

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

Корисна схема Whoogle показує публічний маршрут, приватний порт 5000, межу стану та всі допоміжні вимоги. Позначте, якими стрілками передаються облікові дані, а якими — звичайний користувацький трафік. Зовнішня вимога для Whoogle — доступ до outbound HTTPS і стабільна IP-адреса сервера, яку приймають пошукові провайдери. Перевірте outbound DNS, TLS і поведінку провайдера, не публікуючи додатковий вхідний сервіс.

Підтвердьте схему однією реальною дією: виконайте пошук у звичайному та приватному режимах, перевірте посилання в результатах, протестуйте upstream proxy і спровокуйте вибране обмеження частоти запитів. Найімовірніше, проблеми виникатимуть через блокування пошуковим upstream, репутацію IP-адреси сервера, паралельні запити та затримку proxy; моніторте саме цей шлях, а не всі HTTP-запити як рівнозначні.

Налаштуйте маршрут Whoogle без помилкових тверджень про HTTPS

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

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

Зробіть запуск Whoogle відтворюваним

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

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. Читайте найпершу помилку запуску, а не фінальне повідомлення про перезапуск, перевіряйте кожне mount за допомогою docker inspect і стежте за логами, поки виконуєте пошук у звичайному та приватному режимах, перевіряєте посилання в результатах, тестуєте upstream proxy і провокуєте вибране обмеження частоти запитів. Така послідовність допомагає відрізнити неправильну команду запуску image від проблеми із залежністю або правами доступу.

Логи, які відповідають на наступне запитання

Для Whoogle моніторте транзакцію, а не процес: виконайте пошук у звичайному та приватному режимах, перевірте посилання в результатах, протестуйте upstream proxy і спровокуйте вибране обмеження частоти запитів. Поєднуйте її latency та error rate із блокуванням пошуковим upstream, репутацією IP-адреси сервера, паралельними запитами та затримкою proxy, щоб alert вказував на обмежений компонент.

Репетиція оновлення має враховувати, що зміни розмітки upstream і релізи Whoogle можуть зламати parsing, не переводячи контейнер у стан unhealthy. Виконайте restore, міграцію та транзакцію до заміни production-версії. Якщо upstream блокує IP-адресу або змінні середовища proxy налаштовано неправильно, не стирайте дані, щоб запуск завершувався успішно; послідовно порівняйте версію, змінні, mount і доступність залежностей.

Перетворіть smoke test Whoogle на перевірку релізу

Створіть невеликий тимчасовий fixture Whoogle і зберігайте його для кожного релізу. Fixture має перевіряти реальний workflow: виконати пошук у звичайному та приватному режимах, перевірити посилання в результатах, протестувати upstream proxy і спровокувати вибране обмеження частоти запитів. Записуйте digest image, зовнішній hostname, адресу залежності та очікуваний результат, щоб інший оператор міг повторити тест без додаткової інтерпретації цього посібника.

Запустіть fixture тричі. Спочатку використайте свіже розгортання. Потім замініть контейнер, не змінюючи постійний стан. Втретє відновіть резервну копію в порожньому середовищі. Третій запуск вважається успішним лише тоді, коли конфігурація та налаштування повернулися, а фіксований набір запитів і далі повертає придатні для використання посилання в результатах. Під час кожного запуску фіксуйте latency і використання ресурсів навколо блокування пошуковим upstream, репутації IP-адреси сервера, паралельних запитів і затримки proxy; це стане базовою лінією для alert, а не довільним значенням CPU у відсотках.

Зрештою навмисно перевірте негативний сценарій: тимчасово забороніть тестовий шлях, який використовують доступ до outbound HTTPS і стабільна IP-адреса сервера, прийнятна для пошукових провайдерів. Переконайтеся, що Whoogle помітно завершується помилкою, не пошкоджуючи стан, відновіть правильну умову й повторіть успішну транзакцію. Запис релізу з цими чотирма результатами є сильнішим доказом, ніж скриншоти dashboard або одноразова відповідь curl.

Знайдіть кожен постійний байт у Whoogle

Проведіть інвентаризацію всіх постійних артефактів: конфігурації та всіх користувацьких налаштувань, що зберігаються на диску. Підключіть /config до bootstrap, запишіть нешкідливі тестові дані й замініть контейнер, щоб довести, що цей шлях справді є persistent. Додайте до інвентаризації конфігурацію, яка змінює спосіб інтерпретації збережених даних, а не лише найбільшу директорію.

Визначте retention, копіюйте резервні копії за межі хоста й виконайте clean-room restore. Перевірку Whoogle завершено, коли конфігурація та налаштування повернулися, а фіксований набір запитів і далі повертає придатні для використання посилання в результатах. Якщо у плані є snapshots, скористайтеся поясненням щодо PITR і snapshot, щоб задокументувати, що саме може відновити кожен механізм.

Захистіть найціннішу частину Whoogle

Безпечне розгортання Whoogle починається з обмеження повноважень. Не запускайте відкритий публічний proxy без контролю зловживань; натомість захистіть будь-який публічний instance автентифікацією або контролем частоти запитів і не зберігайте облікові дані proxy в image.

Негайно замініть приклад WHOOGLE_CONFIG_PASSWORD, зберігайте його за межами image і змініть так само, як облікові дані адміністратора, якщо секрет було розкрито. Обмежте адміністративні маршрути, використовуйте приватний DNS для залежностей і перевірте кожен bind mount. Якщо логи надсилаються до централізованої системи, відфільтруйте секрети й приватний вміст до того, як вони залишать сервер.

Що Dockup має автоматизувати для Whoogle

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

Після запуску виконайте application contract: опублікуйте пошуковий інтерфейс через HTTPS із виміряними обмеженнями частоти запитів, дозвольте та перевірте доступ до outbound HTTPS і стабільну IP-адресу сервера, яку приймають пошукові провайдери, а також виконайте цю перевірку: пошук у звичайному та приватному режимах, перевірка посилань у результатах, тестування upstream proxy і спровоковане вибране обмеження частоти запитів. Це зберігає практичну цінність one-click experience, не приховуючи деталей, завдяки яким Whoogle можна відновити й захистити.

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

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

Спрямуйте контейнер Whoogle на порту 5000 через один HTTPS origin. Зовнішня вимога доставки — доступ до outbound HTTPS і стабільна IP-адреса сервера, яку приймають пошукові провайдери. Не вважайте Whoogle готовим, доки не зможете виконати пошук у звичайному та приватному режимах, перевірити посилання в результатах, протестувати upstream proxy і спровокувати вибране обмеження частоти запитів.

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

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

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

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

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

Відновіть поточний стан Whoogle в ізольованому розгортанні, застосуйте candidate version і повторіть acceptance transaction. Особливо уважно перевірте цей сценарій, оскільки зміни розмітки upstream і релізи Whoogle можуть зламати parsing, не переводячи контейнер у стан unhealthy. Зберігайте попередню image Whoogle, доки не визначите межі міграції даних і rollback.