Как бы мы автоматизировали сетевое взаимодействие в марионеточной среде?
Наша инфраструктура: мы запускаем Puppet Master для около 250 узлов (около 100 аппаратных серверов). Сама ОС на узлах полностью кукольна.
Теперь мы рассмотрим расширение этой настройки кукол на следующие домены:
- Управление IP/DHCP
- Конфигурация APC
- настройка коммутатора (через SNMP у нас есть коммутаторы Arista)
- управление запасами (где установлен сервер x? как долго действует гарантия?)
Есть ли программное обеспечение (с открытым исходным кодом или не имеет значения), которое позволяет нам достичь этого? Я думаю, что у него есть схема реляционных данных, как server или же switch который может быть заполнен веб-интерфейсом. Затем для каждого из этих 4 пунктов существуют сценарии для извлечения данных из таблиц и передачи их на устройства.
правильно, почему бы нам просто не взять куклу для этого?
Мы бы с удовольствием, так как мы хотим, чтобы все конфигурации были в одном месте, но...
1 + 2 может быть сделано в марионетке, но для 250 узлов, которые выглядят как ад большого манифестного марионетки. Кроме того, мы хотим добавить предоставление виртуальной машины через мастера марионеток в ближайшее время, поэтому "система резервирования IP" должна быть "реагирующей", и, следовательно, IMO должна быть вне марионетки.
3, вероятно, не представляется возможным, так как переключатели еще не готовы к марионетке,
4 возможно с Puppet, когда мы добавим "аппаратный" слой над слоем узла в Puppet.
Какие-нибудь мысли?
2 ответа
AFAIK Форман уже ведет в правильном направлении, поэтому, возможно, вам следует начать играть с этим.
Кроме того, взгляните на пользовательские факты. Они являются мощным способом доступа ко всем видам данных и делают их пригодными для использования в манифестах Puppet. Например, создать собственный факт, как $::inventory_ipaddress или даже перезаписать $::ipaddress Факт с каноническим, который будет использоваться для конфигурации.
Для 1: для большого количества хостов, как правило, желательно не иметь сотни node определения, а точнее имеют набор ролей и профилей.
Общая задача проектирования здесь - обеспечить четкий поток информации из единственного источника (источников) правды в обеспечение.
Для 2+3: вы можете использовать puppet для вызова всевозможных вспомогательных сценариев и инструментов, но я сомневаюсь, что это лучший инструмент для работы, потому что он, вероятно, не будет "источником правды".
Для 4: это где-то посередине. Я сам использую puppet на экземплярах EC2 для периодического запуска обновления инвентаризации Zabbix и использую facter для заполнения, например, роли, версии ОС, групп безопасности. Предостережение: мой нормативный источник правды - инструмент обеспечения, и моя марионетка проявляет себя там, где я могу изменить настройки; с другой стороны, этот инвентарь является только окончательным результатом для проверки результатов.
Коммутаторы Arista можно настроить с помощью Puppet, работающего в операционной системе EOS на самом коммутаторе. Arista даже предоставляет учебное пособие по установке Puppet: установка Puppet на EOS. Это не должно быть проблемой.
Для задач инвентаризации (IP, местоположения, гарантия) я бы порекомендовал Zabbix.