Slik selvhoster du Whoogle i 2026: personvern, rate limits og proxy-innstillinger

En Whoogle-container kan ha grønn status selv om funksjonen brukerne bryr seg om, er ødelagt. For Whoogle skyldes denne skjulte feilen vanligvis at upstream blokkerer IP-adressen, eller at proxy-miljøvariablene er feil. Denne veiledningen bruker «send søk med normale innstillinger og personverninnstillinger, verifiser resultatlenker, test en upstream-proxy og utløs den valgte rate limiten» som akseptansetest, og bygger utrullingen baklengs fra dette resultatet.

Whoogle har en tydelig rolle i stacken: Google-søkeresultater uten annonser, sporing eller JavaScript på klientsiden. Produksjonsspørsmålet er derfor ikke om port 5000 svarer én gang, men om state, avhengigheter og den offentlige adressen fortsatt stemmer overens etter en omstart, oppdatering og gjenoppretting.

Definer suksess for Whoogle først

Et nyttig Whoogle-diagram viser den offentlige ruten, den private porten 5000, state-grensen og alle støttende krav. Marker hvilke piler som inneholder credentials, og hvilke som er vanlig brukertrafikk. Det eksterne kravet for Whoogle er utgående HTTPS-tilgang og en stabil server-IP som søkeleverandørene aksepterer. Test utgående DNS, TLS og leverandørens oppførsel uten å publisere en ekstra innkommende tjeneste.

Bevis diagrammet med én reell handling: send søk med normale innstillinger og personverninnstillinger, verifiser resultatlenker, test en upstream-proxy og utløs den valgte rate limiten. Det sannsynlige presset kommer fra blokkering hos upstream-søk, serverens IP-omdømme, samtidige forespørsler og proxy-latens. Overvåk denne banen i stedet for å behandle alle HTTP-forespørsler likt.

Rute Whoogle uten å late som HTTPS er på plass

Unngå midlertidige og permanente offentlige origins for Whoogle. Publiser i stedet søkegrensesnittet via HTTPS med målte rate limits, pek det valgte DNS-navnet til plattformruten, og prox videre kun til port 5000.

Test denne handlingen utenfra verten: send søk med normale innstillinger og personverninnstillinger, verifiser resultatlenker, test en upstream-proxy og utløs den valgte rate limiten. Hvis ingress feiler, dekker veiledningen for feilsøking av 502 Bad Gateway feil med porter og listeners. Hvis Whoogle mottar forespørselen, men upstream blokkerer IP-adressen eller proxy-miljøvariablene er feil, peker bevisene nå forbi proxylaget.

Gjør oppstarten av Whoogle reproduserbar

Den første containeren bør være enkel å slette og opprette på nytt. Hold data utenfor det skrivbare laget, bind port 5000 bare der proxylaget kan nå den, og send konfigurasjon inn ved 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

Lås image-versjonen etter den første testen. Les den tidligste oppstartsfeilen i stedet for den siste restart-meldingen, verifiser hver mount med docker inspect, og følg loggene mens du sender søk med normale innstillinger og personverninnstillinger, verifiser resultatlenker, tester en upstream-proxy og utløser den valgte rate limiten. Denne rekkefølgen skiller en feil i image-kommandoen fra et problem med avhengigheter eller tillatelser.

Logger som svarer på det neste spørsmålet

For Whoogle bør du overvåke en transaksjon, ikke en prosess: send søk med normale innstillinger og personverninnstillinger, verifiser resultatlenker, test en upstream-proxy og utløs den valgte rate limiten. Kombiner latens og feilrate med blokkering hos upstream-søk, serverens IP-omdømme, samtidige forespørsler og proxy-latens, slik at et varsel identifiserer den begrensende komponenten.

Oppgraderingsøvelsen må dekke at markup hos upstream og Whoogle-releaser kan ødelegge parsing uten at containeren blir unhealthy. Gjenopprett, migrer og kjør transaksjonen før du erstatter produksjonen. Hvis upstream blokkerer IP-adressen eller proxy-miljøvariablene er feil, må du ikke slette data for å få en grønn oppstart. Sammenlign versjon, variabler, mounts og nåbarhet til avhengigheter i denne rekkefølgen.

Gjør smoke-testen for Whoogle til en release-kontroll

Opprett en liten, midlertidig Whoogle-fixture og behold den for hver release. Fixturen bør teste den reelle arbeidsflyten: send søk med normale innstillinger og personverninnstillinger, verifiser resultatlenker, test en upstream-proxy og utløs den valgte rate limiten. Registrer image digest, eksternt hostname, adressen til avhengigheten og det forventede resultatet, slik at en senere operatør kan gjenta testen uten å tolke denne veiledningen.

Kjør fixturen tre ganger. Først bruker du den nye utrullingen. Deretter erstatter du containeren uten å endre persistent state. Til slutt gjenoppretter du sikkerhetskopien i et tomt miljø. Den tredje kjøringen består bare når konfigurasjon og preferanser kommer tilbake, og et fast sett med spørringer fortsatt gir brukbare resultatlenker. Under hver kjøring måler du latens og ressursbruk rundt blokkering hos upstream-søk, serverens IP-omdømme, samtidige forespørsler og proxy-latens. Dette blir grunnlaget for varsler, i stedet for en vilkårlig CPU-prosent.

Til slutt tester du den negative banen med vilje: blokker midlertidig testbanen som brukes av utgående HTTPS-tilgang og en stabil server-IP som søkeleverandørene aksepterer. Bekreft at Whoogle feiler synlig uten å ødelegge state, gjenopprett riktig tilstand og gjenta den vellykkede transaksjonen. En release-registrering med disse fire resultatene er sterkere dokumentasjon enn skjermbilder av et dashboard eller ett enkelt curl-svar.

Finn alle persistente byte i Whoogle

Kartlegg alle persistente artefakter: konfigurasjon og eventuelle brukerpreferanser som lagres på disk. Mount /config før bootstrap, skriv ufarlige eksempeldata, og erstatt containeren for å bevise at banen faktisk er persistent. Ta med konfigurasjon som endrer hvordan lagrede data tolkes, ikke bare den største katalogen.

Definer retention, kopier sikkerhetskopier utenfor verten og gjennomfør en clean-room-gjenoppretting. Whoogle-øvelsen er fullført når konfigurasjon og preferanser kommer tilbake, og et fast sett med spørringer fortsatt gir brukbare resultatlenker. Hvis snapshots er en del av planen, bruker du veiledningen om PITR versus snapshot til å dokumentere hva hver mekanisme kan gjenopprette.

Beskytt den verdifulle delen av Whoogle

En sikker Whoogle-utrulling starter med å fjerne privilegier. Unngå å kjøre en åpen offentlig proxy uten abuse-kontroller. Beskytt i stedet alle offentlige instanser med authentication eller rate controls, og hold proxy-credentials utenfor imaget.

Bytt ut eksempelverdien for WHOOGLE_CONFIG_PASSWORD umiddelbart, lagre den utenfor imaget og roter den som en administrator-credential hvis den blir eksponert. Begrens administrative ruter, bruk privat DNS for avhengigheter og gjennomgå hver bind mount. Når logger sendes til en sentral tjeneste, må secrets og privat innhold filtreres før de forlater serveren.

Hva Dockup bør automatisere for Whoogle

Dockup fjerner manuelt arbeid med reverse proxy og lifecycle rundt Whoogle. Tjenesten får en stabil HTTPS-rute til 5000, injisert konfigurasjon og persistent lagring når containere erstattes. En tilkoblet kundeserver følger samme modell som compute som hostes av Dockup.

Etter lansering må du oppfylle applikasjonskontrakten: publiser søkegrensesnittet via HTTPS med målte rate limits, tillat og verifiser utgående HTTPS-tilgang og en stabil server-IP som søkeleverandørene aksepterer, og kjør denne testen: send søk med normale innstillinger og personverninnstillinger, verifiser resultatlenker, test en upstream-proxy og utløs den valgte rate limiten. Dette gjør one-click-opplevelsen nyttig uten å skjule detaljene som gjør Whoogle gjenopprettbar og sikker.

Vanlige spørsmål

Hva trenger Whoogle for en produksjonsutrulling?

Rout Whoogle-containeren på port 5000 gjennom én HTTPS-origin. Det eksterne leveransekravet er utgående HTTPS-tilgang og en stabil server-IP som søkeleverandørene aksepterer. Ikke erklær Whoogle klar før du kan sende søk med normale innstillinger og personverninnstillinger, verifisere resultatlenker, teste en upstream-proxy og utløse den valgte rate limiten.

Hvilke Whoogle-data hører hjemme i en sikkerhetskopi?

Gjør /config persistent, og ta med konfigurasjon og eventuelle brukerpreferanser som lagres på disk i det samme recovery-manifestet. En ren Whoogle-gjenoppretting er vellykket først når konfigurasjon og preferanser kommer tilbake, og et fast sett med spørringer fortsatt gir brukbare resultatlenker.

Krever Whoogle HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Whoogle-originen, og behold port 5000 på den interne ruten. Bruk Whoogle-innstillingen riktig: publiser søkegrensesnittet via HTTPS med målte rate limits. For Whoogle beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at klientsidenes origin-sensitive oppførsel forblir konsistent.

Hvordan bør en Whoogle-oppgradering testes?

Gjenopprett gjeldende Whoogle-state i en isolert utrulling, installer kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at markup hos upstream og Whoogle-releaser kan ødelegge parsing uten at containeren blir unhealthy. Behold det forrige Whoogle-imaget til grensen for datamigrering og rollback er forstått.