Comments 27
Может объясните где здесь нищета Ансибля? Я вижу один блеск здесь.
Объясняю.
Без установки питонячьей зависимости (а именно - psycopg2, на КДПВ есть) Ansible - инструмент, который изначально задумывался как легковесный и безагентный - оказывается непригодным для провизионирования PostgreSQL, потому что модули "искаропки" рассчитаны именно на эту зависимость.
Всё равно не вижу нищеты. Всегда нужно для чего-то устанавливать зависимости. Блеск и нищета Убунту, чтобы работать с постгрес нужно установить постгрес.
В том то и дело. Для того чтобы из ansible работать s postgresql требовалось поставить не postgres а библиотеку которая за собой тащила кучу других библиотек, которые к тому же не всегда были в скомпилированном виде под все операционные системы. В результате часть зависимостей устанавливалась через ОС, часть через pip. А где-то приходилось собирать из исходников. Квест так себе. И чаще задумываешься а не проще ли дёргать psql на прямую из консольки через command или shell, но возможность получать поддержку check_mode при операциях с БД заставляет проходить эти круги ада.
UPD Исправлена очепятка - благодарю,@emaxx!!!
А что-нибудь вроде python-psycopg2 из системной репы не решает проблему?
В принципе установка этого пакета - да, решает проблему зависимости, но мы же говорим о минимальном "отпечатке" и хотя бы минимальной ИБ-гигиене? На мой взгляд, установка пакета на сервер БД, то есть туда, где этот пакет вообще-то не нужен для основных задач, выполняемых хостом - это в чистом виде облегчение атаки потенциальному злоумышленнику. Что-то в духе "слушай, мы тут тебе пакетик удобный питонячий залили - располагайся, чувствуй себя как дома".
Если он за собой не тянет gcc или *-devel (не проверял), то, кажется, что злоумышленник с таким же успехом может с собой pg8000 принести.
Я к тому, что я почему-то чуть больше доверяю системным пакетам, чем дополнительному коду внутри ансибл.
Лично я тоже системным пакетам больше доверяю - они хотя бы подписаны и всё такое, только вот "pip install psycopg2" им почему-то не доверяет.
А "pip install psycopg2-binary" случаем не решает проблему, не пробовали? Там предсобранные бинари, не требующие ничего от системы https://www.psycopg.org/docs/install.html#quick-install
За статью и репозиторий спасибо, познавательно.
То, что pip не доверяет системным пакетам, как раз и нормально.
Если не хочется ставить пакеты с клиентами БД на сервер БД можно делегировать таск на локалхост или вспомогательный сервер.
В общем, я бы сказал, что для Ansible надо стараться ставить системные пакеты, а pip использовать в виртуальных окружениях, но не для установки недостающих пакетов для Ansible.
Если делегировать на контроллер или ещё хзкуда, то сначала придётся настроить pg_hba.conf на целевом сервере, так что лучше, увы, не стало.
Мой посыл очень прост - проекты на Ansible не только должны, но и могут быть самодостаточными, без всяких "yum install вон то", "apt-get install вот это", "pip install то - не знаю что".
Спасибо, интересный разбор.
Вы его как коллекцию не планируете выложить? В идеале, до community бы дотащить...
В целом, боль при установке psychopg касается только центосей. На дебианах apt install python3-psycopg2 и всё пушисто.
Я не знаю, заинтересованы ли мейнтейнеры репы community в таких штуках. Если судить не по абстрактным рассуждениям, а по действиям, то всех устраивает текущее положение вещей. Соответственно, не вижу смысла кому-либо навязываться.
Если мы говорим про пакеты - то на CentOS одинаково доступны и python-psycopg2 (см.выше), и python3-psycopg2. И ровно по тем же соображениям не вижу смысла тащить этот пакет на серверы БД: он там не нужен.
снимаю шляпу, я бы руки рубил тем кто тянет в систему что-то в обход штатного пакетного менеджера..
упаковать ансибл и все приблуды в докер, не?
Контейнер не является ковром, под который может позволить себе замести грязь нерадивый уборщик. В лучшем случае он побудет способом доставки абсолютно той же зависимости psycopg2, у которой, кстати, прямо в доке предпочитаемым способом использования обозначена сборка из исходников, в худшем - будет использован первый попавшийся контейнер, наглухо протрояненный.
Спасибо! Буквально на прошлой неделе маялся с этим. Плюнул и решил все с помощью "pip3 install psycopg2". Теперь переделаю наверно плейбуки
Если есть достпу через ssh, то что мешает пробросить тунель с ноды на котроллер и подключаться к постгрессу со стороны контроллера? Тогда достаточно будет только на контроллере один раз установить psycopg2 любым способом и не тащить его на ноды.
PS: Я сам с Ansible не работал, поэтому не знаю на сколько моя идея "запускать код на контролере" вписывается в его концепцию.
Такая мысль постоянно витает при работе с почти чем угодно, но у неё есть определённые проблемы - как только мы начинаем городить альтернативный транспорт (а это - транспорт, просто поверх ssh). Одно из важных свойств ансибла - волшебная работа транспорта, о которой многие просто не задумываются. Как только в этом месте возникают нюансы и проблемы, модель плейбук начинает плыть (если оно ломается, оно ломается не в модуле и не в плейбуке, а где-то в другом месте).
В тридевятом энтерпрайзе, за тридесятым файрволом жили-были ИБшники. Невзлюбили они ssh-туннели.... Но это совсем другая история.
Блеск и нищета Ansible