Homarrin itsehostaus vuonna 2026: koontinäytöt, salaisuudet ja reaaliaikaiset ruudut

Homarr-säilö voi näyttää toimivan, vaikka käyttäjille tärkeä toiminto olisi rikki. Homarrissa tämä piilevä vika tarkoittaa yleensä sitä, etteivät widgetit saa yhteyttä palveluihin, koska ne käyttävät isäntäkoneen paikallisia osoitteita. Tässä oppaassa hyväksymistestinä pidetään toimintoketjua ”luo koontinäyttö, lisää palveluruutu, määritä yksi tunnistetietoja käyttävä integraatio ja varmista reaaliaikainen tila sekä haku uudelleenkäynnistyksen jälkeen”, ja käyttöönotto suunnitellaan takaperin tämän lopputuloksen perusteella.

Homarrilla on pinossa oma erityinen tehtävänsä: haettava koontinäyttö itse ylläpidetyille palveluille reaaliaikaisilla ruuduilla. Tuotannon kannalta kysymys ei siis ole siitä, vastaako portti 7575 kerran, vaan siitä, pysyvätkö tila, riippuvuudet ja julkinen osoite yhdenmukaisina uudelleenkäynnistyksen, päivityksen ja palautuksen jälkeen.

Määritä Homarrin onnistuminen ensin

Älä anna Homarr-kuvan määrittää tuotantoarkkitehtuuria vahingossa. Kuva tarjoaa portissa 7575 toimivan prosessin, mutta tallennukselle, reititykselle ja ulkoisille vaatimuksille on silti määritettävä tarkoitukselliset elinkaaret. Paikallinen ajonaikainen vaatimus on pysyvä sovellusdata sekä reaaliaikaisissa integraatioissa tarvittavat tunnistetiedot. Tämä kuuluu kapasiteetti- ja liitossuunnitelmaan yhdessä omistajan ja mitattavan rajan kanssa.

Käyttöönotto on valmis perusteellisempaa testausta varten, kun sillä voi luoda koontinäytön, lisätä palveluruudun, määrittää yhden tunnistetietoja käyttävän integraation ja varmistaa reaaliaikaisen tilan sekä haun uudelleenkäynnistyksen jälkeen. Seuraa tapahtumaketjua lokeista ja tarkkaile widget-pyyntöjen haarautumista, taustajärjestelmien API-viivettä, sovellusdatan kokoa ja samanaikaisia koontinäyttöasiakkaita. Näistä havainnoista selviää, eristääkö nykyinen topologia oikean komponentin.

Harjoittele riskialtis Homarr-muutos

Toimiva säilö on välttämätön, mutta ei yksin riittävä. Palvelutason mittarina on toimintaketjun ”luo koontinäyttö, lisää palveluruutu, määritä yksi tunnistetietoja käyttävä integraatio ja varmista reaaliaikainen tila sekä haku uudelleenkäynnistyksen jälkeen” onnistunut suoritus. Todennäköisiä kuormitussignaaleja ovat widget-pyyntöjen haarautuminen, taustajärjestelmien API-viive, sovellusdatan koko ja samanaikaiset koontinäyttöasiakkaat.

Muutoshallinta on tärkeää, koska Homarrin skeemamigraatiot ja salausavaimen jatkuvuus voivat vaikuttaa tallennettuihin integraatioiden tunnistetietoihin. Säilytä vanha kuva, testaa migraatiot kopioidulla tilalla ja dokumentoi, tuetaanko palautusta skeeman siirtymisen jälkeen. Jos widgetit eivät saa yhteyttä palveluihin, koska ne käyttävät isäntäkoneen paikallisia osoitteita, selvitä ensimmäinen raja, joka poikkeaa toimivasta ympäristöstä.

Tallenna tunnetusti toimiva Homarr-käyttöönotto

Älä käytä ensimmäisen käyttäjän liikennettä Homarrin hyväksymistestinä. Valmistele vaaraton esimerkkitila ja suorita koko toiminto ”luo koontinäyttö, lisää palveluruutu, määritä yksi tunnistetietoja käyttävä integraatio ja varmista reaaliaikainen tila sekä haku uudelleenkäynnistyksen jälkeen”. Kirjaa suoritukseen liittyvä tarkka julkinen URL-osoite, tulos, kuvaviite ja lokien aikaväli.

Korvaa säilö ja toista testi dataa uudelleen rakentamatta. Palauta seuraavaksi ympäristö tyhjälle isäntäkoneelle; palautuksen onnistumisen edellytys on, että koontinäytöt, käyttäjät, integraatiot ja mukautetut resurssit palaavat ja tunnistetietoja käyttävät widgetit muodostavat yhteyden uudelleen. Tarkkaile widget-pyyntöjen haarautumista, taustajärjestelmien API-viivettä, sovellusdatan kokoa ja samanaikaisia koontinäyttöasiakkaita jokaisella kierroksella ja määritä hälytys toimintaketjun heikkenemisen, ei joutokäynnillä olevan säilön mittareiden, perusteella.

Yhden viimeisen tarkistuksen pitäisi epäonnistua tarkoituksella: lähetä vaaraton syöte lähelle tähän rajapintaan liittyvää resurssi- tai muotorajaa: widgetit eivät saa yhteyttä palveluihin, koska ne käyttävät isäntäkoneen paikallisia osoitteita. Varmista, että syntyvä Homarr-viesti tunnistaa olennaisen rajan eikä käynnistä tietojen poistoa tai loputonta uudelleenkäynnistystä. Palauta kelvollinen tila ja varmista, että sama esimerkkitoiminto onnistuu. Pidä tämä lyhyt harjoitus mukana julkaisutarkistuslistassa.

Käynnistä ensimmäinen tuotantoa vastaava instanssi

Ensimmäisen säilön pitäisi olla helppo poistaa ja luoda uudelleen. Pidä data kirjoitettavan kerroksen ulkopuolella, sido portti 7575 vain välityspalvelimen saavutettavaksi ja välitä määritykset ajon aikana.

docker run -d \
  --name homarr \
  --restart unless-stopped \
  -p 127.0.0.1:7575:7575 \
  -v homarr-data:/appdata \
  -e SECRET_ENCRYPTION_KEY=replace-with-a-long-random-value \
  ghcr.io/homarr-labs/homarr:latest

Kiinnitä kuva tiettyyn versioon ensimmäisen testin jälkeen. Lue aikaisin käynnistysvirhe viimeisen uudelleenkäynnistysviestin sijaan, tarkista jokainen liitos komennolla docker inspect ja seuraa lokeja, kun luot koontinäytön, lisäät palveluruudun, määrität yhden tunnistetietoja käyttävän integraation ja varmistat reaaliaikaisen tilan sekä haun uudelleenkäynnistyksen jälkeen. Tämä järjestys erottaa virheellisen kuvakomennon riippuvuus- tai käyttöoikeusongelmasta.

Volyymit ovat vasta ensimmäinen palautuskerros

Homarrin käyttöönoton palautettavuus alkaa koontinäytöistä, käyttäjistä, integraatioista, salaisuuksista ja mukautetuista resursseista. Liitä /appdata ennen alustusta, kirjoita vaaratonta esimerkkidataa ja korvaa säilö varmistaaksesi, että polku on todella pysyvä. Testaa polku korvaamalla säilö, kun vaaraton esimerkkidata on edelleen olemassa; näin paljastuvat liitokset, jotka osoittavat yhden hakemiston liian ylös tai alas.

Testaa seuraavaksi palautuminen tyhjälle isäntäkoneelle. Käytä tarvittaessa sovelluksen kanssa yhdenmukaista tietokantavientiä ja varmista, että koontinäytöt, käyttäjät, integraatiot ja mukautetut resurssit palaavat ja tunnistetietoja käyttävät widgetit muodostavat yhteyden uudelleen. Palautustestattu tietokantojen varmuuskopiointiopas tarjoaa paremman tavoitteen kuin pelkkä tarkistus siitä, että arkistotiedosto luotiin.

Estä välityspalvelimen onnistumista peittämästä sovellusvikaa

Selaimen, API-asiakkaan ja Homarrin on käytettävä samaa originia. Jotta näin tapahtuu, määritä ulkoinen HTTPS-isäntänimi ja sallitut originit. Säilytä alkuperäinen isäntä ja protokolla samalla, kun pidät portin 7575 poissa käytöstä kilpailevana julkisena osoitteena.

Verkkosivu ei toimi -vianmääritysopas auttaa erottamaan saavuttamattoman reitin vastaavasta sovelluksesta. Ero on tässä tärkeä: widgetit eivät saa yhteyttä palveluihin, koska ne käyttävät isäntäkoneen paikallisia osoitteita. Vain ensin mainittu korjaantuu ingress-muutoksilla; jälkimmäinen edellyttää Homarr-lokien, tilan tai kuormituksen tarkastelua.

Poista väliaikainen käyttöönoton aikainen pääsy

Turvallinen Homarr-käyttöönotto alkaa käyttöoikeuksien poistamisesta. Älä vaihda salausavainta sen jälkeen, kun integraatioiden salaisuudet on tallennettu. Pidä sen sijaan SECRET_ENCRYPTION_KEY muuttumattomana, suojaa koontinäyttöjen muokkaus ja rajaa jokaisen widgetin tunnistetiedot.

Luo SECRET_ENCRYPTION_KEY kerran, pidä se poissa Gitistä ja säilytä se palautusmanifestin yhteydessä, koska sen vaihtaminen voi mitätöidä salatun tai allekirjoitetun sovellustilan. Rajoita ylläpitoreittejä, käytä riippuvuuksille yksityistä DNS:ää ja tarkista jokainen liitos. Kun lokit toimitetaan keskitettyyn järjestelmään, suodata salaisuudet ja yksityinen sisältö ennen niiden poistumista palvelimelta.

Siirrä toistettava infrastruktuurityö Dockupiin

Homarrin yhteydessä Dockup on hyödyllisimmillään kuvan ja pysyvän palvelun rajapinnassa. Se pitää reitin porttiin 7575, TLS:n, salaisuuksien arvot ja tallennustilan liitettyinä säilöjen vaihdoissa riippumatta siitä, kuuluuko laskenta Dockupille vai liitetylle palvelimellesi.

Viimeistele käyttöönotto sovellustason tiedoilla: määritä ulkoinen HTTPS-isäntänimi ja sallitut origin-osoitteet, varmista paikallinen vaatimus — pysyvä sovellusdata sekä reaaliaikaisissa integraatioissa tarvittavat tunnistetiedot — ja suorita tämä tarkistus: luo koontinäyttö, lisää palveluruutu, määritä yksi tunnistetietoja käyttävä integraatio ja varmista reaaliaikainen tila sekä haku uudelleenkäynnistyksen jälkeen. Säilytä tulos käyttöönottotarkistuksena, jotta seuraava kuvapäivitys arvioidaan toiminnan eikä säilön tilan perusteella.

Usein kysytyt kysymykset

Mitä Homarr tarvitsee tuotantokäyttöönottoon?

Reititä Homarr-säilö portissa 7575 yhden HTTPS-originin kautta. Paikallinen ajonaikainen vaatimus on pysyvä sovellusdata sekä reaaliaikaisissa integraatioissa tarvittavat tunnistetiedot. Älä pidä Homarria valmiina, ennen kuin voit luoda koontinäytön, lisätä palveluruudun, määrittää yhden tunnistetietoja käyttävän integraation ja varmistaa reaaliaikaisen tilan sekä haun uudelleenkäynnistyksen jälkeen.

Mitkä Homarrin tiedot kuuluvat varmuuskopioon?

Säilytä /appdata ja sisällytä koontinäytöt, käyttäjät, integraatiot, salaisuudet ja mukautetut resurssit samaan palautusmanifestiin. Puhdas Homarr-palautus onnistuu vain, kun koontinäytöt, käyttäjät, integraatiot ja mukautetut resurssit palaavat ja tunnistetietoja käyttävät widgetit muodostavat yhteyden uudelleen.

Edellyttääkö Homarr HTTPS:ää käänteisvälityspalvelimen takana?

Käytä julkisessa Homarr-originissa HTTPS:ää ja pidä portti 7575 sisäisessä reitissä. Määritä Homarr-asetus oikein: aseta ulkoinen HTTPS-isäntänimi ja sallitut origin-osoitteet. Homarrin tapauksessa HTTPS suojaa tunnistetiedot ja käyttäjäsisällön siirron aikana sekä pitää originista riippuvan asiakaskäyttäytymisen yhdenmukaisena.

Miten Homarr-päivitys pitäisi testata?

Palauta Homarrin nykyinen tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksymistesti. Kiinnitä erityistä huomiota siihen, että Homarrin skeemamigraatiot ja salausavaimen jatkuvuus voivat vaikuttaa tallennettuihin integraatioiden tunnistetietoihin. Säilytä aiempi Homarr-kuva, kunnes sen datamigraation ja palautuksen rajat on ymmärretty.