Comment auto-héberger Whoogle en 2026 : confidentialité, limites de débit et paramètres de proxy

Un conteneur Whoogle peut être au vert alors que la fonctionnalité qui intéresse les utilisateurs est en panne. Avec Whoogle, cette panne invisible vient généralement du blocage de l’IP par le service upstream ou de variables d’environnement de proxy incorrectes. Ce guide considère comme test d’acceptation le fait de « lancer des recherches avec des paramètres standard et de confidentialité, vérifier les liens de résultats, tester un proxy upstream et déclencher la limite de débit choisie », puis construit le déploiement à rebours à partir de ce résultat.

Whoogle joue un rôle précis dans la stack : fournir les résultats de recherche Google sans publicités, tracking ni JavaScript côté client. La question à se poser en production n’est donc pas de savoir si le port 5000 répond une fois, mais si l’état, les dépendances et l’adresse publique continuent de correspondre après un redémarrage, une mise à jour et une restauration.

Définissez d’abord les critères de réussite de Whoogle

Un schéma utile de Whoogle montre la route publique, le port privé 5000, la limite de l’état et chaque prérequis associé. Indiquez quelles flèches transportent des identifiants et lesquelles correspondent à du trafic utilisateur ordinaire. Le prérequis externe de Whoogle est l’accès HTTPS sortant et une IP de serveur stable acceptée par les fournisseurs de recherche. Testez le DNS sortant, TLS et le comportement du fournisseur sans publier un autre service entrant.

Validez le schéma avec une action réelle : lancez des recherches avec des paramètres standard et de confidentialité, vérifiez les liens de résultats, testez un proxy upstream et déclenchez la limite de débit choisie. Les principaux points de pression sont probablement le blocage par le moteur de recherche upstream, la réputation de l’IP du serveur, les requêtes concurrentes et la latence du proxy ; surveillez ce chemin au lieu de considérer toutes les requêtes HTTP comme équivalentes.

Exposez Whoogle sans faire semblant concernant HTTPS

Évitez les origines publiques temporaires et permanentes pour Whoogle. Publiez plutôt l’interface de recherche via HTTPS avec des limites de débit mesurées, faites pointer le nom DNS choisi vers la route de la plateforme et proxyfiez uniquement vers le port 5000.

Effectuez cette action depuis l’extérieur de l’hôte : lancez des recherches avec des paramètres standard et de confidentialité, vérifiez les liens de résultats, testez un proxy upstream et déclenchez la limite de débit choisie. Si l’ingress échoue, le guide de dépannage des erreurs 502 Bad Gateway couvre les erreurs de port et de listener. Si Whoogle reçoit la requête, mais que le service upstream bloque l’IP ou que les variables d’environnement de proxy sont incorrectes, les éléments disponibles indiquent désormais un problème situé au-delà du proxy.

Rendez le démarrage de Whoogle reproductible

Le premier conteneur doit pouvoir être supprimé et recréé facilement. Conservez les données en dehors de la couche inscriptible, liez le port 5000 uniquement là où le proxy peut l’atteindre et transmettez la configuration au 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

Épinglez l’image après le test initial. Lisez la première erreur survenue au démarrage plutôt que le dernier message de redémarrage, vérifiez chaque mount avec docker inspect et suivez les logs pendant que vous lancez des recherches avec des paramètres standard et de confidentialité, vérifiez les liens de résultats, testez un proxy upstream et déclenchez la limite de débit choisie. Cette séquence permet de distinguer une mauvaise commande d’image d’un problème de dépendance ou de permissions.

Des logs qui répondent à la prochaine question

Avec Whoogle, surveillez une transaction plutôt qu’un processus : lancez des recherches avec des paramètres standard et de confidentialité, vérifiez les liens de résultats, testez un proxy upstream et déclenchez la limite de débit choisie. Mettez en relation sa latence et son taux d’erreur avec le blocage par le moteur de recherche upstream, la réputation de l’IP du serveur, les requêtes concurrentes et la latence du proxy afin qu’une alerte identifie le composant sous contrainte.

La répétition générale d’une mise à niveau doit tenir compte du fait que le markup upstream et les versions de Whoogle peuvent casser le parsing sans rendre le conteneur unhealthy. Restaurez, migrez et exécutez la transaction avant de remplacer la version en production. Si le service upstream bloque l’IP ou que les variables d’environnement de proxy sont incorrectes, n’effacez pas les données pour faire passer le démarrage au vert ; comparez dans cet ordre la version, les variables, les mounts et l’accessibilité des dépendances.

Transformez le smoke test de Whoogle en vérification de release

Créez une petite fixture Whoogle jetable et conservez-la pour chaque release. Elle doit exercer le workflow réel : lancer des recherches avec des paramètres standard et de confidentialité, vérifier les liens de résultats, tester un proxy upstream et déclencher la limite de débit choisie. Enregistrez le digest de l’image, le hostname externe, l’adresse de la dépendance et le résultat attendu afin qu’un autre opérateur puisse répéter le test ultérieurement sans devoir interpréter ce guide.

Exécutez la fixture trois fois. Premièrement, utilisez le déploiement vierge. Deuxièmement, remplacez le conteneur sans toucher à l’état durable. Troisièmement, restaurez la sauvegarde dans un environnement vide. La troisième exécution ne réussit que si la configuration et les préférences sont restaurées et qu’un ensemble fixe de requêtes produit toujours des liens de résultats exploitables. Pendant chaque exécution, mesurez la latence et l’utilisation des ressources autour du blocage par le moteur de recherche upstream, de la réputation de l’IP du serveur, des requêtes concurrentes et de la latence du proxy ; ces données deviennent la base des alertes, plutôt qu’un pourcentage de CPU arbitraire.

Enfin, testez délibérément le chemin négatif : refusez temporairement le chemin de test utilisé pour l’accès HTTPS sortant et une IP de serveur stable acceptée par les fournisseurs de recherche. Vérifiez que Whoogle échoue de manière visible sans corrompre l’état, rétablissez la condition correcte et répétez la transaction réussie. Un compte rendu de release contenant ces quatre résultats constitue une preuve plus solide que des captures d’écran d’un dashboard ou qu’une réponse curl obtenue une seule fois.

Trouvez chaque octet durable de Whoogle

Inventoriez chaque artefact durable : la configuration et les éventuelles préférences utilisateur stockées sur disque. Montez /config avant le bootstrap, écrivez des données d’exemple sans risque et remplacez le conteneur pour prouver que ce chemin est bien persistant. Incluez la configuration qui modifie la manière dont les données stockées sont interprétées, pas uniquement le répertoire le plus volumineux.

Définissez la rétention, copiez les sauvegardes hors de l’hôte et exécutez une restauration en clean room. Le test de reprise de Whoogle est terminé lorsque la configuration et les préférences sont restaurées et qu’un ensemble fixe de requêtes produit toujours des liens de résultats exploitables. Si les snapshots font partie du plan, utilisez le guide PITR contre snapshots pour documenter ce que chaque mécanisme permet de restaurer.

Protégez ce qui compte dans Whoogle

Un déploiement Whoogle sécurisé commence par la réduction des privilèges. Évitez d’exécuter un proxy public ouvert sans contrôles anti-abus ; protégez plutôt toute instance publique avec une authentification ou des contrôles de débit, et ne stockez pas les identifiants du proxy dans l’image.

Remplacez immédiatement l’exemple de WHOOGLE_CONFIG_PASSWORD, stockez-le en dehors de l’image et faites-le tourner comme un identifiant administrateur s’il est exposé. Restreignez les routes d’administration, utilisez un DNS privé pour les dépendances et vérifiez chaque bind mount. Lorsque les logs sont envoyés vers un emplacement central, filtrez les secrets et le contenu privé avant qu’ils ne quittent le serveur.

Ce que Dockup devrait automatiser pour Whoogle

Dockup supprime le travail manuel lié au reverse proxy et au lifecycle autour de Whoogle. Le service reçoit une route HTTPS stable vers le port 5000, une configuration injectée et un stockage persistant lors des remplacements. Un serveur client connecté suit le même modèle que l’infrastructure de calcul hébergée par Dockup.

Après le lancement, respectez le contrat applicatif : publiez l’interface de recherche via HTTPS avec des limites de débit mesurées, autorisez et vérifiez l’accès HTTPS sortant ainsi qu’une IP de serveur stable acceptée par les fournisseurs de recherche, puis exécutez cette preuve : lancez des recherches avec des paramètres standard et de confidentialité, vérifiez les liens de résultats, testez un proxy upstream et déclenchez la limite de débit choisie. L’expérience one-click reste ainsi utile sans gommer les détails qui rendent Whoogle récupérable et sécurisé.

Foire aux questions

De quoi Whoogle a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Whoogle sur le port 5000 via une seule origine HTTPS. Le prérequis de distribution externe est l’accès HTTPS sortant et une IP de serveur stable acceptée par les fournisseurs de recherche. Ne considérez pas Whoogle comme prêt avant de pouvoir lancer des recherches avec des paramètres standard et de confidentialité, vérifier les liens de résultats, tester un proxy upstream et déclencher la limite de débit choisie.

Quelles données Whoogle doivent être incluses dans une sauvegarde ?

Conservez /config et incluez la configuration ainsi que les éventuelles préférences utilisateur stockées sur disque dans le même manifeste de reprise. Une restauration Whoogle propre ne réussit que si la configuration et les préférences sont restaurées et qu’un ensemble fixe de requêtes produit toujours des liens de résultats exploitables.

Whoogle nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Whoogle et conservez le port 5000 sur la route interne. Appliquez correctement le paramètre Whoogle : publiez l’interface de recherche via HTTPS avec des limites de débit mesurées. Pour Whoogle, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit la cohérence du comportement client dépendant de l’origine.

Comment tester une mise à niveau de Whoogle ?

Restaurez l’état actuel de Whoogle dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car le markup upstream et les versions de Whoogle peuvent casser le parsing sans rendre le conteneur unhealthy. Conservez l’image Whoogle précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.