Руководство по установке

Эта страница — технический справочник по инсталлятору. Если вы разворачиваете сервер впервые — идите по пути новичка: Азбука → Большое руководство, там те же шаги объяснены «на пальцах».

Требования #

Установка #

git clone https://github.com/your-org/mitdev.git
cd mitdev
sudo ./install.sh

Шаги инсталлятора #

1. Проверка окружения (preflight) #

Автоматически проверяются: права root, дистрибутив и версия Ubuntu, архитектура, доступ в интернет, тип виртуализации, свободный диск, RAM, занятость APT другим процессом. Критические проблемы останавливают установку с понятным сообщением; предупреждения (например, мало RAM) установку не блокируют.

2. Выбор компонентов #

Чекбокс-список. Обязательные модули (система, пользователь, усиление SSH, утилиты, очистка) не отображаются и выполняются всегда.

Зависимости разрешаются автоматически: PM2 → Node.js, Certbot → Nginx, PostgreSQL-кластер → PostgreSQL, Виртуальный IP → PostgreSQL-кластер.

3. Пользователь деплоя #

• имя (по умолчанию deploy; валидация POSIX-имени);
• пароль с повторным вводом (пусто — не менять, удобно при повторном запуске);
• публичный SSH-ключ (опционально). Независимо от этого инсталлятор предложит сгенерировать отдельные Ed25519-ключи для Termius: один для deploy-пользователя, второй для root.

Пользователь получает sudo, группу docker (если выбран Docker) и каталоги ~/apps ~/docker ~/logs ~/backups ~/scripts с правами 750.

Сгенерированные приватные ключи хранятся root-only: /root/.mitdev-keys/<пользователь>_ed25519 и /root/.mitdev-keys/root_ed25519. После установки их можно показать командами sudo mitdev ssh-key show deploy и sudo mitdev ssh-key show root, затем импортировать в Termius: Keychain → New Key → Import/Paste private key.

4. Безопасность SSH #

• порт SSH (1–65535; при смене порта учтена socket-активация Ubuntu);
• запрет прямого входа root (рекомендуется, если deploy-пользователь уже имеет ключ и sudo);
• отключение парольной аутентификации SSH для всех пользователей. Это правильная практика после установки ключей; без deploy-ключа инсталлятор не даст отрезать себе доступ.

Конфигурация пишется в drop-in /etc/ssh/sshd_config.d/99-mitdev.conf и применяется только после успешного sshd -t.

5. PostgreSQL-кластер (если выбран) #

Выбор роли сервера:

• primary — опционально список IP будущих реплик (можно оставить пустым и добавлять позже командой mitdev pg add-replica <ip>);
• replica — адрес primary и пароль репликации (значение replication_password из /root/.mitdev-credentials на primary), IP остальных узлов кластера (пиры для самовосстановления), включение авто-failover и приоритет реплики (основная / резервная с задержкой 45 с). Показывается явное предупреждение: локальные данные PostgreSQL будут замещены копией primary (старый каталог сохраняется рядом, не удаляется).

Watchdog самовосстановления ставится на все узлы кластера (и на primary тоже — для fencing/самопонижения при возврате после failover).

5а. Kubernetes (если выбран) #

Режим сервера: single (одиночный), init (первый сервер HA-кластера) или join (присоединение — URL https://<IP>:6443 и токен из mitdev k8s token, плюс IP пиров для файрвола).

5б. База данных проекта (если выбран PostgreSQL) #

Инсталлятор спрашивает имя базы, пользователя БД и пароль (пусто — сгенерировать; двойной ввод). Повторный запуск с новым паролем обновляет его у существующей роли. На реплике кластера вопросы не задаются — база и учётные данные приезжают с primary через репликацию. Всё сохраняется в /root/.mitdev-credentials.

6. Подтверждение плана #

Полный список модулей (с пометкой «переустановка» для уже выполненных), настройки пользователя, SSH и кластера. Установка начинается только после «Да».

7. Установка #

Прогресс-бар по модулям, спиннер по текущему модулю, каждый шаг — в журнал. При сбое модуля: экран ошибки с последними строками журнала → предложение отката изменений этого модуля → выбор «продолжить остальные / прервать».

8. Итоговая сводка #

IP сервера, версия Ubuntu, версии Node/Docker/Compose/PM2, статусы Nginx/UFW/Fail2Ban, имя пользователя, каталоги, пути к журналам и файлу учётных данных.

Повторный запуск (идемпотентность) #

Повторный запуск безопасен. Выполненные модули определяются по маркерам в /var/lib/mitdev/state/ и помечаются «(уже установлен)»; на каждом инсталлятор спросит, переустанавливать ли. Внутри модулей все операции проверяют текущее состояние (существующий пользователь, настроенный пароль Redis, работающая реплика PostgreSQL и т.д.) и не ломают его.

Неинтерактивные переопределения #

Любое значение из config/defaults.conf переопределяется окружением (полный список — CONFIGURATION.md):

sudo NODE_MAJOR=24 TIMEZONE=Europe/Amsterdam SWAP_SIZE_MB=4096 ./install.sh

Что и куда ставится #

После установки #

sudo bash /opt/mitdev/tests/verify.sh   # верификация всех модулей
mitdev doctor                           # диагностика
sudo mitdev ssh-key status              # пути и команды для ключей Termius
sudo mitdev ssh-key show deploy         # приватный ключ deploy-пользователя
sudo mitdev ssh-key show root           # приватный ключ root, если root-вход разрешён
sudo cat /root/.mitdev-credentials      # пароли служб

Важно: если вы сменили порт SSH — проверьте новое подключение (ssh -p <порт> <пользователь>@<ip>), не закрывая текущую сессию.

Типовые сценарии #

Веб-сервер под Node-приложения #

Компоненты по умолчанию → mitdev app → домен + SSL. Готово.

Docker-хост #

Достаточно Docker + Nginx + Certbot + UFW + Fail2Ban. Приложения — через mitdev app (compose-файл подхватывается автоматически).

Kubernetes-нода #

Выберите Kubernetes (+ по желанию Nginx: тогда traefik отключится, публикация пойдёт через nginx). Деплой: mitdev k8s deploy <имя> <образ> [порт] [домен].

Кластер PostgreSQL из трёх узлов (рекомендуемая схема) #

1 primary + 2 replica с авто-failover и единой строкой подключения через виртуальный IP:

1. Узел A: модули «PostgreSQL-кластер» (primary, реплики B C) + «Виртуальный IP» (например 10.0.0.100/24, пиры B C).
2. sudo cat /root/.mitdev-credentials на A → replication_password.
3. Узлы B и C: те же модули, роль replica, primary = A, авто-failover «Да», тот же VIP. На C задайте PROMOTE_DELAY=45 (приоритет B).
4. Приложения подключаются к postgresql://…@10.0.0.100:5432/… — строка не меняется даже после failover. Доступ каждому серверу приложений откройте на всех узлах: mitdev pg allow <ip-приложения>.

Ресурсы DB-узла: 1 ГБ RAM / 2 ядра — рабочий минимум для небольших нагрузок (инсталлятор сам создаст swap 2 ГБ); комфортно — от 2 ГБ. Узлы кластера держите выделенными под PostgreSQL — не совмещайте с Docker- приложениями и тем более с Kubernetes (k3s один съедает ~512 МБ).

Узлы в разных дата-центрах (нет общей сети)? Модуль pgvip пропустите — VIP работает только в одной L2-сети. Вместо него на каждом сервере приложений выполните mitdev pg proxy <ip1> <ip2> <ip3>: приложения подключаются к 127.0.0.1:5432, HAProxy сам направляет на текущий primary. Репликация и клиенты между ДЦ — только по TLS (настраивается автоматически). Подробности — в COMMANDS.md.

Полный сценарий и действия после failover — в COMMANDS.md.

Устранение неполадок #

См. TROUBLESHOOTING.md.