В качестве предисловия
Основной задачей моей работы является поддержка парка железных и vm хостов — уже под 200 (а приходил было менше 100, эх, время бежит...) Поддерживаю все железо, а также сеть. Также на мне весь мониторинг (используем Opsview — сделан на ядре nagios), аггрегация логов (я внедрил Logstash, обалденное opensource решение за место ну ооочень дорогого Splunk), configuration management (puppet), бекапы, поддержка баз данных и прочих систем тоже на мне (MongoDB, MySQL, Redis, ElasticSearch, etc). В общем — все самое интересное). Стоит отметить что у нас достаточно тонкая грань между поддержкой и разработкой, и разработчики часто говорят что они хотят, а я уже занимаюсь внедрением. Хочется рассказать обо всем что происходит интересного и какие технологии удается использовать. Какие прижились, а какие по каким-то причинам нет.
В свободное от решения проблем время перевожу инфраструктуру на Infrastructure-as-a-code (IaaC), выбрал puppet для этого из-за неоднородности нашей инфраструктуры. В моей сети зоопарк из Windows Server 2008, Windows Server 2012, CentOS 5.5, CentOS 6.4. Ах, да, пару дедушек на 2003 — пора их на пенсию отправлять скоро…
Я уже писал о том, как я использую Puppet для автоматической настройки мониторинга в Opsvew, а сегодня хочу поговорить о том, как я в очередной раз «боролся» с гетерогенностью моей среды.
Задача
Возникла необходимость автоматизировать конфигурацию WMI на серверах Windows 2008 / 2012. Ключевой необходимостью стало добавление сервисного пользователя (назовем его «domainservice-user») в локальные группы сервера, которые разрешают удаленное использование WMI, а также доступ к Performance Counters, Performance Logs, в общем ко всему что нужно чтобы удаленно мониторить сервер. Сами группы определились достаточно быстро, оставалось найти удобный и быстрый способ это сделать. Также необходимо было дать права пользователю domainservice-user на доступ к корневым неймспейсам WMI. Так же все это должно быть частью общей концепции IaaC, что должно означать как минимум проверку текущего состояния, и пропускать выполнение если пользователь уже добавлен куда нужно в любом варианте присутствия-отсутствия пользователя в группах. Т.е. решение должно быть максимально автоматизированным, а точнее полностью. После небольшого гугления стало ясно что для моего случая нужно, а мне предстояло:
Читать полностью »
