Comments 7
Спасибо за статью, очень познавательно, особенно когда ты много времени и сил тратишь на то чтобы понять как это сделать в своей компании. Остались вопросы:
1)CMDB.noc — это ваша собственная разработка или все таки доработанная NOC Project? (спрашиваю потому что сам смотрю в эту сторону)
2)Почему выбор пал именно SolarWinds, а не тот же NOC Project?
1)CMDB.noc — это ваша собственная разработка или все таки доработанная NOC Project? (спрашиваю потому что сам смотрю в эту сторону)
2)Почему выбор пал именно SolarWinds, а не тот же NOC Project?
Спасибо за отзыв!
CMDB.noc — собственная. Пу сути это база mysql, с админ-панелью. Изначально, нам нужно было хранить данные по подключенным каналам связи и провайдерам с привязкой к объекту. Там много кастомных полей, поэтому пришлось делать свое решение. Позже решили туда же добавить и сетевое оборудование, т.к. нужны связи между объектом, каналом и железом, плюс также много кастомных полей, вроде нескольких external id других систем. Использовать готовое решение сходу не получалось, не хватало необходимого функционала. Плюс, нужно было решение которое является Single Source of Truth для железа.
2) Изначально выбор был по ТЗ и цене среди предлагаемых на рынке решений для энтерпрайза. SW достаточно прост в структуре и показался очень удобным к адаптации. Там есть недостатки по API.
Сейчас я бы посоветовал присмотреться к Netbox, довольно приятное решение, можно совмещать базу оборудования и IPAM. На странице проекта как раз описан подход Single Source of Truth для системы инвентаризации.
Про NOC project, к сожалению, не могу подробно сказать. Его не использовали.
CMDB.noc — собственная. Пу сути это база mysql, с админ-панелью. Изначально, нам нужно было хранить данные по подключенным каналам связи и провайдерам с привязкой к объекту. Там много кастомных полей, поэтому пришлось делать свое решение. Позже решили туда же добавить и сетевое оборудование, т.к. нужны связи между объектом, каналом и железом, плюс также много кастомных полей, вроде нескольких external id других систем. Использовать готовое решение сходу не получалось, не хватало необходимого функционала. Плюс, нужно было решение которое является Single Source of Truth для железа.
2) Изначально выбор был по ТЗ и цене среди предлагаемых на рынке решений для энтерпрайза. SW достаточно прост в структуре и показался очень удобным к адаптации. Там есть недостатки по API.
Сейчас я бы посоветовал присмотреться к Netbox, довольно приятное решение, можно совмещать базу оборудования и IPAM. На странице проекта как раз описан подход Single Source of Truth для системы инвентаризации.
Про NOC project, к сожалению, не могу подробно сказать. Его не использовали.
Интересный опыт, спасибо.
И еще пара вопросов, если возможно.
2. Какой подход к безопасному хранению учеток/паролей и их импорту в скрипты используете в сетевой автоматизации?
И еще пара вопросов, если возможно.
Это netmiko, это pysnmp, это jinja2 и etc.1. А Nornir не доводилось использовать? Не так давно для себя его обнаружил, выглядит многообещающе. Это дополнительная абстракция над netmiko и napalm с инвентори и мультитредингом.
2. Какой подход к безопасному хранению учеток/паролей и их импорту в скрипты используете в сетевой автоматизации?
Привет.
1. Nornir смотрел, но пока в качестве факультатива, в проде еще не использовали. Зависит от цели использования. Если применим в работе, то в одной из следующих статей попробую рассказать об успехе, или нет.
2. Зависит от системы. Например, для Ansible это ansible-vault. Для gitlab это внутренние скрытые переменные. Для чистого python вопрос неоднозначный пока для нас. Можно предложить хранить их как и ssh-ключи, с доступом только от root в linux. Предполагается, что рутовый доступ закрыт от любых пользователей.
1. Nornir смотрел, но пока в качестве факультатива, в проде еще не использовали. Зависит от цели использования. Если применим в работе, то в одной из следующих статей попробую рассказать об успехе, или нет.
2. Зависит от системы. Например, для Ansible это ansible-vault. Для gitlab это внутренние скрытые переменные. Для чистого python вопрос неоднозначный пока для нас. Можно предложить хранить их как и ssh-ключи, с доступом только от root в linux. Предполагается, что рутовый доступ закрыт от любых пользователей.
Спасибо за статью, Александр.
1). Расскажите, пожалуйста, подробнее об использовании Batfish. Вы проверяете каждый конфиг по отдельности на ошибки? Тестируете сеть небольшими сегментами? Какими Batfish вопросами пользуетесь?
2). Рассматривали ли Вы NAPALM, с его опциями replace/merge, для доставки конфигурации на сетевое железо?
1). Расскажите, пожалуйста, подробнее об использовании Batfish. Вы проверяете каждый конфиг по отдельности на ошибки? Тестируете сеть небольшими сегментами? Какими Batfish вопросами пользуетесь?
2). Рассматривали ли Вы NAPALM, с его опциями replace/merge, для доставки конфигурации на сетевое железо?
Добрый день.
1) Развернутого ответа пока нет. Пробуем использовать, тематика интересная пытаемся понять возможности для нас. Не все получается. Как раз ваш гайд помог начать. Спасибо:)
2) Рассматриваем различные инструменты. Для Cisco, например, есть много возможностей и многие инструменты очень удобны, в частности тот же Batfish. Но часто не получается использовать универсальное решение, так как у нас используется много оборудования HPE на платформе Comware. Для него либо нет готовых решений, либо их мало. Конкретно сейчас не используем Napalm, пытаемся написать кастомное решение под свою инфраструктуру. Но мы в этой части пока в самом начале пути, возможно мы к нему придем.
1) Развернутого ответа пока нет. Пробуем использовать, тематика интересная пытаемся понять возможности для нас. Не все получается. Как раз ваш гайд помог начать. Спасибо:)
2) Рассматриваем различные инструменты. Для Cisco, например, есть много возможностей и многие инструменты очень удобны, в частности тот же Batfish. Но часто не получается использовать универсальное решение, так как у нас используется много оборудования HPE на платформе Comware. Для него либо нет готовых решений, либо их мало. Конкретно сейчас не используем Napalm, пытаемся написать кастомное решение под свою инфраструктуру. Но мы в этой части пока в самом начале пути, возможно мы к нему придем.
Спасибо за статью. Было бы интересно узнать о продолжении развития.
Sign up to leave a comment.
Как мы делаем автоматизацию большой legacy сети