Comments 9
системы с поддержкой WSL (Windows Subsystem for Linux) позволяют запускать дистрибутивы Linux без накладных расходов на виртуальные машины.
WSL2 является виртуальной машиной
when: path_var.stat.exists is not definedЭто условие будет всегда ложным, потому что переменная exists определена всегда, даже если файл не существует (тогда она будет иметь значение false)
Правильно так: when: not path_var.stat.exists
А ещё странно, что в тексте статьи отсутствует таск с собственно модулем stat
Уж лучше бы рассказали про AWX Operator
Нет, это простой и эффективный инструмент... на человекочитаемом языке YAML... сродни файлам README.
Ха. YAML нифига не человекочитаемый, а скорее беспощадный к любому огреху. Поставили лишний пробел или табуляцию? Получаете ошибку. Затесался лишний нечитаемый символ? Ошибка. Не поставили двоеточие? Ловите ошибку. Ах поставили двоеточие? Снова ловите ошибку, ведь вы забыли про отступы. Когда надо ставить двоеточие? Вроде всегда, но заранее не знаешь, нужно внимательно читать доки. Всё равно не работает? Наверное, нужно поставить тирэ, ведь это новый элемент списка. Теперь работает? Вроде ошибок не выдаёт, но кажется снова отступы забыли поставить...
И вот все эти миллион мучений просто из-за чертовски придирчивого синтаксиса. И вместо того, чтобы тратить время на логику и правильный деплой - время тратится на борьбу с синтаксисом.
И если тот же json можно легко проверить на валидацию, то в yaml почти любой вариант будет валидный, но ты заранее не знаешь, всё ли ты сделал правильно. От этого его правильность можно проверять, только запуская чекер в самом ansible , а не каким-то встроенным плагином (по кр.мере я не нашел).
Ха. YAML нифига не человекочитаемый, а скорее беспощадный к любому огреху.
Плюс комментарию, плюс в карму!
Сначала был XML, в котором всё было понятно и только иногда случались холивары по поводу того, что тут поставить — атрибут или вложенный тег. И было куча инструментов. И DTD и XSL, всё было отлично. Но нам казалось, что это всё слишком многословно. Так оно, конечно и было, но всё же в формате были предусмотрены даже комментарии.
Потом появился JSON. Я помню, сильно радовался. Он казался таким элегантным, таким программистским, таким понятным. И не надо было ставить закрывающие теги, всё обходилось закрывающей фигурной скобкой. Я считал, что он идеален. И только потом выяснилось, что комментарии там не предусмотрены, валидация сложная, потому что типизации считай нет и ещё были какие-то проблемы. И ссылок не было предусмотрено, объекты приходилось копировать или придумывать велосипеды. Но по крайней мере там нельзя было полностью всё сломать, поставив лишний пробел. Однако и он показался нам слишком избыточным
И вот сделали YML. Про него в предыдущем комментарии неплохо написано. Хотя кто знает, может дело в том, что с xml и json я провёл гораздо больше времени )).
И ни в одном курсе по ansible не затрагивается вопрос управления windows серверами. А ведь там куча нюансов - многие из них описаны в документации, но часть надо где-то искать и спрашивать (службы, порты, версии powershell и ОС...)
Если контроллер (сервер) с ansible в домене, и я подключусь к нему по ssh доменным пользователем, можно ли выполнить плейбук без указания в нём (или ещё где-то) учётных данных (юзер, пасс)? Чтобы выполнился с моими учётными данными на всех указанных windows серверах (в домене).
Что значит "выполняются параллельно"? То есть если я укажу в инвентори 1000 серверов, на них ansible отправит разом команды? А сам контроллер от этого кони не двинет? А 10к, а 70к? И в каком порядке: 1 таск на все серверы, потом второй на все серверы...; или же все таски разом на все серверы отправляются. Или этим можно как-то управлять, скажем, ограничить количество одновременных коннектов. У нас, например, легко может "возбудиться" система контроля трафика или что-то ещё (их несколько). Да и если задания связаны будут со скачиванием чего-то, то массовое скачивание обернётся проблемами.
что-то ещё было, забыл уже.
Или этим можно как-то управлять, скажем, ограничить количество одновременных коннектов
можно, forks управляет значением максимальных "потоков" выполнения плейбука (коннекты, на самом деле, не всегда должны быть, к примеру, при перезагрузке сервера в рамках выполнения плейбука у вас не стартанет 31-ый, при значении forks = 30).
Ansible FAQ