@@ -19,14 +19,10 @@ Tower позволяет сделать service registry. Подробности
* Для этого типа инсталяции ставятся пакеты из файла `requirements/prod.txt`. Сейчас это утилита [alerta](http://docs.alerta.io/en/latest/)
* Также копируется файл для совместной работы supervisord и alerta
* Также патчится supervisord на предмет поддержки oom_score_adj на linux системах. Патч основан на https://github.com/Supervisor/supervisor/pull/754
Остальные варианты типов инсталяции не делают ничего дополнительного.
Обратите внимание, что при наличии правок в локальной директории при обновлении, обновление NOC повиснет на этапе `Pull NOC`. В таком случае нужно зайти на ноду и решить вопрос с локальными правками:
* Для начала имеет смысл остановить текущее обновление для этого находим в списке процессов `hg pull` и убиваем его.
* Выполняем либо
**`hg revert -a ; hg --clean` - полная отчистка текущий директории от локальных правок.
**`hg diff >/tmp/hg_diff.txt` - бекапим изменения. в временный файл. позже после деплоя восстанавливаем `hg import -f —no-commit /tmp/hg_diff.txt`
* Бывает, что этого недостаточно, и у вас есть правки которые попадают под категориюю `abort: untracked file in working directory differs from file in requested revision` - поступаем с файлом по своему разумению.
Для инсталяций типа eval и test локальные правки блокируют обновление. Локальные правки должны храниться в отдельной диреткории ../noc_custom. структура этого каталога должна повторять структуру в основном репозитарии. Локальные комимты для этих типов инсталяции будут отклонены.
Инсталяция типа develop после начальной инсталяци совсем не побновляет дерево исходных кодов. Только выполняет команду `git fetch origin`. В инсталяции этого типа предполгается что все дальнейшие работы будут выполняться администратором в ручную. Эта версия толерантно относится к переключению ветвей и накладыванию любых правок
**В**: На какую систему лучше всего ставить NOC ?
...
...
@@ -47,14 +43,14 @@ RHEL 7+, Debian, Ubuntu, CentOS и FreeBSD. Однако лучше всего
**В**: Что такое `Node` ?
**О**: В терминологии системы `нода` - это сервер на котором будет крутится часть сервисов системы. Например DB или web-сервер.
**О**: В терминологии системы `node` - это сервер на котором будет крутится часть сервисов системы. Например DB или web-сервер.
**В**: Как должна быть настроена нода ?
**В**: Как должна быть настроена `node` ?
**О**: На ноде должен быть:
**О**: На `node` должен быть:
* создан пользователь ansible
* пользователь ansible должен иметь возможность сделать `sudo -s`*без пароля*
* на ноде должен быть установлен python2
* на `node` должен быть установлен python2
**В**: Что делать с ошибкой `ERROR! SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", "unreachable"`?
...
...
@@ -70,7 +66,7 @@ RHEL 7+, Debian, Ubuntu, CentOS и FreeBSD. Однако лучше всего
**В**: Как должен быть настроен сервер tower ?
**О**: В целом конфигурация описана в Readme.md. Однако в подробностях процесс выглядит так:
**О**: В целом конфигурация описана в [Readme.md]. Однако в подробностях процесс выглядит так:
* Сам web сервис запускается из под пользователя tower. С консоли в простейшем случае, или через systemd (см. `contrib/systemd`)
* Через web интерфейс принимается команда Deploy. Она выполняется из-под пользователя tower и условно делает следующие команды:
```
...
...
@@ -79,7 +75,7 @@ RHEL 7+, Debian, Ubuntu, CentOS и FreeBSD. Однако лучше всего
где `NAME` это имя заданное в названии `Environment`. После задания переменных и начальной конфигурации системы можно вполне пользоваться консольными командами. А не нажимать кнопку в web-интерфейсе
где `NAME` это имя заданное в названии `Environment`. По умолчанию `NOC`. После задания переменных и начальной конфигурации системы можно вполне пользоваться консольными командами, а не нажимать кнопку в web-интерфейсе
**В**: В чем еще преимущества использования консоли вместо web ?