А на сервере лежит плагин, который умеет делать только именно эту штуку.

это отлично решается чере pssh и sudoers

без всяких наворотов

Только не даёт такой гибкости типа: - выполнить там, где факт role =~ balancer-[0-3] - там, где подключен класс паппета такой-то, пригнать паппет незамедлительно И единственное, что надо, чтобы это работало при наличии mcollective — положить ключи и выдать права. Да, это не новая задача, и да, есть другие решения. Но эти решения меньше интегрируются в существующую инфраструктуру Puppet и дают меньше гибкости.

Это как бы круто звучит но запуск агента по классу редко кода нужен, чаще по роли а это просто списки хостов.

Субъективно конечно

Ну списки хостов меняются постоянно.

У нас даже Ansible здорово завязан на PuppetDB, что позволяет делать подобные же штуки. Очень удобно.

А то так получается: — Кто опять забыл сделать git pull?! Тихо из угла: — Бл* :(

Не проблема эти списки генерить на основе site.pp вот вобще

Нууу

Это совсем другая проблема

Да, теперь, когда нет наследования нод, действительно меньше проблем.

Это совсем другая проблема

Не соглашусь. Надо строить рабочий процесс так, чтобы при любой запаре было меньше возможностей накосячить.

С этим трудно спорить

Но вы же решаете эту же проблему в ансибле ?

И параллельные запуски )

Ансибл используется только ограниченным количеством людей. Обычно теми, у кого и так есть рут на серверах.

Паппет — это инструмент, к которому мы давали доступ желающим. Знаешь паппет — вперёд, можешь что-то шевелить на сервере. Все деплои только так. Просто так доступ — отдельная процедура.

Я понимаю, что наш случай — это наш случай и не везде так. И у нас это, кстати, работало через раз :(

Как это бъется с количеством косяков и приносимыми им проблемами ?

Или просто решили что там где будет ансибл эта проблема не проблема вовсе ?

Как это бъется с количеством косяков и приносимыми им проблемами ?

Валидация кода. Я написал целый велосипед, который отбивает код, не подходящий под правила.

Например, нельзя включать классы мимо ноды, нельзя пушить код, в котором есть определённые классы без авторизации. Очевидно, нельзя запушить невалидный код.

Нельзя пушить пользовательские функции и факты на руби.

Странная тема а почему нельзя было сделать микрокостыль чека версии ?

В кейсе с незапуленным паппетом

Поясни чуть больше?

Ну проверять что пытаются катить не последнюю версию и верещать об этом

Если я правильно понял проблему.

Паппет — это инструмент, к которому мы давали доступ желающим. Знаешь паппет — вперёд, можешь что-то шевелить на сервере. Все деплои только так. Просто так доступ — отдельная процедура.

Эм, а не страшно продакшен сломать?

Возможно туплю, т.к. выпил, но при чём тут последняя версия? Надо сделать так, чтобы только правильные люди могли пушить специфичный код, который может потенциально привести к тем штукам, которые видеть не хочется. Не хочется, чтобы: - любой, кто может пушить в репу с кодом паппета, мог исполнять код на паппет-мастере: запрет на пуш функций - нельзя включать классы на верхнем уровне scope, чтобы не подключалось на всех нодах окружения - любому желающему нельзя править правила файрволла через класс ferm - ... Очевидно, это больше защита от дурака. Желающий, понятное дело, это обойдёт. На детектирование таких вещей заточены другие инструменты

Эм, а не страшно продакшен сломать?

У нас несколько environments

От продакшна вообще вилами гоняем

У нас сейчас ансибл, но если бы был паппет, я бы делала по бранчу и энвайроменту на фичу, а продакшен через код ревью перед спринтом

У нас сейчас ансибл, но если бы был паппет, я бы делала по бранчу и энвайроменту на фичу, а продакшен через код ревью перед спринтом

Во.

В продакшн пускаем merge requestЫ, например

Там только не бранчи даже, а отдельные группы в гитлабе

А как это все делаете?

Я чуть выше писал про велосипед, который код валидирует. Он же его при успешной валидации таскает на мастера.

Скриптами?

Поделка на Синатре с апишечкой.

Поделка на Синатре с апишечкой.

Можно подробнее?

У нас, кстати, не только GitLab, но ещё и древний SVN. И там, и там есть код паппета, который надо таскать на мастера и валидировать все коммиты. Итак, есть приложение. Оно сидит на каждом мастере и мониторит состояние локального кода. Как только происходит пуш в гитлаб, через API этот код передаётся одному из инстансов этого приложения на валидацию. Если всё ОК, оно говорит, что ОК, можешь принимать пуш. Если нет — отбивает, отдавая в stderr сообщение с ошибками, которое потом передаётся клиенту (ты сразу после команды git push видишь в консоли, что 1. синтаксис кривой тут 2. тут другой косяк 3. т.п.). Если всё ОК, приложуха командует остальным мастерам обновить код. Команда ставится в очередь на выполнение.

Тут более детально сложно рассказывать, не углубляясь в API гитлаба, например и говнокод, который я понаписал. Почему нам не подошла r10k — это потому, что оно вроде тогда не умело в гитлаб и точно не умело вещи типа "достать все репозитории из группы production"

А гитлаб это надстройка над гитом с которой можно такие штуки проворачивать?

Возможно туплю, т.к. выпил, но при чём тут последняя версия? Надо сделать так, чтобы только правильные люди могли пушить специфичный код, который может потенциально привести к тем штукам, которые видеть не хочется. Не хочется, чтобы: - любой, кто может пушить в репу с кодом паппета, мог исполнять код на паппет-мастере: запрет на пуш функций - нельзя включать классы на верхнем уровне scope, чтобы не подключалось на всех нодах окружения - любому желающему нельзя править правила файрволла через класс ferm - ... Очевидно, это больше защита от дурака. Желающий, понятное дело, это обойдёт. На детектирование таких вещей заточены другие инструменты

вопрос "пушить в репор" решается ревью как бы не ?

субъективно всё это какие то странные решения, которые дают псевдозащиту.

непонтно зачем на них тратить время если всё равно защиту они не дают, а экономят.... ну хз. много ли времени.

и если "мёрджит в прод" всё равно человек отвественный за всё это и потом смотрит глазами что ок доехало, то непонятно зачем эти сложные автопроверки выходящие за рамки линтера )

А гитлаб это надстройка над гитом с которой можно такие штуки проворачивать?

Гитлаб это вроде локального битбакета,

Ну, когда паранойя мучает :)

Битбакет на своём сервере

Впрочем, в двух конторах, где я работала, я его таки ставила сама, ТК менеджера она (паранойя) мучала, поэтому не SaaS

Но мы всякие группы не юзали. В одной конторе юзали тикетницу гитлаба, но она там убогая, и плохая для AGILE

Забавно было, что в первой конторе стандарт был паппет, так что я для установки гитлаба писала враппер вокруг их официального установщика на шефе

Забавно было, что в первой конторе стандарт был паппет, так что я для установки гитлаба писала враппер вокруг их официального установщика на шефе

Есть вполне рабочий пуппет модуль

На фордже

Неужели на этом канале теперь есть жизнь ;)?

А разве ее не было ?

Я сегодня снова попробую настроить тачки с помощью puppet'а и засыплю вас вопросами, можно?) Индусы там что-то понакоммитили, вдруг MacOS 10.12 заведется ?

Общий вопрос: есть ли какая-то непрерывная интеграция для puppet пакетов? Или как вообще тестируют puppet-пакеты?

serverspec

Кек

Кек

Угу

привет. А кто сталкивался в puppetdb с ёOutOfMemoryError: Java heap space? Я этой твори уже 5Гб выделил, а оно все эксепшенами гадит

или я как-то не так память под JVM выделяю?

или я как-то не так память под JVM выделяю?

покажите

разобрался уже. Зависшие коммиты к постгресу из-за не возможности доставить репорты

разобрался уже. Зависшие коммиты к постгресу из-за не возможности доставить репорты

интересно

Это на четвёрке, да?

неа, 3.8

а зачем паппетдб использует kahadb?

уже вроде нет

они съехали же с эктива на свою реализацию.

PuppetDB 4.3.0 is a backward-compatible feature release that changes the way PuppetDB handles incoming commands. Previously they were stored in ActiveMQ for future processing, but now they’re being handled by stockpile. This should increase performance and may decrease the maximum heap required for a given workload. Please see the queue information in the support guide if you’re interested in the details.

https://docs.puppet.com/puppetdb/latest/pdb_support_guide.html#message-queue

у меня паппетдб 2.3.8 так исторически сложилось

У меня тоже так было год назад но я начал активно двигать историю вперед )

И сейчас серверная часть актуальная вся

А агенты до сих пор 3.8.7

а реально будет паппет 3.8.7 подружить с дб 4+?

или сразу все апгрейдить?

а реально будет паппет 3.8.7 подружить с дб 4+?

попробуй в виртуалке на лабе

потестить все свои манифесты/модули