DinD HostingПосібник
ENУК
Огляд/Посібник/Початок
РОЗДІЛ 01

Основні поняття

Одинадцять термінів пояснюють усю платформу. Засвойте їх один раз — і решта розділів читатиметься швидко.

Словник#

Термін Що це
Користувач Людина (або ідентичність агента) з електронною поштою, паролем і роллю: admin або user. Користувачів створюють адміністратори — самореєстрації немає.
Псевдонім Короткий унікальний ідентифікатор із 2–15 символів [a-z0-9], який є в кожного користувача. З'являється в іменах демонів і сайтів (<slug>.<alias>.<base_domain>).
Проєкт Одиниця розгортання: slug, відображувана назва й базовий домен. Проєкт володіє одним вебзастосунком, його базами даних, доменами, змінними та резервними копіями.
Slug Коротке ім'я проєкту, 2–40 символів [a-z0-9-], унікальне для кожного користувача.
Застосунок Запущений вебзастосунок проєкту — один контейнер, зібраний із вашого вихідного коду. У цій версії — один застосунок на проєкт.
Розгортання Одна спроба зібрати й запустити. Нумерується в межах проєкту, має статус, журнал збірки та визначений маніфест.
Середовище виконання Як збирається й запускається ваш вихідний код: static, node, python або php. Визначається автоматично або задається в platform.yaml.
Демон (DinD) Демон Docker, що працює всередині контейнера. Кожен користувач має власний для застосунків; бази даних живуть у спільному. Ваш код ніколи не ділить демон з іншим користувачем.
База даних Контейнер PostgreSQL або MySQL, підключений до проєкту, зі згенерованими обліковими даними та SQL-консоллю.
Бакет Ваш особистий бакет S3 (<alias>-files) у вбудованому MinIO з вашими власними ключами доступу.
Токен Довготривалий API-токен dt_… для агентів і CI, створюється на сторінці Токени.

Як усе вкладено одне в одне#

Усе, що запускає платформа, живе всередині одного привілейованого контейнера dind-hosting. Усередині нього сервіси та демони користувачів спільно використовують приватну мережу, а застосунки кожного користувача працюють у його власному демоні.

зовні Браузери*.alex.example.com REST-клієнти · CIBearer JWT / токен dt_ ШІ-агентиClaude Code · MCP Ingress хоста проксі абоnftables на хостіваше рішення → 10.10.10.10 dind-hostingголовний DinD · privileged · міст «hosting» · 10.10.10.10 · портів не публікує platform-net · 172.28.0.0/16 · статичні IP Traefik:80 :443 · ACME172.28.0.3 management:8900 UI·API·MCP172.28.0.2 platform-pgстан · метрики172.28.0.4 MinIOS3 · копії172.28.0.5 projects-alex172.28.0.64 blogstatic:10000 shopnode 24:10001 dbспільний демон БД172.28.0.10 postgresshop-main:20000 mysqlblog-wp:20001 projects-bob172.28.0.65 apipython 3.12:10000 sitephp 8.5:10001 db-aliceнеобов'язково · окремий postgresanalytics:20000 /platform-data/sockets/ main.sock · db.sock · projects-alex.sock · … data/ на хості монтується в головний DinD: main-docker · platform/{db,minio,deploys, traefik,secrets,sockets} · dind/ умовні позначення HTTP-маршрут за Host Docker API через unix-сокети демон користувача (застосунки) демон баз даних єдиний контейнер рівня хоста
Уся платформа. Один контейнер рівня хоста містить сервіси платформи та по одному демону застосунків на користувача. Бази даних живуть у спільному демоні або у виділеному, якщо адміністратор вмикає це для користувача.

Варто звернути увагу на три речі:

  1. Одна адреса назовні, до хоста. Платформа доступна за адресою 10.10.10.10 у мостовій мережі хоста. Вона не публікує жодних портів хоста; що саме пересилається з Інтернету, вирішуєте ви на рівні вхідного шлюзу (ingress).
  2. Демон на користувача. Ваші застосунки збирає й запускає демон, яким користуєтеся лише ви. Це межа ізоляції між користувачами.
  3. Усе узгоджується. Контейнер management (узгоджувач, reconciler) під час кожного запуску знову встановлює бажаний стан усього цього — перезавантаження чи збій повертають увесь стек без стороннього втручання.

Хто чим володіє#

користувачідемони застосунків (по одному на користувача)спільні сервісиalexроль: користувачпсевдонім: alexbobроль: користувачпсевдонім: bobprojects-alex172.28.0.64blogstatic · nginx:10000shopnode 24:10001projects-bob172.28.0.65apipython 3.12 · :10000володієволодієdbспільний демон БДpostgresshop-mainmysqlblog-wppostgresapi-mainMinIOIAM-користувач і бакет на кожногоalex-filesIAM-користувач alexbob-filesIAM-користувач bobЗастосунки отримують DB_MAIN_HOST/PORT/USER/PASSWORD/NAME і S3_* як змінні середовища.Бірюзовий — доступ до баз даних через platform-net · зелений пунктир — S3 зі власними ключами користувача.
Розмежування користувачів. Кожен користувач володіє демоном застосунків зі своїми проєктами; бази даних і об'єктне сховище — спільні сервіси, розмежовані за користувачами.

Платформа перевіряє право власності на сервісному рівні, тому вебконсоль, REST API та MCP-інструменти поводяться однаково:

  • Користувач бачить і змінює лише власні проєкти, бази даних, резервні копії та токени. Чужий об'єкт відповідає не знайдено, а не заборонено, тож факт його існування не розкривається.
  • Адміністратор також бачить усі проєкти й може створювати та вимикати користувачів, вмикати чи вимикати виділений демон баз даних користувача, читати метрики всієї платформи та змінювати налаштування платформи.

Три входи, одні правила#

Веб-консольReact SPA · браузервхід → JWT (8 год)REST API/api/v1 · JSON · SSEJWT або токен dt_…MCP-сервер/mcp/ · stdioтокен dt_… для агентівmanagement · сервісний шарRBAC і власністькористувач бачить лише свої об'єктибізнес-логікарозгортання · БД · домени · копіїжурнал аудитуaudit_log · query_log на кожну змінуоднакові правиладля кожних «дверей»Демони Dockerлише unix-сокети · docker-pyБаза даних платформикористувачі · проєкти · розгортання · журналиMinIO · файли Traefikадміністрування S3 через mc · файли маршрутів
Консоль, REST API та MCP-сервер — тонкі обгортки над тим самим сервісним шаром: та сама авторизація, ті самі ліміти, той самий журнал аудиту.

Усе, що можна натиснути, можна також автоматизувати (curl) або доручити агентові (deploy_app, run_query, …). Автентифікацію описано в розділі API-токени, REST і MCP.

Що де зберігається#

Дані Де зберігаються Переживають повторне розгортання?
Користувачі, проєкти, розгортання, налаштування, записи аудиту, метрики PostgreSQL платформи (platform-pg) Так
Ваші архіви з вихідним кодом data/platform/deploys на хості Доки їх не видалить очищення за терміном зберігання
Журнали збірки Живий буфер під час збірки, потім MinIO Так
Зібрані образи й томи застосунків Ваш демон застосунків projects-<alias> Образи перебудовуються; томи зберігаються
Файли баз даних Іменований том усередині демона баз даних Так
Резервні копії та дампи Бакет MinIO platform Згідно з політикою зберігання
Ваші власні файли Бакет MinIO <alias>-files Так
Згенеровані секрети (ключ JWT, паролі, ключ Fernet) data/platform/secrets (режим 0600) Так

Файлові системи контейнерів — тимчасові

Розгортання замінює контейнер застосунку. Усе, що застосунок записує поза оголошеним томом (див. platform.yaml) або поза S3, зникає після наступного розгортання чи перестворення.

Статуси, які ви побачите#

Об'єкт Значення
Розгортання у черзі отримання коду збірка працює збій
Контейнер застосунку працює зупинено відсутній
Перевірка домену очікує пройдено помилка DNS помилка маршрутизації
Сертифікат немає очікує видано помилка

Ліміти коротко#

1 застосунокна проєкт
2–40символів у slug
512 МіБмаксимальний розмір завантаженого архіву
100змінних проєкту на проєкт
1 000 рядківабо 1 МіБ на результат SQL
14 днів · 5типовий термін зберігання резервних копій для кожної області