Cum să găzduiești singur Directus în 2026: baza de date, încărcările și URL-ul public

Privește Directus ca pe un sistem de mici dimensiuni, nu ca pe o imagine Docker. Obiectivul pentru utilizator este clar: un API REST și GraphQL, plus o interfață de administrare pentru datele tale; implementarea este acceptabilă doar atunci când poți inițializa administratorul, crea o colecție și un rol, scrie prin REST, interoga prin GraphQL și încărca un fișier.

Această distincție scoate la iveală problema pe care operatorii o întâlnesc după testarea locală: clientul bazei de date este configurat greșit sau stocarea pentru încărcări nu permite scrierea. De asemenea, face planul de backup și upgrade suficient de specific pentru a putea fi testat.

Demonstrează că Directus supraviețuiește înlocuirii

O imagine de container poate fi descărcată din nou; baza de date, încărcările, extensiile, fluxurile și snapshoturile schemei nu pot fi reconstruite automat. Montează /directus/database înainte de inițializare, scrie date de test inofensive și înlocuiește containerul pentru a demonstra că acea cale este într-adevăr persistentă. Inspectează montarea efectivă în loc să te bazezi pe numele unui fișier Compose și verifică dacă utilizatorul runtime poate scrie în locația așteptată de Directus.

Alege perioada de retenție și o destinație din afara gazdei, apoi exersează recuperarea fără să atingi producția. Testul este reușit doar atunci când schema, rolurile, fluxurile, elementele, extensiile și încărcările sunt restaurate, iar verificările REST și GraphQL reușesc. Pentru starea susținută de baza de date, combină snapshoturile stocării cu exporturi consistente la nivelul aplicației, așa cum este descris în recuperarea la un anumit moment față de snapshoturi.

Structura Directus pentru producție

Trasează trei limite în jurul Directus: ingress către portul 8055, starea persistentă și cerințele de suport. Containerul poate fi înlocuit, însă celelalte două componente au nevoie de responsabili definiți explicit. Contractul de rețea pentru Directus este PostgreSQL, plus Redis și stocare de obiecte opționale pentru implementări scalate. Păstrează endpointurile private în DNS intern, permite doar apelurile outbound necesare și oferă Directus o acreditare de serviciu cu permisiuni limitate.

Diagrama este completă atunci când un client nou poate inițializa administratorul, crea o colecție și un rol, scrie prin REST, interoga prin GraphQL și încărca un fișier. Colectează date despre durată și resurse pentru pool-ul de conexiuni la baza de date, concurența cererilor API, workerii Flow, generarea thumbnailurilor și stocarea pentru încărcări. Dacă tranzacția eșuează, prima limită care nu se comportă conform documentației indică dacă trebuie să investighezi rutarea, capacitatea locală sau un serviciu de suport.

Demonstrează funcționarea Directus de la un capăt la altul

Creează un fixture Directus mic și temporar și păstrează-l pentru fiecare release. Fixture-ul trebuie să verifice fluxul real: inițializarea administratorului, crearea unei colecții și a unui rol, scrierea prin REST, interogarea prin GraphQL și încărcarea unui fișier. Notează digestul imaginii, hostname-ul extern, adresa dependenței și rezultatul așteptat, astfel încât un operator ulterior să poată repeta testul fără să interpreteze acest ghid.

Rulează fixture-ul de trei ori. Mai întâi, folosește implementarea nouă. Apoi, înlocuiește containerul fără să modifici starea persistentă. În al treilea rând, restaurează backupul într-un mediu gol. A treia rulare este reușită doar atunci când schema, rolurile, fluxurile, elementele, extensiile și încărcările sunt restaurate, iar verificările REST și GraphQL reușesc. În timpul fiecărei rulări, colectează latența și utilizarea resurselor pentru pool-ul de conexiuni la baza de date, concurența cererilor API, workerii Flow, generarea thumbnailurilor și stocarea pentru încărcări; acestea devin baza pentru alerte, în locul unui procent CPU ales arbitrar.

În cele din urmă, testează intenționat calea negativă: refuză temporar identității de test accesul la PostgreSQL, plus Redis și stocarea de obiecte opționale pentru implementări scalate. Confirmă că Directus eșuează vizibil fără să corupă starea, restabilește condiția corectă și repetă tranzacția reușită. O înregistrare a release-ului care conține aceste patru rezultate oferă dovezi mai solide decât capturile unui dashboard sau răspunsul obținut o singură dată cu curl.

Pornește Directus cu setări implicite ușor de observat

Pornește Directus astfel încât ruta să rămână privată până la finalizarea inițializării.

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

Dacă procesul intră într-o buclă de repornire, compară utilizatorul așteptat de imagine cu proprietarul fiecărei căi montate. Dacă rămâne pornit, testează local portul 8055 și treci direct la fluxul de lucru: inițializează administratorul, creează o colecție și un rol, scrie prin REST, interoghează prin GraphQL și încarcă un fișier. Fixează versiunea imaginii doar după ce verificarea completă de la un capăt la altul reușește și notează configurația exactă lângă serviciu.

Acreditări, roluri și suprafețe expuse

Închide fereastra de inițializare imediat ce există primul administrator de încredere. Capcana concretă în Directus este folosirea parolei administratorului de bootstrap după prima autentificare sau rotirea necontrolată a SECRET; limita mai sigură este să înlocuiești acreditările de bootstrap, să folosești roluri cu privilegii minime și să păstrezi SECRET stabil, deoarece protejează sesiunile și tokenurile aplicației.

Generează SECRET o singură dată, nu îl păstra în Git și salvează-l împreună cu manifestul de recuperare, deoarece schimbarea lui poate invalida starea criptată sau semnată a aplicației. Rețeaua privată trebuie să transporte acreditările dependențelor, iar rolurile din Directus trebuie să acorde cea mai mică permisiune utilă. Nu include în logurile obișnuite corpurile sensibile ale cererilor și răspunsurile providerilor.

Fă originea publică lipsită de ambiguități

Evită originile publice temporare și permanente pentru Directus. În schimb, setează PUBLIC_URL la adresa HTTPS canonică, indică numele DNS ales către ruta platformei și fă proxy doar către portul 8055.

Execută această acțiune din afara gazdei: inițializează administratorul, creează o colecție și un rol, scrie prin REST, interoghează prin GraphQL și încarcă un fișier. Dacă ingress-ul eșuează, ghidul de depanare pentru 502 acoperă problemele legate de porturi și listener. Dacă Directus primește cererea, dar clientul bazei de date este configurat greșit sau stocarea pentru încărcări nu permite scrierea, dovezile indică acum o problemă dincolo de proxy.

Exerciții de simulare a defecțiunilor pentru Directus

Pentru Directus, monitorizează o tranzacție, nu un proces: inițializează administratorul, creează o colecție și un rol, scrie prin REST, interoghează prin GraphQL și încarcă un fișier. Combină latența și rata de erori cu pool-ul de conexiuni la baza de date, concurența cererilor API, workerii Flow, generarea thumbnailurilor și stocarea pentru încărcări, astfel încât alerta să identifice componenta limitativă.

Repetiția generală pentru upgrade trebuie să acopere faptul că migrările schemei Directus, extensiile și compatibilitatea cu furnizorul bazei de date trebuie verificate ca un tot unitar. Restaurează, migrează și rulează tranzacția înainte de înlocuirea din producție. Dacă clientul bazei de date este configurat greșit sau stocarea pentru încărcări nu permite scrierea, nu șterge datele pentru a face pornirea să apară ca reușită; compară în această ordine versiunea, variabilele, montările și accesibilitatea dependențelor.

Ce ar trebui să automatizeze Dockup pentru Directus

Stratul de platformă pentru Directus este format din portul 8055, ingress, TLS, configurația runtime, stocare și accesibilitatea dependențelor. Dockup poate reproduce aceste componente pentru propria infrastructură sau pentru un server conectat de client.

Apoi operatorul finalizează stratul produsului: setează PUBLIC_URL la adresa HTTPS canonică; impune această regulă de acces — înlocuiește acreditările de bootstrap, folosește roluri cu privilegii minime și păstrează SECRET stabil, deoarece protejează sesiunile și tokenurile aplicației; și rulează „inițializează administratorul, creează o colecție și un rol, scrie prin REST, interoghează prin GraphQL și încarcă un fișier”. Înregistrarea testului împreună cu implementarea evită confundarea provisioning-ului automat cu disponibilitatea aplicației.

Întrebări frecvente

De ce are nevoie Directus pentru o implementare de producție?

Rutează containerul Directus pe portul 8055 printr-o singură origine HTTPS. Cerința de rețea pentru serviciile de suport este PostgreSQL, plus Redis și stocare de obiecte opționale pentru implementări scalate. Nu considera Directus pregătit până când nu poți inițializa administratorul, crea o colecție și un rol, scrie prin REST, interoga prin GraphQL și încărca un fișier.

Ce date Directus trebuie incluse într-un backup?

Persistă /directus/database și include baza de date, încărcările, extensiile, fluxurile și snapshoturile schemei în același manifest de recuperare. O restaurare Directus curată este reușită doar atunci când schema, rolurile, fluxurile, elementele, extensiile și încărcările sunt restaurate, iar verificările REST și GraphQL reușesc.

Are Directus nevoie de HTTPS în spatele unui reverse proxy?

Folosește HTTPS pentru originea publică Directus și păstrează portul 8055 pe ruta internă. Aplică setarea Directus corect: setează PUBLIC_URL la adresa HTTPS canonică. Pentru Directus, HTTPS protejează acreditările și conținutul utilizatorilor în tranzit și menține consecvent comportamentul clientului dependent de origine.

Cum trebuie testat un upgrade Directus?

Restaurează starea actuală Directus într-o implementare izolată, aplică versiunea candidată și repetă tranzacția de acceptanță. Acordă o atenție deosebită acestui aspect, deoarece migrările schemei Directus, extensiile și compatibilitatea cu furnizorul bazei de date trebuie verificate ca un tot unitar. Păstrează imaginea Directus anterioară până când limitele migrării datelor și ale rollbackului sunt înțelese.