Добрый день!
Хочу автоматизировать некоторые процессы в Active Directory по типу: Создание юзеров, добавление в группы, удаления пользователей из групп, и из AD, Репорты. Чтобы не хранить скрипты и не запускать их через Powershell постоянно.
И я бы хотел узнать как правильно создавать джобы для этого в Jenkins?
Я поднял Jenkins на Ubuntu, установил плагин Active Directory и связал его с AD, чтобы можно было логиниться.
Но теперь не могу разобраться как создать там джобу чтобы на Windows машине выполняла задачи.
Помогите пожалуйста!)
А вы уверены, что взяли правильный инструмент для решения ваших задач?
Вы берете задачи класса "управление конфигурацией" и пытаетесь их решить инструментом непрерывной интеграции (CI/CD) - наверное, так можно, но выглядит как забивание гвоздей микроскопом
имхо, для ваших задач Ansible и его плейбуки подходят в разы лучше
Jenkins is a continuous integration (CI) tool primarily used for building and testing software projects.
Ansible is a configuration management and orchestration tool for automating infrastructure and application deployment, setup, and administration.
Роман Безруков, Не думал о том что это будет так выглядеть, знал что Jenkins CI/CD инструмент, но просто работаю на нескольких работах, и в одной из них видел что ребята для создания пользователей, и ресету пароля используют дженкинс, и показалось что вроде не плохая идея.
А Ansible разве можно будет иметь некий UI где можно будет менять параметры для заполнения ?
Billy_Pluto, глядя на эту статью, предположу, что "ребята" для типовых административных задач сделали несколько джобов с параметрами, внутри которых запускают обычные виндовые скрипты - "потому что могут". Возможно, в их инфраструктуре это приемлемый вариант, и "ребята" не заморачиваются.
У Ansible плейбуки умеют принимать параметры.
P.S. работал я некоторые время назад в финтех-конторе, которая занимается денежными переводами. Разрабы (а это больше половины состава) проповедовали свой CI\CD, pipelines,гиты, репы и т.д. Но даже они не додумались до такого использования Jenkins - все, что связано с AD, делалось плейбуками Ansible
Роман Безруков, Благодарю про статью Дженкинса, и информацию, о том что не такой уж и хороший вариант ). Думаю попробую тогда изучить Ansible, но запуски данных скриптов будут делать поддержка офиса, и думаю для них будет немного тяжеловато их запускать, ведь они привыкли больше к UI где все легко и просто, а ansbile вроде не имеет таких штук.
P.S. Не могли бы вы также поделиться ссылкой на ansible изучение если не затруднит ? Вроде как в гугле полно, да и на канале "ADV-IT", видал, но может у вас есть и по лучше варианты)
Роман Безруков, одно другому не мешает, у нас юзеров создают из ansible, который запускается в jenkins...
Правда, я обычно всё равно гоняю ansible напрямую, потому что при каждой попытке использовать у меня что-то идёт не так: то повиснет на умершем хосте, то --limit неправильно прочитался и потому проигнорировался (привет прогон по всем серверам), то хочешь отменить и он час висит не отменяется...
Billy_Pluto, Если у вас вот прям реальные windows/ad/powershell, то ansible тоже не совсем тот инструмент,
это всё таки про изменение конфигурации компов, а не юзеров/АД
ну и он под виндами только через wsl работает и морока там с подключением к хостам.
Если у вас предполагается, что запуск неких скриптов будут делать офисные работники, стоит подумать, на основе какой информации будет этот запуск
руками вбивают данные юзера - "автоматизация" околонулевая, вообще ни о чём
выгрузка из 1С, например - можно вешать в шедулер скрипт, который мониторит папочку с выгрузкой и на основе выложенного туда создаёт/меняет юзеров. или письма мониторит соответствующие, может какие-то другие источники...
первый вариант - это вообще не автоматизация, проще дать доступ к ADUC
во втором случае навертеть автоматизацию можно ого-го какую
и с точки зрения безопасности юзер из под которого запускаются скрипты знает только админ и шедулер (на защищённом сервере)
MaxKozlov, Ну Windows/AD/Powershell уж точно реальные)
А вот запускать данные "скрипты" в Jenkins будут все таки не просто офисные работники, а именно служба поддержки ИТ нашего офиса, просто ребята там, не особо горят делать, что-то новое и что-то сложное, а от руководства была поставлена задача автоматизировать такие вещи как создание юзеров и.т.д, потому что ребята очень часто косячат с аттрибутами при создании пользователей, и сказали убрать данный человеческий фактор. Но запуск с powershell, я уверен сделает еще хуже.
Скоуп Джоб который дали чтобы выполнял Jenikns или что-то другое:
1. Создание/Удаление пользователей
2.Добавление/Удаление в группы AD
3.Вытаскивать отчеты кто состоит в каких группах в AD
4. Вытаскивать отчет о том у кого есть доступ к группе "P Driver(Общая папка)"
5.Выгрузка пользователей в .xml формате для сверки кто еще работает, а кто нет.
С 1С ничего такого нету(Но думаю на пока что).
И таких не особо по сути важных Джоб очень много, я и сам конечно 3,4,5 вариант ручками могу сделать, там уже написанные скрипты я себе сделал и записал их в текстовый файлик). Но хочется также делегировать на ребят.
Да, и очень интересно обучиться таким инструментам как "Jenkins" и "Ansible"
Billy_Pluto, к PowerShell-скрипту можно приделать обычный GUI (хоть WinForms, хоть XAML) и до кучи завернуть все в EXE, а можно и веб-интерфейс - пусть ТП в браузере кнопки нажимает. Ansible Documentation
Роман Безруков, Не знал про такой вариант приделывания GUI к Powershell, почему-то в голове подумал что вы про ISE, но потом отпало ) . Погуглю посмотрю возможно будет подходящим вариантом)
Благодарю за ссылочку по Ansible:)
Billy_Pluto, Не буду уговаривать :)
но всё ж, на мой взгляд, не тот случай, стоит ли ради этого ansiblе громоздить? хост будет всего один.
тем более что параметры типа юзеров для него всё равно кто-то должен задавать.
а там текстовые файлики, косячь-не хочу.
По моему опыту я создавал/видел три варианта подобной автоматизации.
1. выгрузка из 1С, парсинг, создание юзеров по определённым правилам - вообще полная автоматизация (c#, слышал про аналоги на ps)
2. GUI приложение на C# - вводим ФИО, галочками выбираем отдел или создаём нового пользователя на основе уже существующего.
3. Скрипты на Powershell - на вход опять же ФИО и отдел.
Во всех случаях логины делаются автоматом, группы раздаются автоматом, поля типа отдел и т.д.
и то накосячить умудрялись :)
то в 1С случайно пользователя "уволят"
то ФИО копипастой с невидимыми переносами строки в поле вставят
Для внесения изменений со стороны стороннего сервиса не нужна интеграция сервиса с AD.
Нужен сервисный аккаунт в AD с необходимым минимумом прав, который будет использовать сторонний сервис для внесения изменений.
Либо нужен промежуточный между сторонним сервисом и AD специализированный Identity Manager - типа MIM, либо Keycloak и.т.п.
Простой
Средний
