Експлуатація

Для того, хто відповідає за хост Linux. Три команди піднімають платформу; усе, що має зберігатися, лежить в одному каталозі, який можна скопіювати будь-яким файловим інструментом.

Вимоги#

• хост Linux із Docker (і Compose v2);
• щонайменше приблизно 2 CPU і 4 ГБ ОЗП — вкладені демони потребують багато ресурсів;
• вихідний доступ до Інтернету для завантаження образів: хост має пересилати й маскарадити мережу hosting, щоб платформа могла дістатися до реєстрів;
• ext4 (або інша файлова система, сумісна з overlay) для data/.

Встановлення трьома командами#

git clone <this repo> && cd dind   # 1
make build                          # 2 — збирає образ management (і MinIO); перший раз і після змін у коді
make up                             # 3 — ідемпотентний початковий запуск

Команду make up безпечно запускати повторно будь-коли. Вона створює мережу hosting, запускає головний DinD, завантажує образи платформи, створює внутрішню мережу, запускає контейнер management і чекає, поки він повідомить про справний стан. Після цього відкрийте http://10.10.10.10:8900 і увійдіть як admin@platform.example з паролем, виведеним у журналі management (він також лежить у data/platform/secrets/panel.admin_password).

Щоденні команди#

Щоб виконати команду всередині головного DinD, використовуйте docker exec dind-hosting docker … (наприклад, docker exec dind-hosting docker ps).

Самовідновлення#

• Перезавантаження хоста → Docker запускає dind-hosting → кожен внутрішній контейнер має restart: unless-stopped → стек повертається без втручання.
• Збій management → він перезапускається за своєю політикою; під час завантаження узгоджувач (reconciler) заново приводить до потрібного стану мережу, контейнери платформи та демон кожного користувача (створює, якщо відсутній, запускає, якщо зупинений — і ніколи не знищує дані користувачів).
• Збій демона → його контейнери повертаються разом із ним, а сокет створюється знову.
• Демону, який лише ще запускається, дається пільговий проміжок часу, перш ніж його вважатимуть несправним.

Резервне копіювання даних#

Усе, що має зберігатися, лежить у data/ поруч із Makefile:

Для узгодженої копії платформу треба зупинити (make down), потім скопіювати data/ на рівні файлів (rsync, знімок, tar) і виконати make up. Зберігайте data/platform/secrets разом з рештою — там лежить ключ шифрування збережених паролів, і без нього збережені паролі баз даних і секрети розшифрувати неможливо.

Оновлення#

git pull
make build            # новий образ management
scripts/upgrade.sh    # завантажити його, перестворити management, дочекатися справного стану

Дані не зачіпаються; міграції Alembic виконуються під час запуску. Щоб відкотитися, перезберіть попередній коміт і знову запустіть scripts/upgrade.sh.

• Типові версії середовищ виконання (node, python, php, nginx) задано в backend/app/services/deploy/runtimes.py; їх можна перевизначити через PLATFORM_DEFAULT_*_VERSION — застосунки, що йдуть за типовою версією, переходять на нову під час наступної перебудови.
• Образи баз даних для нових баз — PLATFORM_DB_POSTGRES_IMAGE / PLATFORM_DB_MYSQL_IMAGE; наявні бази зберігають свій образ. База даних самої платформи залишається на postgres:16-alpine — не переводьте її на 17.

Домени та TLS у режимі prod#

1. Спрямуйте A-запис домену на вхідний шлюз (ingress) перед хостом.
2. Переконайтеся, що ingress пересилає порти 80 і 443 на 10.10.10.10 і що платформа має доступ до ACME CA.
3. Вкажіть Публічні IP балансувальника і справжню електронну адресу в полі Контактна пошта у розділі Платформа → Налаштування / Сертифікати (ACME), потім переведіть Режим TLS у значення prod.
4. Додавайте домени; кожен спершу має пройти перевірку.

Справжні адреси клієнтів за L4 ingress#

Якщо перед платформою стоїть nginx stream (або щось подібне), він може надсилати протокол PROXY, щоб застосунки та журнали бачили справжню адресу клієнта. За замовчуванням його вимкнено: задайте PLATFORM_TRAEFIK_PROXY_PROTOCOL_TRUSTED_IPS (або окремі для точок входу …_WEB_TRUSTED_IPS / …_WEBSECURE_TRUSTED_IPS) рівним адресі проксі. Адресу клієнта визначає заголовок довіреного вузла; заголовок недовіреного ігнорується; значення з неправильним форматом, /0 або такі, що перетинаються з мережею платформи, відхиляються під час запуску.

Великі завантаження через ingress#

PUT архіву понад 100 МБ на …/api/v1/uploads/<token> проходить через ваш ingress: дозвольте тіло запиту щонайменше 512 МіБ, вимкніть буферизацію запитів для цього шляху й задайте щедрий тайм-аут. Передавайте Host і X-Forwarded-Proto у location /mcp/ або задайте PLATFORM_PUBLIC_URL, щоб посилання для завантаження містило правильну адресу.

Використання диска#

Шари образів і томи накопичуються всередині кожного демона. Перевіряйте їх для кожного демона окремо:

docker exec dind-hosting docker system df
docker exec dind-hosting docker exec projects-<alias> docker system df

Очищайте кеш збірки та «висячі» образи всередині демона командами docker image prune / docker builder prune — але ніколи не виконуйте volume prune на демоні баз даних.

Обмеження журналів контейнерів#

Журнал кожного контейнера, який створює платформа — сервіси платформи, демони користувачів, застосунки, бази даних — ротується за PLATFORM_LOG_MAX_SIZE (типово 25m) × PLATFORM_LOG_MAX_FILE (типово 2) = щонайбільше 50 МБ; найновіші 25 МБ завжди переживають ротацію. Задайте ці дві змінні як змінні CI/CD. Docker не вміє змінювати параметр журналу в працюючого контейнера, тому нове значення потрапляє в management під час наступного поступового оновлення, у Traefik — під час наступного запуску management, а в застосунки й бази даних — під час їх наступного розгортання чи перестворення; контейнери платформи зі станом зберігають старе налаштування, доки їх не перестворять.

Де шукати журнали#

Розгортання самої платформи (CI)#

Розгортання в production виконуються з GitLab CI на окремому runner (тег h0-infra): перевірка стану, оновлення та ручне завдання розгортання. Конвеєр викликає ті самі скрипти, що описані вище, — через ssh нічого не змінюється. Перелік завдань і змінні CI дивіться в посібнику оператора (OPERATIONS.md).