Slik selvhoster du PicoShare i 2026: opplastinger, delte hemmeligheter og lagring

Det er ved den første redeployen, ikke den første docker run, at selvhosting av PicoShare virkelig blir interessant. Hvis opplastinger møter proxygrenser eller filer forsvinner fordi /data-stien er ephemeral, kan Docker fortsatt rapportere en prosess som er helt frisk. Distribusjonen nedenfor er organisert rundt observerbar atferd: last opp en fil, last den ned fra en ny nettleser, test utløping eller sletting, og prøv på nytt med en fil nær den valgte størrelsesgrensen.

Den tiltenkte oppgaven til PicoShare er tydelig: minimal fildeling som gjør opplastinger om til lenker. Denne beskrivelsen forteller oss hva som må være offentlig, hva som bør forbli privat, og hva en sikkerhetskopi må kunne gjenopprette.

Gjør gjenoppretting av PicoShare målbar

Lag et gjenopprettingsmanifest for PicoShare: opplastede filer og PicoShare-metadata i /data. Monter /data før bootstrap, skriv ufarlige eksempeldata, og erstatt containeren for å bevise at denne stien faktisk er persistent. Kontroller eierskap og ledig plass nå, fordi en montert, men ikke skrivbar sti i praksis oppfører seg som om det ikke finnes persistent lagring.

Sikkerhetskopier til et failure domain som er separat fra serveren som kjører. Gjenopprett PicoShare fra det pinnede imaget, og bekreft at opplastede byte og metadata kommer tilbake, og at et utvalg av eksisterende lenker laster ned filer med samsvarende hasher. Veiledningen om persistent volumes hjelper deg med å omsette denne øvelsen til en policy for snapshots og retention.

Produksjonsoppsettet for PicoShare

HTTP-prosessen til PicoShare lytter på 4001. Behold denne porten på applikasjonsnettverket, og publiser bare plattformruten. Det lokale runtime-kravet er et persistent data volume og nok diskplass til filer som skal beholdes. Dokumenter forventet kapasitet, eierskap og failure mode i stedet for å overlate dette til image-standardene.

Skriv ned grensen som en kort kontrakt: hvem som eier kravet, hvilken credential som brukes, hvilken timeout som er akseptabel, og hvordan en feil vises. Kjør deretter denne transaksjonen: last opp en fil, last den ned fra en ny nettleser, test utløping eller sletting, og prøv på nytt med en fil nær den valgte størrelsesgrensen. Følg med på diskkapasitet, opplastingsbåndbredde, proxyens body limits og samtidige nedlastinger under kjøringen, fordi denne arbeidsbelastningen gir et mer nyttig utgangspunkt for dimensjonering enn en inaktiv container.

Release-gaten for PicoShare

Gjør PicoShare-smoketesten om til en repeterbar release-kommando eller en kort runbook. Resultatet må dokumentere følgende: last opp en fil, last den ned fra en ny nettleser, test utløping eller sletting, og prøv på nytt med en fil nær den valgte størrelsesgrensen. Registrer applikasjonsversjon, container-digest, rutehostname og identifikator for testdata sammen med resultatet.

Kjør den samme kontrollen etter et vanlig containerbytte og etter at opplastede filer og PicoShare-metadata er gjenopprettet et annet sted i /data. Gjenopprettingen er vellykket når opplastede byte og metadata kommer tilbake, og et utvalg av eksisterende lenker laster ned filer med samsvarende hasher. Sammenlign tidsbruk og forbruk knyttet til diskkapasitet, opplastingsbåndbredde, proxyens body limits og samtidige nedlastinger. En stor endring bør undersøkes selv når den endelige handlingen fortsatt lykkes.

Test deretter en trygg feiltilstand: send inn ufarlige data nær ressurs- eller formatgrensen som gjelder for denne grensen: opplastinger møter proxygrenser, eller filer forsvinner fordi /data-stien er ephemeral. Bekreft at PicoShare viser feilen og går tilbake til normal drift uten destruktive manuelle endringer. Ta vare på bare det nødvendige, redigerte utdraget fra loggen. Denne firedelte gaten dekker oppstart, persistent lagring, gjenoppretting og feilhåndtering.

Containerinnstillinger det er verdt å gå gjennom

Start PicoShare på en måte som holder ruten privat til bootstrap er fullført.

docker run -d \
  --name picoshare \
  --restart unless-stopped \
  -p 127.0.0.1:4001:4001 \
  -v picoshare-data:/data \
  -e PS_SHARED_SECRET=replace-with-a-long-random-value \
  mtlynch/picoshare:latest

Hvis prosessen går i loop, sammenlign brukeren imaget forventer, med eieren av hver monterte sti. Hvis den holder seg oppe, test port 4001 lokalt og gå deretter direkte til arbeidsflyten: last opp en fil, last den ned fra en ny nettleser, test utløping eller sletting, og prøv på nytt med en fil nær den valgte størrelsesgrensen. Pinn imaget til en bestemt versjon først etter at denne ende-til-ende-kontrollen er bestått, og dokumenter den nøyaktige konfigurasjonen sammen med tjenesten.

Begrens hvilke rettigheter PicoShare har

Bootstrap-credentials er midlertidige; trust-modellen er permanent. Med PicoShare bør du unngå et gjettbart shared secret og ubegrenset anonym lagring. Bruk i stedet et langt shared secret, rate-limit opplastinger, og unngå å gjøre tjenesten til ubegrenset anonym lagring.

Bytt ut eksempelverdien for PS_SHARED_SECRET umiddelbart, lagre den utenfor imaget, og roter den som en administrator-credential hvis den blir eksponert. Kjør imaget uten unødvendige Linux capabilities, og eksponer bare den offentlige applikasjonsruten. Sørg for at administratoraktivitet er synlig uten å logge hemmelighetsverdier.

Rute PicoShare uten å late som HTTPS er på plass

Unngå midlertidige og permanente offentlige origins for PicoShare. Publiser i stedet én HTTPS-origin, dimensjoner proxyen for forventede opplastinger, pek det valgte DNS-navnet mot plattformruten, og prox videre bare til port 4001.

Test denne handlingen utenfra verten: last opp en fil, last den ned fra en ny nettleser, test utløping eller sletting, og prøv på nytt med en fil nær den valgte størrelsesgrensen. Hvis ingress feiler, dekker veiledningen for feilsøking av 502 feil med porter og listeners. Hvis PicoShare mottar forespørselen, men opplastinger møter proxygrenser eller filer forsvinner fordi /data-stien er ephemeral, peker bevisene nå forbi proxyen.

Kapasitets- og oppgraderingskontroller

En health check i inaktiv tilstand sier lite om PicoShare. Følg med på diskkapasitet, opplastingsbåndbredde, proxyens body limits og samtidige nedlastinger, og varsle på symptomet brukerne faktisk opplever: at handlingen «last opp en fil, last den ned fra en ny nettleser, test utløping eller sletting, og prøv på nytt med en fil nær den valgte størrelsesgrensen» feiler. Hold liveness lokal og rimelig; la readiness rapportere migreringer eller initialisering uten å utløse en restart storm.

Det risikable ved en oppgradering er at PicoShare-metadata og filoppsett bør kontrolleres før oppgraderingen, fordi lenken bare er nyttig så lenge begge stemmer overens. Les release notes, ta et snapshot av tilstanden, deploy målversjonen mot en gjenopprettet kopi, og gjenta akseptansetesten. Hvis opplastinger møter proxygrenser eller filer forsvinner fordi /data-stien er ephemeral, må du korrelere klientforespørselen med den første relevante applikasjonsloggen i stedet for å slette tilstand eller legge til redirects på måfå.

Deploy PicoShare på Dockup uten å miste grensene

Dockup fjerner manuelt arbeid med reverse proxy og livssyklus rundt PicoShare. Tjenesten får en stabil HTTPS-rute til 4001, injisert konfigurasjon og persistent lagring under utskiftinger. En tilkoblet kundeserver følger samme modell som Dockup-hostet compute.

Etter lansering må du oppfylle applikasjonskontrakten: publiser én HTTPS-origin og dimensjoner proxyen for forventede opplastinger, bekreft det lokale kravet — et persistent data volume og nok diskplass til filer som skal beholdes — og kjør denne testen: last opp en fil, last den ned fra en ny nettleser, test utløping eller sletting, og prøv på nytt med en fil nær den valgte størrelsesgrensen. Slik forblir one-click-opplevelsen nyttig uten å skjule detaljene som gjør PicoShare gjenopprettbar og sikker.

Vanlige spørsmål

Hva trenger PicoShare for en produksjonsdistribusjon?

Rute PicoShare-containeren på port 4001 gjennom én HTTPS-origin. Det lokale runtime-kravet er et persistent data volume og nok diskplass til filer som skal beholdes. Ikke erklær PicoShare klar før du kan laste opp en fil, laste den ned fra en ny nettleser, teste utløping eller sletting, og prøve på nytt med en fil nær den valgte størrelsesgrensen.

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

Gjør /data persistent, og inkluder opplastede filer og PicoShare-metadata i /data i det samme gjenopprettingsmanifestet. En ren PicoShare-gjenoppretting er bare vellykket når opplastede byte og metadata kommer tilbake, og et utvalg av eksisterende lenker laster ned filer med samsvarende hasher.

Krever PicoShare HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige PicoShare-origin, og behold port 4001 på den interne ruten. Bruk PicoShare-innstillingen riktig: publiser én HTTPS-origin og dimensjoner proxyen for forventede opplastinger. For PicoShare beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientatferd som avhenger av origin.

Hvordan bør en PicoShare-oppgradering testes?

Gjenopprett gjeldende PicoShare-tilstand i en isolert distribusjon, bruk kandidatversjonen, og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på dette: PicoShare-metadata og filoppsett bør kontrolleres før en oppgradering, fordi lenken bare er nyttig så lenge begge stemmer overens. Behold det forrige PicoShare-imaget til grensene for datamigrering og rollback er forstått.