Докер решает все эти проблемы

Докер не решает всё. Особенно когда его нет.

сделайте так чтоб был !

Начинаются проблемы с докером )

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

Докер решает все эти проблемы

Вот конкретно эту проблему он решает ни разу не лучше, чем рпм-билдер

Как разница где будет pip install -r req.txt - в докерфайле или в спеке%pre

разница будет в результате когда это развернется

разница будет в результате когда это развернется

Если у тебя стейтлессный микросервис: Package { servicename: } -> File { configname: } ~> Service { servicename: } То, в общем-то тоже пофиг :)

нет не пофиг если ты чуточку ошибёшься в путях и пришибёшь всё

Его можно апгрейдить, даунгрейдить, канареечно и пр...

у тебя пакеты воздействуют на одну систему беспорядочно меняя её стейт

ни о каком стейтлесе тут речи не идёт

Если у тебя стейтлессный микросервис: Package { servicename: } -> File { configname: } ~> Service { servicename: } То, в общем-то тоже пофиг :)

У меня patroni на 2 сервака и без инета.

нет не пофиг если ты чуточку ошибёшься в путях и пришибёшь всё

Чего все-то? Корявый контейнер пришибет общий волюм с не меньшим успехом

а зачем тебе оббщий вольюм в аппе ?

Зависимости у пакета локальные же (статические) - pip install --target ${package}/lib --isolated -r req.txt и доставляются прямо в пакете, никаких рекурсивных даун/ап-грейдов, лишь один пакет

Только в приложуху не забыть воткнуть sys.path.insert с путем до lib/

а зачем тебе оббщий вольюм в аппе ?

Я подумал, что ты про нарушение целостности общих данных кривым релизом

не не не

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

или ещё хуже, менеджишь венвы пакетом

это может привести к тому, что ты своим спеком покрошишь что то чужое

это может привести к тому, что ты своим спеком покрошишь что то чужое

юнит-тесты никто не отменял, нарукожопить в докерфайле тоже можно

ещё больше сложности )

и так 100500 строк кода в инфре чтобы развернуть пип пакет и поставить его ещё и тесты сверху )

Не, все проще же, изолированное окружение

В пакет собирается только основное приложение, в процессе сборки пип дотаскивает внутрь пакета зависимости

и тут приходит РКН и твой ап в момент деплоя не ставится да ? )

и тут приходит РКН и твой ап в момент деплоя не ставится да ? )

Всегда нужны кэши для пипа, контейнер тоже не соберется, если что-нибудь в процессе выполнения докерфайла сфейлится

тока мы это узнаем на момент билда а не деплоя

и проще сделать кеши \ прокси для билд фермы, а не для всех мест куда деплоим

rpmbuild тоже сфейлится, если что-то вернет ему код != 0

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

Зависимости у пакета локальные же (статические) - pip install --target ${package}/lib --isolated -r req.txt и доставляются прямо в пакете, никаких рекурсивных даун/ап-грейдов, лишь один пакет

так это же на момент инстала а не билда

rpm пакет один, в нем приложуха и все её питонящие зависимости

так это же на момент инстала а не билда

Билда

Формируется структура вида: %{_bindir}/my_app.py %{_libdir}/my_app/ - сюда пихаются питонящие дела, которые пипом поставились во время сборки "локально" (не в /lib/python билдера, а в билд-директорию/lib пакета)

Вот нотариально заверенный скриншот (код в закрытой инфре без интернетов)

лол

всё понятно и удобно)))

у меня такая же херь в виде грувишных билдов для дженкинса

Это издержки закрытой инфры, я не могу сделать pip install --update pip

Т.е. у билдера нет рута

это издержки сборки пакетов )

это издержки сборки пакетов )

Издержки pci-dss, пакеты нужно подписывать, а отдельный стейдж с другим контейнером для этого не стали делать (слишком много времени съедает сборка)

ну про это мы уже говорили )

Формируется структура вида: %{_bindir}/my_app.py %{_libdir}/my_app/ - сюда пихаются питонящие дела, которые пипом поставились во время сборки "локально" (не в /lib/python билдера, а в билд-директорию/lib пакета)

А приложение как поймёт что библиотеки в этой папке, а не в системной?

А приложение как поймёт что библиотеки в этой папке, а не в системной?

Нет, ему нужно это указать в sys.path

Причем, нужно аншифт массива делать, иначе оно будет сначала в системных директориях искать

Спасибо всем за советы. Пойду делать rpm.

привет, а есть кто провиженит AWS из папета ?

провиженим запущенные терраформом в авс инстансы

А в рамках Puppet::Parser::Functions::newfunction можно добраться до каталога?

Или хотеть проитерировать коллектор - это хотеть странного?

А кто как решает ситуацию puppet & yum update?

Я пока не придумал ничего лучше, чем написать свой package-провайдер на базе yum.rb с подготовкой лок-листа в секции prefetch

А кто как решает ситуацию puppet & yum update?

Метапакет, у него в зависимостях все rpm инстанса. Номер метапакета = номер спринта

После спринта обновляется

Номер в переменной

Метапакет билдится моим питон-скриптом

Я пока не придумал ничего лучше, чем написать свой package-провайдер на базе yum.rb с подготовкой лок-листа в секции prefetch

А какую задачу это решает?

А какую задачу это решает?

Проблема: yum update -y Для случаев любых пакетов с конкретной версией в конфигурации

Метапакетов не наготовишься :(

+ это усложняет ci

Метапакетов не наготовишься :(

А если автоматически?

Прописали версии пакетов, выкатили с помощью ci,

Запустили тесты

Если сломалось - алерт в мониторинг

Прописали версии пакетов, выкатили с помощью ci,

Вот про это усложнение ci я и говорил: нужно готовить для разных серверов разные метапакеты и учитывать наличие и изменения в этих пакетах в конфигурациях

Не, просто автоматически добавляешь последние версии. Если сломалось, разбираешься

Модифицированный провайдер пакетов, который готовит versionlock.list перед началом применения конфигурации, в этом плане лучше

Правда, я был ограничен во времени и сделать хорошо не успелось (уволился), чтобы после установки пакета делался yum-q с последующей корректировкой версии в лок-листе. Это позволило бы избежать необходимости прописывать релизную часть версии пакета (локер это требует) и создать возможность управления вайлдкардами в версиях

https://pastecode.xyz/view/946db026 Вот какое-то такое

Вы ненавидете людей просто

Коллеги, на новой работе есть puppet, подскажите что по нему почитать можно, чтоб быстро въехать?

Мне их официальный бесплатный курс неплохо помог осознать что происходит https://learn.puppet.com/category/self-paced-training

всем привет, подскажите такую вещь: нужно установить локальный пакет nginx(с репы не подходит, билдился с поддержкой lua), у него ес-но есть зависимости. rpm зависимости не решает. yum первый раз выполняется без проблем но при повторном вызове паппет агента возвращает "Nothing to do" что паппет принимает за ошибку и дальнейшие изменения не накатывает. как это побороть?

package { 'web_nginx': ensure => 'installed', # name => '/tmp/nginx-1.10.2-1.el6.x86_64.rpm', name => 'nginx', provider => 'rpm', source => '/tmp/nginx-1.10.2-1.el6.x86_64.rpm', require => File['/tmp/nginx-1.10.2-1.el6.x86_64.rpm'], }

для yum name менял местами

иначе тянет из реп

А что говорит rpm -q nginx ?

Он не может найти пакет name=>nginx среди установленных и выполняет повторную установку файла /tmp/nginx...rpm

Но пакет уже установлен и rpm вываливается с ошибкой nothin to do

нет, он не может установить только при первом запуске, с ключем -q не пробовал

Надо узнать название пакета

Может быть, еще и версию вписать

yum list installed |grep nginx

не, главная боль при чистой установке : yum устанавливает пакет, но при повторном вызове (раз в N промежуток контроль состояния) вываливается rpm не может установить из-за зависимостей, но если пакет установлен повторные вызовы проходят гладко

Т.е. наоборот?

+++

Так это: package { ["new", "nginx", "lua", "requirements"]: ensure => present } -> package { "web_nginx": ... }

понаставють стрелочек своих !