Комментарии 30
В своё время, ещё на заре двухтысячных, не осилив написание чего-то там на bash, ибо громоздко выходило и было не понятно, как всё это поддерживать, взялся за серьезное изучение perl. На нём вышло более презентабельно, и, кажется, более компактно.
Согласен, bash был в начале проекта, далее хотелось перевести на python в силу его простоты (для меня), и использовать pyqt5 вместо графики через zenity.
Но это займет время, а хотелось бы развивать проект в плане функционала, что я и делаю последнее время на заказ. То есть пишут пользователи с просьбой помочь с той или иной функцией, и далее она появляется в приложении.
Благодаря Habr'у, если пойму что спрос больше чем мне казалось, то может займусь наведением красоты и правильности в коде!
Bash - неплохая отправная точка, в плане понимания, чего же мы всё-таки хотим от нашего проекта.
Смещение в сторону питона тоже понятно - всё-таки, не язык для однострочников, да еще и всякие юпитеры при нём, что тоже удобно. Зоопарк из библиотек, правда, может слегка дезориентировать.
Питон проще поддерживать, тем более если когда-то появятся помощники.
С библиотеками все в рамках разумного думаю. Ну и красивая графика поможет пользователям использовать все это в школах, вузах и т.д.
Где системные администраторы либо начинающие, или уже заканчивающие свой путь ( без обид, скорее всего это реальная статистика).
И весь этот софт писался именно как помощник им, а не в прод для больших компаний, где используется уже terraform/opentofu, ansible, salt и т.д.
В продолжение данной статьи расскажу именно о своих плейбуках и исследованиях в ОС. Возможно мои костыли, помогут решить кому-то свои собственные задачи
Не совсем понимаю, какую задачу вы хотите решить с помощью AstraWizard.
- Всю автоматизацию на Linux делает Python.
- Чтобы не разбираться в Python был придуман высокоуровневый инструмент автоматизации Ansible.
- Чтобы не запоминать с какими параметрами запускать плейбуки Ansible был придуман Web интерфейс ansible awx и ansible semaphore.
Конкретно мы в компании используем Jenkins в качестве Web-интерфейса к Ansible. Админ, разработчик или тестировщик могут просто зайти в Jenkins и запустить нужный ранбук. Они просто жмут кнопку и далее происходит вся магия Ansible. Все креды и extra vars вшиты и о них думать не нужно. Если какие-то extra vars нужно заполнить, то jenkins предоставляет для этого красивую форму. В общем, очень удобная связка. По факту Ansible + Jenkins у нас делают то, что вы хотите сделать с помощью AstraWizard.
Настойчиво рекомендую вам познакомиться с ansible semaphore. Он скорее всего закроет все ваши потребности. Если нет, то смотрите тогда в сторону Ansible AWX или связки Ansible + Jenkins.
Добрый день, да все это известно и давно работает, но как давал ответ выше. Вы говорите о проде, вы говорите о людях с базовыми компетенциями ( написание своих плейбуков хотя бы, знание модулей и т.д.).
Я же даю уже готовый вариант собранный в деб пакет людям, кто не имеет возможности использовать более сложные инструменты.( Например: админ вузов, где я и работал и писал данный проект, админы школ и других гос. учреждений).
Чаще всего сотрудники там либо молодые и без опыта работы, либо работали всю жизнь с windows и боятся работать с Linux.
И перед ними стоит выбор:
1. развернуть продукты, изучать их связки и работу;
2. базово использовать мой продукт, у которого есть и видео уроки, и код открыт, также как я писал выше я могу оформить любую хотелку также в плейбук и добавить его в AstraWizard.(если данный функционал мне будет интересен и большинству пользователей продукта)
Из последнего, коллеги просили настроить удаленный помощник по паролю, чтобы администратор, мог попадать в сессию пользователя, но и чтобы это было безопасно, чтобы администратор не мог этого делать по своему желанию, так появилась последняя версия и доработка в виде установки удаленного помощника.
Я не говорю о конкуренции с гигантами, а лишь о проекте, который родился как локальный в 1 месте, а уже помогает в разных местах решать простые задачи начинающим администраторам.
Изобрели maas и foreman, но для более приземленных целей получается... Неплохо, без сарказма) Сам часто о таком задумывался, но слишком тупой чтобы реализовать даже с помощью llm :D
Да, спасибо за понимание.
Все верно, просто помогал людям с которыми работал, а далее с добавлением ansible под капот, решил сделать публичным ПО.
Есть еще множество разработок, о которых собираюсь рассказать в ближайших статьях.
Возможно комьюнити поможет советами, или в комментариях напишут свои *хотелки*, а я реализую.
Мне опыт, людям польза
По опыту работы с астрой вот что заметил - люди которые всю жизнь (20+лет) админили Винду почему-то совсем не могут в x11vnc. Сто раз приходится объяснять как подключиться к текущей сессии пользователя удаленно и прочие гадости творить. Так же без графики не в состоянии по ssh с помощью smbclient забирать файлы с ФС на клиентский пк, например. Уж больно много там всяких ключей, кавычек и экранов для них...
Хотя вижу, что всё впринципе охвачено в этом велосипеде. Даже не знаю... Автоматизация это конечно здорово, главное чтобы со скоростью работы не увеличивалось количество задач =D
Приветствую, как раз про x11vnc я и рассказал в комментариях выше.
Я в последней версии добавил его автоматическую установку на клиентские машины с помощью ansible.
Далее у пользователя появляется на рабочем столе ярлык - удаленный помощник.
Когда пользователь его запускает, то у него поднимается сервер vnc, а на экране появляется пароль из 6 цифр и имя пк + ip адрес, чтобы он смог их продиктовать администратору при запросе.
Далее пользователь говорит админу данные цифры, и админ с помощью любой утилиты, которая поддерживает протокол vnc подключается используя имя пк или ip и пароль, который диктует пользователь с экрана.
По поводу копирования файлов, в моем AstraWizard также есть возможность как положить так и стянуть с удаленного хоста файл, или несколько файлов.
То есть вы выбираете данную функцию, и если хотите передать, то вас попросит выбрать 1 или несколько файлов. А при получение с удаленного хоста, попросит указать путь до файла и куда его положить на вашем пк.
Все уже есть! Исходный код, а также все мои ролики можно найти на гите в проекте.
P.S.
Ссылки на плейлисты, где я рассказываю что умеет AstraWizard, и конечно же показываю
А это вообще работает в контексте именно рабочих мест? Я имею ввиду безагентский push-подход и Ansible в частности.
Это серверы из-за своей бизнес функции имеют постоянную сетевую доступность и покрыты мониторингом. Там безагентский push-подход в целом и Ansible в частности прекрасно работают by design: подавляющее большинство доступно и работает в любой момент времени, а что вот прямо сейчас не работает — на особом контроле.
А с рабочими местами в большинстве своём хаос: в сколько-нибудь крупной организации всегда часть рабочих мест недоступны: сотрудник на выезде с ноутом без сети, болеет, в отпуске, командировке, на обеде, встрече.
И с рабочими местами агентская pull-схема выглядит наиболее рабочей: клиент при первой же возможности тянет (синхронизирует) описание целевого состояния и автономно поддерживает конфиг/состояние рабочего места в требуемом состоянии, а не когда у админа (или Jenkins’а) доходят руки до этого конкретного клиента.
Приветствую, да конечно в больших продах pull модели, задания по крона и тд.
В AstraWizard есть возможность сканирования сети на предмет активных хостов. Также есть логи где можно посмотреть где применились.
Я писал для школ и вузов, где компьютерные классы удобно контролировать, а рабочие места почти всегда активны в рабочее время.
И по большей части всегда можно сказать, чтобы сотрудники не выключали пк, для этого также есть возможность выводить всем сообщение в их сессии и они точно не пропустят его, так как его можно закрыть только в ручную самому пользователю.
Понятно, что в большом интерпрайзе, это решение не будет работать так , как планировалось.
Но, в маленьких проектах или небольшим компаниях будет удобно начать админить, тем более в рамках импортозамещения.
Для пользовательских ПК - Puppet + Foreman
Для серверов - Ansible + AWX (исторически так сложилось)
Посмотрел на образцы кода и не понял, зачем такие велосипеды накрутили. Если используется Ansible, то зачем пользовательский ввод на баше? Если раскатка конфигураций управляемых ПК, то зачем удаленное подключение к ним по паролю? Не проще все нужные параметры положить сразу в исходные параметры начальной установки? Той самой, где и пароль заводится, который потом зачем-то вручную нужно вводить.
Нет раскатки готовой конфигурации.
Есть набор универсальных политик:
Установить деб пакет
Установить софт из реп
Удалить софт
Запустить службу
И много много всего
Я даю не понимающему человеку просто ввести в диалоговое окно название пакета, или в случае скаченного/собранного им деб пакета просто указать до него путь в гуи, далее мой софт автоматом положит на удаленных хост пакет и установит.
И также со службами, человек вводит любое имя службы и смотрит статусы, перезапускает и тд.
По паролю подключение происходит только 1 раз, если на хосте нет ключа. Далее только по ключу.
В статье не говорить, что мой софт = готовый набор сетапа пк.
Наоборот, я даю возможность админу не писать плейбуки, а заполнять их через гуи, на русском языке, а все плейбуки принимают значения и выполняют на удаленных пк.
Как говорили коллеги выше это похоже на awx, AstraAutomation или semaphore, однако мой продукт бесплатный , прост в понимание.
Также я дописываю возможный функционал по требованию комьюнити, пиши отдельные плейбуки на необходимые процессы автоматизации.
Есть несколько кастомных разработок, о которых я поведаю во 2 части.
Я даю не понимающему человеку просто ввести в диалоговое окно название пакета
Это понятно. Непонятно, зачем для ввода диалогового окна использовать баш, если потом эти значения все равно передаются в Ansible. В Ansible есть свои инструменты для пользовательского ввода с диалоговым запросом.
Супер, если я правильно понимаю, то вы говорите про vars_prompt , но это только терминальная работа.
Опять пользователю надо понимать как самому писать плейбуки, как они строятся, и т.д. Я молчу что ему надо будет самому придумывать 100 плейбуков или ролей, заполнять их и далее либо хардкодить переменные, или менять их.
Либо пладить много инвентари и варсов, либо каждый раз вызывать плейбук с екста-варсами.
А мой посыл, есть инструмент, который я развиваю безвозмездно.
Я готовлю шаблонные плейбуки, или готовые в зависимости от функционала.
Даю удобное гуи ( пока что на bash, планируется py qt5), чтобы пользователь мог не вникать в работу подкапотных функция, а просто жать кнопки и ему на русском будут спрашивать:
Какой пакет установить? Откуда скачать файл? Куда положить файл?
Также я позволяю вводить в домен freeipa и есть отдельный проект под ALD Pro ( от Астры), то есть я не вижу минусов данного проекта в целом.
Если есть желание улучшать или давать советы, то милости прошу или на гитфлик, или в ЛС, я всегда рад учиться и улучшать инструменты, тем более раз мне доверяют люди, которые уже сейчас используют и успешно переходят на Астру
Супер, если я правильно понимаю, то вы говорите про vars_prompt , но это только терминальная работа.
Даю удобное гуи ( пока что на bash, планируется py qt5)
Доктор, вы определитесь. (c) Bash и GUI - это как бы взаимоисключающие параграфы. С одной стороны вы не хотите терминал, с другой подкладываете Bash, который без терминала смысла не имеет. Где логика?
Вы либо не видели и не переходили по ссылке моего проекта , либо не знакомы с пакетом zenity, который спокойно рисует окна и запросы используя bash.
Логика прямая, zenity входит в состав ос в 1.7, в 1.8 ставиться из репозитория.
Bash есть в любой ОС и работает везде одинаково, что позволяет не тянуть много зависимостей.
В закрытом контуре можно использовать bash и zenity , как сертифицированное ПО, в отличии от либ питона, которые многие отделы ИБ не пропускают в контур.
Bash есть в любой ОС
Не в любой. И даже в Linux он не везде есть отнюдь.
В закрытом контуре можно использовать bash и zenity , как сертифицированное ПО, в отличии от либ питона, которые многие отделы ИБ не пропускают в контур.
Вы все равно туда включаете Ansible, который уже тянет с собой туеву хучу питоновских зависимостей. Смысл экономить на одной либе?
Я, собственно, к чему. Против zenity и Bash как таковых ничего против не имею, но ваша реализация вызова Ansible кажется мне неоптимальной. Если уж строить сценарии автоматизации на Ansible, то количество кода на Bash желательно сводить к минимуму.
Вообще, использование zenity в контексте Ansible - довольно интересный юзкейс. Думаю, можно сделать свой action-plugin для Ansible PyZenity и вызывать эти диалоги прямо из контекста Ansible, получая ваши любимые диалоговые окна вместо консоли. А если сделать кастомный callback-плагин с PyZenity, то можно и вывод Ansible из консольного в GUI перевести.
По паролю подключение происходит только 1 раз, если на хосте нет ключа. Далее только по ключу.
А пароль на хосте как появляется? Из ноосферы прилетает?
Пароль на хосте? Что? в чем вопрос?
Если вы имели ввиду ключ, то я все описал в цитате, которую вы же и комментируете.
Что администратор вводит пароль, и если хоста нет в known хостах, то с помощью применения пароля он кладется в уз пользователя на удаленном хосте, и далее вторая и далее ГП будут применяться без использования пароля.
Администратор может сам раскидать везде ключи, и тогда пароль не будет использован.
Также я описал в статье, что мне самому не нравится данная реализация, сначала я использовал только пароль, потом решил добавить ключи, но пока решения автоматизированного как класть ключи сразу на все хосты без пароля не придумал и рад любым советам.
Пароль на хосте? Что? в чем вопрос?
Откуда на хостах, на которые вы загружаете ключи, берутся изначальные пароли? Кто их задает?
На любой ОС при ее установке создается локальная уз админа.
Также при накатке , админы могут создавать свои учетки для управления, а далее просто используя мою утилиту вводить данные для данной уз, ключ будет класться в нее и далее подключение под этой УЗ будет происходить по ключу и все действия будут выполняться от нее.
На любой ОС при ее установке создается локальная уз админа.
Кем создается? И почему этот кто-то не может создать пару ключей для этого же админа?
Он создаст ключ, потом должен руками скопировать его на флешку и как то положить на админский хост? Выглядит как bad practice
Он создает ключ и передает его на админский хост как то? Если есть такие знания, то моя утилита будет полезна лишь от части
Если первоначальный пользователь, локальный потом не используются, а используется домен фриипа? Как быть тогда исходя из вашей претензии к коду? В фриипе создали УЗ еникею с определены и правами, админу, безопаснику и тд. У каждого разные права, и при использовании мой утилиты кто то сможет только поставить пакеты, а кто то проверить статус службы, а кто-то только положить файл конфигурации.
и как быть тут? Какое ваше предложение ?
Он создаст ключ, потом должен руками скопировать его на флешку и как то положить на админский хост? Выглядит как bad practice
Он создает ключ и передает его на админский хост как то? Если есть такие знания, то моя утилита будет полезна лишь от части
Мне представлялось логичным, что при начальной установке системы (с условной флешки) туда уже должна быть заложена определенная базовая конфигурация в виде тех же сервисных аккаунтов с нужными публичными ключами. Но в целом ваш юзкейс тоже понятен.
Ansible, bash и я: три мушкетёра в мире автоматизации управления компьютерами на Linux