Як розгорнути Directus у 2026 році: база даних, завантаження та публічний URL

Розглядайте Directus як невелику систему, а не просто Docker image. Користувацька мета Directus зрозуміла: REST і GraphQL API, а також адміністративний інтерфейс для роботи з вашими даними. Розгортання можна вважати прийнятним лише тоді, коли ви можете створити адміністратора, колекцію та роль, записати дані через REST, виконати запит через GraphQL і завантажити файл.

Ця відмінність допомагає виявити проблему, з якою оператори стикаються після локального тестування: використовується неправильний клієнт бази даних або сховище завантажень недоступне для запису. Вона також робить план резервного копіювання й оновлення достатньо конкретним для перевірки.

Доведіть, що Directus переживає заміну

Container image можна завантажити повторно, а базу даних, завантаження, розширення, flows і знімки схеми — ні. Підключіть /directus/database до первинного запуску, запишіть безпечні тестові дані та замініть container, щоб перевірити, чи цей шлях справді зберігається. Перевіряйте фактичне mount-підключення, а не покладайтеся на назву Compose-файлу, і переконайтеся, що runtime user може записувати туди, куди очікує Directus.

Визначте термін зберігання та зовнішнє сховище, а потім відпрацюйте відновлення, не торкаючись production. Перевірка вважається успішною лише тоді, коли повертаються схема, ролі, flows, items, extensions і uploads, а перевірки REST та GraphQL завершуються успішно. Для стану, що зберігається в базі даних, поєднуйте snapshots сховища з експортами, узгодженими зі станом застосунку, як описано в матеріалі відновлення на певний момент часу та snapshots.

Production-архітектура Directus

Окресліть навколо Directus три межі: ingress до порту 8055, постійний стан і супутні вимоги. Container можна замінити, але для двох інших складових потрібно явно визначити відповідальних. Мережева вимога Directus — Postgres, а для масштабованих розгортань також optional Redis та object storage. Залишайте приватні endpoints у внутрішньому DNS, дозволяйте лише необхідні outbound-з’єднання та надавайте Directus service credential з обмеженими правами.

Схему можна вважати завершеною, коли чистий client може створити адміністратора, колекцію та роль, записати дані через REST, виконати запит через GraphQL і завантажити файл. Збирайте дані про час виконання та використання ресурсів для database connection pool, API request concurrency, Flow workers, генерації thumbnails і upload storage. Якщо транзакція не вдається, перша межа, яка поводиться не так, як описано в документації, підказує, чи потрібно досліджувати маршрутизацію, локальну capacity або supporting service.

Перевірте розгортання Directus наскрізь

Створіть невеликий disposable fixture для Directus і зберігайте його для кожного релізу. Fixture має перевіряти реальний workflow: створення адміністратора, колекції та ролі, запис через REST, запит через GraphQL і завантаження файлу. Зафіксуйте image digest, зовнішній hostname, адресу dependency та очікуваний результат, щоб наступний оператор міг повторити тест без додаткової інтерпретації цього посібника.

Запустіть fixture тричі. Спочатку використайте свіже розгортання. Потім замініть container, не змінюючи постійний стан. Втретє відновіть backup у порожньому середовищі. Третій запуск вважається успішним лише тоді, коли повертаються схема, ролі, flows, items, extensions і uploads, а перевірки REST та GraphQL завершуються успішно. Під час кожного запуску збирайте дані про latency та використання ресурсів для database connection pool, API request concurrency, Flow workers, генерації thumbnails і upload storage; це стане базовою лінією для alert-ів замість довільного відсотка CPU.

Насамкінець навмисно перевірте негативний сценарій: тимчасово забороніть тестовій identity доступ до Postgres, а також optional Redis та object storage для масштабованих розгортань. Переконайтеся, що Directus явно повідомляє про збій і не пошкоджує стан, відновіть правильну умову та повторіть успішну транзакцію. Запис релізу, що містить ці чотири результати, є надійнішим доказом, ніж screenshots dashboard або одноразова відповідь curl.

Запустіть Directus із налаштуваннями, придатними для спостереження

Запускайте Directus так, щоб маршрут залишався приватним до завершення первинного налаштування.

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

Якщо process зациклюється, порівняйте user, якого очікує image, із власником кожного підключеного path. Якщо він працює стабільно, перевірте порт 8055 локально, а потім одразу перейдіть до workflow: створіть адміністратора, колекцію та роль, запишіть дані через REST, виконайте запит через GraphQL і завантажте файл. Зафіксуйте версію image лише після успішної наскрізної перевірки та збережіть точну конфігурацію поруч із service.

Облікові дані, ролі та відкриті поверхні

Закрийте вікно первинного налаштування одразу після створення першого довіреного адміністратора. Конкретна пастка Directus — використовувати пароль bootstrap-адміністратора після першого входу або бездумно змінювати SECRET. Безпечніший підхід — замінити bootstrap credentials, використовувати least-privilege roles і залишати SECRET незмінним, оскільки він захищає application sessions і tokens.

Згенеруйте SECRET один раз, не зберігайте його в Git і додайте до recovery manifest, оскільки його зміна може зробити недійсним зашифрований або підписаний application state. Для credentials dependencies використовуйте private networking, а ролям усередині Directus надавайте мінімально необхідні permissions. Не записуйте конфіденційні request bodies і provider responses у звичайні logs.

Зробіть public origin однозначним

Не використовуйте для Directus тимчасові та постійні public origins. Натомість задайте PUBLIC_URL як канонічну HTTPS-адресу, спрямуйте вибране DNS-ім’я на platform route і проксуюйте запити лише до порту 8055.

Виконайте цю дію ззовні host: створіть адміністратора, колекцію та роль, запишіть дані через REST, виконайте запит через GraphQL і завантажте файл. Якщо ingress не працює, у посібнику з усунення помилки 502 описано проблеми з портами та listeners. Якщо Directus отримує запит, але використовується неправильний клієнт бази даних або upload storage недоступне для запису, тепер докази вказують на проблему за межами proxy.

Відпрацювання збоїв Directus

Для Directus відстежуйте транзакцію, а не process: створення адміністратора, колекції та ролі, запис через REST, запит через GraphQL і завантаження файлу. Поєднуйте її latency та error rate з показниками database connection pool, API request concurrency, Flow workers, генерації thumbnails і upload storage, щоб alert вказував на обмежений компонент.

Під час rehearsal оновлення потрібно врахувати, що schema migrations, extensions і підтримку vendor бази даних Directus слід перевіряти як єдине ціле. Виконайте restore, migration і транзакцію до заміни production. Якщо використовується неправильний клієнт бази даних або upload storage недоступне для запису, не видаляйте дані, щоб зробити startup успішним; у такому порядку порівняйте version, variables, mounts і доступність dependencies.

Що Dockup має автоматизувати для Directus

Platform layer для Directus складається з порту 8055, ingress, TLS, runtime configuration, storage і доступності dependencies. Dockup може відтворити ці складові для власної infrastructure або для сервера, до якого підключається customer.

Після цього operator завершує product layer: задає PUBLIC_URL як канонічну HTTPS-адресу; застосовує це access rule — замінює bootstrap credentials, використовує least-privilege roles і залишає SECRET незмінним, оскільки він захищає application sessions і tokens; а також запускає “створити адміністратора, колекцію та роль, записати дані через REST, виконати запит через GraphQL і завантажити файл”. Збереження цього тесту разом із deployment допомагає не плутати automated provisioning із готовністю application.

Поширені запитання

Що потрібно Directus для production-розгортання?

Спрямуйте Directus container через порт 8055 до одного HTTPS origin. Мережева вимога для supporting services — Postgres, а для масштабованих розгортань також optional Redis та object storage. Не вважайте Directus готовим, доки не зможете створити адміністратора, колекцію та роль, записати дані через REST, виконати запит через GraphQL і завантажити файл.

Які дані Directus потрібно включати до backup?

Зберігайте /directus/database, а database, uploads, extensions, flows і schema snapshots додайте до одного recovery manifest. Чисте відновлення Directus вважається успішним лише тоді, коли повертаються схема, ролі, flows, items, extensions і uploads, а перевірки REST та GraphQL завершуються успішно.

Чи потрібен Directus HTTPS за reverse proxy?

Використовуйте HTTPS для public origin Directus, а порт 8055 залишайте на internal route. Правильно застосуйте налаштування Directus: задайте PUBLIC_URL як канонічну HTTPS-адресу. Для Directus HTTPS захищає credentials або user content під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Directus?

Відновіть поточний стан Directus в ізольованому deployment, застосуйте candidate version і повторіть acceptance transaction. Особливу увагу приділіть тому, що schema migrations, extensions і підтримку vendor бази даних Directus слід перевіряти як єдине ціле. Зберігайте попередній Directus image, доки не зрозумієте межі міграції даних і rollback.