Shlinkin itseisännöinti vuonna 2026: domainit, API-avaimet ja tilastot
Käytännön opas Shlinkin itseisännöintiin: Docker, portit, pysyvä data, TLS, tietoturva, varmuuskopiot ja tuotantokäytön estävät ongelmat. Vaihe vaiheelta.
Shlinkin itseisännöinti alkaa kiinnostaa ensimmäisen uudelleenasennuksen yhteydessä, ei ensimmäisen docker run -komennon kohdalla. Vaikka luodut linkit käyttäisivät HTTP:tä tai migraatiot eivät pääsisi tietokantaan, Docker voi silti ilmoittaa prosessin olevan täysin terve. Alla oleva käyttöönotto perustuu havaittavaan toimintaan: luo lyhyt URL API:n kautta, seuraa sen uudelleenohjausta, kirjaa käynnit ja tarkastele tilastoja web-asiakasohjelmasta.
Shlinkin käyttötarkoitus on selkeä: API-first-linkkien lyhentäjä, jossa on tilastot. Tämä kuvaus kertoo, minkä on oltava julkisesti saatavilla, mikä kannattaa pitää yksityisenä ja mitä varmuuskopion on pystyttävä palauttamaan.
Mistä Shlink riippuu
Shlinkin prosessin toimintakunto ja tuotteen toimintakunto ovat eri asioita. Portti 8080 voi vastata, vaikka käyttäjän kannalta tärkeä tapahtumaketju epäonnistuisi. Shlinkin verkkosopimus edellyttää Postgresia tai MariaDB:tä sekä tuotannossa valinnaista Redisiä. Pidä yksityiset päätepisteet sisäisessä DNS:ssä, salli vain tarvittavat lähtevät yhteydet ja anna Shlinkille rajatuin oikeuksin varustettu palvelutunnus.
Käytä tätä valmiustestiä merkittävien määritysmuutosten jälkeen: luo lyhyt URL API:n kautta, seuraa sen uudelleenohjausta, kirjaa käynnit ja tarkastele tilastoja web-asiakasohjelmasta. Älä sisällytä kalliita ulkoisia tarkistuksia liveness-probeihin, jotta palveluntarjoajan häiriö ei aiheuta uudelleenkäynnistyssilmukkaa. Kapasiteettia kannattaa arvioida uudelleenohjausten läpimenon, tietokantakirjoitusten, geosijaintitietojen latausten ja cachen toiminnan perusteella, sillä nämä kuvaavat Shlinkin todellista kuormitusta paremmin kuin sivupyynnöt.
Volyymit ovat vasta ensimmäinen palautuskerros
Shlinkin vakioimageen ei odoteta tallennettavan kirjoitettavaa sovellustilaa. Säilytä tietokanta, API-avaimet ja kaikki tuodut käyntitiedot sekä käytetty digest ja tarkistettu reittimääritys sen sijaan, että varmuuskopioisit tyhjän kontin tiedostojärjestelmän.
Luo Shlink tyhjästä toisella palvelimella ja varmista, että domainit, lyhytkoodit, tagit ja käyntitiedot palautuvat ja että jokainen otokseen kuuluva lyhyt URL uudelleenohjautuu täsmälleen samalla tavalla. Jos käyttöön lisätään erillinen tietokanta, room server tai autentikointikerros, nimeä kullekin komponentille oma selkeä palautuksesta vastaava omistaja. Gitistä tuotantoon -opas näyttää, miten toistettavasti luotu artifact korvaa kontin varmuuskopion.
Tallenna uudelleenrakennuskomento ja odotetun tuloksen testi julkaisun yhteyteen. Tilattoman palautussuunnitelman onnistuminen perustuu toiminnan toistamiseen luotettavista lähtötiedoista; sen ei pidä riippua läpinäkymättömän käynnissä olevan kontin kopioimisesta.
Suojaa Shlinkin arvokkain osa
Turvallinen Shlink-käyttöönotto alkaa oikeuksien vähentämisestä. Älä altista REST API -avainta tai vaihda julkista domainia sen jälkeen, kun linkit on julkaistu. Pidä API-avaimet sen sijaan poissa selaimen koodista, käytä HTTPS:ää ja rajoita hallintaa samalla, kun uudelleenohjaukset pysyvät julkisina.
DEFAULT_DOMAIN on määritys, ei salaisuus. Pidä sen arvo selkeästi määritettynä ja suojaa Shlinkin käyttämät erilliset tunnistetiedot. Rajoita hallintareittejä, käytä riippuvuuksille yksityistä DNS:ää ja tarkista jokainen bind mount. Kun lokit lähetetään keskitettyyn järjestelmään, suodata salaisuudet ja yksityinen sisältö ennen niiden poistumista palvelimelta.
Tee Shlinkin smoke-testistä julkaisun tarkistus
Määritä Shlinkille ennen käyttöönottoa toimivaksi todettu tapahtumaketju: luo lyhyt URL API:n kautta, seuraa sen uudelleenohjausta, kirjaa käynnit ja tarkastele tilastoja web-asiakasohjelmasta. Tallenna sen edellytykset, odotettu vastaus ja siivousvaiheet versionhallintaan ilman salaisia arvoja. Lukitse kyseisen viitteen luomiseen käytetty image.
Käytä tapahtumaketjua korvaavan käyttöönoton ja erillisen palautuksen validointiin. Palautettu palvelu hyväksytään vasta, kun domainit, lyhytkoodit, tagit ja käyntitiedot palautuvat ja jokainen otokseen kuuluva lyhyt URL uudelleenohjautuu täsmälleen samalla tavalla. Seuraa samalla uudelleenohjausten läpimenoa, tietokantakirjoituksia, geosijaintitietojen latauksia ja cachen toimintaa ja tee hitaimmasta tai rajoittavimmasta osasta service-level-hälytys.
Tarkistukseen tarvitaan myös negatiivinen tapaus: estä testitunnukselta tilapäisesti pääsy Postgresiin tai MariaDB:hen sekä tuotannossa valinnaiseen Redisiin. Varmista, että Shlink tuottaa käyttökelpoisen virheilmoituksen säilyttäen datan, palauta toimiva tila ja toista onnistuneeksi todettu tapahtumaketju. Kun molemmat tulokset säilytetään, pinnallinen health endpoint ei pääse muodostumaan ainoaksi tuotantoa koskevaksi näytöksi.
Käynnistä Shlink ilman, että liikkuvat osat piilotetaan
Seuraava komento tekee kontin rajapinnan näkyväksi yrittämättä kuitenkaan alustaa jokaista ulkoista palvelua.
docker run -d \
--name shlink \
--restart unless-stopped \
-p 127.0.0.1:8080:8080 \
-e DEFAULT_DOMAIN=go.example.com \
shlinkio/shlink:stable
Ennen sisääntulevan liikenteen avaamista tarkista ratkaistu ympäristö, mountit ja kuuntelija. Lisää tarkistetut yhteysmääritykset Postgresille tai MariaDB:lle sekä tuotannossa valinnaiselle Redisille. Käytä yksityisille palveluille yksityisiä nimiä. Onnistunut käynnistys päättyy vasta, kun voit luoda lyhyen URL:n API:n kautta, seurata sen uudelleenohjausta, kirjata käynnit ja tarkastella tilastoja web-asiakasohjelmasta – ei silloin, kun docker ps tulostaa Up.
Anna Shlinkille yksi kanoninen osoite
Shlinkin julkisen rajapinnan pitäisi käyttää yhtä kanonista isäntänimeä, automaattista TLS:ää ja yhtä sisäistä kohdetta portissa 8080. Aseta DEFAULT_DOMAIN ja IS_HTTPS_ENABLED ennen lyhyiden URL-osoitteiden luomista, jotta asiakkaat ohjataan takaisin palvelun tunnistamaan osoitteeseen.
Jos hyväksymistapahtuma epäonnistuu, luokittele ensimmäinen virhe. DNS-, sertifikaatti- ja 502-ongelmat kuuluvat TLS-validoinnin tarkistuslistaan. Ehto ”luodut linkit käyttävät HTTP:tä tai migraatiot eivät pääse tietokantaan” kuuluu sovelluspuolelle sen jälkeen, kun pyyntö on saavuttanut Shlinkin onnistuneesti.
Selvitä terveen näköisen Shlinkin ongelmat
Seuraa Shlinkin kohdalla tapahtumaketjua prosessin sijaan: luo lyhyt URL API:n kautta, seuraa sen uudelleenohjausta, kirjaa käynnit ja tarkastele tilastoja web-asiakasohjelmasta. Yhdistä sen viive ja virheaste uudelleenohjausten läpimenoon, tietokantakirjoituksiin, geosijaintitietojen latauksiin ja cachen toimintaan, jotta hälytys tunnistaa rajoittavan komponentin.
Päivitysharjoituksen on katettava se, että tietokantamigraatiot ja API-yhteensopivuus on vaiheistettava, koska julkaistut lyhyet linkit eivät voi odottaa manuaalista korjausta. Palauta varmuuskopio, suorita migraatiot ja aja tapahtumaketju ennen tuotantokorvausta. Jos luodut linkit käyttävät HTTP:tä tai migraatiot eivät pääse tietokantaan, älä poista dataa saadaksesi käynnistyksen näyttämään onnistuneelta. Vertaile versio, muuttujat, mountit ja riippuvuuksien saavutettavuus tässä järjestyksessä.
Pidä Shlinkin määritys selkeänä ja anna Dockupin hoitaa reititys
Dockupin yhden napsautuksen Shlink-käyttöönoton pitäisi tehdä korvaamisesta turvallista: reitti osoittaa edelleen porttiin 8080, salaisuuksia ei leivota imageen ja pysyvät polut palautuvat uuteen konttiin. Sama käyttöönotto voi toimia Dockupin laskentaympäristössä tai liitetyllä koneella.
Viimeistele sovelluskohtainen työ yhdistämällä ja testaamalla Postgres tai MariaDB sekä tuotannossa valinnainen Redis, määrittämällä kanoninen julkinen osoite ja suorittamalla tämä hyväksymistarkistus: luo lyhyt URL API:n kautta, seuraa sen uudelleenohjausta, kirjaa käynnit ja tarkastele tilastoja web-asiakasohjelmasta. Lisää palautuksen tulos runbookiin ennen oikeiden käyttäjien saapumista.
Usein kysytyt kysymykset
Mitä Shlink tarvitsee tuotantokäyttöönottoon?
Reititä Shlink-kontti portissa 8080 yhden HTTPS-alkuperän kautta. Tukevan verkon vaatimus on Postgres tai MariaDB sekä tuotannossa valinnainen Redis. Älä merkitse Shlinkiä valmiiksi ennen kuin voit luoda lyhyen URL:n API:n kautta, seurata sen uudelleenohjausta, kirjata käynnit ja tarkastella tilastoja web-asiakasohjelmasta.
Mitkä Shlinkin tiedot kuuluvat varmuuskopioon?
Shlinkin vakioimage ei edellytä sovellusdatan mountia. Säilytä sen käyttöönottomääritykset ja varmuuskopioi kaikki yhdistetty tila erikseen. Palautus on onnistunut, kun domainit, lyhytkoodit, tagit ja käyntitiedot palautuvat ja jokainen otokseen kuuluva lyhyt URL uudelleenohjautuu täsmälleen samalla tavalla.
Edellyttääkö Shlink HTTPS:ää käänteisen proxyn takana?
Käytä julkisessa Shlink-alkuperässä HTTPS:ää ja pidä portti 8080 sisäisessä reitissä. Määritä Shlinkin asetus oikein: aseta DEFAULT_DOMAIN ja IS_HTTPS_ENABLED ennen lyhyiden URL-osoitteiden luomista. Shlinkin tapauksessa HTTPS suojaa tunnistetietoja tai käyttäjien sisältöä siirron aikana ja pitää alkuperästä riippuvan asiakastoiminnan yhdenmukaisena.
Miten Shlinkin päivitys pitäisi testata?
Palauta nykyinen Shlink-tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista hyväksymistapahtuma. Kiinnitä tähän erityistä huomiota, koska tietokantamigraatiot ja API-yhteensopivuus on vaiheistettava, sillä julkaistut lyhyet linkit eivät voi odottaa manuaalista korjausta. Säilytä aiempi Shlink-image, kunnes sen datamigraation ja rollbackin rajat on ymmärretty.