Как да хоствате Directus самостоятелно през 2026 г.: база данни, качвания и публичен URL

Разглеждайте Directus като малка система, а не просто като Docker image. Потребителската цел за Directus е ясна: REST и GraphQL API плюс admin интерфейс върху вашите данни; deployment-ът е приемлив само когато можете да bootstrap-нете администратора, да създадете collection и role, да запишете данни чрез REST, да изпълните заявка чрез GraphQL и да качите файл.

Това разграничение разкрива failure mode-а, с който операторите се сблъскват след локално тестване: database client-ът е грешен или upload storage-ът не позволява запис. То също така прави плана за backup и upgrade достатъчно конкретен за реално тестване.

Докажете, че Directus оцелява при подмяна

Container image-ът може да бъде изтеглен отново, но базата данни, качванията, extensions, flows и schema snapshots не могат. Mount-нете /directus/database преди bootstrap, запишете безвредни примерни данни и подменете container-а, за да докажете, че този path наистина е persistent. Проверете ефективния mount, вместо да разчитате на името на Compose файла, и се уверете, че runtime user-ът може да записва там, където Directus очаква.

Изберете retention политика и off-host destination, след което репетирайте възстановяването, без да засягате production средата. Тестът е успешен само когато schema, roles, flows, items, extensions и uploads се възстановят и probe-овете през REST и GraphQL са успешни. За състояние, съхранявано в базата данни, комбинирайте storage snapshots с application-consistent exports, както е описано в възстановяване до определен момент спрямо snapshots.

Production архитектурата на Directus

Очертайте три граници около Directus: ingress към порт 8055, durable state и supporting requirements. Container-ът може да бъде подменен, но за останалите две граници трябва да има изрично определени отговорници. Мрежовият contract на Directus е Postgres плюс optional Redis и object storage за scaled deployments. Дръжте private endpoints във вътрешен DNS, разрешете само необходимите outbound calls и дайте на Directus service credential с ограничен scope.

Диаграмата е завършена, когато чист client може да bootstrap-не администратора, да създаде collection и role, да запише данни чрез REST, да изпълни заявка чрез GraphQL и да качи файл. Събирайте timing и resource данни за database connection pool, API request concurrency, Flow workers, thumbnail generation и upload storage. Ако transaction-ът се провали, първата граница, която не се държи според документацията, показва дали трябва да проверите routing-а, локалния капацитет или supporting service.

Докажете Directus deployment-а от край до край

Създайте малък, disposable Directus fixture и го запазете за всеки release. Fixture-ът трябва да покрива реалния workflow: bootstrap на администратора, създаване на collection и role, запис чрез REST, заявка чрез GraphQL и качване на файл. Запишете image digest-а, external hostname-а, dependency address-а и очаквания резултат, за да може следващ оператор да повтори теста, без да интерпретира това ръководство.

Изпълнете fixture-а три пъти. Първо използвайте fresh deployment. Второ, подменете container-а, без да променяте durable state. Трето, възстановете backup-а в празна среда. Третото изпълнение е успешно само когато schema, roles, flows, items, extensions и uploads се възстановят и probe-овете през REST и GraphQL са успешни. При всяко изпълнение измервайте latency и resource use около database connection pool, API request concurrency, Flow workers, thumbnail generation и upload storage; това ще бъде baseline за alert-ите, а не произволен процент CPU.

Накрая тествайте умишлено и negative path-а: временно забранете на test identity достъпа до Postgres плюс optional Redis и object storage за scaled deployments. Потвърдете, че Directus се проваля видимо, без да поврежда state-а, възстановете правилното условие и повторете успешния transaction. Release record с тези четири резултата е по-силно доказателство от screenshots на dashboard или еднократен curl response.

Стартирайте Directus с наблюдаеми defaults

Стартирайте Directus по начин, който запазва route-а private, докато bootstrap-ът не приключи.

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

Ако процесът влиза в loop, сравнете очаквания user на image-а с owner-а на всеки mounted path. Ако остане активен, тествайте локално порт 8055 и след това преминете директно към workflow-а: bootstrap на администратора, създаване на collection и role, запис чрез REST, заявка чрез GraphQL и качване на файл. Фиксирайте версията на image-а едва след като тази end-to-end проверка премине успешно, и запишете точната configuration до service-а.

Credentials, roles и exposed surfaces

Затворете bootstrap window-а веднага щом първият доверен администратор бъде създаден. Конкретният капан при Directus е да използвате bootstrap admin password-а след първия login или да rotate-нете SECRET без ясна причина; по-сигурната граница е да замените bootstrap credentials, да използвате least-privilege roles и да запазите SECRET стабилен, защото той защитава application sessions и tokens.

Генерирайте SECRET веднъж, не го съхранявайте в Git и го запазете в recovery manifest-а, защото промяната му може да инвалидира encrypted или signed application state. Private networking трябва да пренася dependency credentials, а roles в Directus трябва да предоставят минималното необходимо действие. Не включвайте чувствителни request bodies и provider responses в стандартните logs.

Направете public origin-а еднозначен

Избягвайте временни и постоянни public origins за Directus. Вместо това задайте PUBLIC_URL към canonical HTTPS адреса, насочете избраното DNS име към platform route-а и proxy-вайте само към порт 8055.

Изпълнете това действие извън host-а: bootstrap на администратора, създаване на collection и role, запис чрез REST, заявка чрез GraphQL и качване на файл. Ако ingress-ът се провали, ръководството за отстраняване на проблеми с 502 обхваща грешки в port и listener. Ако Directus получи request-а, но database client-ът е грешен или upload storage-ът не позволява запис, доказателствата вече насочват извън proxy-то.

Failure drills за Directus

При Directus наблюдавайте transaction, а не процес: bootstrap на администратора, създаване на collection и role, запис чрез REST, заявка чрез GraphQL и качване на файл. Комбинирайте неговите latency и error rate с database connection pool, API request concurrency, Flow workers, thumbnail generation и upload storage, за да показва alert-ът кой компонент е ограничен.

Upgrade rehearsal-ът трябва да обхваща изискването schema migrations, extensions и database vendor support на Directus да се проверяват като едно цяло. Възстановете, мигрирайте и изпълнете transaction-а преди production replacement. Ако database client-ът е грешен или upload storage-ът не позволява запис, не изтривайте данни, за да направите startup-а green; сравнете версията, variables, mounts и dependency reachability в този ред.

Какво Dockup трябва да автоматизира за Directus

Platform layer-ът за Directus се състои от порт 8055, ingress, TLS, runtime configuration, storage и dependency reachability. Dockup може да възпроизведе тези компоненти за собствената си infrastructure или за server, свързан от клиента.

След това операторът завършва product layer-а: задава PUBLIC_URL към canonical HTTPS адреса; налага това access rule — заменете bootstrap credentials, използвайте least-privilege roles и запазете SECRET стабилен, защото той защитава application sessions и tokens; и изпълнява „bootstrap на администратора, създаване на collection и role, запис чрез REST, заявка чрез GraphQL и качване на файл“. Записването на този тест заедно с deployment-а предотвратява объркването между automated provisioning и application readiness.

Често задавани въпроси

Какво е необходимо на Directus за production deployment?

Маршрутизирайте Directus container-а на порт 8055 през един HTTPS origin. Мрежовото изискване за supporting services е Postgres плюс optional Redis и object storage за scaled deployments. Не считайте Directus за готов, докато не можете да bootstrap-нете администратора, да създадете collection и role, да запишете данни чрез REST, да изпълните заявка чрез GraphQL и да качите файл.

Кои данни на Directus трябва да бъдат включени в backup?

Направете /directus/database persistent и включете database, uploads, extensions, flows и schema snapshots в един и същ recovery manifest. Clean Directus restore е успешен само когато schema, roles, flows, items, extensions и uploads се възстановят и probe-овете през REST и GraphQL са успешни.

Изисква ли Directus HTTPS зад reverse proxy?

Използвайте HTTPS за public Directus origin-а и оставете порт 8055 във вътрешния route. Приложете правилно Directus setting-а: задайте PUBLIC_URL към canonical HTTPS адреса. При Directus HTTPS защитава credentials или user content при пренос и поддържа consistent client behavior, зависещо от origin-а.

Как трябва да се тества upgrade на Directus?

Възстановете текущия state на Directus в изолиран deployment, приложете candidate версията и повторете acceptance transaction-а. Обърнете особено внимание, защото schema migrations, extensions и database vendor support на Directus трябва да се проверяват като едно цяло. Запазете предишния Directus image, докато не изясните границите на data migration-а и rollback-а.