NOC Project установка

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

Предисловие

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

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

Как это реализовать? Ansible, скрипты? Как сравнивать конфиги на изменения? Как автоматически выстроить карту сети? Нужен заточенный под это софт. Таким софтом является NOC.

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

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

• Можно кидать конфиги на внешний TFTP с помощью команды глобальной конфигурации archive. В качестве TFTP сервера удобно использовать tftpd64 service edition, а примерная конфигурация на устройстве следующая:

archive
 log config
  logging enable
  hidekeys
 path tftp://10.20.0.100/$H-$T.cfg
 write-memory

---

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

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

В частности на канале опубликован стрим Как установить NOC. С этого момента актуальность данной статьи уменьшается, но кому-то она поможет.

---

Решение проблем с NOC Project

Ещё есть канал для живого общения, можно поспрошать там. На канале соблюдайте правила:

• Не надо вываливать лог ошибки в чат, для этого есть сайт и ещё один. Вставляете там лог ошибки, формируете запись и уже ссылку на запись — в чат. Желательно зарегистрироваться на этих сайтах, это даст возможность контролировать свои записи;
• Пользуйтесь поиском по каналу. Если возникла  проблема, то с большой вероятностью решение этой проблемы уже обсуждалось, возможно даже неоднократно;
• Для найденных ошибок, а также для своих хотелок от NOC есть баг-трекер. Открываете новую issue и пишите там что вам потребно. После выполнения заявки не забывайте её закрыть.

---

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

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

Скрипты написаны на Python. В основе лежат две (!) базы данных: MongoDB и PostgreSQL. Первая для устройств, вторая для веба и прочих радостей.

Достоинства

• Полностью бесплатное ПО;
• Богатый функционал;
• NOC активно дорабатывается.

Недостатки

• Есть ошибки в коде, как результат внедрения новых фич;
• Документация разрабатывается, но до совершенства пока далеко;
• Составлять свою документацию довольно сложно: пока собираешь информацию, она успевает устаревать.

Хотелось бы чтобы разработчики в приоритете шлифовали существующий функционал.

Структура NOC

NOC Project состоит из двух инсталляций. NOC Tower:

• Централизованно хранит настройки;
• Распространяет эти настройки.

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

NOC Node — основная рабочая среда. Установка и обновление Node происходит через деплой настроек с Tower.

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

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

---

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

Из-за множества сервисов, которые должны работать слажено, нода очень требовательна к производительности сервера, даже можно сказать капризна.

Так когда RAID-массив деградировал и скорость дисковых операций упала, начал отваливаться сервис MongoDB. При рестарте VM он не мог запуститься, затем при запуске руками стартовал с третьего раза и через некоторое время опять падал. Загрузка ядер на этот момент не более 7-10% в пике.

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

Как только нода испытывает любые затыки в производительности, сразу в её работе что-нибудь отваливается. Учитывайте этот момент.

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

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

• Локальный репозиторий для ноды не подойдёт, слишком много зависимостей;
• Работа через TOR рассказана дальше;
• Прямой доступ — на данный момент не получится развернуть, почему также в секции про TOR.

TOR

Репозиторий Consul заблокирован для России.

This content is not currently available in your region.
Please see trade controls.

К этому репо обращается нода в начале деплоя и башня где-то после сотого шага. Поэтому просто взять и поставить через прямой доступ в интернет NOC Project нельзя. У кого есть VPN отлично. Далее для тех, у кого его нет.

Для башни нужен предварительный шаг:

# vim docker-compose.yml

 image: registry.getnoc.com/noc/tower:alpine
 network_mode: "host" - нужно добавить эту строчку, перезапустить Compose
 restart: always

Устанавливаем TOR и заворачиваем туда трафик HTTPS. Для ноды и башни одинаково:

# apt-get install iptables tor -y
# vim /etc/tor/torrc

Добавить в конец файла:

VirtualAddrNetworkIPv4 10.192.0.0/10
CircuitBuildTimeout    30
KeepAlivePeriod        60   # немного ускоряет работу
NewCircuitPeriod       15   # частота смены цепочки
NumEntryGuards         8
ExcludeExitNodes {RU},{UA},{BY}  # исключить Exit-ноды следующих стран
TransPort              9040  # транзитный порт для трафика

# service tor start 
# iptables -t nat -A OUTPUT -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 9040

Подключение к TOR занимает некоторое время. Проверяем для ноды:

# curl https://ident.me 

Для башни:

# docker ps

CONTAINER ID   IMAGE                                  COMMAND                  CREATED       STATUS         PORTS     NAMES
768517cdcc48   registry.getnoc.com/noc/tower:alpine   "/entrypoint.sh ./bi…"   3 hours ago   Up 8 minutes             tower_tower_1

# docker exec 768517cdcc48 curl https://ident.me

Должны выводиться чужие IPs. Настройки сохраняются до ребута. Если ISP блочит TOR, то у меня нет универсального солюшена как это решить.

Обход блока TOR

Данная информация приведена исключительно в целях установки NOC Project.

Не гарантирую что взлетит, но попробовать можно.

# apt-get install obfs4proxy -y

Далее прописать в /etc/tor/torrc:

ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
UseBridges 1
Bridge obfs4 ...
Bridge obfs4 ...
Bridge obfs4 ...

Где взять адреса бриджей полно инфы в нете. Самый топовый способ поставить десктоп версию TOR, добиться работоспособности, а после установки соединения подсмотреть адреса бриджей. Бридж может быть один, но он должен быть рабочий. Так как если ISP блокирует TOR, он скорее всего блокирует и бриджи. У меня в конечном итоге заработало.

Контролировать процесс установки соединения TOR лучше так:

# service tor stop
# tor

И если доезжает до 100%, то можно прерывать и запускать уже как сервис.

---

NOC Tower

Как установить башню рассказано в 2 файлах:

1. Установка; 
2. Обновление.

Башня ставится в контейнер Docker, поэтому какая будет хостовая ОС разницы нет. Для определённости ставлю в Ubuntu Server:

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

Установка docker-compose
# apt-get install docker-compose -y
# 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 pull tower
# docker-compose up --force-recreate

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

---

NOC Node

NOC можно развернуть поверх разных дистрибутивов. По статистике с NOC канала Telegram более 40% предпочли использовать Debian в качестве платформы для NOC.

Хотя люблю CentOS 7, он экстремально старый. И вот эту фичу с obfs4proxy на нём без сильных танцев не сделать. Если для организации TOR не блокируется ISP и выбирать CentOS, то там обязательно потребуется:

  # yum install epel-release -y 

В остальном всё аналогично установке на Debian, даже попроще в моментах.

Настройка Debian

Cоздаём пользователя ansible на этапе установки. Ставим SSH и стандартные системные утилиты. Далее:

ansible@node:~$ su
Password:
# apt-get install vim sudo curl -y

Vim надо подшаманить, чтобы работала вставка по правой кнопке мыши:

# nano /etc/vim/vimrc.local

source $VIMRUNTIME/defaults.vim
let skip_defaults_vim = 1
if has('mouse')
  set mouse=r
endif

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

# vim /etc/sudoers

ansible ALL=(ALL) NOPASSWD:ALL - добавляем а конец
:wq! - записать и выйти

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

# cd /etc/docker-compose/tower
# docker-compose exec tower ssh-copy-id -f -i /opt/tower/var/tower/data/deploy_keys/id_rsa.pub ansible@node_ip

Number of key(s) added: 1

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

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

# docker exec 768517cdcc48 rm /root/.ssh/known_hosts

Вход ansible без пароля

После этого нужно удостовериться что вход без ввода пароля действительно работает:

# docker-compose exec tower ssh 'ansible@node_ip'

Если нет, то можно попробовать вот это, у меня взлетело:

# docker ps

CONTAINER ID ...
768517cdcc48 ...

# docker cp /opt/tower/var/tower/data/deploy_keys/id_rsa 768517cdcc48:/root/.ssh/

Контролировать процесс подключения башни к ноде так:

# docker-compose exec tower ssh -v 'ansible@ip_ноды'

Ещё на ноде можно покрутить конфиг SSH.

# vim /etc/ssh/sshd_config

Раскомментировать строчки:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

И в завершение перезапустить сервис SSH:

# service sshd restart

---

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

Подключаемся к Вебу башни: http://ip_башни:8888/. Вводим admin/admin. Попали в Веб башни, добавляем новую Environment. Если нет желания править скрипты и самому исправлять какие-то ошибки, то выбираем Productive. А если есть Evaluation. Примерно вот так и сохраняем:

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

Следующий раздел Nodes. Имя хоста ноды и Name в разделе Nodes башни должны совпадать.

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

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

• Башня не подгружает через Pull актуальный список сервисов. Внимание, можно всё разломать. Лечится удалением старого Environment и заведением его снова. Сперва необходимо задокументировать существующие настройки для каждого сервиса. Не лишним будет предварительно сделать выгрузки баз монги и постгре.

Настройка сервисов

Теперь важный пункт — настройка сервисов. Многие значения предустановлены, тем не менее всё нужно проверить. Кроме того в описании каждого сервиса есть подсказки сколько и чего должно быть. Не забывайте жмакать кнопку Save.

Возможно смена дефолтных паролей может вызывать проблемы для некоторых сервисов, но это не точно. Менять пароли нужно до первого деплоя. Со сменой дефолтного пароля mongodb вроде бы проблем не было. С паролем postgresql тоже.

Самое главное здесь:

• Выставить сервис activator по 2 на ядро ноды;
• Как правильно выбрать релиз NOC читаем тут;

Чуть подробнее. Получается либо release-номер_релиза, либо stable. Релиз лучший вариант. Но могут появиться более свежие версии, в том числе более свежие релизы.

Второе самое последнее исправления ошибок, но есть риск появления новых ошибок. Хоть и называется stable, стабильность тут минимально гарантированная.

Мой выбор релиз. Отслеживать мержи можно тут. Как появляется новый backport для релиза, пора запускать деплой.

• Отключить сервисы nsqd, nsqlookupd они не используются с версии 22.1;
• Настроить mailsender;
• Отключить все остальные сендеры, если они не используются;
• Сервис nginx включить Redirect http to https и Self-signed certificate;
• trapcollector и syslogcollector можно оставить как есть: 0.0.0.0:162 и 0.0.0.0:514. Нули означают прослушивание на всех интерфейсах или указать IP интерфейса, если у ноды их несколько.

На этом настройка завершена. Если на работающей ноде выполнить команду service noc status, то вот они сервисы, которые выставляли в башне.

---

Деплой

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

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

Самая центровая тут ошибка: VM уплыла на другой сервер и Hyper-V автоматом залепил ей галку Выполнить перенос на физический компьютер с другой версией процессора. В результате нет поддержки SSE 4.2 со стороны CPU. А значит не будет работать clickhouse и datastream.

Деплой насчитывает ~400 шагов, зависит от количества экземпляров сервисов и настроек. Доезжает до конца обычно не с первого раза. И идёт достаточно долго, это нормально. А через медленный TOR и того дольше. Особенно долгие установки TASK [clickhouse : Install CH], TASK [noc : Clone NOC]. Шаги которые отработали на прошлом деплое, на последующем пролетают довольно быстро.

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

Ошибки деплоя

Если возникает критическая ошибка и деплой прерывается, то нужно включить опцию Be extremely verbose. Тогда можно чётко увидеть что именно не в порядке. Для разных дистрибутивов свои приколы. Идём в нет, на канал Telegram и ищем инфу по ошибке.

# cd /opt/noc 
# ./noc crashinfo list

Непродуманные действия при исправлении ошибок могут привести к тому, что нода превратится в кирпич. И поднять её будет легче уже с нуля. Предупредил. Какие тут основные ошибки?

• No package matching ... is available:

# apt-get update

Возможно нужно прописать специфичный репо.

• Unable to correct problems, you have held broken packages;

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

• Failed to fetch ... 403 Forbidden;

Проблемы с репозиториями, править файл:

# vim /etc/apt/sources.list
# apt-get update

• TASK [clickhouse : Add CH repository] Msg: apt cache update failed.

Буквально "неразрешимая проблема", изломал всю голову, переставлял несколько раз ноду с нуля. Проблема возникала каждый раз. Удалось победить, но что именно стало триггером решения проблемы не знаю. Нужно проверить ещё.

Ошибки миграции

Особняком стоят ошибки миграции. Это заключительные и наиболее важные шаги деплоя. TASK migrate. Ошибки на этих шагах обычно говорят о повреждении баз:

b'django.db.utils.ProgrammingError: relation "sa_managedobject" does not exist'

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

# cd /opt/noc
# ./noc migrate
# ./noc ensure-indexes
# ./noc collection sync
# ./noc sync-perm
# ./noc sync-mibs

Сэкономит время. В общем-то ошибки у всех однотипные, если хорошо поискать, то можно найти решение. Полезная вещь:

# cd /opt/noc 
# ./noc help

Наконец труды вознаграждены:

---

Веб ноды

Наверное уже поняли что NOC непростое дело. 🙂 После удачного деплоя нужно перейти по адресу https://ip_ноды. Вводим admin/admin и наблюдаем такую картинку, которая является финалом нашей установки:

---

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

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

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

Поэтому предварительно должны быть выполнена необходимая настройка SSH и 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

Настройка 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
Router(config-line)# end
Router# wr

Для SNMP ещё нужно настроить трапы. Как это сделать рассказал в записях из цикла CCNA.