У меня такой опыт есть. Нужно, наверное, отдельную статью написать. Fleeting Plugin мы тоже пробовали, как и автоскейлинг на лямбдах. Все равно везде получались свои недостатки. У Fleeting - довольно большое время реакции (время сырого старта инстанса из AMI - порядка минуты) и медленное масштабирование. Плюс сам основной раннер, отслеживающий очередь джоб и стартующий экзекьюторы, тоже в итоге становится боттлнеком и при большом потоке джоб начинает тормозить, а то и вообще зависает, делая весь CI нерабочим.
В CI там запускается простая конструкция ansible-test для sanity, которую вы легко бы запустили у себя локально, если бы потратили на это чуток времени.
Тесты писать не всегда просто, но без них поддерживать модуль в дальнейшем будет сложно, т.к. нет гарантий что не поймаешь какую-то регрессию при обновлении каких-то зависимостей.
По Ansible модулю. Сама идея хорошая и контрибьют приветствуется. Только пока что модуль еще на этапе код ревью и PR не принят. Я бы на вашем месте дождался хотя бы апрува и мержа в develop, если не ближайшего релиза, прежде чем рекламировать свои достижения. Тогда модулем могли бы сразу воспользоваться все желающие, узнавшие о нем из статьи. А сейчас это доступно лишь избранным энтузиастам, не поленившимся скачать сырой код из вашего форка ради экспериментов.
Сам код модуля на вид довольно сырой. Отсутствуют integration тесты. Ну, и на данный момент, насколько я могу видеть, код не проходит даже первичные quality gates в виде линтеров вроде pep8. На вашем месте я бы освоил ansible-test и довел локально код до ума хотя бы в плане следования стандартам оформления. Чтобы вас не заворачивал на ревью тупой автолинтер по формальным признакам.
—Извините, Ваш пароль используется более 30 дней, необходимо выбрать новый! — Розы. — Извините, слишком мало символов в пароле! — Розовые розы. — Извините, пароль должен содержать хотя бы одну цифру! — 1 розовая роза. — Извините, не допускается использование пробелов в пароле! — 1розоваяроза. — Извините, необходимо использовать как минимум 10 различных символов в пароле! — 1грёбанаярозоваяроза. — Извините, необходимо использовать как минимум одну заглавную букву в пароле! — 1ГРЁБАНАЯрозоваяроза. — Извините, не допускается использование нескольких заглавных букв, следующихподряд! — 1ГрёбанаяРозоваяРоза. — Извините, пароль должен состоять более чем из 20 символов! — 1ГрёбанаяРозоваяРозаБудетТорчатьУтебяИзЗадницыЕслиТыНеДашьМнеДоступПрямоБлтьСейчас! — Извините, этот пароль уже занят.
При выполнении slurp большую часть времени займет считывание файла, тем более если по сети. Эти микросекунды на перекодировку никакой погоды не сделают.
интересно как бы быстро работал ansible на rust'е)
Можете собрать и потестить. Рабочий вариант уже есть. Большая часть автоматизации никакой особой скорости не требует. Благо, не 3D-моделирование автоматизируют обычно. Скорость сценариев автоматизации обычно упирается в скорость API сервисов, с которыми взаимодействует тот же Ansible, скорости ввода-вывода, файловые операции, задержки на сетевой обмен и т.п. Все это никак не решается растом.
Тут получается усложненная логика применения, которую легко пропустить на ревью. Вот только на днях сталкивался. Коллеги (любители тегов) поменяли в роли import_tasks на include_tasks и удивлялись, почему роль вдруг перестала работать.
Остается вопрос - зачем проливать кровь и пот над тегами, если аналогичного результата можно добиться другими стандартными средствами, не имеющими таких издержек?
Он создаст ключ, потом должен руками скопировать его на флешку и как то положить на админский хост? Выглядит как bad practice
Он создает ключ и передает его на админский хост как то? Если есть такие знания, то моя утилита будет полезна лишь от части
Мне представлялось логичным, что при начальной установке системы (с условной флешки) туда уже должна быть заложена определенная базовая конфигурация в виде тех же сервисных аккаунтов с нужными публичными ключами. Но в целом ваш юзкейс тоже понятен.
Не в любой. И даже в Linux он не везде есть отнюдь.
В закрытом контуре можно использовать bash и zenity , как сертифицированное ПО, в отличии от либ питона, которые многие отделы ИБ не пропускают в контур.
Вы все равно туда включаете Ansible, который уже тянет с собой туеву хучу питоновских зависимостей. Смысл экономить на одной либе?
Я, собственно, к чему. Против zenity и Bash как таковых ничего против не имею, но ваша реализация вызова Ansible кажется мне неоптимальной. Если уж строить сценарии автоматизации на Ansible, то количество кода на Bash желательно сводить к минимуму.
Вообще, использование zenity в контексте Ansible - довольно интересный юзкейс. Думаю, можно сделать свой action-plugin для Ansible PyZenity и вызывать эти диалоги прямо из контекста Ansible, получая ваши любимые диалоговые окна вместо консоли. А если сделать кастомный callback-плагин с PyZenity, то можно и вывод Ansible из консольного в GUI перевести.
У меня такой опыт есть. Нужно, наверное, отдельную статью написать. Fleeting Plugin мы тоже пробовали, как и автоскейлинг на лямбдах. Все равно везде получались свои недостатки. У Fleeting - довольно большое время реакции (время сырого старта инстанса из AMI - порядка минуты) и медленное масштабирование. Плюс сам основной раннер, отслеживающий очередь джоб и стартующий экзекьюторы, тоже в итоге становится боттлнеком и при большом потоке джоб начинает тормозить, а то и вообще зависает, делая весь CI нерабочим.
В CI там запускается простая конструкция ansible-test для sanity, которую вы легко бы запустили у себя локально, если бы потратили на это чуток времени.
Тесты писать не всегда просто, но без них поддерживать модуль в дальнейшем будет сложно, т.к. нет гарантий что не поймаешь какую-то регрессию при обновлении каких-то зависимостей.
По Ansible модулю. Сама идея хорошая и контрибьют приветствуется. Только пока что модуль еще на этапе код ревью и PR не принят. Я бы на вашем месте дождался хотя бы апрува и мержа в develop, если не ближайшего релиза, прежде чем рекламировать свои достижения. Тогда модулем могли бы сразу воспользоваться все желающие, узнавшие о нем из статьи. А сейчас это доступно лишь избранным энтузиастам, не поленившимся скачать сырой код из вашего форка ради экспериментов.
Сам код модуля на вид довольно сырой. Отсутствуют integration тесты. Ну, и на данный момент, насколько я могу видеть, код не проходит даже первичные quality gates в виде линтеров вроде pep8. На вашем месте я бы освоил ansible-test и довел локально код до ума хотя бы в плане следования стандартам оформления. Чтобы вас не заворачивал на ревью тупой автолинтер по формальным признакам.
Напомнило старую копипасту:
Или нет
А потом в вашем bare-metal в самый неподходящий момент вылетает критичная железяка, которой нигде нет у поставщиков в наличии...
Я так и не понял смысла в системе, которая по всем параметрам уступает любому обычному внешнему SSD.
При выполнении slurp большую часть времени займет считывание файла, тем более если по сети. Эти микросекунды на перекодировку никакой погоды не сделают.
Можете собрать и потестить. Рабочий вариант уже есть. Большая часть автоматизации никакой особой скорости не требует. Благо, не 3D-моделирование автоматизируют обычно. Скорость сценариев автоматизации обычно упирается в скорость API сервисов, с которыми взаимодействует тот же Ansible, скорости ввода-вывода, файловые операции, задержки на сетевой обмен и т.п. Все это никак не решается растом.
https://docs.ansible.com/ansible/latest/cli/ansible-pull.html
Если кто не в курсе
Еще упущен момент, что Ansible по pull модели тоже может работать вполне. Хоть там и не такой богатый инструментарий, как у Puppet в этом случае.
Ты кто такой давай техзадание,
Ты кто такой давай техзадание,
Ты кто такой давай техзадание...
Он с тобой все обсудить попытается,
Отчет, аудит всучить пытается.
Знаешь, где реальный дело начинается?
Только там где ТЗ появляется!
А теперь товарищ, внимание -
Нету ТЗ - давай до свидания!
Правка конфига вместо темплейта
Башсибл на пустом месте вместо стандартных модулей
ignore_errors без хендлинга исключений
Вы решили поставить рекорд по количеству антипаттернов в статье с примерами кода Ansible?
Серьезно? :)
Тут получается усложненная логика применения, которую легко пропустить на ревью. Вот только на днях сталкивался. Коллеги (любители тегов) поменяли в роли import_tasks на include_tasks и удивлялись, почему роль вдруг перестала работать.
Остается вопрос - зачем проливать кровь и пот над тегами, если аналогичного результата можно добиться другими стандартными средствами, не имеющими таких издержек?
Мне представлялось логичным, что при начальной установке системы (с условной флешки) туда уже должна быть заложена определенная базовая конфигурация в виде тех же сервисных аккаунтов с нужными публичными ключами. Но в целом ваш юзкейс тоже понятен.
Не в любой. И даже в Linux он не везде есть отнюдь.
Вы все равно туда включаете Ansible, который уже тянет с собой туеву хучу питоновских зависимостей. Смысл экономить на одной либе?
Я, собственно, к чему. Против zenity и Bash как таковых ничего против не имею, но ваша реализация вызова Ansible кажется мне неоптимальной. Если уж строить сценарии автоматизации на Ansible, то количество кода на Bash желательно сводить к минимуму.
Вообще, использование zenity в контексте Ansible - довольно интересный юзкейс. Думаю, можно сделать свой action-plugin для Ansible PyZenity и вызывать эти диалоги прямо из контекста Ansible, получая ваши любимые диалоговые окна вместо консоли. А если сделать кастомный callback-плагин с PyZenity, то можно и вывод Ansible из консольного в GUI перевести.
Кем создается? И почему этот кто-то не может создать пару ключей для этого же админа?