Homepage-palvelun itsehostaus vuonna 2026: sallitut hostit, widgetit ja konfiguraatio
Käytännönläheinen Homepage-palvelun itsehostausopas, joka käsittelee Dockeria, portteja, pysyvää dataa, TLS:ää, tietoturvaa, varmuuskopioita ja tuotantokäyttöä estäviä vikatilanteita. Mukana tarkistukset.
“Homepage-palvelun ajamisesta” on kaksi eri versiota: säilö on olemassa tai palvelu hoitaa oikean tehtävänsä. Vain jälkimmäisellä on merkitystä. Tässä se tarkoittaa, että palvelut ja kirjanmerkit latautuvat, useita live-widgetejä voidaan kutsua, haku toimii ja säilö voidaan käynnistää uudelleen YAML-konfiguraatiotiedoston muokkauksen jälkeen.
Homepage on tarkoitettu tähän: itsehostattujen palvelujen aloitussivuksi, jossa on live-widgetejä. Käyttöönoton on säilytettävä kaikki tämän toiminnan taustalla olevat osat; portti, volume ja sertifikaatti ovat syötteitä, eivät lopputulos.
Valitse pienin toimiva Homepage-topologia
Hyödyllinen Homepage-kaavio näyttää julkisen reitin, yksityisen portin 3000, tilarajan ja kaikki tukivaatimukset. Merkitse, mitkä nuolet välittävät tunnistetietoja ja mitkä ovat tavallista käyttäjäliikennettä. Homepage-palvelun ulkoinen vaatimus on vain luku -muotoinen konfiguraatio sekä valinnaisten palveluwidgetien tunnistetiedot. Testaa lähtevän liikenteen DNS-, TLS- ja provider-toiminta julkaisematta uutta sisääntulevaa palvelua.
Todista kaavio yhdellä oikealla toiminnolla: lataa palvelut ja kirjanmerkit, kutsu useita live-widgetejä, testaa haku ja käynnistä palvelu uudelleen YAML-konfiguraatiotiedoston muokkauksen jälkeen. Todennäköinen kuormitus syntyy widgettien fan-out-liikenteestä, hitaista downstream-API-rajapinnoista, DNS-resoluutiosta ja selainkoontinäytön päivitystiheydestä. Seuraa tätä reittiä sen sijaan, että käsittelisit kaikkia HTTP-pyyntöjä samanarvoisina.
Päivitä Homepage arvailematta
Ensimmäinen hyödyllinen Homepage-palvelun operatiivinen mittari on se, latautuvatko palvelut ja kirjanmerkit, voidaanko useita live-widgetejä kutsua, toimiiko haku ja voidaanko palvelu käynnistää uudelleen YAML-konfiguraatiotiedoston muokkauksen jälkeen. Yhdistä tähän widgettien fan-out-liikenteen, hitaiden downstream-API-rajapintojen, DNS-resoluution ja selainkoontinäytön päivitystiheyden saturation-signaalit. Pelkkään prosessiin perustuvan probe-tarkistuksen ei pidä kutsua raskaita riippuvuuksia tai käynnistää säilöä uudelleen vain siksi, että upstream-palvelu ei hetken aikaa vastaa.
Käsittele päivityksiä datamuutoksina, koska konfiguraatioavaimet ja widget-integraatiot voivat muuttua. Validoi YAML ja providerien toiminta ennen image-päivitystä. Kiinnitä versiot, harjoittele palautetulla tilalla ja pidä edellinen image saatavilla, kunnes rollback on edelleen mahdollinen. Jos host hylätään tai YAML:n sisennys estää konfiguraation lataamisen, säilytä lokit ennen uudelleenkäynnistystä; niissä on yleensä varsinainen syyviesti.
Homepage-palvelun tuotantovalmiuden hyväksymistesti
Ennen oikeiden käyttäjien saapumista tee Homepage-palvelulle release-taulukko. Sen on nimettävä kiinnitetty image, portti 3000, kanoninen origin, pysyvät polut sekä vain luku -muotoisen konfiguraation ja valinnaisten palveluwidgetien tunnistetietojen omistaja. Liitä mukaan tämän transaktion odotettu tulos: palvelut ja kirjanmerkit latautuvat, useita live-widgetejä voidaan kutsua, haku toimii ja palvelu voidaan käynnistää uudelleen YAML-konfiguraatiotiedoston muokkauksen jälkeen.
Käytä taulukkoa normaalin korvauksen ja puhtaan palautuksen jälkeen. Palautus hyväksytään vain, jos palvelut, kirjanmerkit, widgetit ja mukautetut resurssit palaavat ja kaikki kriittiset widgetit käsittelevät downstream-virheet näkyvästi. Kerää lisäksi lyhyt resurssijälki, joka kattaa widgettien fan-out-liikenteen, hitaat downstream-API-rajapinnat, DNS-resoluution ja selainkoontinäytön päivitystiheyden. Säilytä se releasen yhteydessä, jotta tulevia kapasiteettimuutoksia verrataan samaan kuormaan.
Sisällytä yksi hallittu vikatilanne: estä tilapäisesti vain luku -muotoisen konfiguraation ja valinnaisten palveluwidgetien tunnistetietojen käyttämä testireitti. Varmista, että Homepage raportoi ongelman oikealla rajalla, palauta toimiva tila ja suorita transaktio uudelleen. Tämä testaa virheiden näkyvyyttä, ei pelkkää onnistumista, ja estää terveen näköistä käyttöliittymää peittämästä rikkinäistä workeria, callbackia tai tietokantayhteyttä.
Tee Homepagen käynnistyksestä toistettava
Käsittele säilöä korvattavana runtimena, älä totuuden lähteenä.
docker run -d \
--name homepage \
--restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-v homepage-data:/app/config \
-e HOMEPAGE_ALLOWED_HOSTS=home.example.com \
ghcr.io/gethomepage/homepage:latest
Salli ja varmista vain luku -muotoisen konfiguraation ja valinnaisten palveluwidgetien tunnistetietojen edellyttämä lähtevä tai client-puolen reitti. Tarkista säilön käyttäjä, kirjoitettavat polut ja sidottu listener ennen palvelun julkaisemista. Suorita koko toiminto — lataa palvelut ja kirjanmerkit, kutsu useita live-widgetejä, testaa haku ja käynnistä palvelu uudelleen YAML-konfiguraatiotiedoston muokkauksen jälkeen — ja tallenna tarkan tuloksen tuottanut image-viite.
Erota korvattavat säilöt pysyvästä datasta
Pysyvä palautuskokonaisuus sisältää konfiguraatiotiedostot, kirjanmerkit, palvelut ja mukautetut resurssit. Liitä /app/config ennen bootstrapia, kirjoita vaaratonta esimerkkidataa ja korvaa säilö todistaaksesi, että polku on todella pysyvä. Volume suojaa dataa säilön korvaamiselta, mutta ei hostin katoamiselta, tahattomalta poistamiselta tai sovellustason korruptiolta.
Ota datalähteen huomioivia varmuuskopioita: käytä tarvittaessa live-tietokannoille loogisia dumppeja ja kopioi tiedostoja vain yhtenäisestä tilasta. Säilytä yksi salattu kopio Homepage-hostin ulkopuolella. Palautuksen hyväksymiskriteeri on tarkka: palvelut, kirjanmerkit, widgetit ja mukautetut resurssit palaavat ja kaikki kriittiset widgetit käsittelevät downstream-virheet näkyvästi. Palautustestatun varmuuskopion opas selittää, miksi jobin pelkkä onnistuminen ei riitä.
Domainit, proxy-headerit ja portti 3000
Selaimen, API-clientin ja Homepagen on käytettävä samaa originiä. Jotta näin tapahtuu, määritä sallitut hostit tarkalle domainille ja proxyn hostname-nimelle. Säilytä alkuperäinen host ja protokolla, mutta pidä portti 3000 poissa kilpailevasta julkisesta osoitteesta.
Site-down-vianmääritysopas auttaa erottamaan saavuttamattoman reitin vastaavasta sovelluksesta. Erottelu on tässä tärkeä: host hylätään tai YAML:n sisennys estää konfiguraation lataamisen. Vain ensimmäinen korjataan ingress-muutoksilla; jälkimmäinen vaatii Homepagen lokien, tilan tai kuorman tarkastelua.
Homepage-palvelua koskevat tietoturvaratkaisut
Älä siirrä paikallisen tutoriaalin tietoturvaoletuksia tuotantoon. Homepagen erityinen riski on widgettien API-avainten committaaminen julkiseen repositoryyn. Tuotannossa sallitut hostit on siksi määritettävä täsmällisesti, ja widgettien API-avaimet on säilytettävä environmentissa tai salaisuuksiin perustuvassa konfiguraatiossa julkisen repositoryn sijaan.
HOMEPAGE_ALLOWED_HOSTS ohjaa toimintaa, ei luottamuksellisuutta. Validoi sen tyyppi ja arvo ja säilytä varsinaiset Homepage-tunnistetiedot erillään. Rajaa tiedosto- ja verkkokäyttöoikeudet, suojaa setup-endpointit ja määritä upload-, request- tai execution-rajat widgettien fan-out-liikenteelle, hitaille downstream-API-rajapinnoille, DNS-resoluutiolle ja selainkoontinäytön päivitystiheydelle.
Miten Dockup vähentää Homepage-palvelun ylläpitotyötä
Homepagen tapauksessa Dockup on hyödyllisimmillään imagen ja pysyvän palvelun välisellä rajalla. Se pitää portin 3000 reitin, TLS:n, salaisuuksien arvot ja tallennustilan kiinnitettyinä säilöjen vaihtamisen yhteydessä riippumatta siitä, sijaitseeko compute Dockupissa vai liitetyllä palvelimellasi.
Viimeistele käyttöönotto sovellustuntemuksella: määritä sallitut hostit tarkalle domainille ja proxyn hostname-nimelle; salli ja varmista vain luku -muotoinen konfiguraatio sekä valinnaisten palveluwidgetien tunnistetiedot; suorita tämä varmennus: lataa palvelut ja kirjanmerkit, kutsu useita live-widgetejä, testaa haku ja käynnistä palvelu uudelleen YAML-konfiguraatiotiedoston muokkauksen jälkeen. Säilytä tulos käyttöönoton tarkistuksena, jotta seuraavaa image-päivitystä arvioidaan toiminnan eikä säilön tilan perusteella.
Usein kysytyt kysymykset
Mitä Homepage tarvitsee tuotantokäyttöön?
Reititä Homepage-säilö portissa 3000 yhden HTTPS-originin kautta. Ulkoinen toimitusvaatimus on vain luku -muotoinen konfiguraatio sekä valinnaisten palveluwidgetien tunnistetiedot. Älä merkitse Homepagea valmiiksi, ennen kuin palvelut ja kirjanmerkit latautuvat, useita live-widgetejä voidaan kutsua, haku toimii ja palvelu voidaan käynnistää uudelleen YAML-konfiguraatiotiedoston muokkauksen jälkeen.
Mitkä Homepagen tiedot kuuluvat varmuuskopioon?
Säilytä /app/config ja sisällytä konfiguraatiotiedostot, kirjanmerkit, palvelut ja mukautetut resurssit samaan palautusmanifestiin. Puhdas Homepage-palautus onnistuu vain, kun palvelut, kirjanmerkit, widgetit ja mukautetut resurssit palaavat ja kaikki kriittiset widgetit käsittelevät downstream-virheet näkyvästi.
Tarvitseeko Homepage HTTPS:ää reverse proxyn takana?
Käytä julkisessa Homepage-originissa HTTPS:ää ja pidä portti 3000 sisäisellä reitillä. Ota Homepage-asetus käyttöön oikein: määritä sallitut hostit tarkalle domainille ja proxyn hostname-nimelle. Homepagen tapauksessa HTTPS suojaa tunnistetietoja tai käyttäjäsisältöä siirron aikana ja pitää origin-riippuvaisen client-käyttäytymisen yhdenmukaisena.
Miten Homepagen päivitys pitäisi testata?
Palauta nykyinen Homepage-tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksymistransaktio. Kiinnitä erityistä huomiota siihen, että konfiguraatioavaimet ja widget-integraatiot voivat muuttua, joten validoi YAML ja providerien toiminta ennen image-päivitystä. Säilytä edellinen Homepage-image, kunnes sen datamigraation ja rollbackin rajat ovat selvillä.