Потому что порог входа сильно выше. В минимальном варианте Linux way - это BolgenOS с нескучными обоями, а Windows way - ReactOS - надо именно что поддерживать и развивать.
Прочитал. Протёр глаза, сказал "брррррр!", умылся холодной водой, заглянул в дерево исходников Ansible - но нет, статья всё также осталась откровенной дичью. Объясню по пунктам свою точку зрения.
В нём есть какой-то action plugin, и он отправляет запрос на исполнение модуля на каком-то удаленном хосте.
В дереве исходников Ansible не существует такого action-плагина, который "отправляет запрос на исполнение модуля на каком-то удалённом хосте". Вот это поворот, правда? И можно даже не доставать контраргумент в виде action-плагина template, который внутри себя вызывает модуль copy - это и так общеизвестный факт. Только вот сам "модуль" copy - не модуль, а action-плагин. Только ведь в статье же не об этом action-плагине говорилось? Скиньте, пожалуйста, ссылку на этот волшебный action-плагин в дереве исходников Ansible, я реально с превеликим удовольствием углублю свои познания во внутреннем устройстве инструмента.
Установка зависимостей через "pip install" - это прямо праздник непослушания какой-то. Нормально написанные модули не таскают с собой развесистые клюквы зависимостей, а если всё-таки зависимости нужны, то это делается с уважением ко времени и силам того, кто будет использовать модуль. Достаточно просто сложить зависимости в проект по предопределённым путям (lib + module_utils, просто почитайте материалы об этом в Интернете и на Хабре), и тогда и модуль, и зависимости будут автомагически подгружаться Ansible, без малейших усилий со стороны автора или пользователя модуля .
Хелпер module_utils
Что, простите? Это не "хелпер", а Python-пакет (если в каталоге есть файл __init__.py, то Python расматривает этот каталог как пакет). Правильно ли я понимаю, что "...оптимизация на пустом месте – она никогда ещё лишней не была..." (С), и в данном случае странное нерусское слово - просто ярлычок для того, в чём вам не захотелось разбираться?
По поводу использования contextmanager. Вся экономия на спичках в виде замены вызовов dict() на создание словарей-литералов с помощью фигурных скобок умерла примерно где-то в районе import contextlib.
try:
import syslog
HAS_SYSLOG = True
except ImportError:
HAS_SYSLOG = False
try:
from systemd import journal, daemon as systemd_daemon
# Makes sure that systemd.journal has method sendv()
# Double check that journal has method sendv (some packages don't)
# check if the system is running under systemd
has_journal = hasattr(journal, 'sendv') and systemd_daemon.booted()
except (ImportError, AttributeError):
# AttributeError would be caused from use of .booted() if wrong systemd
has_journal = False
HAVE_SELINUX = False
try:
from ansible.module_utils.compat import selinux
HAVE_SELINUX = True
except ImportError:
pass
Кстати, если уж очень хочется самовыражаться в коде модуля (все мы это иногда делаем, чего уж там): для сообщения об отсутствующей внешней зависимости с 2018 года есть штатная функция missing_required_lib.
Про инвентори. INI-инвентори в 2022? Серьёзно? Он как формат умер лет шесть назад, с возвращением из забытья YaML-формата, так что оставьте уже, пожалуйста, INI покоиться с миром. Его популярность в русскоязычных видео по Ansible на YouTube говорит только о том, что авторы этих видео не горят желанием осваивать ничего нового, но не более.
Это я уж не говорю, что очень странно в оформлении сниппеты кода кидать картинками там, где у хабраразметки есть специальный тег (тем более, что код можно убирать под спойлеры). Хотя нет, я, кажется, понял: речь о том, чтобы, ничего не меняя, использовать готовые слайды с лекций (facepalm.jpg).
Если подытожить, то вся подача материала очень напоминает карго-культ: в основном всё про ритуалы-ритуалы-ритуалы без знания основ и, как результат, без малейших объяснений, почему конкретный приём нужен и как работает под капотом.
Так что вот вам моя честная и открытая просьба: пожалуйста, хотя бы из уважения к вложенным усилиям авторов инструмента, не беритесь учить других тому, в чём не слишком хорошо и глубоко разбираетесь.
Довелось мне работать вахтой в компании-подрядчике на обслуживании одного из крупных месторождений в Тюменской области в 2013-2014 годах. Так вот, ещё перед приездом туда руководители чётко объяснили: появился без средств защиты (спецодежда, каска, перчатки, очки) на объекте - штраф тебе лично 30К, на компанию 100К. "Переключили не то" - штраф за останов прокачки на компанию 1КК, и потом за каждый час сверху 100К (spice must flow, you know).
Платили, естественно, заметно выше, чем средняя по региону на тот момент (всё честно: ответственность выше - оплата выше).
Так вот, реально сразу становишься пипец какой внимательный, и все свои действия проверяешь не семь, а сто семь раз, и работаешь, естественно, с напарником, чтобы не ошибиться ни в коем случае. И никаких проблем с дисциплиной, хотя ближайщий начальник только в телефоне, больше чем в 500 километрах от тебя.
Контейнер не является ковром, под который может позволить себе замести грязь нерадивый уборщик. В лучшем случае он побудет способом доставки абсолютно той же зависимости psycopg2, у которой, кстати, прямо в доке предпочитаемым способом использования обозначена сборка из исходников, в худшем - будет использован первый попавшийся контейнер, наглухо протрояненный.
Если делегировать на контроллер или ещё хзкуда, то сначала придётся настроить pg_hba.conf на целевом сервере, так что лучше, увы, не стало.
Мой посыл очень прост - проекты на Ansible не только должны, но и могут быть самодостаточными, без всяких "yum install вон то", "apt-get install вот это", "pip install то - не знаю что".
Я в энтерпайзе живу - у нас Ansible имеет версию 2.9.27, а коллекции бесполезны, ибо всё происходит внутри тридевятого окружения за тридесятым файрволом :-))))
Но мысль насчёт "выложить в коллекцию" всё равно интересная, и я её, конечно, обещаю обдумать.
Вообще - пробовал, решает. Только идея статьи в том, чтобы найти возможость не ставить ничего лишнего на целевой хост, потому что это против изначального концепта инструмента.
Пожалуйста! Читайте, и кормите свою любознательность досыта: пусть приносит вам только пользу :-)
Я не знаю, заинтересованы ли мейнтейнеры репы community в таких штуках. Если судить не по абстрактным рассуждениям, а по действиям, то всех устраивает текущее положение вещей. Соответственно, не вижу смысла кому-либо навязываться.
Если мы говорим про пакеты - то на CentOS одинаково доступны и python-psycopg2 (см.выше), и python3-psycopg2. И ровно по тем же соображениям не вижу смысла тащить этот пакет на серверы БД: он там не нужен.
В принципе установка этого пакета - да, решает проблему зависимости, но мы же говорим о минимальном "отпечатке" и хотя бы минимальной ИБ-гигиене? На мой взгляд, установка пакета на сервер БД, то есть туда, где этот пакет вообще-то не нужен для основных задач, выполняемых хостом - это в чистом виде облегчение атаки потенциальному злоумышленнику. Что-то в духе "слушай, мы тут тебе пакетик удобный питонячий залили - располагайся, чувствуй себя как дома".
Объясняю. Без установки питонячьей зависимости (а именно - psycopg2, на КДПВ есть) Ansible - инструмент, который изначально задумывался как легковесный и безагентный - оказывается непригодным для провизионирования PostgreSQL, потому что модули "искаропки" рассчитаны именно на эту зависимость.
1. Создатели "MSPOS-K" - НТЦ "Альфа-Проект" (см. пруф). 2. Незаслуженно не раскрыта тема, важная для многих небольших ИП: возможность одной физической онлайн-кассой, стоящей на торговой точке, и выдавать чеки покупателям, и обслуживать интернет-магазин. Почему я считаю её важной - потому, что в период "нерабочих рабочих дней" продажи онлайн становятся всё более актуальными. И это точно умеет делать Модуль.Касса - приложение для ПТК "MSPOS-K", а про историю работы с ними можно прочитать в статье (раздел называется "Онлайн-кассу нннада?...")
На Хабре была просто шикарная статья, которая описывала всю дичь вокруг блютус-кодеков - там всё расписано достаточно подробно.
А если вдруг захочется на Win7/Win10 послушать AptX - фигушки, беспременно нужен адаптер, производитель которого купил лицензию на кодек (соответственно, шанс купить такой адаптер в ближайшем киоске/магазине электроники близки к нулю). Если что, даже на встроенном блютусе/вайфае от Intel в приличном вендорском ноутбуке это не так. Ну или вдруг захочется на Win7 BLE завести - так тоже облом ждёт за углом.
Справедливости ради - https://github.com/nginx/agent.
Потому что порог входа сильно выше. В минимальном варианте Linux way - это BolgenOS с нескучными обоями, а Windows way - ReactOS - надо именно что поддерживать и развивать.
UPD. Исправил пару очепяток. @ajijiadduh, благодарю!
Видел стенд Nixys на DevOpsConf. Как-то это не вяжется с техническим уровнем статьи.
Прочитал. Протёр глаза, сказал "брррррр!", умылся холодной водой, заглянул в дерево исходников Ansible - но нет, статья всё также осталась откровенной дичью. Объясню по пунктам свою точку зрения.
В дереве исходников Ansible не существует такого action-плагина, который "отправляет запрос на исполнение модуля на каком-то удалённом хосте". Вот это поворот, правда? И можно даже не доставать контраргумент в виде action-плагина template, который внутри себя вызывает модуль copy - это и так общеизвестный факт. Только вот сам "модуль" copy - не модуль, а action-плагин. Только ведь в статье же не об этом action-плагине говорилось? Скиньте, пожалуйста, ссылку на этот волшебный action-плагин в дереве исходников Ansible, я реально с превеликим удовольствием углублю свои познания во внутреннем устройстве инструмента.
Установка зависимостей через "pip install" - это прямо праздник непослушания какой-то. Нормально написанные модули не таскают с собой развесистые клюквы зависимостей, а если всё-таки зависимости нужны, то это делается с уважением ко времени и силам того, кто будет использовать модуль. Достаточно просто сложить зависимости в проект по предопределённым путям (lib + module_utils, просто почитайте материалы об этом в Интернете и на Хабре), и тогда и модуль, и зависимости будут автомагически подгружаться Ansible, без малейших усилий со стороны автора или пользователя модуля .
Что, простите? Это не "хелпер", а Python-пакет (если в каталоге есть файл __init__.py, то Python расматривает этот каталог как пакет). Правильно ли я понимаю, что "...оптимизация на пустом месте – она никогда ещё лишней не была..." (С), и в данном случае странное нерусское слово - просто ярлычок для того, в чём вам не захотелось разбираться?
По поводу использования contextmanager. Вся экономия на спичках в виде замены вызовов dict() на создание словарей-литералов с помощью фигурных скобок умерла примерно где-то в районе import contextlib.
Импорты пакетов/модулей в кодовой базе Ansible принято делать вполне определённым образом,
а именно:
Кстати, если уж очень хочется самовыражаться в коде модуля (все мы это иногда делаем, чего уж там): для сообщения об отсутствующей внешней зависимости с 2018 года есть штатная функция missing_required_lib.
Про инвентори. INI-инвентори в 2022? Серьёзно? Он как формат умер лет шесть назад, с возвращением из забытья YaML-формата, так что оставьте уже, пожалуйста, INI покоиться с миром. Его популярность в русскоязычных видео по Ansible на YouTube говорит только о том, что авторы этих видео не горят желанием осваивать ничего нового, но не более.
Это я уж не говорю, что очень странно в оформлении сниппеты кода кидать картинками там, где у хабраразметки есть специальный тег (тем более, что код можно убирать под спойлеры). Хотя нет, я, кажется, понял: речь о том, чтобы, ничего не меняя, использовать готовые слайды с лекций (facepalm.jpg).
Если подытожить, то вся подача материала очень напоминает карго-культ: в основном всё про ритуалы-ритуалы-ритуалы без знания основ и, как результат, без малейших объяснений, почему конкретный приём нужен и как работает под капотом.
Так что вот вам моя честная и открытая просьба: пожалуйста, хотя бы из уважения к вложенным усилиям авторов инструмента, не беритесь учить других тому, в чём не слишком хорошо и глубоко разбираетесь.
Довелось мне работать вахтой в компании-подрядчике на обслуживании одного из крупных месторождений в Тюменской области в 2013-2014 годах. Так вот, ещё перед приездом туда руководители чётко объяснили: появился без средств защиты (спецодежда, каска, перчатки, очки) на объекте - штраф тебе лично 30К, на компанию 100К. "Переключили не то" - штраф за останов прокачки на компанию 1КК, и потом за каждый час сверху 100К (spice must flow, you know).
Платили, естественно, заметно выше, чем средняя по региону на тот момент (всё честно: ответственность выше - оплата выше).
Так вот, реально сразу становишься пипец какой внимательный, и все свои действия проверяешь не семь, а сто семь раз, и работаешь, естественно, с напарником, чтобы не ошибиться ни в коем случае. И никаких проблем с дисциплиной, хотя ближайщий начальник только в телефоне, больше чем в 500 километрах от тебя.
В тридевятом энтерпрайзе, за тридесятым файрволом жили-были ИБшники. Невзлюбили они ssh-туннели.... Но это совсем другая история.
Контейнер не является ковром, под который может позволить себе замести грязь нерадивый уборщик. В лучшем случае он побудет способом доставки абсолютно той же зависимости psycopg2, у которой, кстати, прямо в доке предпочитаемым способом использования обозначена сборка из исходников, в худшем - будет использован первый попавшийся контейнер, наглухо протрояненный.
Если делегировать на контроллер или ещё хзкуда, то сначала придётся настроить pg_hba.conf на целевом сервере, так что лучше, увы, не стало.
Мой посыл очень прост - проекты на Ansible не только должны, но и могут быть самодостаточными, без всяких "yum install вон то", "apt-get install вот это", "pip install то - не знаю что".
Я в энтерпайзе живу - у нас Ansible имеет версию 2.9.27, а коллекции бесполезны, ибо всё происходит внутри тридевятого окружения за тридесятым файрволом :-))))
Но мысль насчёт "выложить в коллекцию" всё равно интересная, и я её, конечно, обещаю обдумать.
Вообще - пробовал, решает. Только идея статьи в том, чтобы найти возможость не ставить ничего лишнего на целевой хост, потому что это против изначального концепта инструмента.
Пожалуйста! Читайте, и кормите свою любознательность досыта: пусть приносит вам только пользу :-)
Я не знаю, заинтересованы ли мейнтейнеры репы community в таких штуках. Если судить не по абстрактным рассуждениям, а по действиям, то всех устраивает текущее положение вещей. Соответственно, не вижу смысла кому-либо навязываться.
Если мы говорим про пакеты - то на CentOS одинаково доступны и python-psycopg2 (см.выше), и python3-psycopg2. И ровно по тем же соображениям не вижу смысла тащить этот пакет на серверы БД: он там не нужен.
Лично я тоже системным пакетам больше доверяю - они хотя бы подписаны и всё такое, только вот "pip install psycopg2" им почему-то не доверяет.
В принципе установка этого пакета - да, решает проблему зависимости, но мы же говорим о минимальном "отпечатке" и хотя бы минимальной ИБ-гигиене? На мой взгляд, установка пакета на сервер БД, то есть туда, где этот пакет вообще-то не нужен для основных задач, выполняемых хостом - это в чистом виде облегчение атаки потенциальному злоумышленнику. Что-то в духе "слушай, мы тут тебе пакетик удобный питонячий залили - располагайся, чувствуй себя как дома".
UPD Исправлена очепятка - благодарю,@emaxx!!!
Объясняю.
Без установки питонячьей зависимости (а именно - psycopg2, на КДПВ есть) Ansible - инструмент, который изначально задумывался как легковесный и безагентный - оказывается непригодным для провизионирования PostgreSQL, потому что модули "искаропки" рассчитаны именно на эту зависимость.
Есть пара замечаний по статье.
1. Создатели "MSPOS-K" - НТЦ "Альфа-Проект" (см. пруф).
2. Незаслуженно не раскрыта тема, важная для многих небольших ИП: возможность одной физической онлайн-кассой, стоящей на торговой точке, и выдавать чеки покупателям, и обслуживать интернет-магазин. Почему я считаю её важной - потому, что в период "нерабочих рабочих дней" продажи онлайн становятся всё более актуальными. И это точно умеет делать Модуль.Касса - приложение для ПТК "MSPOS-K", а про историю работы с ними можно прочитать в статье (раздел называется "Онлайн-кассу нннада?...")
Недоделанная директива "return" ?(http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return). Кажется, автор оригинальной статьи не любит читать документацию.
На Хабре была просто шикарная статья, которая описывала всю дичь вокруг блютус-кодеков - там всё расписано достаточно подробно.
А если вдруг захочется на Win7/Win10 послушать AptX - фигушки, беспременно нужен адаптер, производитель которого купил лицензию на кодек (соответственно, шанс купить такой адаптер в ближайшем киоске/магазине электроники близки к нулю). Если что, даже на встроенном блютусе/вайфае от Intel в приличном вендорском ноутбуке это не так. Ну или вдруг захочется на Win7 BLE завести - так тоже облом ждёт за углом.