ActiveScaleинженерная практика

Флаги install-ng: словарь и ловушки

Справочники installinstall-ngflagsphasesreference

Коротко. install-ng.py — не «одна кнопка установки», а набор фаз, каждая из которых включается своим флагом. Флаги складываются по ИЛИ с ключами config-ng.ini, поэтому «лишний» ключ в ini включает фазу даже без флага. Код возврата 0 не означает «сделано»: часть фаз при неверном входе завершается нулём, ничего не меняя. Судить только по гейтам.

1. Как устроен запуск

install-ng.py выполняет фазы-if в порядке main(). Флаг не «переставляет» фазы, а только разрешает или запрещает очередную. Отсюда два следствия, которые ломают прогоны:

  1. Порядок фиксирован. Нельзя «сначала DSS, потом сеть»: фазы идут в порядке кода.
  2. Слияние по ИЛИ. Эффективное значение = флаг CLI или ключ ini. Флаг не может выключить то, что уже включено в config-ng.ini; для «только эта фаза» в ini все булевы ключи должны быть False, а нужный флаг — только в командной строке.

Запуск — от пользователя marvin, из /home/marvin, в фоне (setsid nohup), с обязательным --product activescale. Без --product берётся mcore и прогон падает на get_default_role.

2. Словарь флагов

Флаг Фаза Что делает Ловушка
-t combined тип управление и хранилище на одном стенде (scaler/storage/combined) не путать с mcore
-c <file> вход путь config-ng.ini очереди дефолт — config.ini в текущем каталоге
--product activescale вход продукт без него — mcore, падение get_default_role
-e 1 импорт environment и очереди в модель, systemscan через него доезжают additional_packages (профиль железа)
-i 2 management init локальной ноды, импорт machine.json только здесь импортируется машина
-I 3 initialize Nodes: ставит ОС на удалённые ноды по PXE единственная фаза, которая ставит ОС
-n <N> 3 сколько нод ждать по PXE работает только с -I; без него прогон на одну ноду
-m 4 configure Nodes: провижининг приложений перерендеривает конфиги ролей — ручные правки не переживут
-a 5 arakoon-кластеры идёт после -m
-A — setup-accounts (обе ветки) догон аккаунтов
-AST 6 accounts storage: s3/axm, setup_dss(policy_type), добавление storage падает, если группы политики нет в dssconfig.yml, — и всё равно rc=0
-C 7 configure Columns: создаёт и настраивает колонку 500, если -AST оставил колонку пустой
-ASC 8 accounts scaler: setup_iam, iamd, политики парная к -AST
-D 10 disable-environment (специфика scale-out) не «DSS»: DSS — это -AST и -C
-d служебный --debug: подробный лог и трейсбеки в install.log не «deploy DSS»; см. §6
-S режим --is-scale-out: пропускает создание федеративной БД для первой ноды пути A — запрещён
-x служебный --extend-clusters: раскатывает mongod на остальные management-ноды без него mongod только на ведущей → пустой GUI
-T служебный все arakoon одного класса на первую ноду только для однонодового теста
-P <policy> вход policy_type из dssconfig.yml альтернатива правке ini
-F служебный переиспользовать существующие ФС при установке с нуля — не ставить
-V служебный validate очереди и выход безопасная «сухая» проверка
-W служебный не ждать задачи в конце для отладки; по умолчанию ждёт
-p <path> вход каталог данных модели переопределяет путь очереди
-E <file> вход initial_environment.json начальные данные окружения

-N и --max-metastores/--arakoon-size — устаревшие или тонкие настройки arakoon; в новых скриптах не использовать.

3. Порядок фаз

-e                 импорт очереди, профиль железа
-i -m              ведущая ONLINE, свой DHCP/PXE
-I -n <N>          ноды по PXE, ОС на диск
-m -a -AST -C -ASC блоксторы, arakoon, аккаунты, колонка, S3
-x                 mongod на все management-ноды

Ноды должны уже грузиться по PXE к моменту старта -I: флаг загрузки, выставленный после запуска, прогон не увидит. -I и -n убирают из кластерных прогонов: иначе wait_for_remote_pxe_nodes съедает часы на ожидании нод, которые уже с ОС.

4. Наборы, которые реально нужны

# 1) environment и дополнительные пакеты (отдельно, раньше всего)
-t combined -e -d

# 2) ведущая и ноды с ОС (ноды уже грузятся по PXE)
-t combined -i -m -I -n <N> -d

# 3) кластерные фазы (ноды уже с ОС; -I и -n убрать)
-t combined -m -a -AST -C -ASC -d

# 4) раскатать mongod на все management-ноды
-t combined -x -d

Дробить фазы «по одной» без нужды и сокращать набор нельзя: незакрытый предыдущий слой роняет следующий, и это выглядит как новая поломка.

5. Ловушки

  1. --product забыт. Дефолт — mcore; падение на get_default_role. Симптом выглядит как «сломанный установщик», а не как неверный флаг.
  2. -S на первой ноде пути A. skip_federated_db=True убирает federated_model из создаваемых кластеров. Дальше — 404 на /federated/_status/, No suitable management server found, и в модели «нечего расширять».
  3. -x не указан. Всё зелёное, колонка CONFIGURED, но mongod живёт только на ведущей, а страница «Ресурсы» пуста. Проверка — pgrep -c mongod на каждой ноде.
  4. Два узла одновременно. Прогон ждёт оба и даёт nr_of_nodes=0 или зависание. Ставить по очереди; в config-ng.ini есть вендорный bypass nr_of_nodes = 0 для wait_for_remote_pxe_nodes.
  5. Бэкапы .orig/.bak в group_vars. Ansible грузит все файлы каталога, и бэкап побеждает. Бэкапы выносить за пределы group_vars.
  6. status в column.json. С полем status валидатор не пускает → column NOTINITIALIZED. Поля быть не должно.
  7. Нет группы политики в dssconfig.yml. -AST завершается rc=0, колонка создаётся пустой, -C падает 500 at least one S3 connection is required. Политику вписывают в мастер-копию dssconfig.yml до первого прогона, а не в dssconfig.d/.
  8. Ручные правки конфигов после -m. -m перерендеривает конфиги ролей из group_vars/модели; правка «руками» исчезает на следующем прогоне. Все фиксы — через ansible-переменные.

6. Про -d и -D: почему конспекты расходятся

В некоторых кратких конспектах -d описывают как «deploy DSS», а -D — как «DSS». По коду 7.3.1.2 это не так:

  • -d = --debug — подробный лог и полные трейсбеки. Ставить всегда, разбирать по /opt/ampli/var/log/marvin/install.log.
  • -D = --disable-environment — фаза 10, пометка environment для scale-out.
  • DSS включается фазами -AST (политика, ns, storage) и -C (колонка), а не отдельным флагом «DSS».

Если конспект и --help расходятся — верить --help и коду на конкретной сборке: набор флагов меняется между версиями. В статье install-ng: фазы, флаги и маркер завершения описание фаз верное, а строку про -d/-D сверяйте с этим разделом.

7. Проверка до и после

До запуска (read-only):

sudo -u marvin /opt/ampli/apps/marvinbase/venv/bin/python \
  /opt/ampli/apps/marvinbase/tools/install-ng.py \
  --config /opt/ampli/apps/marvinbase/queue/<NODE>/config-ng.ini \
  --product activescale -V

-V проверяет очередь и выходит, ничего не меняя. Затем — pgrep -f "[i]nstall-ng.py" (никто не запущен) и удаление старого маркера /tmp/.unattended_install_finished.

После запуска — не по коду возврата, а по гейтам:

  • /federated/_status/ → 200 быстрее 50 мс;
  • барометр DSS ok, неймспейсы status: ok;
  • selectedstoragepolicy не null, политика влезает: w + s ≤ N;
  • pgrep -c mongod — по числу кластеров на каждой ноде;
  • приложения: NOTCONFIGURED = 0;
  • S3 PUT/GET round-trip, GUI без пустот.

8. Источники

  • Software Documentation Center (7.3) (дата доступа 2026-11-07)
  • Наша практика (обезличено): прогоны install-ng на 3-нодных стендах, сверка флагов с install-ng.py --help сборки 7.3.1.2.

Связанное

Нужен инженер? Разберу вашу ситуацию и скажу, что делать — по шагам, с проверками.

Обсудить задачу