Directusin itsehostaus vuonna 2026: tietokanta, uploadit ja julkinen URL-osoite

Käsittele Directusia pienenä järjestelmänä, älä Docker-imagena. Directusin käyttäjälle näkyvä tavoite on selkeä: REST- ja GraphQL-API sekä hallintakäyttöliittymä datallesi. Käyttöönotto on valmis vasta, kun voit luoda ylläpitäjän, kokoelman ja roolin, kirjoittaa RESTin kautta, tehdä kyselyitä GraphQL:n kautta ja ladata tiedoston.

Tämä ero tuo esiin ongelman, johon ylläpitäjät törmäävät paikallisen testauksen jälkeen: tietokanta-ajuri on väärä tai upload-tallennustilaan ei voi kirjoittaa. Samalla varmuuskopiointi- ja päivityssuunnitelmasta tulee riittävän täsmällinen testattavaksi.

Varmista, että Directus kestää korvaamisen

Container-image voidaan ladata uudelleen, mutta tietokantaa, uploadeja, extensioneita, flow’ta ja skeeman snapshotteja ei voida palauttaa samalla tavalla. Liitä /directus/database ennen alustusta, kirjoita vaaratonta testidataa ja korvaa container varmistaaksesi, että polku on todella pysyvä. Tarkista aktiivinen mount sen sijaan, että luottaisit Compose-tiedoston nimeen, ja varmista, että runtime-käyttäjällä on kirjoitusoikeus sinne, minne Directus odottaa.

Valitse säilytysaika ja off-host-kohde ja harjoittele palautusta koskematta tuotantoon. Harjoitus on onnistunut vasta, kun skeema, roolit, flow’t, itemit, extensionit ja uploadit ovat palautuneet ja sekä REST- että GraphQL-testit onnistuvat. Tietokantapohjaisen tilan yhteydessä yhdistä tallennustilan snapshotit sovelluksen kannalta yhdenmukaisiin exportteihin, kuten artikkelissa point-in-time-palautus verrattuna snapshotteihin kuvataan.

Directusin tuotantorakenne

Piirrä Directusin ympärille kolme rajaa: ingress porttiin 8055, pysyvä tila ja tukipalveluiden vaatimukset. Container voidaan korvata, mutta kahdelle muulle on määritettävä selkeät omistajat. Directusin verkkosopimus on Postgres sekä skaalatuissa ympäristöissä valinnaiset Redis ja object storage. Pidä yksityiset endpointit sisäisessä DNS:ssä, salli vain tarvittavat ulospäin suuntautuvat yhteydet ja anna Directusille rajattu service credential.

Kaavio on valmis, kun puhdas client voi luoda ylläpitäjän, kokoelman ja roolin, kirjoittaa RESTin kautta, tehdä kyselyitä GraphQL:n kautta ja ladata tiedoston. Kerää ajoitus- ja resurssitiedot tietokantayhteyksien poolista, API-pyyntöjen samanaikaisuudesta, Flow-työntekijöistä, thumbnailien luonnista ja upload-tallennustilasta. Jos transaktio epäonnistuu, ensimmäinen dokumentoidulla tavalla toimimaton raja osoittaa, pitääkö tutkia reititystä, paikallista kapasiteettia vai tukipalvelua.

Varmista Directus-käyttöönotto alusta loppuun

Luo pieni, helposti hävitettävä Directus-fixture ja säilytä se jokaista julkaisua varten. Fixturen tulee käyttää todellista työnkulkua: luo ylläpitäjä, kokoelma ja rooli, kirjoita RESTin kautta, tee kysely GraphQL:n kautta ja lataa tiedosto. Tallenna imagen digest, ulkoinen hostname, riippuvuuden osoite ja odotettu tulos, jotta seuraava ylläpitäjä voi toistaa testin ilman tämän oppaan tulkintaa.

Suorita fixture kolme kertaa. Käytä ensimmäisellä kerralla uutta käyttöönottoa. Toisella kerralla korvaa container koskematta pysyvään tilaan. Kolmannella kerralla palauta varmuuskopio tyhjään ympäristöön. Kolmas suoritus on onnistunut vasta, kun skeema, roolit, flow’t, itemit, extensionit ja uploadit ovat palautuneet ja sekä REST- että GraphQL-testit onnistuvat. Kerää jokaisen suorituksen aikana latenssi- ja resurssitiedot tietokantayhteyksien poolista, API-pyyntöjen samanaikaisuudesta, Flow-työntekijöistä, thumbnailien luonnista ja upload-tallennustilasta. Tästä muodostuu hälytysten perusta mielivaltaisen CPU-prosentin sijaan.

Testaa lopuksi myös negatiivinen polku tarkoituksella: estä testikäyttäjän pääsy väliaikaisesti Postgresiin sekä skaalatuissa ympäristöissä valinnaisiin Redis- ja object storage -palveluihin. Varmista, että Directus epäonnistuu näkyvästi tilaa korruptoimatta, palauta oikea tila ja toista onnistunut transaktio. Julkaisumerkintä, joka sisältää nämä neljä tulosta, on vahvempaa näyttöä kuin hallintapaneelin kuvakaappaukset tai yksittäinen curl-vastaus.

Käynnistä Directus havaittavilla oletusasetuksilla

Käynnistä Directus niin, että reitti pysyy yksityisenä alustuksen valmistumiseen asti.

docker run -d \
  --name directus \
  --restart unless-stopped \
  -p 127.0.0.1:8055:8055 \
  -v directus-data:/directus/database \
  -v directus-uploads:/directus/uploads \
  -v directus-extensions:/directus/extensions \
  -e SECRET=replace-with-a-long-random-value \
  -e KEY=replace-with-a-second-long-random-value \
  -e ADMIN_EMAIL=admin@example.com \
  -e ADMIN_PASSWORD=replace-with-a-strong-bootstrap-password \
  -e DB_CLIENT=sqlite3 \
  -e DB_FILENAME=/directus/database/data.db \
  -e PUBLIC_URL=https://app.example.com \
  directus/directus:latest

Jos prosessi jää silmukkaan, vertaa imagen odotettua käyttäjää kunkin mountatun polun omistajaan. Jos prosessi pysyy käynnissä, testaa portti 8055 paikallisesti ja siirry sitten suoraan työnkulkuun: luo ylläpitäjä, kokoelma ja rooli, kirjoita RESTin kautta, tee kysely GraphQL:n kautta ja lataa tiedosto. Kiinnitä imagen versio vasta, kun tämä päästä päähän tehtävä tarkistus on onnistunut, ja tallenna tarkka konfiguraatio palvelun yhteyteen.

Tunnistetiedot, roolit ja näkyviin avatut pinnat

Sulje alustuksen aikainen ikkuna heti, kun ensimmäinen luotettu ylläpitäjä on luotu. Directusin konkreettinen sudenkuoppa on käyttää alustuksen ylläpitäjän salasanaa ensimmäisen kirjautumisen jälkeen tai vaihtaa SECRET harkitsemattomasti. Turvallisempi toimintatapa on korvata alustustunnistetiedot, käyttää vähimpien oikeuksien rooleja ja pitää SECRET muuttumattomana, koska se suojaa sovelluksen sessioita ja tokeneita.

Luo SECRET kerran, pidä se poissa Gitistä ja säilytä se palautusmanifestsin kanssa, sillä sen vaihtaminen voi mitätöidä sovelluksen salatun tai allekirjoitetun tilan. Yksityisen verkon tulee välittää riippuvuuksien tunnistetiedot, ja Directusin rooleille tulee antaa vain pienin hyödyllinen käyttöoikeus. Älä tallenna arkaluonteisia request bodyja ja provider-vastauksia tavallisiin lokeihin.

Tee julkisesta originista yksiselitteinen

Vältä Directusille väliaikaisia ja pysyviä julkisia origineja. Aseta sen sijaan PUBLIC_URL kanoniseksi HTTPS-osoitteeksi, ohjaa valittu DNS-nimi alustan reitille ja välitä liikenne vain porttiin 8055.

Suorita tämä toiminto hostin ulkopuolelta: luo ylläpitäjä, kokoelma ja rooli, kirjoita RESTin kautta, tee kysely GraphQL:n kautta ja lataa tiedosto. Jos ingress epäonnistuu, 502-virheiden vianmääritysopas käsittelee portti- ja listener-virheitä. Jos Directus vastaanottaa pyynnön mutta tietokanta-ajuri on väärä tai upload-tallennustilaan ei voi kirjoittaa, näyttö ohjaa nyt proxyn ulkopuoliseen ongelmaan.

Directusin vikatilanteiden harjoittelu

Seuraa Directusissa prosessin sijaan transaktion onnistumista: luo ylläpitäjä, kokoelma ja rooli, kirjoita RESTin kautta, tee kysely GraphQL:n kautta ja lataa tiedosto. Yhdistä sen latenssi ja virheprosentti tietokantayhteyksien pooliin, API-pyyntöjen samanaikaisuuteen, Flow-työntekijöihin, thumbnailien luontiin ja upload-tallennustilaan, jotta hälytys tunnistaa rajoittuneen komponentin.

Päivitysharjoituksen tulee kattaa se, että Directusin skeemamigraatiot, extensionit ja tietokantavendorien tuki on tarkistettava kokonaisuutena. Palauta tila, suorita migraatio ja aja transaktio ennen tuotantokorvausta. Jos tietokanta-ajuri on väärä tai upload-tallennustilaan ei voi kirjoittaa, älä poista dataa saadaksesi käynnistyksen näyttämään onnistuneelta. Vertaa tässä järjestyksessä versiota, muuttujia, mountteja ja riippuvuuksien saavutettavuutta.

Mitä Dockupin pitäisi automatisoida Directusia varten

Directusin alustakerros koostuu portista 8055, ingressistä, TLS:stä, runtime-konfiguraatiosta, tallennustilasta ja riippuvuuksien saavutettavuudesta. Dockup voi toistaa nämä osat omalle infrastruktuurilleen tai palvelimelle, jonka asiakas yhdistää.

Tämän jälkeen ylläpitäjä viimeistelee tuotekerroksen: aseta PUBLIC_URL kanoniseksi HTTPS-osoitteeksi, pakota tämä käyttöoikeussääntö — korvaa alustustunnistetiedot, käytä vähimpien oikeuksien rooleja ja pidä SECRET muuttumattomana, koska se suojaa sovelluksen sessioita ja tokeneita — ja suorita ”luo ylläpitäjä, kokoelma ja rooli, kirjoita RESTin kautta, tee kysely GraphQL:n kautta ja lataa tiedosto”. Testin tallentaminen käyttöönoton yhteyteen estää automatisoidun provisioinnin ja sovelluksen valmiuden sekoittamisen toisiinsa.

Usein kysytyt kysymykset

Mitä Directus tarvitsee tuotantokäyttöönottoon?

Reititä Directus-container portissa 8055 yhden HTTPS-originiin kautta. Verkon tukivaatimus on Postgres sekä skaalatuissa ympäristöissä valinnaiset Redis ja object storage. Älä katso Directusia valmiiksi, ennen kuin voit luoda ylläpitäjän, kokoelman ja roolin, kirjoittaa RESTin kautta, tehdä kyselyitä GraphQL:n kautta ja ladata tiedoston.

Mitkä Directusin tiedot kuuluvat varmuuskopioon?

Säilytä /directus/database ja sisällytä tietokanta, uploadit, extensionit, flow’t ja skeeman snapshotit samaan palautusmanifestiin. Directusin puhdas palautus on onnistunut vasta, kun skeema, roolit, flow’t, itemit, extensionit ja uploadit ovat palautuneet ja sekä REST- että GraphQL-testit onnistuvat.

Edellyttääkö Directus HTTPS:ää reverse proxyn takana?

Käytä julkisessa Directus-originissa HTTPS:ää ja pidä portti 8055 sisäisellä reitillä. Määritä Directusin asetus oikein: aseta PUBLIC_URL kanoniseksi HTTPS-osoitteeksi. Directusin tapauksessa HTTPS suojaa tunnistetietoja ja käyttäjäsisältöä siirron aikana sekä pitää originista riippuvan client-käyttäytymisen yhdenmukaisena.

Miten Directus-päivitys pitäisi testata?

Palauta nykyinen Directus-tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksyntätransaktio. Kiinnitä erityistä huomiota siihen, että Directusin skeemamigraatiot, extensionit ja tietokantavendorien tuki on tarkistettava kokonaisuutena. Säilytä aiempi Directus-image, kunnes sen datamigraation ja rollbackin rajat on ymmärretty.