NOC Project установка

NOC Project установка - первая часть материала по NOC Project, здесь будут рассмотрены основные моменты связанные с установкой.

Предисловие

Когда в небольшой компании десяток управляемых коммутаторов и 1 маршрутизатор, то с ними нет проблем. Несложно держать всю основную информацию об этих устройствах в голове, их конфиги - в файлах Блокнота. Раз в квартал, даже реже (Zabbix тут в помощь) можно подсоединиться, посмотреть что происходить на каждом устройстве. Но что делать если таких устройств десятки? А если пару сотен или больше? Плюс когда количество сетевых устройств исчисляется сотнями, то значит есть и другие сотрудники, которые с этими железками работают. Нужно как-то отслеживать запланированные и незапланированные действия с железками. Возникает необходимость со всем этим хозяйством как-то управляться и нужен заточенный под это софт. Таким софтом является NOC.

Информация собиралась (больше относится ко 2 части, хотя для этой тоже верно) в течение нескольких месяцев в основном методом многократных проб и ошибок, не ручаюсь за её корректность - это исключительно мой опыт и мой взгляд на продукт.

Очень помогло чтение канала NOC на Telegram, сразу избавлю от иллюзий - никто там вам постоянно разжёвывать не будет, но иногда могут здорово помочь/подсказать и также непрерывно идёт обсуждение и обмен различной полезной инфой.

С другой стороны информации в интернете о NOC очень мало - её попросту нету, попадается или старьё с развёртыванием ещё без NOC Tower, или же очень скудные, обрывочные сведения.

Альтернатива для CISCO

Если железок не очень много (десятки) и все они CISCO, то есть пара вариантов:

  • Можно кидать конфиги на внешний TFTP с помощью команды глобальной конфигурации archive. В качестве TFTP сервера удобно использовать tftpd32 service edition, а примерная конфигурация на устройстве следующая:
archive
 log config
  logging enable
  logging persistent reload
  hidekeys
 path tftp://10.20.0.100/$H-$T.cfg
 write-memory
  • Можно использовать старый, но боевой CISCO Network Assistant (CNA). Он предлагает не так много функций, но полезен и бесплатен для скачивания. Хорошее обзорное видео. Минус - работает через HTTP:

NOC Project установка

Для полноценной работы в GUI на железки нужно установить Security Device Manager (SDM), тогда HTTP сеанс выглядит так:

NOC Project установка

Или можно использовать CISCO Configuration Professional. CCP в виде установочного пакета для Windows не обновлялось очень давно и последняя довольно-таки старая версия это 2.8. Работает оно неспешно, требует Java версии 6, танцев вокруг Java и Adobe Flash Player. Новые версии CCP устанавливаются уже прямо на железку и запускаются оттуда.

Лично мне такое графическое счастье не нужно, удобнее через CLI.

Возможно есть и какие-то более новые приблуды. Для других вендоров — свои сборки ПО. Отличие NOC в том, что он мультивендорный. Это гигантский жирный плюс.

Предварительные сведения о NOC

NOC (Network's Operation Centers) — специализированная программная среда для работы с сетевыми устройствами, в первую очередь с коммутаторами и маршрутизаторами разных производителей, с большим количеством таких устройств в одной установке NOC.

Достоинства
  • Полностью бесплатное ПО;
  • Богатый функционал;
  • NOC активно, очень активно дорабатывается. Так за время моего знакомства с NOC версия продукта выросла с 15.05.1dev17713 до 15.05.1dev188++, то есть на 1000+ минорных подверсий (на настоящий момент, ноябрь 2017, версия отображается в другом формате) и некоторые вещи, которые изначально не работали - стали работать, хотя конечно далеко не все. В сентябре 2018 вышел релиз 18.1.
Неочевидные достоинства
  • Скорее всего, вне зависимости от желания, придётся познакомиться с регулярными выражениями ("регулярками", regexp) языка Python;
  • Возможность разрабатывать/дорабатывать скрипты под своё оборудование -  опять же придётся с большой вероятностью;
  • Баг-трекер куда можно скинуть обнаруженные ошибки в NOC, форум, канал Telegram;
  • Онлайн общение с  разработчиками и фанатами проекта.

Где вы такое ещё найдёте? 🙂

Недостатки
  • Документация разрабатывается, появились всплывающие подсказки для некоторых элементов Веба, но до совершенства пока далеко;
  • Раньше продукт постоянно подвергается значительной переработке, при каждой такой переработке жёстко страдал функционал, с последующими мелкими и большими фиксами, а процесс обновления после такой переработки превращался в танцы с бубном. Сейчас такого нет. Высокая стабильность деплоя и если появляются ошибки, то их оперативно убирают;
  • Составлять документацию довольно сложно: пока собираешь информацию — она успевает устаревать.
Функционал

Минимальным функционалом NOC является сбор конфига с устройств — этот функционал доступен для всех профилей, которые есть в NOC.

Наибольший функционал представлен для профилей CISCO, Qtech — тут автоматически будет собрана информация об интерфейсах устройства, найдены линки между устройствами, включая EtherChannel и отрисована топология сети с возможностью отображения STP, пропускной способности и загрузки линков. Плюс много других плюшек: есть выполнение команд сразу на группе устройств, есть поиск порта по маку, есть сбор заданных метрик с устройства и отрисовка их в Grafana, есть сбор метрик с интерфейса и срабатывание аларма при выходе значений за пороговые — много всего есть, знаю на текущий момент далеко не всё. Часть функционала, как например автоматический IPAM, пока не реализована и присутствует только номинально.

Структура NOC

Ранее существовали отдельные установки NOC. Если организация была большой, то требовалось поднять несколько экземпляров NOC, которые никак не были связаны между собой. Конфигурирование и обновление этих экземпляров вручную представляло собой трудоёмкую задачу. В дальнейшем схема развёртывания была изменена. Теперь добавлена NOC Tower, которая:

  • Централизованно хранит настройки;
  • Распространяет эти настройки на конечные инсталляции NOC — NOC Nodes.

Информация со страницы проекта:

NOC Tower это средство для автоматизации развёртывания NOC. Используется во всех новых версиях, с его появлением установка NOC без его использования не поддерживается.

Поэтому сейчас для установки NOC нужно поднять 1 инсталляцию NOC Tower, настроить её, затем поднять минимум 1 инсталляцию NOC Node и наконец, проверить связь между башней и нодой, перенести настройки с башни на ноду - деплой.

FAQ по теме.

Обновление ноды происходит также через деплой.

Tower может хранить разные настройки для разных нод. При необходимости внести изменения в настройки на нодах, сначала вносятся изменения в конфигурацию на башне, затем деплоем настройки заливаются на ноды, которые работают с данной конфигурацией.

Если всё сказанное не напугало и решили таки ставить NOC - готовьтесь морально к большой самостоятельной работе.

NOC Project установка

Присутствие на канале Telegram крайне рекомендуется, все новости поступают в первую очередь сюда.


Отслеживание изменений

Чтобы оперативно получать информацию об изменениях, нужно подписаться на Telegram-канал NOC Project News https://t.me/nocproject_news

Установка и настройка

NOC можно развернуть поверх разных дистрибутивов линухи (смотри FAQ  и ещё тут). По статистике с NOC канала Telegram более 40% предпочли использовать Debian в качестве платформы для NOC, поэтому все плюшки в первую очередь подгоняются под Debian. С чем сие связано непонятно, ИМХО рпссматриваю для продакшена CentOS 7 only.

Системные требования для NOC

Tower оптимально разворачивать в виртуальной машине (VM), рекомендую 2 ядра и 2048Mb памяти. Для Node требуется много больше ресурсов, зависит от количества обслуживаемых сетевых железок, рекомендуется от 6Gb памяти, при этом 50% уйдёт под MongoDB. Динамическую память для ноды лучше не использовать - давно заметил, что Linux как-то неверно работает с динамической памятью Hyper-V, отжирая всё что можно и не можно. Вобщем когда намечается установка для большого числа устройств лучше сразу планировать для ноды отдельный сервер или весьма жирную виртуалку, лучше всё же виртуалку — в связи со специфичностью ПО желательно всегда иметь возможность безболезненного отката на предыдущее состояние.

Из-за множества сервисов, которые должны работать слажено, нода очень требовательна к производительности сервера, даже можно сказать капризна. Так когда на RAID-массиве сервера виртуализации отвалился диск и скорость дисковых операций упала до 30-40Mb/s, начал отваливаться сервис MongoDB. При рестарте виртуальной машины он не мог запуститься, затем при запуске руками стартовал с третьего раза и через некоторое время опять падал. Загрузка ядер на этот момент не более 7-10% в пике. Веб ноды жёстко глючил, при этом виртуалка базы данных Zabbix, которая трудилась рядом на этом же сервере, на этом же дисковом массиве — работала исправно. При переносе vhdx на другой массив сервера, работоспособность восстановилась. Как только нода испытывает любые затыки в производительности, сразу в её работе что-нибудь отваливается — большая вероятность. Учитывайте этот момент.

Гипервизор

Для меня не существует гипервизоров кроме Hyper-V, поэтому все солюшены для него.

Доступ в интернет

Для работы ноды и башни им нужен доступ в интернет, башне для операции Pull, ноде для установки пакетов:

  • Локальный репозиторий для ноды не подойдёт, слишком много зависимостей;
  • Полноценную работу через прокси-сервер мне настроить не удалось;
  • Прямой доступ — дополнительная настройка не требуется;
  • Доступ для VMs Hyper-V через расшаривание другого подключения с прямым доступом в интернет — рассказано здесь

Новый подход к установке NOC

Готовые тестовые VMs башни и ноды под Hyper-V Windows 10 можно забрать здесь

Появилась новая башня, башня ставится легко и просто через Docker. Весь процесс установки теперь другой. Можно не заморачиваться с установкой и взять готовые VMs. В прошлый раз ошибся и выложил неимпортируемые машины, в этот раз (вроде) всё проверил. Версия конфигурации Hyper-V достаточно высока для других ОС — 8.3, но на Windows 10 последней версии должно импортнуться без проблем.

Подготовка VMs
  • CentOS 7 поддерживает VM 2 поколения с включённой безопасной загрузкой:

NOC Project установкаИнструкций по установке CentOS очень много, их несложно найти в интернете, здесь кратко:

  • На закладке Installation Destination — автоматическое разбиение диска, если хочется заморочиться, то в FAQ есть пример ручного разбиения;
  • На закладке Network&Host Name нужно правильно указать Host name и выполнить настройку IPv4 - поменять с Automatic(DHCP) на Manual, через кнопку Add добавить нужное значение, указать DNS. После чего подключение нужно включить — On;

Если забыли включить подключение:

vi /etc/sysconfig/network-scripts/ifcfg-eth0
...
ONBOOT=yes
  • На закладке Security Policy применить профиль Common Profile for General-Purpose Systems;
  • Kdump лучше выключить.

NOC Project установка

У CentOS сразу есть предустановленный SSH и включён вход рута.

Иногда вход по SSH очень долгий, чтобы ускорить:

# vim /etc/ssh/sshd_config

UseDNS no
...
GSSAPIAuthentication no

# service sshd restart

После установки можно пропинговать шлюз и какой-нибудь сайт в интернете для проверки:

ping -c 5 192.168.137.1
ping -c 5 gmail.com

Последнее тут, нужно установить репозиторий (и на ноду, и на башню):

You will likely need the EPEL repositories installed:

# yum install -y epel-release

Порядок настройки CentOS для ноды
[root@node1 ~]# yum install python python-devel python-yaml python-cffi python-cryptography python-markupsafe yaml-cpp-devel libffi libffi-devel openssl-devel gcc sudo dbus vim

Затем создаём пользователя ansible:

[root@node1 ~]# useradd -d /home/ansible -s /bin/bash -m ansible

Задаём ему пароль:

[root@node1 ~]# passwd ansible
Changing password for user ansible.
New password:

Редактируем файл sudoers:

[root@node1 ~]# vi /etc/sudoers

i - переход в режим редактирования

ansible ALL=(ALL) NOPASSWD:ALL - добавляем

Esc - выход из режима редактирования
:wq! - сохраняем файл

Должно получиться так:

...
Allow root to run any commands anywhere
root ALL=(ALL) ALL
ansible ALL=(ALL) NOPASSWD:ALL
## Allows members of the 'sys' group to run networking, software,
...

Создаём контрольную точку VM.


Порядок настройки CentOS для башни
[root@tower ~]# yum install python-virtualenv python python-devel python-yaml python-cffi python-cryptography python-markupsafe yaml-cpp-devel libffi libffi-devel openssl-devel gcc sudo vim

Для башни дополнительно нужно установить python-pip :

[root@tower ~]# yum install python34-pip
[root@tower ~]# easy_install-3.4 pip

Выключаем SELINUX:

[root@tower ~]# vi /etc/selinux/config

...
# disabled - No SELinux policy is loaded.
SELINUX=enforcing - меняем на disabled
# SELINUXTYPE= can take one of three two values:
...

Shift-zz - сохранить файл

Перезагружаем VM.

Затем создаём пользователя ansible:

[root@tower ~]# useradd -d /home/ansible -s /bin/bash -m ansible

Задаём ему пароль (такой же как в ноде):

[root@tower ~]# passwd ansible
Changing password for user ansible.
New password:

Создаём пользователя tower:

[root@tower ~]# groupadd tower
[root@tower ~]# useradd -d /home/tower -g tower -s /bin/bash -m tower

Генерим ему ключ (3 раза нажимаем Enter):

[root@tower ~]# su - tower -c "ssh-keygen -t rsa -b 4096"

Generating public/private rsa key pair.
Enter file in which to save the key (/home/tower/.ssh/id_rsa):
Created directory '/home/tower/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tower/.ssh/id_rsa.
Your public key has been saved in /home/tower/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:tmej+Jfa7ag3vzrPC6IS5ihWUBWMr6p/Rc13m4GDnfo tower@tower.local
The key's randomart image is:
+---[RSA 4096]----+
| +o. |
| o . |
| . . o o o |
| . .. + * o |
| . .. So o + |
| oo .... o |
| o+ o o.=. |
|.o. + o *E* |
|+o.. .o.==+BOo |
+----[SHA256]-----+

[root@tower ~]#

Прописываем хост ноды на башне:

[root@tower ~]# vi /etc/hosts

i - переход в режим редактирования

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.137.155 node1 node1.local

Esc - выход из режима редактирования 
:wq! - сохраняем файл

Теперь нужно из под пользователя tower скопировать ключ, для этого нужно будет ввести пароль пользователя ansible на ноде:

[root@tower ~]# su tower

[tower@tower root]$ ssh-copy-id -i /home/tower/.ssh/id_rsa.pub ansible@node1

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/tower/.ssh/id_rsa.pub"
The authenticity of host 'node1 (192.168.137.155)' can't be established.
ECDSA key fingerprint is SHA256:EqR98GlXzjlZwfgKAJz321L5Nd9/L9XHZ6fZTxaxJzw.
ECDSA key fingerprint is MD5:5b:9a:07:dc:39:0a:2f:8a:d1:f1:f4:57:2c:dd:bc:c5.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
ansible@node1's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'ansible@node1'"
and check to make sure that only the key(s) you wanted were added.

Теперь возвращаемся к пользователю root и снова проверяем подключение к ноде:

[tower@tower root]$ exit

exit

[root@tower ~]# su - tower -c "ssh ansible@node1"
[ansible@node1 ~]$ sudo -s
[root@node1 ansible]# python

Python 2.7.5 (default, Aug 4 2017, 00:39:18)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

Ctrl-d

[root@node1 ansible]# exit

exit

[ansible@node1 ~]$ exit

logout
Connection to node1 closed.

[root@tower ~]#

Это важный шаг и никаких ошибок тут быть не должно.


Новая башня

Новая башня ожидалась уже давно и появилась в конце марта 2018. По разведданным старая башня будет поддерживаться до 01.06.2018. Теперь башня живёт Docker'е. Как поставить подробно рассказано в 3 файлах:

  1. Установка:  https://code.getnoc.com/noc/tower/blob/master/Readme.md
  2. Обновление:  https://code.getnoc.com/noc/tower/blob/master/UPDATING.md
  3. Миграция со старой башни: https://code.getnoc.com/noc/tower/blob/master/docs/migrate_dc.md
Миграция старой башни/установка новой

Собираем воедино: итак, у меня старая башня, хочу новую. Или же установка новой башни  с нуля.

Установка докера
# curl https://get.docker.com | sudo sh 
# systemctl start docker

Установка docker-compose
# pip install docker-compose
# mkdir /etc/docker-compose/tower -p

Установка башни
# curl https://code.getnoc.com/noc/tower/raw/master/docker-compose.yml > /etc/docker-compose/tower/docker-compose.yml
# cd /etc/docker-compose/tower
# docker-compose up -d  если башня актуальна, то выводится соответствующее сообщение

Проверяем файл настроек docker-compose:

# vim /etc/docker-compose/tower/docker-compose.yml

Меняем название хоста для порядка и Environment, как он был заведён в башне, для возможности запуска ansible из командной строки. Не знаю пригодится последнее или нет, но если понадобится чтобы не ломать потом голову (а ещё лучше при заведении не менять название для Environment и оставить по умолчанию NOC):

hostname: tower
..
NOC_ENV: NOC1
...
ANSIBLE_ROLES_PATH: /opt/tower/var/tower/playbooks/NOC1/additional_roles:/opt/tower/var/tower/playbooks/NOC1/system_roles:/opt/tower/var/tower/playbooks/NOC1/noc_roles

После заливки башни через curl, эти настройки затираются, их нужно добавлять снова.

Также чтобы сервис docker стартовал автоматом:

systemctl enable docker

Сама башня стартует теперь вместе с сервисом. Команды докера:

# doker ps — список контейнеров
# docker stop/start имя_контейнера (tower_tower_1)
# systemctl daemon-reload 
# systemctl restart docker.service

Вот теперь конкретно для миграции: для того чтобы новая башня могла подключится к ноде, переносим ключи SSH:

# cp /home/tower/.ssh/* /opt/tower/var/tower/data/deploy_keys - ключи там уже есть, перезаписываем

Рестартуем для проверки VM, заходим в веб башни, Pull, проверяем сервисы.

Надо сказать, что все настройки и сервисы с моей старой башни нормально подхватились, как и говорилось в мануале.

Сохраняем сервисы, дополнительные сервисы по умолчанию, затем пробный Deploy. Не с 1 раза, но деплой таки доехал до конца.

NOC Project установка

Run post deploy tests отключил, так как на моей тестовой тормозящей системе сервисы просто не успевают подняться в заданный промежуток времени, выдавая ошибку:

TASK [check if noc services are down]
fatal: [node1]: FAILED! => {} 

MSG: 

Timeout (12s) waiting for privilege escalation prompt

Обновление башни (происходит по протоколу HTTPS с сайта registry.getnoc.com ):

# cd /etc/docker-compose/tower
# docker-compose pull
# docker-compose up -d - если версия башни актуальна, то выводится соответствующее сообщение

Текущая версия башни 0.4.4.

Прокси-сервер

С настройкой прокси разобраться не удалось. По факту и нода, и башня требуют прямой доступ в интернет. Пишу то, что удалось выяснить.

Общая настройка прокси рассказана тут. Продублирую

  • Для Yum:
# vi /etc/yum.conf
proxy=http://192.168.137.1:3128
  • Системный прокси, нужно добавить локальные адреса, которые будут открываться без прокси, ускоряет некоторые шаги деплоя:
# vi /etc/profile
MY_PROXY_URL="http://ServerProxy:8080/"
HTTP_PROXY=$MY_PROXY_URL
HTTPS_PROXY=$MY_PROXY_URL
FTP_PROXY=$MY_PROXY_URL
http_proxy=$MY_PROXY_URL
https_proxy=$MY_PROXY_URL
ftp_proxy=$MY_PROXY_URL
no_proxy="localhost, 127.0.0.1, ..."
export HTTP_PROXY HTTPS_PROXY FTP_PROXY http_proxy https_proxy ftp_proxy no_proxy
Нода

Метод деплоя для ноды прописан в Environment: git+https://github.com/nocproject/ansible_deploy@microservices. Git может работать через HTTP или SSH, или по собственному протоколу, поэтому помимо системного прокси ему нужен свой собственный прокси:

# git config --global http-proxy ip_прокси:порт
# git config --global https-proxy ip_прокси:порт

Если этого не сделать, то деплой вставал на тасках, где использовался GIT.

После всех этих манипуляций деплой встаёт на ~280 шаге, открывая сессию по 443 порту к python.pub, на этой же машине с прямым доступом в интернет деплой доезжает до конца. Видимо нужно где-то ещё прокси подпихнуть, но что и где уже и не знаю.

Убрать прокси для Git:

# git config --global --unset http.proxy 
# git config --global --unset https.proxy

Проверить настройки Git:

# git config --global --list
# git config --local --list

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

Башня

Как выяснилось, для башни этих настроек тоже недостаточно, Pull в вебе не подгружает чего нужно (хотя заканчивается со статусом Complete), при создании дополнительных сервисов они тоже не погружаются. Нужен прямой доступ в интернет.

Нужно прописать прокси для Docker, как сделать сказано здесь, дублирую:

# mkdir -p /etc/systemd/system/docker.service.d
# vi /etc/systemd/system/docker.service.d/proxy.conf

[Service]
Environment="HTTP_PROXY=http://myproxy.hostname:8080"
Environment="HTTPS_PROXY=http://myproxy.hostname:8080/"
Environment="NO_PROXY="localhost,127.0.0.1,..."

# systemctl daemon-reload
# systemctl restart docker.service

Если этого не сделать, то Pull не будет работать ни через CLI, ни в Вебе башни. Кроме этого в прокси должен быть разрешён адрес: cdn.getnoc.com.

После всех этих манипуляций Pull в вебе башни не отрабатывал. Решилось прописыванием внешних DNS на башне и так как башня (и нода) получают адрес по DHCP, то чтобы значения каждый раз при инициализации сети не перезаписывались, то:

# vim /etc/resolv.conf
nameserver 8.8.8.8 
nameserver 8.8.4.4

# chattr +i /etc/resolv.conf

Кроме этого позже проявилась проблема, деплой вис на 20 шаге с ошибкой:

TASK [goss : Get goss release] 00:20

fatal: [n5000-noc-node1 -> 127.0.0.1]: FAILED! => {
    "changed": false
}

MSG:
Failed to connect to github.com at port 443: [Errno -3] Try again

Вылечилось предоставлением башне прямого доступа в интернет.

Траблшутинг
  • При работе через прокси не идёт Pull на башне, нужно прописать (как уже говорил) прокси для Docker'а;
  • Траблшутинг работы прокси проще организовать так:
netstat -pA inet

И смотреть что/куда подключается (необходимо установить пакет net-tools )

  • Зависает деплой на шаге TASK [telegraf : Install CentOS system packages]. На самом деле не устанавливаются пакеты по таймауту с ошибкой 12, хотя репозиторий доступен. Это можно посмотреть, если запустить установку пакета вручную. Одна из причин, что к провайдеру настроен IPv6, соответственно он имеет приоритет, а на VMs настройки IPv6 нет. Вариант 1 вырубить IPv6 к провайдеру, вариант 2 отключить IPv6 в VMs, вариант 3 настроить IPv6 для VMs.

Вариант 2:

vim /etc/sysctl.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

sysctl -p
systemctl restart network
  • Удалить сертификаты SSH для пользователя tower на башне после пересоздания ноды с тем же именем:
[tower@tower root]$ cd ~
[tower@tower ~]$ rm .ssh/known_hosts
  • Работа с файрволом:
# systemctl mask firewalld - отключить службу 
# systemctl stop firewalld - остановить
# systemctl unmask firewalld - включить
# systemctl start firewalld - запустить

# systemctl status firewalld - статус
# firewall-cmd --state - или так
  • Поиск файла:
find / -name имя_файла
  • Смена имени хоста CentOS 7:
# hostnamectl set-hostname New_HostName
# scarletctl disable set-hostname
# systemctl restart systemd-hostnamed - чтобы все изменения вступили в силу

hostnamectl status - проверка

Настройка Веба башни

Если всё сделано правильно, то подключаемся к Вебу башни, у меня это: http://192.168.137.156:8888/

Вводим логин admin пароль admin.

Что делать если Веб башни недоступен 

Отключить антивирус и файрвол компьютера, с которого производится подключение к башне, отключить встроенный фаервол CentOS на башне (на ноде должен быть включён):

# systemctl stop firewalld
# systemctl mask firewalld

Возможно придется немного попрыгать с бубном, это нормальная ситуация для NOC — привыкайте 🙂

Действия в башне

Для новой башни многие значения предустановлены, нужно проверить и там, где надо, поставить свои значения. В основном это IP и имя ноды. Для старой башни описание оставляю.

Попали в Веб башни, добавляем новую Environments:

NOC Project установка

Для старой башни примерно так и сохраняем:

NOC Project установка

  • Имя - буквы и цифры;
  • Ветка - git_migrate (подробнее тут);
  • Хост - IP ноды, можно указать имя хоста ноды, но тогда адрес https://node1 должен быть разрешим, иначе будут проблемы с Grafana;
  • Тип - Evaluation чтобы можно было править существуюшие скрипты и добавлять свои.

Для новой отличается (название лучше оставить по умолчанию NOC):

NOC Project установка

Добавляем Дата-центр, тут для новой башни также, как и для старой:

NOC Project установка

Пул оставляем как есть - default. После деплоя будет 2 пула - default и P0001. P0001 служебный, на нём устройства не опрашиваются через activator. Опять же для старой и новой башен — одинаково.

Добавляем ноду для старой башни:

NOC Project установка

  • Имя для хоста ноды и Имя в разделе Nodes башни должны совпадать.

Для новой башни чуть по-другому:

NOC Project установка

Сервисы пока не определены, чтобы их заполнить нажимаем Pull, это занимает некоторое время:

NOC Project установка

Для новой башни: Pull в вебе сначала лезет на github.com, потом на registry.getnoc.com. После пула и заполнения сервисов их нужно настроить.

Какие баги тут наблюдались?

  • Башня не подгружает через Pull актуальный список сервисов. Лечится удалением Environment и заведением его снова. Помогает также избавиться от сервисов, которые уже выведены из использования (omap ). Так с башней версии 0.4.4 сервисы datastream и selfmon упорно отсутствовали в списке;
  • При неактуальной версии башни и неактуальном списке сервисов деплой проходит нормально и вроде всё ok, но на самом деле требования версий ПО уже улетели далеко вперед и когда сервисы наконец-то актуализированы, то деплой валится с требованием обновить и то, и это.
Настройка сервисов

Теперь очень важный пункт — настройка сервисов. При неправильной настройке не будет даже проходить деплой, не говоря уже о работе ноды.

В последней версии башни настройки сервисов по умолчанию выставлены нормально. В большинстве случаев каких-то специальных настроек для сервиса делать не нужно. Количество бекап-экземпляров (на зелёном поле) — по нулям, кроме тех, где уже прописано другое значение. При выставлении количества экземпляров для сервиса не забывайте нажать кнопку Save.

Пример. Сервис Activator — Scale Recommendations: At least two per core on node. 

Global:

bi - 2 
card - 2
ch_datasource - 1
chwriter - 1
clickhouse
consul - 1 (для новой башни: параметр bootstrap)
consul-template
datastream - 1 (требует MongoDB версии 3.6)
escalator - 1
goss - добавлен после появления новой башни
grafana
grafanads - 2
login - 2
mailsender - 1 (заполнить реквизиты)
mib - 1
mongod - для новой башни: параметры server, file, wiredTiger) версия 3.6 (обновление версии с 3.4 до 3.6 поставится автоматом при деплое, только если версия была изначально 3.4 при развёртывании NOC; если же было обновление с 3.2 до 3.4, то не поставится и нужно будет делать руками, рассказано дальше
mrt - 2
nbi - 2
nginx - отметить чекбоксы: редирект на https, самоподписанный сертификат
noc - Noc version: release-18.1 - текущий релиз, далее он будет меняться. Тут подробнее: Есть ветка релиза, туда вливаются багфиксы. И периодически на ветке выставляются теги (18.1a1). Со-но если нужно зафиксировать состояние, то пользуем теги (но их надо менять по мере навешивания новых). А если просто нужны последние багфиксы, то используем релиз (release-18.1). Далее появятся новые релизы и новые теги
nsqd 
nsqlookupd
postgres - актуальная версия 9.6, нужно указать (для новой башни: параметр master; для старой башни: команда запуска башни с параметром POSTGRES_VERSION имеет приоритет над этим значением)
sae - 2
scheduler - 1
selfmon - 1
tgsender - 1 (подробнее во 2 части, должен быть прописан токен или отключаем)
web - 2

Default:

activator - 2 на ядро
classifier - 2
correlator - 1
discovery - 2 (1 резервный)
ping - 4 (1 резервный)
syslogcollector - 1
trapcollector - 1
  • trapcollector и syslogcollector нужно оставить как есть: 0.0.0.0:162 и 0.0.0.0:514 — нули означают прослушивание на всех интерфейсах или указать интерфейс, если у ноды их несколько.

Additional services (включаются на отдельной закладке, добавляют свои сервисы в список Global):

pgbouncer - 1 (у меня много железок)
Сервис telegraf переведён на prometheus, influx упразднён. Как это теперь настраивать непонятно. При всех танцах сервис telegraf упорно хочет influx (которого нет) и не стартует. Либо же стартует, но всё тот же influx и ошибка плагина influx.

Если всё же заниматься с Telegraf и пароль админа отличается от стандартного, то его нужно подправить в файле /etc/telegraf/telegraf.d/fm-monitor.conf, поменяв хеш для дефолтной связки admin:admin на хеш для admin:new_password (вычислить хеш можно тут).

После выставления количества сервисов и сохранения нужно нажать F5 и ещё раз сверить их количество. В новой баше это работает чётко, в старой же количество сервисов сохранялось через раз.

Значения по умолчанию подойдут для небольших установок. Например небольшой офис и несколько branch-офисов, где-то 50-60 железок. Если железок ощутимо больше, то сервисов будет не хватать. Нужно смотреть по работе скриптов, запуская их вручную. Само-собой разумеющееся действия при активной работе с нодой. Скрипты сами скажут чего не хватает. В первую очередь добавлять sae, discovery и конечно activator.

После появления сервиса datastream и его установки для правильной работы сервисов (ping, syslog, trap ) нужно однократно выполнить на ноде:

# cd /opt/noc
# ./noc fix apply fix_rebuild_datastream

Также полезные команды на ноде из директории /opt/noc:

./noc crashinfo list — общий список крашей
./noc crashinfo view UID — расширенный вывод по конкретному крашу, UID взять из list

Тюнинг ноды и разбор ошибок, а они будут — дело вдумчивое и неспешное. Если на работающей ноде запустить service noc status, то вот они сервисы, которые выставляли в башне. Хорошо когда есть чёткое понимание какой сервис чего делает.


Деплой

Стандартный деплой это Run pre deploy checks, Install Everything, Run post deploy tests.

Run pre deploy checks

Если предеплой выдаёт ошибки, то нужно с ними разбираться. Так на старой инсталляции было найдено 3 ошибки:

  1. Нет поддержки SSE 4.2, необходимой для работы ClickHouse — вылечилось снятием галки с чекбокса в свойствах VM Hyper-V Выполнить перенос на физический компьютер с другой версией процессора. После этого сразу заработал сбор метрик, которые просматриваются в Grafana;
  2. Было предложено перевести сервис Consul в bootstrap;
  3. Было предложено снести старый Postgre 9.4, так как 9.6 тоже был уже установлен и использовался.

После появления сервиса datastream ещё 2:

  1. Было предложено обновить монгу до 3.6;
  2. Было предложено обновить консул (описание как обновить):
MSG: 
Consul installed version not the same as requered. You have to update it. 
Requested version = 1.2.2 
Installed version = 0.9.3

Обновление монги с 3.4 на 3.6: сначала прочитать чего говорят на официальном сайте, а именно нужно обновить набор фич до 3.4: The 3.4 instance must have featureCompatibilityVersion set to 3.4. Делаем:

# mongo -u root -p noc --authenticationDatabase admin

noc:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : "3.2", "ok" : 1 }
noc:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )
{ "ok" : 1 }

Далее выставляем в башне, в сервисе монги версию 3.6 и запускаем деплой. Монго 3.6 успешно устанавливается:

# mongod --version
db version v3.6.7

После чего включаем набор фич 3.6:

# mongo -u root -p noc --authenticationDatabase admin

noc:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.4" }, "ok" : 1 }
noc:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )
{ "ok" : 1 }
noc:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.6" }, "ok" : 1 }

Всё, монга 3.6 установлена.

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

Первичный деплой
  • Первичный деплой насчитывает ~450++ шагов (зависит от количества экземпляров сервисов и настроек) и идёт достаточно долго (5-10 минут на быстрых системах и ~15 минут на медленных) — это нормально. А вот если деплой сильно долго задумался на каком-то шаге — скорее всего будет ошибка. Последующие деплои проходят гораздо быстрее (после переезда на git среднее время и количество шагов деплоя выросли):

NOC Project установка

  • Важно чтобы во время деплоя VM ноды имела подключение к интернету;
  • Удачный деплой заканчивается со статусом Complete, с неудачным сложнее - лучше ориентироваться по цифрам снизу, в конце лога деплоя;
  • Некоторое время назад (до новой башни) при деплое на красном поле ошибок отображались цифры со знаком минус, это ничего страшного и относится к варнингам для сервисов, которые по нулям. Каждый такой варнинг в логе деплоя добавляет единичку:
skipping: [node1] 
 [WARNING]: Could not match supplied host pattern, ignoring: svc-haproxy

PLAY [haproxy tasks]01:28

skipping: no hosts matched
 [WARNING]: Could not match supplied host pattern, ignoring: svc-keepalived

NOC Project установка

С переездом на новую башню вроде эта проблема исчезла, оставляю на всякий пожарный.

Очень может быть, что с 1 раза деплой не взлетит, здесь тоже есть элемент танца с бубном.

  • Раньше разработчики предупреждали о нежелательности деплоя с вечера четверга по утро понедельника, связано было со скидыванием в конце недели наработок за неделю в "общий котёл" с последующим непредсказуемым эффектом. Сейчас такого нет, мерж новых веток идёт постоянно, но я по-старинке в конце недели не обновляюсь, пару раз попадал;
  • Пред очередным деплоем лучше прочитать NOC канал Telegram и убедиться в том, что не было предупреждения не обновляться;
  • Перед обновлением обязательно нужна контрольная точка VM ноды для возможного отката.
Пример

Для написания этой статьи (конец 2017) решил развернуть ещё 1 тестовую инсталляцию на CentOS, все проверил и в результате при деплое получил ошибку установки Grafana Datasource:

NOC Project установка

А при переходе по адресу https://192.168.137.155/ui/grafana/api/datasources

Server side error Failed to create user specified in auth proxy header

Идём разбираться с Grafana. После глубокого сна, просмотра сериала и поисков в интернете найдена следующая информация - это известная проблема для Grafana 4.5.1 - 4.5.2, проверяем:

[root@node1 ~]# rpm -qa | grep grafa
grafana-4.5.2-1.x86_64

Накатываем свежую версию Grafana через репозиторий, как описано тут, снова проверяем:

[root@node1 ~]# rpm -qa | grep grafa
grafana-4.6.1-1.x86_64

На что обратить внимание при деплое

Нормальная ситуация когда последующие деплои, после изменения каких-то настроек для сервисов в башне, проходят штатно. Такой механизм работы и будет в дальнейшем уже в продакшене.

Примерно с 16.11.2017 при деплое на ветке Evaluation проверяется директория /opt/noc на новые и на изменённые файлы. При наличии таковых деплой заканчивается с ошибкой.

cd /opt/noc
git status - посмотреть новые и изменённые файлы

Изменённые скрипты трогать не надо. Ненужные файлы, созданные в процессе работы, надо удалить:

git rm -f имя_файла

Новые файлы надо добавить (скорее всего это будут директории с профилями, созданными вручную):

git add имя_файла

После этого нужно выполнить команду:

git stash

Директория /opt/noc окажется чистой, правленные и рукописные скрипты при этом не потеряются и будут сохранены:

NOC Project установка

После деплоя нужно будет выполнить:

git stash pop

Все правки, которые были  до команды git stash — появятся вновь в CLI. Затем рестартануть сервис нока и правленные скрипты появятся в Веб.

Пример
[root@n5000-noc-node1 noc]# git status
# On branch microservices
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: sa/profiles/Brocade/CER/get_mac_address_table.py
# modified: sa/profiles/Brocade/CER/get_version.py
# modified: sa/profiles/HP/1910/get_interfaces.py
# modified: sa/profiles/HP/1910/get_portchannel.py
# modified: sa/profiles/HP/1910/get_version.py
# modified: sa/profiles/Qtech/QSW/get_interface_status.py
# modified: sa/profiles/Qtech/QSW/get_interfaces.py
# modified: sa/profiles/Qtech/QSW/get_switchport.py
# modified: sa/profiles/Qtech/QSW2800/__init__.py
# modified: sa/profiles/Qtech/QSW2800/get_mac_address_table.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sa/profiles/AlliedTelesis/X600/
# sa/profiles/Arlan/
# sa/profiles/Dionis/
# sa/profiles/Qtech/QSW/get_portchannel.py
# test.py
no changes added to commit (use "git add" and/or "git commit -a")
[root@n5000-noc-node1 noc]#

Чтобы лучше понимать данный процесс работы с Git полезно прочесть это. Здесь разбираются и другие возможности/опции при работе с Git:

* 'git add --ignore-removal <pathspec>', which is the current default, ignores paths you removed from your working tree.
* 'git add --all (-A) <pathspec>' will let you also record the removals.
...

Если правки побились и не восстанавливаются, возможно поможет эта информация.

Помимо полного деплоя — "установить всё" есть и другие возможности. В большинстве случаях для обновления нужно выбрать "обновить источники, быстрый рестарт", хотя на канале Telegram посоветовали обновляться всегда через Install Everything.

Расположение в башне скриптов Playbook, может кому-то пригодится:

/opt/tower/var/tower/playbooks/NOC1/ — где NOC1 - название Environment как заводилось в башне, дальше по ролям, в папке роли есть папка tasks, в ней main.yml с шагами деплоя для данной роли. Всё структурировано и разнесено, множественные обращения к внешним скриптам,
но разобраться можно. 

Типа пример: У меня зависает деплой на шаге TASK [noc : Fetch changes from upstream], нужно получить что конкретно делается на этом шаге. Раз noc, то иду /opt/tower/var/tower/playbooks/NOC1/noc_roles/noc/tasks смотрю main.yml, такого шага там нет, тогда смотрю какой был предыдущий шаг в логе деплоя. Это TASK [noc : Create NOC user], опять смотрю в main.yml такой шаг есть, после него шаг name: Include {{install_method}} install method. Смотрю в логе деплоя какой у меня метод, это git. С учетом  include_tasks: "{{install_method}}.yml" закрываю main.yml, вижу рядом в той же папке git.yml. Открываю его:
...
name: Fetch changes from upstream
command: git fetch origin
args:
chdir: "{{noc_root}}"
environment:
https_proxy: "{{http_proxy}}"
register: git_pill_status
changed_when: "'Already up-to-date.' not in git_pill_status.stdout"
when: noc_env_type == 'dev'
...
Примерно понимаю, что нужно разбираться с прокси. Как-то так..

Как ещё можно контролировать обновление ноды? Уже была упомянута очень полезная команда git:

cd /opt/noc

git show - текущий статус обновлений, полезно сверять с текущими мержами и тогда сразу понятно какие обновления у тебя уже есть, каких нету https://code.getnoc.com/noc/noc/merge_requests?scope=all&utf8=✓&state=merged

Как часто обновлять ноду - решайте сами, но помните, что игнорирование обновления NOC в течение длительного времени (месяц-два) может привести к тому, что без бубна уже обновиться не получиться. Связано опять же с нелинейностью процесса разработки/доработки.

Правки скриптов

Все локальные правки нужно вынести в /opt/noc_custom/:

There are local modifications to /opt/noc directory. Local modification have to be placed to /opt/noc_custom/ directory.

Как это сделать? Создать папку /opt/noc_custom/ и внутри неё структуру вложенности такую же как и в основной папке /opt/noc/. Положить в каждую папку этой структуры пустышку __init__.py. Перенести все файлы профиля в /opt/noc_custom/. В основной папке профилей оставить пустую папку профиля с __init__.py внутри неё. Не разобрался пока как это правильно сделать. У меня NOC ведёт себя нестабильно после данных манипуляций. Возможно что-то делаю неправильно. С этим предстоит разобраться.


Веб ноды

После удачного деплоя нужно перейти по адресу ноды, у меня это https://192.168.137.155

Вводим логин admin, пароль admin и наблюдаем такую картинку:

NOC Project установка

Это и нужно получить в данной части. Далее очень желательно ознакомиться со всеми ресурсами, указанными на стартовой странице.


Общение на NOC канале Telegram

При общении на канале соблюдайте правила:

  • Не надо вываливать лог ошибки в чат, для этого есть сайт https://pastebin.com/ или https://paste.ee. Вставляете там лог ошибки, формируете запись и уже ссылку на запись — в чат. Желательно зарегистрироваться на этих сайтах при работе  с ними, это даст возможность контролировать свои записи;
  • Пользуетесь поиском по каналу. Если возникла  проблема, то с большой вероятностью решение этой проблемы уже обсуждалось, возможно даже неоднократно;
  • Для найденных ошибок, а также для своих хотелок от NOC есть баг-трекер: https://code.getnoc.com/noc/noc/issues — открываете новую issue и пишите там что вам потребно. После выполнения заявки не забывайте её закрыть.

Наcтройка сетевых устройств

Последнее, наверное, о чём тут нужно сказать.

Функционал каждого профиля SA в NOC реализован через набор скриптов, чем больше скриптов — тем больше функционала. Скрипт отрабатывает:

  • Через CLI: происходит подключение к устройству (SSH/Telnet), выполняется команда, результат выполнения команды считывается;
  • Через SNMP: выполняется запрос на устройство.

Некоторые скрипты работают только через SNMP, некоторые только через CLI, но в большинстве скриптов присутствует код и для CLI, и для SNMP. Раньше всегда первым отрабатывал SNMP, а CLI уже в случае неудачи, на данный момент после порядок определяется настройками на ноде (в записи MO, в профиле объекта).

Поэтому предварительно должны быть выполнена необходимая настройка SSH и SNMP на устройствах. Если ещё не "на ты" с SNMP, то рекомендую ознакомится со статьёй Настройка SNMP. Настройки привожу кратко на примере устройства CISCO.

Настройка SSH
Router(config)#ip domain-name cisco.lab
Router(config)#crypto key generate rsa
[1024]
Router(config)#ip ssh version 2
Router(config)#username admin privilege 15 secret 5 password_ssh
Router(config)#line vty 0 4
Router(config-line)#transport unput ssh
Router(config-line)#login local
Router(config-line)#end
Router#wr

Для SSH подключения будет создан пользователь admin с паролем password_ssh, подключаться можно через любой интерфейс (для коммутатора всё тоже самое, только линий VTY скорее всего будет 15 — vty 0 15 и нужно будет задать IP SVI для той VLAN, через которую будет происходить SSH соединение).

Настройка SNMP
Router(config)#ip access-list standard SNMP_ACL
Router(config-std-nacl)#permit 192.168.137.151
Router(config-std-nacl)#exit
Router(config)#snmp-server community NOC rw SNMP_ACL
Router(config)#snmp-server host 192.168.137.151 version 2c NOC

Возможно для некоторых устройств ACL нужно будет задать как access-list 1 permit 192.168.137.151 и тогда запись сообщества будет:

Router(config)#snmp-server community NOC rw 1

Тестовый NOC в домашних условиях

Когда NOC переведён в продакшен, то это сильно ограничивает возможности его настройки и эксперименты с ним по понятной причине. Появляется необходимость в тестовой инсталляции. Разворачивание тестовой инсталляции на предприятии ничем не отличается от разворачивании основной, расскажу про развёртывание на домашнем компьютере, где ресурсы сильно ограничены:

  • Tower - минимальные системные требования более чем скромные, 1 ядра и 1024Mb RAM вполне хватит чтобы заработало,
  • Node - 2 ядра и 2560Mb RAM, наверное самый экстрим-минимум, подобрано было исходя из загрузки ноды при работе с 4 железками на домашнем компьютере. Если же выделять памяти меньше 2560Mb, то веб ноды ведёт себя неадекватно. Это мои наблюдения, на другом железе и гипервизоре может быть по-другому.
Подключение

Необходимые условия:

  • Компьютером с процессором Core i3 и лучше, памятью минимум 6Gb;
  • Тестовое сетевое оборудование для заведения в NOC (у меня это 4 коммутатора CISCO);
  • Минимум 2 сетевые карты, одна подключена к интернет (№1), другая к тестовому сетевому оборудованию (№2);
  • Консольный кабель.

В последней сборке Windows 10 есть Коммутатор по умолчанию, синтетическая сетевая каждой VMs подключается к нему — через это подключение осуществляется связь VMs с домашним компьютером: открывается Веб ноды/башни и SSH.

NOC Project установка

Чтобы VMs могли выходить в интернет, на сетевой №1 с доступом в интернет, на закладке Доступ включается Общий доступ к интернету, выбирается Коммутатор по умолчанию из списка возможных для предоставления общего доступа. Таким образом Коммутатор по умолчанию, а через него и VMs — получают выход в интернет. При включении общего доступа IP адрес для Коммутатора по умолчанию будет выдан автоматически: 192.168.137.1/24, соответственно для VMs IP адреса их первой сетевой должны быть из подсети 192.168.137.0/24, а шлюз 192.168.137.1 (DNS любые).

NOC Project установка

Потом создаётся HUB Hyper-V, привязанный к физической сетевой №2 и при его создании снимается галка: "Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру". Сетевая №2 отдаётся под полное управление Hyper-V и обеспечивает связь ноды с железками напрямую. Затем на ноду добавляется вторая синтетическая сетевая и она привязывается к созданному хабу. Для этой сетевой выбирается новая подсеть (непересекающаяся с имеющимися, у меня это 192.168.64.0/24), задаётся IP адрес (без шлюза по умолчанию). Если у каких-то тестовых железок IP не из 192.168.64.0/24, то на ноде нужно накинуть соответствующий маршрут.

NOC Project установка

Управление тестовым сетевым оборудованием с компьютера происходит через консольный кабель. Причём через консольник подключение только к первому устройству, дальше уже подключение происходит через встроенного SSH-клиента, перетыкать кабель из устройства в устройство не нужно:

3550-1#ssh -l admin 192.168.64.252

Password:

3550-2#

Вот такая схема, возможно не самая оптимальная, зато рабочая.

Для установок с минимальным количеством ресурсов VM:

  • После успешного деплоя на ноде ещё какое-то время идёт обработка, нужно дождаться её окончания (ориентируюсь по активности жесткого диска, как активность пропала - можно подключаться), иначе ошибка;
  • Чем меньше ресурсов у ноды, тем дольше время этой пост-обработки, так на 4 ядрах её и нет, а на 2 ядрах - довольно долго;
  • Тоже самое при включении ноды — загрузка происходит очень долго и пока все сервисы не прогрузятся нода показывает в вебе ошибку 500 — это нормально, просто нужно подождать.

Устаревшая информация

Такие методы установки больше не применяется. Поскольку немало трудов было вложено в написание — оставляю.

Debian 8.8

Установка на Debian 8.5 рассказана на странице проекта. На Debian 9.1 не установилось, на Debian 8.8 всё поставилось - никаких отличий от статьи по 8.5 за исключением следующего:

  • Текущая актуальная ветка на 26.10.2017 - git_migrate.

И ещё вот какие замечания:

  • Debian 8.8 поддерживает машины 2 поколения Hyper-V с выключенной безопасностью для загрузки:

NOC Project установка

  • Для конфига SELINUX будет новый пустой файл, выполнить по описанию - не уверен нужен ли этот шаг на Debian, но делал его;
  • Если машины не прописаны на DNS, то IP ноды нужно прописать в файл hosts на башне.
# vi /etc/hosts

127.0.0.1 localhost
192.168.137.156 tower.local tower
192.168.137.155 node1.local node1

Установка самой башни

Создаём папку для установки непосредственно самой башни:

[root@tower ~]# mkdir /opt/tower
[root@tower ~]# cd /opt/tower

Создаём виртуальное окружение, вывод огромен, поэтому только сами команды:

[root@tower tower]# virtualenv .
[root@tower tower]# ./bin/pip install --upgrade pip
[root@tower tower]# ./bin/pip install https://cdn.getnoc.com/tower/noc-tower-latest.zip
[root@tower tower]# chown -R tower var/

Башня не стартует автоматически при запуске VM, её нужно запустить руками. Запуск в общем виде без параметров:

[root@tower ~]# su - tower -c "cd /opt/tower && ./bin/tower-web"


2017-11-05 08:44:59,823 [tower.daemons.web] Applying database migrations
2017-11-05 08:44:59,867 [tower.daemons.web] Loading service
2017-11-05 08:44:59,867 [tower.daemons.web] Serving UI files from /opt/tower/lib/python2.7/site-packages/tower/ui
2017-11-05 08:44:59,882 [tower.daemons.web] Service is ready

Про различные варианты запуска башни рассказано здесь.

Актуальными версиями на декабрь 2017 являются MongoDB 3.4 и Postgre 9.6, поэтому для начальной инсталляции, когда нода ещё пока пустышка, башню нужно запускать как:

[root@tower ~]# su - tower -c "cd /opt/tower && MONGO_VERSION=3.4 POSTGRES_VERSION=9.6 ./bin/tower-web"

Такой запуск башни при деплое будет устанавливать указанные версии СУБД на ноду.

Если нода уже используется какое-то время и на ней есть MongoDB 3.2 и Postgre 9.4, то указанная выше команда запуска при деплое подтянет MongoDB 3.4 автоматом, а вот Postgre нужно предварительно обновить руками. Как это сделать очень хорошо и подробно описано тут, только я ставил конечно же pgdg-centos96-9.6-3.noarch.rpm.


Обновление башни

На Debiane часто замечал, что если закрыть SSH к башне или просто нажать Ctrl-c, то веб башни сразу падает, на CenOS такого нет — можно ввести Ctrl-c и дальше вводить команды, Веб при этом на месте:

NOC Project установка

Если же не отключаться от сессии башни, то там можно увидеть лог всех действий в Вебе (после переезда на Docker такая возможность пропала).

  • Башню нужно время от времени обновлять. Как часто? Ну об обязательном обновлении можно узнать на канале Telegram. Зайти на башню /opt/tower/bin и запустить скрипт:
# ./tower-upgrade
обновлено или нет можно смотреть по логу:
Requirement already satisfied - последняя версия уже стоит

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *