Установка на текущем сервере

То же самое, что era_installer/install-ssh.adoc#era-installer-install-ssh, но каталог поставки уже лежит на сервере и команда запускается там.

bash era/scripts/install.sh

Отличий от ssh-варианта два: нет экрана подключения и нет доставки файлов. Экраны мастера, экран подтверждения и фаза применения совпадают полностью.

Когда это удобнее

  • Каталог уже на сервере — например, вы копировали его один раз, а установку повторяете.

  • Образ платформы весит гигабайты, а канал до сервера узкий: копировать его каждый раз незачем.

  • Установка выполняется из чужого сценария развёртывания, у которого свой способ доставки файлов.

Каталог копируется любым привычным способом, обычно rsync:

rsync -a --exclude='logs/' ./ user@192.168.0.10:/tmp/era_installer/
ssh -t user@192.168.0.10 'cd /tmp/era_installer && bash era/scripts/install.sh'

То же самое через диспетчер, если так привычнее:

ssh -t user@192.168.0.10 'cd /tmp/era_installer && bash era/era.sh install'

Ключ -t обязателен, если установщик будет что-то спрашивать. Без него ssh не выделяет терминал на той стороне, и мастер это чувствует: псевдографика не запускается, а ввод пароля перестаёт скрываться — набранное отображается вашим локальным терминалом, и выключить это удалённая сторона не может. Установщик предупреждает об этом перед первым же вопросом о пароле.

Если запуск идёт из сценария, где терминала нет вовсе, передавайте пароли файлом: --secrets-file — см. era_installer/unattended.adoc#era-installer-unattended-secrets.

Каталог назначения — /tmp: в него пишет любой пользователь, и копирование не требует прав root. В /opt обычный пользователь писать не может, и rsync остановится на отказе в доступе ещё до установки. Поставку можно разместить в любом каталоге — корень она определяет по собственному пути, — но этот каталог должен быть доступен на запись тому, кто копирует.

Порядок действий фазы применения

Он всегда один и тот же и повторяет план, который вы видели на экране подтверждения.

  1. Прокси — если задан, переменные окружения выставляются до всего остального.

  2. Docker — ставится, если его нет; служба включается, если не запущена.

  3. PostgreSQL — контейнер или кластер в хосте.

  4. Каталоги-тома — создаются и, при запуске без root, передаются пользователю с uid 1000.

  5. Общие каталоги — роль NFS-сервера, роль клиента или пропуск с созданием маркеров.

  6. Параметры ядра — лимиты inotify и, по запросу, сетевые.

  7. Порты в firewalld — до запуска контейнера, чтобы платформа была доступна сразу.

  8. Образ платформы — загружается в docker.

  9. Контейнер платформы — запускается.

  10. Ожидание инициализации — установщик ждёт от контейнера отчёта о результате.

  11. Продуктовый слой — копируется, если найден в era/assets.

Шаг пропускается, если он не нужен при ваших ответах: например, docker не трогается, если он уже работает. Пропущенных шагов нет и в плане — он и очередь действий строятся из одних и тех же условий.

Что изменилось на сервере

Сразу после применения печатается форма: перечень изменений и итог каждого.

== Что изменилось на сервере ==

  [ ok ] Пакеты                             docker-ce, docker-ce-cli, containerd.io и ещё 1
  [ ok ] PostgreSQL                         контейнер postgres<постфикс>, порт 5441
  [ ok ] Роли базы данных                   platformpgadmin
  [ ok ] Каталоги-тома                      12 в /opt
  [ ok ] NFS-сервер                         служба nfs-kernel-server, экспортировано каталогов: 3
  [FAIL] Общие каталоги                     не смонтированы: /opt/era<постфикс>/era_recpath
  [ ok ] Параметры ядра                     fs.inotify.max_user_watches = 10000000
  [warn] Порты в firewalld                  не открыты: 8080/tcp
  [ ok ] Образ платформы                    era_1_11_0-2026_8_31_1_docker
  [ ok ] Контейнер платформы                era<постфикс>, запущен
  [ ok ] Инициализация платформы            Install server success!

Изменены системные файлы:
    /etc/exports.d/era_nfs.exports
    /etc/sysctl.d/97-era-platform-inotify.conf

Метки те же, что у предпроверок, но отвечают они на другой вопрос. Предпроверки смотрят, можно ли начинать; форма — что получилось на самом деле, и берёт это из состояния системы, а не из кода возврата команды: контейнер запущен, служба активна, каталог смонтирован, кластер отвечает.

Это важно, потому что часть шагов намеренно не прерывает установку: неудачное монтирование NFS, неоткрытый порт в firewalld, молчание контейнера по таймауту. Без формы их отказ остался бы только в логе.

Проверки не зависят от того, от кого запущен установщик: лимит ядра читается из /proc, а не через sysctl (его каталог /usr/sbin в PATH обычного пользователя обычно отсутствует), сведения о базе берутся из самой базы, о контейнерах — у docker. Если значение прочитать не удалось совсем, строка получает [warn], а не [FAIL]: не увидев значения, утверждать, что изменение не сделано, нельзя.

Метка Что значит

[ ok ]

Изменение сделано и подтверждено проверкой.

[warn]

Сервер работает, но не полностью: например, порт не открыт — платформа поднимется, а снаружи будет недоступна. На код возврата не влияет.

[FAIL]

Изменение не удалось. Установщик завершается с кодом 5, даже если очередь действий дошла до конца.

[skip]

До этого шага не дошли: установка оборвалась раньше.

Форма печатается и после отказа — тогда она нужнее всего: видно, что успели изменить и что осталось работать. При --dry-run формы нет: сервер не менялся, отчитываться не о чем.

При удалении печатается такая же форма, но отвечает она на вопрос «что осталось»: контейнер, кластер, монтирования, каталог инстанса.

Что показывается в конце

После успешной установки печатаются:

  • команда, которой этот сервер устанавливается заново;

  • команда, которой он удаляется;

  • команда установки по ssh, если адрес подключения известен;

  • команды для дополнительных серверов, если вы их перечислили на экране 10;

  • путь к файлу с готовой командой.

Пароли в напечатанных командах скрыты: экран остаётся в прокрутке терминала. Команда с настоящими значениями лежит в файле .cmd рядом с логом, с правами 0600 — копируйте оттуда; команды дополнительных серверов лежат там же.

Команды для дополнительных серверов

Если на экране 10 вы ответили, что планируются другие серверы, и перечислили их имена и адреса, в конце печатается по одной готовой команде на каждый. Команда неинтерактивная: её остаётся выполнить на том сервере.

Основа команды — ответы этого запуска: сервера входят в одну систему, и постфикс, каталоги, пароль базы и параметры сети у них общие. Отличается роль и то, что из неё следует:

  • --master=n, а домен мастера не передаётся — мастер в системе один;

  • --micaddress=mic1@<адрес мастера> — по этому адресу сервер находит мастер;

  • --dopginstall=n и --pghost=<адрес мастера> — своя база не ставится, сервер подключается к базе мастера;

  • --installnfsserver=n, а при NFS-сервере на мастере — --nfsserveraddr=<адрес мастера>;

  • --lang — тот же, на котором шла установка мастера: команду выполняет человек, и получить установку на другом языке было бы неожиданностью. В команде повтора этого ключа нет — её выполняет сценарий.

Проверьте команду перед запуском: установщик берёт за основу ответы мастера и не знает, чем именно отличается конкретный сервер.

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт