Как стать автором
Обновить

Комментарии 5

Вроде бы при поднятии pull-сервера рядом сразу же можно поднять сервер отчётов и с него в xml получать информацию о статусах тасков. Вас его функционал не устроил?
Показалось, что проще получать обычный текстовый вывод в реалтайме, чем парсить XML
Осуществили, такой же переход, с DSC на Ansible. Переход оправдал себя полностью. Преимущества использования Ansible, которых мы не смогли достичь с DSC:
* В Ansible порог входа ниже и он гибок в реализации различных сценариев, которые в DSC нужно было решать через powershell. Как результат, в разработку инфраструктурного кода включились другие подразделения (Dev, ИБ) и это снизило нагрузку на SRE.
* Мы смогли реализовать удобное тестирование инфраструктурного кода используя molecule и сделать его частью нашего CI. Запускаем тесты в подготовленном docker образе с vagrant и другими нужными нам утилитами. Это так же снизило нагрузку на SRE, т.к. ушло полу ручное тестирование кода DSC при Merge Requests. Тесты для DSC ранее были написаны используя сам DSC и Pester, но их реализация сложнее.
* Deploy с Ansible предсказуемый, в особенности если он становится частью CI/CD pipelines.

Есть ряд задач которые DSC решает лучше, мы используем его в таких случаях, т.к. Ansible позволяет использовать DSC модули.
С WinRM у нас проблем не было, по тестам он работал даже быстрее и стабильнее на каналах с высокой задержкой.

Круто! А до интеграционного тестирования ролей доходили? (Мы — ещё нет)

Да, сразу начали использовать. Нам было проще, т.к. автоматизацию windows инфраструктуры делали SRE с сильным linux бэкграундом, давно использовавшие ansible и знакомые с powershell.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий